
第一個選項是使用像 Baileys 這樣的非官方函式庫,它透過WhatsApp 經逆向工程分析出的網路協定進行連線。這種方法雖然可行——但終究會失效。它違反了WhatsApp服務條款,每當WhatsApp 其客戶端WhatsApp 就會失效,甚至可能導致開發者的個人電話號碼遭到永久封禁。對於任何認真想要推出產品的人來說,這都是不可接受的。
第二種選擇是官方途徑:透過 Meta 申請自己的WhatsApp API 存取權限,完成為期數天的企業驗證流程,自行管理 webhook 基礎架構,並安全地處理 Meta Cloud API 憑證。對於擁有專職開發人員的企業團隊來說,這尚屬可行;但對於正在開發 AI 代理程式原型的獨立開發者而言,這無異於一道高牆。
兩者之間從未有過一條快速、正式且無阻礙的通道。我們開闢了一條。
無需完成 Meta Business 驗證。無需配置 API 憑證。無需架設 webhook 伺服器。imBee 負責運作已驗證的WhatsApp 帳號(WABA)、路由基礎架構以及安全層。您的本地 OpenClaw 實例透過一次性 QR 碼流程與 imBee 的號碼配對,此後發送至該號碼的每則訊息,都將在 500 毫秒內轉發至您的客服人員。
此外掛程式透過 ClawHub 註冊表和 npm 進行發行。只需一筆指令即可安裝:
openclaw 外掛程式 安裝whatsapp
接著,它便會作為一級通道選項出現在標準 新增 openclaw 頻道 設定精靈,以及您已安裝的其他頻道。
新增 openclaw 頻道, 該外掛程式會在頻道選單中顯示為「官方WhatsApp (透過 imBee)」。CLAW-A3F9-Z7KL) 並將其連同每個實例的 API 金鑰一併傳回。wa.me 深度連結。兩者均包含 imBee 已驗證的WhatsApp 號碼以及您的專屬配對碼。配對代碼僅限使用一次,有效期為 10 分鐘,且由 36⁸ ≈ 2.8 兆種組合中產生。一旦您的執行個體完成配對,該代碼即失效,且絕不會儲存在您的裝置上。
當WhatsApp 傳送到 imBee 的已驗證號碼時,我們的路由伺服器會識別已配對的本地實例,並透過持久的 WebSocket 連線在 500 毫秒內轉發完整的事件。對於文字訊息,您的客服人員還會自動向用戶發送輸入提示——因此當客服人員處理請求時,客戶會看到「正在輸入…」的提示。
支援的傳入訊息類型:
外發回覆會透過單一 REST 呼叫傳送至 imBee 的路由伺服器,該伺服器隨後會透過WhatsApp API 進行傳送。您的客服人員可以發送文字或多媒體內容(包括圖片、影片、音訊或文件),而無需直接接觸 Meta 或 360dialog。
您本地的外掛程式與 imBee 路由伺服器之間的每項連線均採用 TLS 1.2 或更高版本。WebSocket 連線則採用 wss://. 您的本地實例會透過配對過程中生成的、專屬該實例的 Bearer 憑證進行驗證,該憑證會透過 SecretRef 表面 — 絕不會以純文字形式儲存在磁碟上。
每次傳入事件都會驗證 Webhook 的完整性:針對 Meta Cloud API 後端,會使用 Meta 的應用程式密鑰進行 HMAC-SHA256 驗證,或 Ocp-Apim-訂閱金鑰 360dialog 後端的驗證。任何未能通過這些檢查的請求都會被拒絕,並顯示 403 禁止存取.
最重要的是:訊息內容絕不會永久儲存於 imBee 的路由伺服器上。資料包會在記憶體中處理,並立即轉發至您的本地實例。我們唯一會永久儲存的資料是路由元資料——包括電話號碼、WABA 號碼、實例 ID 以及連線狀態——這些資料對於將未來的訊息傳送給正確的代理程式至關重要。
這正是 imBee 為金融服務、醫療保健及物流領域的企業客戶所提供的安全防護措施。此外掛程式在設計上繼承了這項特性。
對於在 OpenClaw 上進行開發的開發者,請透過 ClawHub 或 npm 進行安裝:
openclaw 外掛程式 安裝whatsapp
接著執行:
新增 openclaw 頻道
請從選單中選擇「官方WhatsApp (透過 imBee)」,用手機掃描 QR 碼,並從WhatsApp 傳送配對碼。設定就完成啦。
對於WhatsApp 更廣泛的人工智慧代理策略WhatsApp 評估,並想了解 imBee 的 BSP 級基礎設施如何擴展至專用號碼、多代理路由、廣播活動以及 imBee 全通路平台的其他功能之企業—— 立即預約演示 與我們的團隊。我們協助亞太地區的企業,以大規模且安全的方式將人工智慧融入客戶對話中。
OpenClaw 的官方WhatsApp 現已透過ClawHub及GitHub 儲存庫提供下載。