只接到「能回消息」自动化还只做了一半。完整一点的链路是听得到会话还能让这个微信号在账户侧继续动——同步通讯录、加好友、打标签、建群——并始终用同一个设备身份串起来。可以按阶段接接收。回调进队识别意图咨询、加好友意愿、带单号的查询等。约 3 秒内先返回重活进 Worker。账户。需要时拉通讯录同意或发起好友申请更新备注或标签。标签更新多为全量覆盖只传新标签会清掉旧的合并后再提交。动作。文本回复或通知需要则建群、拉人。闭环。结果回写 CRM失败进死信掉线先恢复原设备再重放不要换新设备 ID 把映射打穿。消息接收解决「听得到」账户自动化解决「这个号还能不能代表业务继续动」。多号时每一步都带正确设备禁止全局默认号。通讯录列表和「聊天里出现过的所有群」不是同一份东西未存通讯录的群常常要靠群消息回调再补入库。加好友通常是先搜索再处理申请和「拉列表」不要当成同一次任务硬拧在一起。建议骨架回调 → 快返回 → 队列 → 意图分流仅回 / 仅账户 / 回账户 → 各动作幂等键分开 → 统一用事件里的设备身份咨询类可以只回一条加好友类要过滤、频控、幂等。主动类通知状态变更可以不走回调由业务事件触发与自动回拆账。别踩的坑只接发送不接回调账户动作没有触发源。回调超时后面账户动作全无触发。登录后乱换设备 ID客户/群映射全废。加好友无过滤、无频控、无幂等。标签只传新 ID清掉旧标签。接收与账户动作堵在同一同步链路上互相拖垮。搜索与添加之间丢关键凭证或串到别的号上执行。把系统号、公众号当客户做账户动作。怎么验收新消息进队可观测咨询类只回一条加好友类同一申请不点两次。断线告警恢复原设备后队列可续跑。通讯录同步后过滤系统号打标签前后旧标签仍在。规则/知识故意清空时咨询走转人工而不是瞎编。账户动作失败进死信可重放不丢、不狂重试。