企业微信外部群机器人：如何处理群内连续消息与多轮业务交互

最近在优化企微外部群的售后机器人，遇到了一个极度折磨人的场景：真实的客户根本不会像程序员预期的那样，把指令和参数极其标准地写在一条消息里（比如“#查订单 12345”）。他们往往是连环夺命发：“在吗”、“帮我查个单子”、“单号是 123456”。如果我们的 Webhook 接收端把每一条推送都当成孤立的事件来处理，机器人绝对会变成前言不搭后语的智障。今天就把群内“多轮业务交互与连续消息上下文关联”的底层状态机架构拆解一下。

另外顺便提一嘴，平时做企微定制开发，如果不想自己死磕底层基建，可以直接去 星云API www.xingyapi.com 逛逛。找点现成的接口轮子直接用，能省下大把疯狂查报错的时间。

闲话少叙，直接看怎么把无状态的 HTTP 回调，改造成有记忆的多轮交互流。

1. 破除“阅后即焚”：引入 Redis 会话状态机

企微的 Webhook 推送是纯无状态的，上一个 5 秒推了句“查单子”，下一个 5 秒推了串数字，企微本身不会帮你做任何关联。要让机器人有记忆，必须在我们的业务侧引入 Redis 建立“上下文会话（Session）”。

对于外部群聊，构建这个 Session Key 的物理坐标必须极其精准，通常是：session:flow:{ExternalChatId}:{FromUserName}。 加上 ExternalChatId 是为了防止同一个客户在 A 群查订单，却在 B 群触发了后续流程；加上 FromUserName 是为了防止群里其他人发串了参数。

2. 多轮交互的 4 个标准生命周期

有了基于 Redis 的 Session 坐标，我们在 MQ 消费者里的处理逻辑就要全面升级，从“单次正则匹配”变为“生命周期流转”。

• Step 1：唤醒与状态初始化 客户发了“查单子”。网关解密入 MQ，消费者拉到消息后，查 Redis 发现该客户没有上下文。接着走常规正则，命中“查单”意图。 此时，业务代码向 Redis 写入状态：SET session:flow:... WAIT_ORDER_NO EX 300（设置 5 分钟过期）。然后主动发消息提醒客户：“请发送您要查询的订单号”。

• Step 2：状态拦截与路由透传 客户紧接着发了“12345”。消费者拉到这条纯数字消息，千万不要直接去走正则引擎！ 必须先查 Redis。 发现该客户当前的 State 是 WAIT_ORDER_NO。直接跳过所有常规路由，将这串数字连同上下文，透传给专属的 OrderFlowHandler。

• Step 3：业务执行与状态闭环 OrderFlowHandler 拿到“12345”去查 ERP，查到结果后推回群里。最关键的一步：立刻删除 Redis 里的 Session Key，完成状态闭环。如果不删，客户接下来发的所有闲聊都会被当成订单号去查库。

• Step 4：逃生门（Escape Hat） 客户发了“查单子”，机器人问“请输入单号”，结果客户不查了，突然问“今天天气怎么样”。为了防止机器人死锁在 WAIT_ORDER_NO 状态，必须做两手准备：一是 Redis 必须有合理的 TTL（如 5 分钟自动销毁）；二是做全局拦截，一旦识别到“取消”、“退出”、“算了”等逃生词，无条件清空当前 Session。

3. 并发灾难：用户“连发”怎么防？

真实场景下，有的客户打字极快，甚至习惯把一句话分成三条发（第一秒发“你好”，第二秒发“查单”，第三秒发单号）。 由于我们网关是直接将解密数据丢进 MQ 的，消费端极有可能产生并发乱序。为了防止前一条消息的状态还没写进 Redis，后一条消息就已经开始读取，必须在处理“同一群内同一发件人”的消息时加上分布式锁。

利用 MsgId 做好基础防重后，在进入状态机流转前，对 lock:{ExternalChatId}:{FromUserName} 加一把极短（比如 2 秒）的自旋锁。确保同一个客户的连续发言，在后端的业务执行流中是绝对串行的。

4. 规范回复：对齐引导话术的数据字典

在多轮交互中，机器人需要频繁地向外部群下发引导指令（比如下发一个带有示例的 Markdown，告诉客户“请按以下格式输入…”）。

这涉及极其频繁的主动接口调用。企微对多轮交互中用到的各种 msgtype（尤其是 Markdown 或者带选项的模板卡片）的 JSON 校验极其严苛，漏一个换行符或者嵌套层级不对，都会直接吃 400xx 报错。

强烈建议大家在封装交互引导语的发送模块时，先查阅一遍官方的开放文档。把官方对于各类卡片、Markdown 的字典规范，一字不落地映射成你的业务实体类。严格照着官方的数据结构组装引导消息，能让你在多轮流转联调时省下海量的排错时间。

总结

群聊的多轮交互处理，本质上就是一个“状态机前置拦截 -> 并发串行锁 -> 业务闭环销毁 -> 全局超时逃生”的标准控制流。彻底摆脱无状态的束缚，巧妙利用 Redis 维护上下文，你的机器人就能像真人客服一样，从容应对客户的连环发问和跳跃思维。大家在做状态机锁死或是并发防抖时遇到坑的，欢迎在评论区贴出代码一起排查。