用 Flowise Chatflow 回复 WhatsApp 消息

为什么 Flowise 前面需要一个接收器？

因为 Meta 的 Webhook 与 Flowise 的 API 使用不同的数据结构。Meta 验证目标地址时会发送一个 GET 请求，必须把 hub.challenge 作为原始响应体返回，随后以嵌套的 JSON POST 投递每条消息。Flowise 的 Prediction API 则要求向 /api/v1/prediction/ 加上流程 ID 发送 POST 请求，并带有 question 字段。双方都不会迁就对方，所以需要接收器来转换。

接收器可以是 n8n 的 Webhook 节点、Python 或 Node 中的一个路由，或任何无服务器函数。它负责应答验证用的 GET 请求，检查放在 Webhook URL 中的一长串随机密钥，立即向 Meta 返回 200，然后再处理实际工作。URL 中的密钥是这里唯一可行的身份验证方式：Meta 使用 Tech Provider 应用的密钥为投递签名，而该密钥从不共享，因此您这一侧无法验证 X-Hub-Signature-256 请求头。

接收器应如何调用 Prediction API？

把客户的文本作为 question，把客户的 WhatsApp 号码作为会话。Flowise 在每次请求中都接受 overrideConfig，其中的 sessionId 能让记忆节点为每个人保留独立的对话，而不是把所有人混在同一个会话里。Webhook 负载中发送者的号码是稳定而自然的键。

如果 Chatflow 设有 API 密钥保护，接收器需要把它作为 Bearer 令牌发送。除非接收器能够拼接数据流，否则请把 streaming 设为 false，因为 WhatsApp 一次投递一条完整的消息，而不是逐个 token 显示。

答复会以 Cloud API 文本消息的形式，从同一号码发出。在客户消息开启的 24 小时窗口内，这是免费且允许的。流程之后想发送的任何内容，例如提醒，都必须使用已批准的消息模板。

POST https://your-flowise-host/api/v1/prediction/<flow-id>
Authorization: Bearer <flowise-api-key>
Content-Type: application/json

{
  "question": "do you have anything friday?",
  "streaming": false,
  "overrideConfig": { "sessionId": "14155550188" }
}

Flowise 智能体可以使用 EasyCoexistence MCP 服务器吗？

目前不行。Flowise 的 Custom MCP 通过 URL 和一组请求头连接 Streamable HTTP 服务器，通常使用保存在 Flowise 变量中的静态 Bearer 令牌。EasyCoexistence MCP 服务器采用 OAuth 验证，需要在浏览器中登录，并使用它自行签发的令牌，因此没有可以放进请求头的静态密钥。

可行的分工是：由流程决定，由接收器发送。流程返回要说的文本；如果客户已超过一天没有回复，则返回某个消息模板的名称。接收器再用该号码的访问令牌调用 Cloud API。这样访问令牌就不会存放在 Flowise 内部，而 24 小时规则由代码通过检查联系人最近一次发言的时间来执行，不必交给可能忘记它的模型。

无论发送采用哪种方式，收到的消息仍然只能通过 Webhook 到达。

常见错误

• 遗漏 sessionId。所有客户会共用同一份记忆，一个人的资料可能出现在另一个人的答复中。
• 等 Flowise 处理完才答复 Meta。缓慢的 200 响应会被重试，同一条消息因此被处理两次。
• 让流程在一天后发送自由文本。窗口之外，Meta 会以错误代码 131047 拒绝。

常见问题

继续阅读