用 Dify 應用程式回覆 WhatsApp 訊息

Meta 可以直接把 WhatsApp 訊息送到 Dify 嗎？

無法完成驗證握手。Meta 在傳送任何內容之前，會先以 GET 請求呼叫目的地，並期望回應本文原樣帶回 hub.challenge 的值。Dify 的 Webhook Trigger 每個觸發器只接受一種 HTTP 方法，其文件亦指出非 JSON 的回應本文會自動轉換成 JSON，所以 OK 會變成一個訊息物件回來。challenge 永遠無法原樣回傳，Meta 也就不會開始傳送訊息。

因此前面需要一個小型元件。n8n 的 Webhook 節點、以 Python 或 Node 寫的路由，或無伺服器函數，都可以負責回應 GET、接收 POST，並把文字交給 Dify。Webhook URL 中那段長長的隨機密鑰也在這個接收器檢查，因為 X-Hub-Signature-256 標頭是以 Tech Provider 的應用程式密鑰簽署，客戶本身無法驗證。

接收器如何與 Dify 應用程式溝通？

只需呼叫一次 Dify 的 Service API：POST /chat-messages，並以該應用程式的 API 金鑰驗證。內容帶有 query（客戶的文字）和 user（由您自訂的識別碼）。請以發送者的 WhatsApp 號碼作為 user，並保留 Dify 回傳的 conversation_id，讓同一個人的下一則訊息延續同一段對話。

response_mode 十分重要。blocking 會在答案完成後才回傳，而 Dify 的文件警告，在 Dify Cloud 上，較長的生成內容可能被邊緣代理中斷。Agent 應用程式只支援 streaming，對它發出 blocking 請求會以 400 失敗。最穩妥的做法是由接收器讀取串流，最後只發送一則 WhatsApp 訊息。

回覆隨後以 Cloud API 文字訊息送到同一個號碼。在客戶訊息開啟的 24 小時視窗內，這類訊息免費。

MCP 伺服器在 Dify 內有什麼用途？

它讓 Dify 的 Agent 無需您逐一串接每個呼叫，就能直接操作該號碼。Dify 透過 HTTP 連接 MCP 伺服器，並預設以 OAuth 動態客戶端註冊向伺服器登記，而 EasyCoexistence MCP 伺服器正支援這種方式。在「工具」下加入它，登入一次，Agent 就能使用這些工具：列出號碼、檢查號碼的健康狀態、傳送訊息、傳送已核准的訊息範本、讀取訊息範本狀態。

主動跟進正適合這樣做：隔天跟進的 Dify 工作流程必須使用 send_template，因為在時限以外傳送自由格式訊息會回傳錯誤 131047，工具說明也已向模型註明這點。

MCP 做不到的，是在客戶來訊時喚醒 Dify。此協定屬於請求與回應模式，所以來訊仍須經由 Webhook 和前面的接收器進入。

常見錯誤

• 把 Dify Webhook Trigger 的 URL 當作 Webhook 目的地。challenge 會被包成 JSON 回來，Meta 永遠無法驗證該端點。
• 對 Dify Agent 應用程式發出 blocking 請求。Agent 應用程式只支援 streaming，呼叫會以 400 失敗。
• 每則訊息都使用新的 user 值。Dify 的對話以 user 為範圍，所以每則訊息都會開始一段沒有記憶的新對話。

常見問題

繼續閱讀