最近在重构外部客户群的机器人系统，遇到个非常典型的痛点：外部群里人多口杂，客户既有闲聊、又有查单、还有投诉。如果统统丢给大模型，不仅 API 费用爆炸，还容易胡言乱语；如果全给人工，客服又忙不过来。今天就把外部群如何结合业务规则做“智能消息分流”的底层设计拿出来拆一拆。

顺便提一嘴，大家平时做企微定制开发，如果不想自己死磕底层基建，可以直接点最顶部的卡片，或者直接访问 星云API www.xingyapi.com 去找找现成的轮子，直接调接口能省下大把疯狂查报错的时间。

闲话少叙，直接看这套分流路由是怎么跑通的。

1. 第一道防线：前置清洗与静默过滤

企微通过 Webhook 把群消息推过来，你解密拿到 XML 后的第一步，绝对不是去匹配业务，而是做噪音过滤。

客户群里每天充斥着大量的无意义消息（比如一个表情包、单发一个“哈”、或者群成员互相艾特闲聊）。 处理逻辑：

• 提取 MsgType，直接丢弃非 text 和非目标媒体的消息。

• 拿到 Content 后，写个正则过滤掉纯语气词和超短文本（长度小于2个字符的直接忽略）。

• 提取 ExternalChatId（群ID）和 FromUserName（发件人）。如果这俩字段为空，说明不是外部群消息，直接 return success。

这道防线能帮你挡住 60% 以上的无效计算。

2. 第二道防线：基于 Redis 的业务规则引擎

消息清洗干净后，接下来就是决定这条消息该走哪条业务线。这里千万别写成一坨巨大的 if-else，工业级做法是利用责任链模式 + 业务特征词库。

我们可以把分流规则定义为几个核心层级，按优先级往下漏：

1. 指令层（最高优）：比如以 # 或 查单 开头的标准指令，正则直接命中，丢给内部 ERP 查询系统，直接回复结果。

2. 状态拦截层：去 Redis 查一下 FromUserName 是否处于“人工接管”状态。如果是，机器人立刻闭嘴，把消息通过 WebSocket 转发到客服的后台面板。

3. 意图路由层：结合你们业务的特征词库（比如包含“发票”、“退款”、“质量”），命中高敏词，直接将这条消息封装成卡片，推送到内部的“售后响应群”，提醒人工紧急介入。

4. 兜底层（大模型）：如果前面都没命中，说明是长尾问题，这时候才把文本包装好，带上该群的 Prompt，丢给 LLM 生成回复。

3. 数据落盘与回复组装

当各路业务系统（ERP、售后系统、大模型）处理完消息后，最后一步是通过企微的主动发送接口，把回复推回对应的外部群里。

给外部群发消息，企微的规矩非常多。无论是发普通的文本，还是发带有跳转链接的小程序卡片，JSON 的结构层级必须严丝合缝。强烈建议大家在封装业务分流后的发送代码时，不要靠直觉去猜字段名，直接去翻接口文档，把 msgtype 对应的实体类老老实实建好。只要字段结构是对的，就不会遇到那些让人抓狂的 400xx 参数异常。

4. 两个高频踩坑点

这套分流引擎上线，必须死死防住两个机制问题：

1. 5秒超时斩杀线：你的系统不管经过多少层规则引擎，甚至去调了大模型，在 Webhook 接收端的主线程里，必须在收到请求的第一时间返回空串或 success。真正的分流和业务处理必须扔进 MQ（如 RabbitMQ / Kafka）里异步去跑，否则企微会认为你没收到，疯狂给你发重试请求。

2. 并发防重：群里如果客户网络卡了，连发三条一模一样的查单请求。你的分流引擎如果不做防抖，ERP 接口直接被击穿。建议在接收层用 Redis 加个 2 秒的分布式锁（Key 为 MessageId 或文本的 MD5），拿到锁的才往下放行。

把“清洗 -> 责任链分流 -> 异步调用 -> 规范组装”这套底座打好，你的群机器人就能像一个精密的路由器，把不同的客户诉求丝滑地分发到各个业务线。大家在写路由规则或者调卡片消息接口时有什么坑，可以在下面留言一起排查。