做过多智能体系统的人应该都有同感：Demo 阶段最风光，一上真实业务就现原形。单 Agent 在演示里像模像样，一旦碰到真实流程、真实系统、真实的人，立刻暴露天花板。这也是我把团队从“一个 Prompt 写到底”推向 MultiAgent 架构的直接原因。
这篇文章以得物技术侧的落地实践为背景，聊聊我们在企业级场景下做 MultiAgent 的真实经验，重点拆解两种核心机制：Plan 模式和主子 Agent 协作。它们解决的不是“模型聪明不聪明”的问题，而是“如何让一群模型稳定地干完一件复杂的事”的问题。如果你是技术负责人、AI 应用架构师，或者正在做 Agent 落地的研发，这篇文章能帮你少踩不少坑。
1. 先把“为什么要多 Agent”这件事想清楚
1.1 单 Agent 足够用吗：从一次真实需求说起
我们在业务里遇到过这样一个需求：用户提交一个售后咨询，需要自动完成“意图识别 → 订单信息拉取 → 售后政策匹配 → 赔付金额计算 → 生成回复话术”五个步骤。一开始我们尝试让一个 Agent 把所有逻辑都写在 Prompt 里，结果很不理想。不是模型不行，而是问题出在“角色混乱”上——同一个模型既当客服、又当计算器、又当政策库，还要控制输出格式，上下文一旦超过一定长度，决策质量就迅速下降，而且你很难定位到底哪一步出了问题。
单 Agent 的另一个痛点是不可维护。Prompt 里叠加的业务规则越多，越像一个“提示词屎山”，每次业务方提一个新需求，你都要在一条巨长的 Prompt 里找一个不起眼的角落塞上一行新逻辑，改完这行又影响前一行的行为，测试成本高到离谱。
所以我们很快意识到：当任务的复杂度超过某个阈值，拆分是唯一的出路。这和做软件是一个道理——你不会把整个电商系统写进一个类的 main 方法里，你也不会把十几条业务链路塞进一个函数。多 Agent 其实就是把软件的模块化思想搬回 AI 应用里。
1.2 多 Agent 本质是“流程的工程化”
很多人对 MultiAgent 有误解，以为就是多开几个模型实例、分别配 Prompt 再拼一起。那只是“多个单 Agent 的堆叠”。真正的多 Agent 架构，核心是任务编排、状态管理和容错设计。它本质上是在做一个流程引擎，只是这个流程里每个节点的“执行者”是大模型，而不是固定代码。
在得物的落地过程中，我们设计了一套主从结构的 MultiAgent 体系，主 Agent 负责理解用户请求、拆解任务、调度子 Agent 执行、收集结果并统一输出；子 Agent 则像领域专家一样，只负责执行某一种特定类型的工作。这样既保留了“一个统一入口”的用户体验，又在内部实现了专业化分工。
1.3 Plan 模式解决什么问题：和 ReAct 的分水岭
很多人问我们：为什么不用 ReAct 模式？ReAct 用“Thought → Action → Observation”的循环，能让模型在推理过程中动态调用工具，灵活度很高。但 ReAct 有个致命弱点：它不适合长链路、有严格时序依赖的任务。
想象一个复杂的售后场景，任务必须按顺序完成，中间还需要依赖前一步的输出。ReAct 模式每走一步都要决策一次，模型在某些节点会反复探索错误的路径，浪费大量时间和 Token，而且过程中不理解全局目标，经常走着走着“忘了自己要干嘛”。
Plan 模式则完全不同。它先让 Agent 基于全局信息生成一份完整的执行计划，再按计划逐步执行。这两种模式的对比很像“走一步看一步”和“先画地图再出发”的区别。企业级场景中，稳定性、可控性、可审计性远比“看起来聪明”重要，所以我们最终选择以 Plan 模式作为主执行框架。
2. Plan 模式：把“跑一步看一步”改成“先想后做”
2.1 ReAct 模式的死穴与 Plan 模式的架构优势
在实际业务里，ReAct 模式还有一个很隐蔽又很致命的问题：Observe 环节不可靠。工具返回的结果复杂时，模型对观察结果的解读经常出现偏差，错误一旦发生，后面的步骤全跟着错，而且很难追溯。而 Plan 模式下，每个节点的输入输出都有明确的定义和校验，某个环节出错，可以直接定位到具体步骤并重放或修复该步骤。
Plan 模式的架构一般包含三个核心组件：计划生成器（Planner）、执行器（Executor）和校验器（Validator）。Planner 负责把复杂任务分解为有序子任务，Executor 负责调用子 Agent 或工具执行每个子任务，Validator 负责检查每一步的产出是否符合预期，不符合就触发修正或重新规划。
这三个组件各司其职，才能真正支撑起“先计划后执行”的可靠性。
2.2 计划生成：任务拆解的三种策略
计划生成是 Plan 模式的第一步，也是最直接影响效果的一步。我们试过三种策略，各有适用场景：
第一种是固定模板法。针对业务高度标准化的场景，比如“订单退款处理”，计划永远只有三个步骤：验证订单 → 检查退款资格 → 执行退款。这种情况直接用预设模板最稳定，不依赖模型的临场发挥，也最容易做单元测试。缺点是灵活性差，业务一变就得改代码。
第二种是自由生成法。让 Planner 模型直接根据用户请求生成一份多步骤计划。这个方法灵活，但有个坑：模型生成的计划经常“看起来合理、实际上不可执行”，比如遗漏了关键依赖步骤，或者把两个不相关的任务强行串行。所以用自由生成法必须配套强校验。
第三种是分层分解法。先让 Planner 生成一个粗粒度的阶段计划，再由每个阶段的子 Agent 自行细化内部步骤。这种策略最适合复杂业务，也是我们目前的主力方案。它结合了模板的稳定和生成的灵活，每一层都只做“适度抽象”，避免一次生成太长的计划导致精度下降。
2.3 计划校验：不能只靠“大模型觉得”
这里我要特别强调一个观念：让大模型自己判断计划好不好，是这整条链路里最不靠谱的一环。模型对自己的输出天然有“自我感觉良好”的倾向，它生成一份三步骤的计划，你问它完整吗，它大概率说完整，但实际上可能缺了“风控校验”这一步。
我们的做法是建立一套基于代码的规则校验器。每个计划步骤都带结构化字段：操作类型、目标对象、输入参数来源、输出流向。校验器检查四类问题：依赖是否完整、参数引用是否存在、步骤顺序是否违反业务约束、输出是否能被下一步消费。这一层纯用代码实现，不走模型，准确率 100%。
计划校验通过后，才允许进入执行阶段。很多团队省略了这一层，直接把模型生成的计划丢给执行器，这条路走不远——因为在大模型驱动的系统里，不可控的不是模型能力，而是模型输出对应的“契约”是否被遵守。
2.4 计划修正与重规划：企业级场景必须有的兜底
执行过程中，计划不一定完全正确。我们实践中至少遇到过三种计划需要修正的情况：子 Agent 返回的结果不足以支撑下一步执行、外部系统返回异常、用户在中途变更了需求意图。
针对这三种情况，我们在架构里设计了一个重规划机制（Re-Plan）。当执行器发现某一步失败时，不会简单地报错退出，而是把失败信息和已执行的中间结果回传给 Planner，让 Planner 重新生成剩余步骤的计划。
这里要控制重规划的次数，不然容易陷入“失败 → 重新规划 → 又失败 → 再重新规划”的死循环。我们的做法是给重规划设置一个最大次数，一般是 2 到 3 次，超过就直接降级为人工处理。降级路径比重规划本身还重要，因为企业业务对“失败时做什么”的要求，比对“成功时做什么”的要求更高。
3. 主子 Agent 协作：管理权力下放，让每个 Agent 只干一件专业的事
3.1 主 Agent 的定位：调度中枢，而不是回答者
采用主从架构后，主 Agent 的角色发生了根本变化。它不再是直接回答用户问题的“答题者”，而是变成一个调度中枢。它要理解目标、规划路径、分派任务、汇总结果。自始至终，主 Agent 不直接执行任何具体业务逻辑，它只做决策和管理。
这样设计的好处是职责清晰。主 Agent 的 Prompt 里不用塞各种业务细节，只需要定义好“如何拆任务”“如何评价子 Agent 结果”“如何组织最终回复”这几个抽象问题。Prompt 越短，行为越稳定。这个观点可能和很多人的直觉相反——觉得主 Agent 应该最聪明、知道最多细节。其实恰恰相反，主 Agent 越抽象，越不容易出错。
3.2 子 Agent 的专业边界设计
子 Agent 是真正干活的角色。在我们的架构里，子 Agent 分为两类：代码型 Agent和技能型 Agent。
代码型 Agent 的“技能”是通过确定性代码实现的，比如查数据库、调用 API、执行计算。这类 Agent 背后有严格的输入输出模式，模型的作用只是把自然语言转化为结构化的调用参数。
技能型 Agent 的“技能”则靠模型自身能力，比如写一段营销文案、总结一份文档、判断一个用户情绪。这类 Agent 没有确定性的输出保障，需要靠更精细的 Prompt 和评测来约束。
子 Agent 设计最核心的经验是：一个子 Agent 只负责一种类型的任务。比如“退款计算 Agent”只负责算钱，不负责解释退款规则；“政策查询 Agent”只负责从知识库里检索政策原文，不负责生成话术。边界一旦模糊，主从协作就会退化成一个“大杂烩 Agent”，重新陷入单 Agent 的泥潭。
3.3 消息协议：Agent 之间怎么说“人话”
多 Agent 协作的最底层基础设施是消息协议。我们早期踩过一个坑：子 Agent 之间直接用自然语言文本传递结果，主 Agent 去解析这些文本时，经常遇到格式不一致的问题——有的子 Agent 回复“订单已找到”，有的回复“找到了订单”，模型去解析时必然出幺蛾子。
后来我们给所有 Agent 之间的通信设计了一套轻量级 JSON 协议。每条消息必然包含type、status、data、error四个字段。type表示消息类型，status表示执行状态，data是结构化业务数据，error是错误信息。子 Agent 的输出必须严格符合这个协议，不符合就直接判为失败，不做模糊容忍。
这套消息协议相当于 Agent 世界里的“接口文档”，它让整个系统变得可编程、可测试、可追踪。如果没有这层协议，MultiAgent 系统就是一盘散沙，你根本没法定位问题到底出在哪个 Agent 身上。
3.4 上下文传递与状态同步的工程细节
关于上下文，我特别想说一个反直觉的经验：子 Agent 的上下文不是越多越好。每个子 Agent 只应该看到它完成当前任务所需的最小上下文集合。
举个例子：一个“订单详情查询 Agent”，它的输入只需要订单 ID 和一个用户身份令牌，不需要知道用户之前说了什么、不需要知道售后政策的完整内容。我们把用户原始会话、业务背景这些信息都留在主 Agent 手里，只把必要的字段下发给子 Agent。
这样做的原因有两个。第一是成本，上下文越长 Token 消耗越大，长链路任务里这个成本会被放大好几倍。第二是效果，上下文信息冗余时，模型容易被无关信息干扰，尤其是对话历史里的情绪化表达，会影响子 Agent 的判断。
状态同步方面，我们采用集中式状态管理。所有 Agent 的中间状态统一存在内存态的工作流实例里，每个步骤执行完，就更新对应字段。子 Agent 不保存任何状态，它们是无状态的执行者，状态只属于工作流实例。这个设计和后端开发里“Serverless 函数无状态”的理念如出一辙，好处是任何子 Agent 挂掉都可以直接重启一个新实例继续跑，不影响整体流程。
4. 落地过程中必须做好的几件工程事
4.1 可观测性：给 MultiAgent 系统装上“监控仪表盘”
MultiAgent 系统最让运维头疼的一点是不确定性。传统服务的日志是确定性的，每次请求的日志结构都相同，出了问题查一下堆栈就行。但一个 MultiAgent 服务，同一个用户请求，两次执行可能走完全不同的路径，日志格式也可能完全不同。这就导致常规的日志系统几乎没用。
我们为 MultiAgent 系统专门封装了一套基于链路追踪的日志打点方案。每个工作流实例有一个全局唯一的workflow_id，每个子 Agent 执行单元打点都带上workflow_id和step_id，无论这个 Agent 内部调了多少次模型、工具，所有日志都挂在同一个 trace 下。
拿到一个用户反馈“结果不对”之后，我们的排查流程是：先用workflow_id拉出整条链路，看计划是什么、每个子 Agent 的输入输出是什么、哪一步出现了偏差、重规划触发了没有。这一步通常能解决 80% 的问题。再配合关键节点的耗时统计、Token 消耗统计，就能非常清楚地定位到性能瓶颈。
对于长链路任务，我们还会把每一步执行结果自动截个“快照”，类似前端页面里的骨架屏，存到对象存储里备用。这在工作流出现争议时特别有用——客户说你的 AI 给出了错误承诺，你能直接拉出当时每个 Agent 到底看到了什么数据、说了什么话，这比任何解释都有说服力。
4.2 评测体系：没有评测就没有迭代
做 AI 应用最怕“凭感觉优化”。你改了一个 Prompt，觉得效果变好了，结果过几天业务方反馈一堆新问题，你又不知道是不是这次改动引起的。所以我们从第一天起就建了一个离线评测集。
评测集的来源是真实业务里的历史问题，我们把它整理成了几百条标准测试用例，每条用例都有“输入请求、期望计划、期望最终结果、关键检查点”四个维度。每次我们修改任何 Agent 的 Prompt、调整任何编排逻辑，都必须先跑一遍完整评测集，对比整体通过率。
这说起来容易做起来难。难在“期望计划”和“关键检查点”的设计上。比如“期望计划”，我们的做法是把计划映射到一个标准步骤序列上，评测程序自动比对实际计划与标准步骤的重合度，重合度低于阈值就判定失败，而不是要求一字不差地相等。
评测还有一个容易被忽视的作用：它是跨团队协作的沟通工具。业务方不理解“你的 Agent 设计得有多好”，但他们看得懂“通过率从 72% 提升到 89%”。用数据说话，能减少大量来回扯皮。
4.3 成本与性能的平衡：Token 用量和响应时延
企业级落地绕不开一个现实问题：钱。一个复杂的 MultiAgent 任务，可能要调用十几个子 Agent，每个都访问一次模型，Token 消耗很容易爆炸。尤其在高峰期，并发一上来，账单数字看着都手抖。
我们控制成本的手段有三个。第一是模型分层：不重要的节点用便宜的小模型，关键节点才用最强的旗舰模型。比如意图识别这类简单任务，用轻量模型就够了；计划生成这种全局决策任务，才需要用更大参数量模型。
第二是结果缓存。同一个用户的同类问题，在短期内产生的子 Agent 结果有大量重复。比如用户连续两天问同一个商品的退货政策，政策查询 Agent 返回的结果可能完全相同。我们在这一层做了 KV 缓存，命中缓存就直接复用结果，不再重新调用模型。
第三是延迟合并。某些步骤之间没有强依赖，可以并行执行。比如查订单信息和查用户会员等级，这两个动作互不依赖，我们就把它放进一个并行组里同时执行。整体时延从原来的“串行 6 秒”降低到“并行 3 秒”，体感提升非常明显。
4.4 灰度发布与失败兜底
Agent 系统的发布可能比传统系统更危险，因为你很难预判模型在一批新 Prompt 下会产生什么行为。所以我们所有 Agent 的配置和 Prompt 都是动态配置，发布过程是一个完整的灰度流程。
具体做法是：把所有 Agent 的 Prompt、模型参数、编排策略都放在远程配置中心，线上服务每秒拉取一次配置。做变更时，先把新配置发布到灰度分组，只让 5% 的流量走新配置，观察指标和坏案例，确认没有问题后再逐步放量。
灰度发布最关键的一点是：必须有自动回滚机制。我们设置了几条硬性红线指标，比如失败率超过阈值、平均时延超过阈值、人工介入率超过阈值，一旦触发，配置中心自动把相关 Agent 回滚到上一个稳定版本，完全不依赖人工决策。这套机制上线后，我们的发布事故率整整降了一个数量级。
很多团队做 Agent 只关心 Prompt 怎么写，不关心发布流程，这是一个很大的误区。Prompt 不是代码，但它在生产环境里的行为比代码还要难预测，所以必须用代码发布的纪律来管理它。
5. 常见问题与排查技巧实录
5.1 上下文串台：“子 Agent 说得不对”往往不是模型笨
排查问题的时候，我们发现一个高频现象：某个子 Agent 给出了非常离谱的回答，但单独拿同样的输入去测它，它又表现正常。一开始我们怀疑是模型随机性导致的，后来查了 trace 才发现，是主 Agent 在下发任务时，把其他任务的上下文误传给当前 Agent 了。
这类“上下文串台”问题，根源往往不在模型，而在编排代码。比如一个工作流实例被并发复用了、消息队列里两个实例的数据串了、或者是字段映射写错了。排查方法是做一次“最小化输入验证”，把子 Agent 直接输入全部打出来，检查里面有没有多余的历史消息或者别的任务的残留。一旦发现串台，一般都能在编排层找到 bug，而不是去改 Prompt。
5.2 计划生成得“太粗”还是“太细”
计划生成的粒度问题，我们折腾了很久。模型生成的计划太粗,比如把“完成订单处理”作为一个步骤，那这个步骤没法执行，因为子 Agent 不知道该做什么。计划太细，比如“调用订单接口，解析字段，判断退款资格，计算金额…”拆了五十步，执行时会因为任何一个微小偏差而失败，而且Token成本骤增。
最终我们的经验是：计划粒度应该以“一个步骤对应一个子 Agent 或一个工具的完整调用”为最小单位。一个步骤完成一个可独立验证的业务目标，步骤内部怎么实现，由子 Agent 自己决定。这样计划层足够稳定，执行层足够灵活。
5.3 循环执行与“死循环”怎么治
Plan 模式在执行过程中，偶尔会出现子 Agent 反复执行同一操作的情况。比如“查询订单状态”的 Agent 查到状态是“处理中”，按理说应该结束这一步或者触发异常分支，但它会反复查询、反复返回相同结果，让流程卡在同一个步骤上。
我们给每个工作流实例增加了执行步数上限和每一步的超时控制。步数上限根据任务类型动态配置，普通任务 20 步，复杂任务 40 步。一旦超过步数上限，工作流自动终止并转人工。超时控制则分两层：模型调用超时和工具调用超时，超时后进入重试逻辑或直接标记失败，不会让流程无限等下去。
另外一个有用的技巧是：给子 Agent 的结果加一个“去重校验”。同一个步骤产生的结果如果和上一次完全相同，且没有新的外部事件发生，就判定为循环，强制跳出。类似后端接口的“幂等性设计”，在 AI 编排里同样适用。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查手段 | 解决方案 |
|---|---|---|---|
| 子 Agent 输出与业务事实不符 | 上下文串台 / 错误数据下传 | 拉 trace 检查输入数据 | 修正编排层字段传递 |
| 计划无法执行 | 计划粒度不匹配 / 依赖缺失 | 检查计划校验日志 | 调整拆解策略，加强规则校验 |
| 任务卡住不返回 | 子 Agent 循环 / 工具超时 | 检查执行步数、超时日志 | 增加步数上限，设置幂等判断 |
| Token 成本异常攀升 | 无关上下文过长 / 重规划过频 | 监控 Token 消耗明细 | 精简上下文，限制重规划次数 |
| 发布新 Prompt 后效果暴跌 | 未充分灰度 / 缺自动回滚 | 检查灰度分组指标 | 启用配置中心自动回滚 |
| 同请求两次结果差异大 | 模型随机性 / 编排路径不稳定 | 跑评测集比对结果 | 降低温度参数，规划路径标准化 |
我还想分享一个特别实用的排查心态：MultiAgent 系统的问题，不在模型就在编排。与其在两边之间反复猜，不如把模型调用和编排流程的日志彻底分开。查看问题时先看编排层的 trace，能定位到具体步骤再聚焦模型层分析，这样能省下大量排查时间。
6. 我的一点实操体会
做了这么久 MultiAgent 落地，我最大的体会是：这个领域真正的门槛不在算法，而在工程化。模型能力是很重要，但企业级系统追求的不是“某一次特别聪明”，而是“一百次里有九十九次稳定可控”。稳定可控靠什么？靠的是清晰的架构边界、严格的消息协议、完善的可观测性和强大的评测体系。
如果你正准备在业务里引入 MultiAgent，我建议从两个地方开始：先跑通一个最小闭环，选择一个最痛的纵向业务场景，用 Plan 模式加上两三个子 Agent 把它做成，感受一下“拆解 + 编排 + 验证”的完整流程；同时把可观测性和评测体系这两个底座尽早建起来，它们越早建，后续迭代的加速度越大。
至于未来，我们还在探索子 Agent 的自主学习和更细粒度的动态规划。但无论框架怎么演进，有一个原则不会变：复杂问题就拆分，拆分之后定义清楚边界，边界之内让模型自由发挥，边界之外交给工程控制。这就是 MultiAgent 能在企业级场景真正跑起来的核心逻辑。
