一、自动回复的核心是闭环

自动回复看着简单，实际是一条“接收—判断—回复”的闭环链路。三个环节任一断裂，整条链路就跑不通。

二、Webhook 接收：消息进来的入口

Eyun 通过 Webhook 把消息事件推送到你配置的回调地址，覆盖消息、好友、群、状态四类事件。回调超时设为 5 秒，失败会重试 3 次，所以服务端响应要快，别在回调里干重活。常见的坑是回调地址不通或返回非 200，导致消息反复重推甚至丢失。

三、逻辑判断：决定回什么

拿到消息后，先解析 JSON 拿到 fromId、content、msgType 等字段，再按业务规则匹配回复内容。这一步要处理关键词命中、上下文记忆、群消息与私聊的分流。判断逻辑里别做耗时操作，否则容易拖垮回调响应，把重试机制逼出来。

四、sendText 回复：把结果发出去

判断完调 sendText 下发回复，wId 要和接收时一致，toId 取消息来源的 fromId。这里要注意 Token 有效性，1002 过期后整个实例都会停摆。高频回复要控速，1004 限频一旦触发，后续消息会被直接拒掉。

五、三环节对比

三个环节串起来看，差异和风险点会更清晰。Webhook 偏稳定性，逻辑判断偏设计，回复偏控速。

六、闭环调用示例

以收到一条文本消息、自动生成工单号并回复为例，请求体如下。实际场景里 content 由判断逻辑产出。

{
  "wId": "instance_001",
  "toId": "wxid_from_abc",
  "content": "收到您的问题，工单号 #20240904 已生成"
}

上面是收到消息后调 sendText 回复的最小请求体，wId 对应接收实例，toId 取回调里的 fromId 即可。整个闭环跑通后，再叠加业务规则、上下文记忆、限流策略才有意义。更多回调字段可参考 Eyun 文档。