用 Dify 应用回复 WhatsApp 消息

Meta 能直接把 WhatsApp 消息发给 Dify 吗？

无法完成握手，所以不行。Meta 在投递任何内容之前，会先向目标地址发送 GET 请求，并期望响应正文原样返回 hub.challenge 的值。Dify 的 Webhook Trigger 每个触发器只接受一种 HTTP 方法，其文档说明非 JSON 的响应正文会被自动转换为 JSON，于是 OK 会变成一个消息对象返回。验证值永远无法原样回显，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 智能体无需您逐个接线，就能直接操作该号码。Dify 通过 HTTP 连接 MCP 服务器，并默认通过 OAuth 动态客户端注册向服务器登记，而 EasyCoexistence MCP 服务器正支持这一方式。在“工具”下添加它并登录一次，智能体就能使用这些工具：列出号码、检查号码的连接状态、发送消息、发送已批准的模板、读取模板状态。

主动联系正适合放在这里：次日跟进的 Dify 工作流必须使用 send_template，因为窗口之外发送自由文本会返回错误 131047，工具说明中也已向模型写明这一点。

MCP 做不到的是在客户来信时唤醒 Dify。该协议是请求与响应模式，所以收到的消息仍然要经由 Webhook 和前面的接收端到达。

常见错误

• 把 Dify Webhook Trigger 的 URL 用作 Webhook 目标地址。验证值会被包装成 JSON 返回，Meta 永远无法验证该端点。
• 向 Dify 的 Agent 应用发送 blocking 请求。Agent 应用只支持 streaming，调用会返回 400 错误。
• 每条消息都使用新的 user 值。Dify 按 user 划分对话，因此每条消息都会开启一段没有记忆的新对话。

常见问题

继续阅读