昨晚跟朋友吃饭，他掏出手机给我看客服群吐槽：

「你们机器人是不是下班了？」
「问了三遍没人理。」
「刚才明明还在回。」

他一脸委屈：「代码没动，服务器也没挂，微信也在线，怎么就哑巴了？」

我让他打开回调服务日志。果然——一堆超时。

---

这事儿不玄乎。个人微信自动化那套，消息不是你去「拉」的，是平台往你服务器「推」的。推过来之后，规矩很死：你得在大概三秒内点头说「收到了」。

点头不等于把活干完。
点头只等于：我接着了，后面慢慢处理。

很多人偏要把「想明白怎么回、调大模型、查订单、拼话术、再发出去」全塞进这三秒。结果呢？你还在慢悠悠思考，对面已经当你死了，这次推送直接扔掉。

用户侧的观感就一个字：冷场。

---

为啥你本地测好好的？

因为你测试时消息少、机器快、模型秒回。一到晚上高峰，模型排队两秒，数据库卡一下，三秒就没了。丢的那几条，往往刚好是最着急的客户。

还有个坑更隐蔽：同一条消息可能推不止一次。服务重启、历史同步、失败重试，都可能让你「回两遍」。不回显得死，回两遍显得傻。正确做法是记个号：这条处理过了，重复来的直接忽略。

手机上你自己发的消息，有时也会推到回调里。你要是不管三七二十一见消息就回，机器人可能跟自己聊起来，越聊越热闹，客户看得一脸懵。

---

所以你要是遇到「在线但不回」，别先骂大模型，也别先重启微信。按这个顺序查：

1. 回调地址还是不是公网能访问

2. 你的接口是不是三秒内就返回了（别在里面干重活）

3. 有没有把消息丢进队列，让后台慢慢回

4. 有没有按消息唯一号去重

把「接收」和「思考」拆开，机器人就稳多了。

说白了：不是它不想回，是你让它在电梯门关上之前背完一篇作文。门关了，作文写得再好也没人听得到。