最近在重构外部客户群的机器人系统遇到个非常典型的痛点外部群里人多口杂客户既有闲聊、又有查单、还有投诉。如果统统丢给大模型不仅 API 费用爆炸还容易胡言乱语如果全给人工客服又忙不过来。今天就把外部群如何结合业务规则做“智能消息分流”的底层设计拿出来拆一拆。顺便提一嘴大家平时做企微定制开发如果不想自己死磕底层基建可以直接点最顶部的卡片或者直接访问 星云API www.xingyapi.com 去找找现成的轮子直接调接口能省下大把疯狂查报错的时间。闲话少叙直接看这套分流路由是怎么跑通的。1. 第一道防线前置清洗与静默过滤企微通过 Webhook 把群消息推过来你解密拿到 XML 后的第一步绝对不是去匹配业务而是做噪音过滤。客户群里每天充斥着大量的无意义消息比如一个表情包、单发一个“哈”、或者群成员互相艾特闲聊。处理逻辑提取MsgType直接丢弃非text和非目标媒体的消息。拿到Content后写个正则过滤掉纯语气词和超短文本长度小于2个字符的直接忽略。提取ExternalChatId群ID和FromUserName发件人。如果这俩字段为空说明不是外部群消息直接return success。这道防线能帮你挡住 60% 以上的无效计算。2. 第二道防线基于 Redis 的业务规则引擎消息清洗干净后接下来就是决定这条消息该走哪条业务线。这里千万别写成一坨巨大的if-else工业级做法是利用责任链模式 业务特征词库。我们可以把分流规则定义为几个核心层级按优先级往下漏指令层最高优比如以#或查单开头的标准指令正则直接命中丢给内部 ERP 查询系统直接回复结果。状态拦截层去 Redis 查一下FromUserName是否处于“人工接管”状态。如果是机器人立刻闭嘴把消息通过 WebSocket 转发到客服的后台面板。意图路由层结合你们业务的特征词库比如包含“发票”、“退款”、“质量”命中高敏词直接将这条消息封装成卡片推送到内部的“售后响应群”提醒人工紧急介入。兜底层大模型如果前面都没命中说明是长尾问题这时候才把文本包装好带上该群的 Prompt丢给 LLM 生成回复。3. 数据落盘与回复组装当各路业务系统ERP、售后系统、大模型处理完消息后最后一步是通过企微的主动发送接口把回复推回对应的外部群里。给外部群发消息企微的规矩非常多。无论是发普通的文本还是发带有跳转链接的小程序卡片JSON 的结构层级必须严丝合缝。强烈建议大家在封装业务分流后的发送代码时不要靠直觉去猜字段名直接去翻接口文档把msgtype对应的实体类老老实实建好。只要字段结构是对的就不会遇到那些让人抓狂的400xx参数异常。4. 两个高频踩坑点这套分流引擎上线必须死死防住两个机制问题5秒超时斩杀线你的系统不管经过多少层规则引擎甚至去调了大模型在 Webhook 接收端的主线程里必须在收到请求的第一时间返回空串或 success。真正的分流和业务处理必须扔进 MQ如 RabbitMQ / Kafka里异步去跑否则企微会认为你没收到疯狂给你发重试请求。并发防重群里如果客户网络卡了连发三条一模一样的查单请求。你的分流引擎如果不做防抖ERP 接口直接被击穿。建议在接收层用 Redis 加个 2 秒的分布式锁Key 为MessageId或文本的 MD5拿到锁的才往下放行。把“清洗 - 责任链分流 - 异步调用 - 规范组装”这套底座打好你的群机器人就能像一个精密的路由器把不同的客户诉求丝滑地分发到各个业务线。大家在写路由规则或者调卡片消息接口时有什么坑可以在下面留言一起排查。
