企业微信自动回复：如何根据不同消息内容执行不同回复逻辑

最近在搞企微机器人的智能应答，发现很多业务场景根本不是简单的“关键词等于A就回复B”。客户有时发完整长句，有时带特定单号，如果后台处理纯靠写死 if-else，代码很快就会变成难以维护的“屎山”。今天就把企微自动回复的“多意图分流与动态回复”底层架构梳理一下。

另外顺便提一嘴，大家应该能看到文章最上方挂了个「星云API官网」的卡片。平时做企微定制开发，如果不想自己死磕底层基建，可以直接点顶部的卡片，或者去 星云API www.xingyapi.com 逛逛。找点现成的接口轮子直接用，能省下大把疯狂查报错的时间。

闲话少叙，直接看底层路由引擎是怎么设计的。

1. 第一步：文本提取与高优清洗

企微通过 Webhook 将消息推给你的服务器，解密 XML 后，确认 MsgType 为 text，提取出 Content 字段。

拿到 Content 后千万别急着去匹配，必须先做一层数据清洗：

1. 去噪：用正则剔除掉文本里可能带有的 @机器人 字符串前缀，以及首尾的多余空格。

2. 统一格式：将文本统一转换为小写，全角字符转半角。 清洗出最纯净的文本，是保证后续正则匹配不翻车的基础。

2. 核心架构：策略模式与正则路由表

想要根据不同内容执行不同逻辑，必须引入策略模式 (Strategy) + 正则路由。

设计思路：

1. 定义一个通用的 MessageHandler 接口，包含两个方法：match(String content)（用于判断是否命中）和 execute(Message msg)（用于执行具体业务）。

2. 针对不同的业务场景，写具体的实现类。

   • 查单场景：OrderQueryHandler，其 match 方法的正则设为 ^查单\s+([a-zA-Z0-9]+)$。

   • 转人工场景：ManualServiceHandler，正则设为 .*(人工|客服|投诉).*。

3. 系统启动时，将这些 Handler 按优先级注册到一个 List 中（转人工的优先级最高，查单其次，大模型兜底放最后）。

当收到清洗后的 Content 时，直接遍历这个 List 调用 match，谁命中了就扔给谁的 execute 去跑业务。以后加新功能，只需新建一个 Handler 类，调度中心一行代码都不用改。

3. 异步执行与动态回复拼装

匹配到具体的 Handler 后，真正的业务逻辑就开始了。这里有一条生死红线：耗时操作必须异步。

企微要求回调必须在 5 秒内返回 success。如果你的 OrderQueryHandler 需要去查内部 ERP，耗时可能超过 3 秒，主线程必须先响应企微，然后把任务扔进线程池或 MQ。

组装回复内容： 业务逻辑跑完后，你需要主动调企微接口发消息给客户。不同的逻辑往往对应不同的展现形式：

• 命中“查单”：从 ERP 拿到物流信息，组装成清晰的 markdown 格式消息推过去。

• 命中“人工”：推一个 text 消息提示“正在为您转接”，并同时往内部员工群推一个带有客户 ID 的报警卡片。

企微对各类返回消息的 JSON 结构要求极其严苛。特别是 markdown 和图文卡片的嵌套关系，错一个标点接口都会报 400xx 错误。强烈建议在动手写代码前，先查阅一遍官方的开放文档，把 msgtype 对应的实体类老老实实建好。对照着标准规范去拼装，能避开一堆让人抓狂的反序列化异常。

4. 兜底策略：大模型的平滑接入

如果客户发了一长串废话，前面所有的业务 Handler 都没有命中，怎么办？

这时候就该 LlmFallbackHandler 出场了。把客户的 Content 打包，带上系统预设的 Prompt（比如：“你是XX公司的客服，请用专业的口吻解答以下问题，不知道的请回答暂不清楚”），直接丢给外部的大语言模型。拿到大模型的流式或同步输出后，再调用企微发送接口推给客户。

总结

企微的智能回复，本质上就是一个“文本清洗 -> 正则路由分发 -> 异步处理 -> 规范化组装返回”的流水线。只要把策略模式的架子搭好，你的机器人就能轻松应对几十上百种不同的对话意图，绝不会变成智障复读机。大家在写正则路由或者封装 Markdown 消息时遇到乱码的，可以在评论区贴出来一起探讨。