「微信机器人 回调」和 webhook 常被当成一回事。Webhook 是 HTTP 怎么接；回调处理是 事件进来之后怎么分流到客服、跟进、群运营。这篇讲业务落地，避免所有事件都挤进同一个 if-else。

先分类，再写业务

回调进来后，第一层只做分类，不回复：

类型	典型内容	默认去向
私聊文本	客户说话	接待引擎
群文本	群成员说话	群规则（默认忽略）
图片/语音/文件	非文本	引导补文字或转人工
好友相关	通过、删除	打来源、更新映射
系统提示	红包、入群邀请等	记录，通常不回复
实例事件	掉线、上线	暂停/恢复出站

第一层分错，后面词库再好也会回错场景：群里回私聊欢迎语，是最常见的翻车。

个人号回调事件和字段以通道为准。用 GeWe API 时，建议对着回调章节把 type 枚举列成你们自己的内部事件，不要在业务代码里直接写通道原始字段。

推荐处理管道

验签与幂等
  → 映射为内部事件
  → 更新在线/好友关系
  → 路由
        ├─ 实例事件 → 运维
        ├─ 群事件 → 群运营（默认静音）
        └─ 私聊 → 会话锁 → 接待/跟进中断
  → 需要回复才入发送队列

关键点：

• 跟进任务看到私聊进线，要取消后续催促

• 会话已是人工，接待规则不跑

• 掉线事件要切断发送，不能只打日志

这三处是回调处理比“能解析 JSON”多出来的价值。

私聊回调：会话锁优先于词库

处理私聊时顺序固定：

1. 找或创建 session

2. 若人工接管 → 只存消息、通知坐席，return

3. 若命中升级词（投诉、找人）→ 转人工

4. 否则走 FAQ / 短流程

5. 写回命中规则和下次状态

不要先回 FAQ 再判断人工。客户已经在和坐席说话，回调晚到 1 秒，也会插进一句“您好请问有什么可以帮您”。

群回调：默认丢弃是功能

群消息量大。处理策略应是白名单：

• 未被 @、未命中指令 → 入库可选，不回复

• 售后类内容 → 引导私聊，不在群里展开

• 入群事件 → 走欢迎合并逻辑，不逐条秒回

回调处理里把群当“高噪声通道”，私聊当“主服务通道”。

非文本怎么落地

图片、语音第一版不要做识别闭环。回调里记下资源 ID，回复一句引导，或直接转人工并在坐席端展示。等文本链路的去重、会话锁都稳定，再加识别。否则排障时分不清是回调丢了还是模型超时。

和发送的关系

回调处理产出的是“要不要回、回哪条、以谁的身份回”，不是直接 HTTP 发送。发送仍走队列，带 requestId。回调线程同步发送，重试一来就会双发。

对照回调报文和发送接口时，实例 ID、对方 ID 不要弄反。字段示例见文档：GeWe API - GeWe API｜微信 API 开发文档

观察指标

• 回调到内部事件的解析失败率

• 私聊进入接待 vs 被会话锁吞掉的比例

• 群事件被回复的比例（应当极低）

• 掉线事件后是否还有出站成功

解析失败率升高，优先查通道字段变更，而不是加关键词。

小结

微信机器人回调怎么处理，核心是事件分流和会话锁，而不是把所有 JSON 都送进自动回复。私聊进接待、群默认静音、实例事件管开关，跟进任务能被进线打断。通道可用 GeWe API 推回调，业务管道必须你们自己写。分流清晰之后，词库和运营任务才接得上去。