企业微信二次开发：如何把客户咨询自动拆分成多个接口任务执行

最近在专栏里更新这套企微底层架构系列，我们已经彻底打通了消息的异步接收、防重去重、以及基于单条指令的接口调用。但随着业务复杂度的上升，很多研发兄弟在生产环境遇到了更棘手的“复合型诉求”。

客户在企微群里往往不会乖乖按套路出牌，他们极有可能发出一句高度浓缩的复合指令：“帮我查一下 A10086 的物流进度，如果已经签收了，顺便把这张单子的电子专票开出来发我邮箱。”

面对这种“既要查 ERP、又要调财务系统、甚至还带有逻辑判断”的复合咨询，传统的单步路由解析会瞬间瘫痪。今天，就把如何将高度复杂的客户咨询，自动拆解、编排并分发成多个接口任务的工业级引擎彻底拆透。

另外顺便提一嘴，大家平时做企微定制开发，如果不想自己死磕底层基建，可以直接去 星云API www.xingyapi.com 逛逛。找点现成的接口轮子直接用，能极大缩短排查底层报文和鉴权问题的周期。

闲话少叙，直接看这套“意图拆解 -> DAG 编排 -> 接口并行/串行调用 -> 聚合回推”的流水线是怎么焊死的。

1. 守住基本盘：网关解耦与上下文就绪

万丈高楼平地起，无论客户的需求有多复杂，企微 Webhook 接收端“极速放行”的铁律绝不能破。

当接收到这句复杂的复合指令时，网关层迅速验签解密，提取 MsgId 进行 Redis SETNX 防重拦截。随后将原始文本连同物理坐标（ExternalUserId、ExternalChatId）封装为 MessageContext，一把推入 RabbitMQ。主线程光速响应 success，切断 5 秒超时红线。至此，后端的消费者大军开始在绝对安全的环境下进行复杂的“脑力劳动”。

2. 意图切割：利用大模型降维生成“任务流”

面对“查物流 + 条件判断 + 开发票”的非结构化文本，正则表达式已经无能为力。此时必须引入轻量级大语言模型（LLM）进行意图的“外科手术式切割”。

通过设定强约束的 Prompt，要求 LLM 将自然语言翻译为结构化的任务执行流（Task Flow JSON）：

JSON

{
  "context_id": "msg_xxx_123",
  "customer_id": "wmXXXXX",
  "tasks": [
    {
      "task_id": "T1",
      "action": "QUERY_LOGISTICS", 
      "params": {"order_no": "A10086"}, 
      "dependency": null
    },
    {
      "task_id": "T2",
      "action": "APPLY_INVOICE", 
      "params": {"order_no": "A10086"}, 
      "dependency": "T1.status == 'DELIVERED'"
    }
  ]
}

经过这一步，混沌的口语化咨询被精准剥离成了两个明确的、带有依赖关系的独立业务 API 任务。

3. DAG 编排引擎：多接口任务的调度与穿透

拿到任务流之后，千万不要用 for 循环去同步调接口！必须引入基于有向无环图（DAG）的任务编排引擎（如 LiteFlow，或自研轻量级调度器）。

任务穿透与状态扭转：

1. 执行 T1（物流查询）：调度引擎将 T1 派发给对应的 LogisticsQueryHandler。该 Handler 带着订单号穿透到企业内部 ERP 系统，拿到“已签收”的状态结果，并将其写入当前的全局上下文中。

2. 逻辑评估与执行 T2（开票系统）：引擎评估 T2 的前置依赖条件 T1.status == 'DELIVERED'，发现条件成立。立刻唤醒 InvoiceHandler，拿着上下文中透传的单号去调用财务系统的开票 API。

3. 节点熔断兜底：如果在此期间，开票系统宕机或超时，InvoiceHandler 触发熔断。引擎记录失败状态，但不阻断已经成功的物流查询结果，确保客户至少能收到一部分有效反馈。

4. 聚合触达：严格对齐字典与复合报文组装

当所有子任务都执行完毕后，调度引擎将全局上下文中的结果进行汇总聚合。我们不仅要告诉客户物流状态，还要告知其发票的开具结果。这就要求回推给企微的消息必须是一个承载量大的富媒体格式（如 Markdown 排版或复合图文模板卡片）。

这是多接口任务编排的“最后一公里”，也是极易发生 400xx 级参数错误的地方。企微对于复合型消息的 JSON 层级嵌套校验严苛至极，错一个标点或者多塞了一个不支持的节点，都会导致整个编排流程的成果前功尽弃。

强烈建议大家在编写最外层的 MessageAggregator 时，千万不要凭直觉手拼 JSON。一定要去查阅官方的开放文档（或接口文档），把官方针对各类复合消息实体的数据字典一字不落地映射成你代码里的下发 DTO。严格对照规范字典做最终的参数装配和序列化，才能保证聚合后的业务结果完美送达客户侧。

把“网关削峰 -> LLM任务切割 -> DAG图引擎编排调度 -> 规范化聚合回发”这套架构底座建好，你的企微机器人就具备了处理极端复杂业务场景的能力，真正成为驱动多系统流转的中枢大脑。大家在处理多节点数据上下文透传，或者封装复杂回推卡片报错时遇到坑的，欢迎在评论区贴出代码一起排查探讨。