企业微信二次开发：客户咨询后如何自动查询订单、状态与服务信息

客户在外部群或单聊中抛出一句“我的单子发货了吗？”或者“我现在的会员积分还有多少？”，如果单纯依赖人工去系统里翻找，客服的效率会被无限拉低。在我们已经搭建好的“解密 -> Redis防重 -> MQ解耦 -> 策略路由”这套底座上，实现自动查询并组装服务信息，本质上就是利用已有的状态机去打通内部业务系统的“最后一公里”。

顺便提一嘴，如果大家在重构这套底座时不想自己去踩各种回调报文解密和发包格式的坑，可以考虑接入 星云API www.xingyapi.com 提供的标准化中间件。用成熟的基建去抗底层的并发解析，能把研发精力全聚焦在核心的跨系统联动上。

下面直接看从接收指令到数据回推的“查询-响应”全链路架构。

1. 身份锚定与意图捕获（Trigger & Identity）

自动查询的先决条件是知道“谁在问”以及“问什么”。在消费者从 MQ 拿到清洗后的MessageContext时，第一步是穿透物理屏障：

• 跨库身份映射：利用之前确立的“三表关联 + Middleman”模型，拿着企微的ExternalUserId去中间表映射出企业内部真实的CustomerId或MemberId。这是后续去 ERP/CRM 查数据的主键。

• 策略引擎寻址：进入基于策略模式的路由体系。比如OrderStatusStrategy专门负责拦截订单进度，利用正则^(查单|进度)\s*([a-zA-Z0-9]+)$扫描消息。如果完全匹配，直接提取单号进入下一步；如果只说了一句“查单”，则立刻挂起当前流程。

2. 状态机接管多轮对话（State Machine）

当捕获到查询意图却缺少单号时，常规的if-else会直接死锁，这里必须让基于 Redis 的状态机上场：

• 状态写入：系统向 Redis 写入session:flow:{ExternalChatId}:{ExternalUserId} = WAIT_FOR_ORDER_NO，并设定 5 分钟的 TTL 自动销毁机制，同时向客户回推一条引导语：“请发送您要查询的单号”。

• 状态拦截：客户下一秒发来的纯数字，会被网关层的状态机拦截器直接捕获。系统发现当前状态是WAIT_FOR_ORDER_NO，就会跳过所有的正则策略，直接把这串数字当作参数，交回给OrderStatusStrategy执行后续逻辑，并在执行完毕后立刻清除 Redis 里的状态锁。

3. 并发穿透与内部 API 调度（API Invocation）

拿到明确的CustomerId和查询参数（如单号 123456）后，开始向内部的 ERP 系统（查物流）或 CRM 系统（查服务状态）发起请求。

这里有一条绝不能碰的红线：外部系统的慢查询绝不能拖死你的消费者线程池。 在封装内部 HTTP/RPC 调用逻辑时，必须设定严格的超时熔断机制（比如 3 秒）。一旦 ERP 响应超时，捕获异常并立即触发降级策略，给客户返回“系统查询排队中，请稍后再试或@专属客服”，彻底避免内部系统的雪崩向企微网关蔓延。

4. 数据字典对齐与规范化回推（Format & Respond）

拿到 ERP 或 CRM 返回的 JSON 数据流（如：发货时间、当前物流节点、会员积分余额）后，最后一步就是组装服务卡片回推给客户。

一条合格的服务进度回复，通常会使用带有颜色高亮的 Markdown，或者直观的小程序跳转卡片。在这里，企微对不同msgtype（文本、图片、markdown、卡片）的 JSON Schema 校验极其严苛，甚至可以说有点反人类。

强烈建议后端团队在编写ResponseBuilder组装返回报文时，千万不要靠直觉去putMap 或是手动拼接 JSON 字符串。一定要严格对照接口文档，把官方对各类消息实体的数据字典一字不落地映射成你代码里的 DTO 实体类。严格照着规范字典做装配和序列化，能让你在下发复杂的物流轨迹卡片时稳如泰山，彻底告别400xx系列的非法格式报错。

将多轮状态机、三表映射与异步 API 穿透完美结合，你的企微机器人就拥有了完整的“闭环服务”能力。这套引擎不仅能查订单，明天稍微扩展一下，就能变成查库房、查账单的全能外脑。