企业级MultiAgent落地实践：Plan模式与主子Agent协作的关键工程化设计-北京尧图网络

做过多智能体系统的人应该都有同感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 能在企业级场景真正跑起来的核心逻辑。

企业级MultiAgent落地实践：Plan模式与主子Agent协作的关键工程化设计

相关推荐

深度强化学习在自动驾驶决策系统中的应用与实践

基于NSGA-II的水电光伏多能互补优化调度与MATLAB实现

LibreChat+MCP：构建企业级AI Agent调度中枢

更多资讯

Unity 6国内下载安装避坑指南与核心新功能解析

Trae AI 里的 DeepSeek / 豆包想走统一通道，TaoToken 的 Key 和 Base URL 怎么填

OpenHarmony中React Native FlatList分组列表实现与优化

Qwen3.5-Plus 1M 上下文 vllm OOM？让 Codex 走 TaoToken 对照 --max-num-seqs

蜂鸟式轻量设计：从colibri字体到网页性能优化

OpenResearch实践指南：构建可复现的开放科研协作工作流

今日更新

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？

相关推荐

深度强化学习在自动驾驶决策系统中的应用与实践

基于NSGA-II的水电光伏多能互补优化调度与MATLAB实现

LibreChat+MCP：构建企业级AI Agent调度中枢

更多资讯

Unity 6国内下载安装避坑指南与核心新功能解析

Trae AI 里的 DeepSeek / 豆包 想走统一通道，TaoToken 的 Key 和 Base URL 怎么填

OpenHarmony中React Native FlatList分组列表实现与优化

Qwen3.5-Plus 1M 上下文 vllm OOM？让 Codex 走 TaoToken 对照 --max-num-seqs

蜂鸟式轻量设计：从colibri字体到网页性能优化

OpenResearch实践指南：构建可复现的开放科研协作工作流

今日更新

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？

Trae AI 里的 DeepSeek / 豆包想走统一通道，TaoToken 的 Key 和 Base URL 怎么填