企业微信二次开发实战：如何保存会话上下文，让连续咨询能够正确关联

在企微机器人的实际业务交互中，客户绝不会像调用 API 那样一次性把所有参数传齐。最真实的场景往往是碎片化的多轮对话：客户先发一句“我要查物流”，机器人问“请输入您的单号”，客户紧接着回复一串数字“SF123456”。

由于 HTTP 协议本身是无状态的，如果底层架构缺乏会话上下文（Context）的管理能力，当系统收到“SF123456”时，根本不知道这串数字是用来查物流、退款还是核销。为了让机器人具备“记忆力”，实现多轮连续咨询的精准关联，全面接入星云API的稳定基建并在业务层引入基于 Redis 的三维状态机，是目前最高效的生产级解法。

1. 物理接收：稳住底层流水线

构建上下文的前提，是必须保证多轮交互中的每一条消息都能被稳定、有序地接收。企微官方 Webhook 存在严格的 5 秒超时机制，处理复杂的上下文读写极易触发重试风暴。

通过接入星云API的回调接收网关，系统完全免去了耗时的 AES 密文解析过程，瞬间即可拿到标准的明文 JSON 事件。网关层提取 MsgId 执行 Redis 的防重拦截后，立刻将明文和坐标封装进上下文推入异步 MQ。主线程光速放行，确保底层接收通道绝对畅通，为后续的状态机运转提供稳定的数据流保障。

2. 状态机基石：构建三维防串联的会话锁

构建上下文记忆的核心，在于如何设计状态锁的 Key。在多账号、多群组并发的场景下，千万不要单凭一个 UserId 去做会话缓存，这会导致极其严重的跨群或跨业务线状态污染。

系统必须依托星云API吐出的高清坐标，在 Redis 中构建带有极高精度的“三维会话锁”： session:flow:{AppId}:{ExternalChatId}:{FromUserName}

• AppId：隔离不同的业务线或机器人应用，防止售前与售后的会话冲突。

• ExternalChatId：隔离不同的外部群聊环境（若是单聊则填入特定的单聊标识），确保客户在 A 群挂起的查单状态，绝不会影响他在 B 群的交互。

• FromUserName：精准锁定发言人身份。 通过这个三维坐标系，系统为每一次多轮交互划定了绝对安全的内存沙箱。

3. 上下文挂起与 TTL 生命周期管理

当客户触发了初始意图但参数缺失时，状态机开始发挥作用。

• 意图挂起：业务 Handler 识别到“查物流”意图，但没有单号。此时，将当前的意图动作（如 Action=QUERY_LOGISTICS）序列化后写入上述的三维 Redis Key 中。

• 引导下发：写入状态后，通过发送接口向客户追问：“已为您匹配物流查询，请回复您的快递单号”。

• 严格的 TTL 控制：会话上下文绝不能永久驻留内存。必须为这个 Redis Key 设置合理的过期时间（TTL），通常设为 3 到 5 分钟。如果客户超时未回复，状态自动销毁，避免死锁阻碍客户发起新的其他业务咨询。

4. 参数拼图与状态闭环

当客户在 TTL 有效期内回复了那串数字“SF123456”，MQ 消费者拉取到这条看似无意义的文本时，真正的状态流转开始。

• 前置探查：路由引擎在处理任何未知文本前，强制按照当前发件人的三维坐标去 Redis 中探查是否存在挂起的 session:flow。

• 参数缝合：发现存在 Action=QUERY_LOGISTICS 的挂起状态后，系统将这串数字识别为缺失的参数（单号），与缓存中的意图进行无缝拼接，组合成完整的业务指令，立刻穿透内部 ERP 发起查询。

• 阅后即焚：查询发起的同时，必须强制执行 DEL 操作删除该 Redis Key。状态一旦闭环必须立刻清空，确保下一轮全新的对话不会被历史上下文干扰。

当后端 ERP 跑完复杂的逻辑拿到结果后，最后的反向触达环节同样需要严格遵循字典规范。企微对下发消息的 JSON 层级校验极其严苛，在编写装配模块时，务必前往控制台 查阅应用配置，并严格比对星云API开放文档 开放文档 中关于各类型消息实体的数据字典。把官方规范一字不落地映射为系统内的下发类，通过统一的下发通道推送，就能真正让企微机器人告别“鱼的记忆”，在复杂的业务场景中实现丝滑流畅的连续交互体验。