做 MultiAgent 的人很多真正敢把它放到生产环境里的团队没几个。这不是模型能力跟不上而是工程化难度被严重低估了。去年我们在得物内部启动了一个 MultiAgent 项目目标是让一组不同职责的 Agent 协作完成一条完整的业务链路。跑通 Demo 只花了三天但从 Demo 到稳定支撑真实业务前后折腾了接近两个月中途推翻了两版架构。最终沉淀下来的核心经验就是两件事用Plan 模式替代自由发挥式的 ReAct 连招用主子 Agent 协作替代全对等的多 Agent 网络。这篇文章把这套企业级 MultiAgent 落地方案掰开讲清楚。内容包含 Plan 模式的规划器怎么设计、主 Agent 与子 Agent 的职责边界和协作机制、状态管理与可观测性这些工程细节还有我们实际踩过的三个大坑和完整的排查链路。适合正在做 MultiAgent 应用、或者准备把 Agent 从 Demo 推到生产的团队参考哪怕你只是刚接触这个概念也能从中理解为什么很多开源项目跑得欢、一上生产就翻车。1. 为什么 MultiAgent 项目大多死在 Demo 阶段1.1 单 Agent 的瓶颈不是模型不够强而是上下文不够用企业级业务里一个复杂任务往往要跨多个系统、查多种数据、做多步决策。拿我们做过的一条工单链路来说用户发起售后申请系统要先判断是否符合退货条件再调取订单、物流、商品快照、历史售后记录综合给出处理意见最后还要生成一条工单同步给客服。如果让一个 Agent 从头做到尾它会在这个长链路里反复切换上下文一个小时内还没处理完上下文窗口就见底了。即便窗口塞得下模型也容易忘掉开头的信息出现做着做着就把用户需求改了的情况。单 Agent 不是不能做这些事而是它的上下文是单一连续的长链路会把它拖垮。这就像让一个实习生从销售、仓储、客服、财务的活全部一个人扛不是能力问题是精力终归有限。MultiAgent 解决的就是这个结构性问题把一个大任务拆成多个小任务让每个 Agent 只负责自己擅长的那一段。1.2 多 Agent 失败的三个典型特征我们调研和拆解了不少社区里的 MultiAgent 项目包括早期比较火、后来热度降下来的那些自主 Agent 项目。它们失败有三个共性特征。第一Agent 之间全对等任务没人兜底彼此之间的对话很容易聊跑偏。几个 Agent 凑在一起聊着聊着就偏了最后产出结果往往只能靠运气。第二没有明确的计划层每个 Agent 都是走一步看一步碰到分支情况就让模型临场发挥随机性非常大同样的输入跑两次结果可能完全不同。第三几乎没有工程化的观测和恢复能力。Agent 一旦进入错误分支整个链路只能靠人肉重启日志不结构化链路追踪不存在出问题之后去复盘成本极高。这三个特征本质问题不在模型而在于整个系统的控制结构太弱。这也是为什么我们后来果断放弃了第一版的全对等架构改成主从控制流。1.3 我们为什么敢在得物内部推 MultiAgent选择运营工单处理这个场景是因为它有几个特点链路长、依赖多个内部系统、对准确率要求高但对时延的容忍度相对较高。这类场景天然适合一个人做主编排、多个专项 Agent 干活的模式。如果连这种链路都处理不好那再往上做经营分析、风控决策之类更复杂的场景就更不用谈了。当时内部其实已经有成熟的大模型单点应用比如对话助手、信息抽取但都是单点能力属于会聊天不是会干活。我们想做一个真正能按流程完成任务的系统把模型从回答问题推进到完成项目。这个目标本身就决定了我们必须要有一套任务规划机制而不是让模型自由发挥。2. Plan 模式先想清楚再动手而不是边做边改2.1 从 ReAct 到 Plan一次踩出来的认知升级初版我们用的是 ReAct 模式模型每一步都先推理再行动。Demo 阶段跑起来很爽看起来很灵活但上了生产环境之后这种灵活性变成了灾难。一个真实任务可能涉及十几个工具调用ReAct 每步都要重新读一遍当前局面调用一多token 消耗是计划模式的数倍而且成本只是其中之一更麻烦的是它路径依赖太强。ReAct 的下一步完全取决于上一步的结果一旦某一步模型输出一个奇怪的选择后面就全跑偏了。你得靠日志去倒推是第几步出了问题而这通常要花掉比重新跑一遍还多的时间。后来我们调整思路换成 Plan-and-Execute先让模型把任务拆成一份明确的计划然后按照计划逐步执行执行过程中允许在特定节点重新规划但不会每个动作都重新想一遍。这个转变可以用一个类比来理解。ReAct 是员工接到任务后一边想一边干每干一小步都要停下来问老板我这么做对不对或者干脆自己猜Plan 模式是员工接到任务后先写一份方案给你确认方案通过后执行只在中间发现关键偏差时才回来找你。前者适合探索性强、没有标准流程的任务后者才适合企业里那些需要稳定交付的业务链路。2.2 规划器怎么设计任务拆分与依赖编排规划器是 Plan 模式的发动机。我们单独给它设计了一套 Prompt 模板并强制用结构化输出。它要做四件事识别用户请求中的实体与约束、把目标拆成若干子任务、标出子任务之间的依赖关系、为每个子任务选择最合适的执行者。规划器输出的 JSON 结构大概长这样{ plan_id: plan_20240617001, goal: 处理售后工单 SR20240617001判断是否满足退货条件并生成处理建议, tasks: [ { task_id: t1, description: 获取订单基本信息与商品SKU, depends_on: [], assignee: order_agent, estimated_steps: 3 }, { task_id: t2, description: 获取物流签收状态与时效数据, depends_on: [t1], assignee: logistics_agent, estimated_steps: 2 }, { task_id: t3, description: 结合订单和物流信息判断退货条件是否满足, depends_on: [t1, t2], assignee: policy_agent, estimated_steps: 4 } ] }为什么必须是 JSON 而不是自然语言因为自然语言计划没法稳定地去重、排序和校验。有了结构化输出我们才能在交给执行器之前先做一次静态校验检查依赖有没有环、有没有子任务没分配到执行者。这一步把大量低级错误挡在了模型调用之外而不是等模型执行到一半才发现计划是错的。2.3 计划执行与动态重规划计划不是执行一次就固定的。我们设计了两个触发重规划的条件一是执行某个子任务失败且重试两次仍然失败二是执行过程中拿到了关键信息发现后续任务依赖的基础变了。比如物流 Agent 查到订单其实还没发货那原来结合签收状态判断退货条件这个任务就失去了意义必须重新规划。重规划不是从零开始而是把已完成的任务结果作为上下文只对剩余任务做重新拆分。为了控制成本我们设了硬性上限一轮任务最多重规划两次超过之后整条链路转人工队列不再让模型瞎试。这里给所有团队提个醒动态重规划如果做得太积极本质上又回到了 ReAct 那种高 token 消耗模式所以规则一定要比想象中更保守。3. 主子 Agent 协作主控拆解执行者专注3.1 为什么不做全对等架构社区里很多 MultiAgent 示例是多个 Agent 自由对话让它们在对话中自发形成分工。这种模式在开放式写作、头脑风暴类任务里效果确实不错但企业内部系统不是这么运转的。企业内部天然有流程、有审批、有职责边界你不可能让一个商品信息审核 Agent 自己去调支付系统和退换货接口。全对等架构还有两个致命问题。一是责任不明确任务完成了说不清是谁的核心贡献任务失败了你找不到可以问责的环节。二是安全边界模糊所有 Agent 都拥有差不多能力攻击面被放大。所以我们最终确定了主子 Agent 架构主 Agent 只做编排和裁决子 Agent 只做执行身份和权限严格分离。3.2 主 Agent 的职责边界主 Agent 做四件事理解用户请求、调用规划器生成计划、把子任务分发给子 Agent、收集结果并产出最终结论。关键设计是主 Agent 不做具体的业务计算也不直接调业务工具。它只做编排和裁决。比如子 Agent 返回了一个不确定的结果主 Agent 要决定是让它重做、降级还是转人工。为了实现这个能力我们给主 Agent 的输入里增加了两个关键上下文当前计划状态表和已完成的子任务摘要。主 Agent 不需要理解每一个子领域的所有细节只需要理解计划是什么、状态是什么、结果是否可信。这个设计让主 Agent 的 Prompt 保持相对短也避免了主 Agent 因为上下文过长而忘事。3.3 子 Agent 的注册与调度机制子 Agent 不是写死在代码里的而是以注册表的形式存在。每个子 Agent 需要提供能力描述、输入输出 Schema、可访问的工具白名单、超时时间、最大重试次数。主控在分配子任务时先根据规划器产出的 assignee 字段去注册表里做精确匹配匹配不到就退化为能力描述向量检索再不行才走重规划。这一步解决了企业场景里工具越来越多、Agent 越来越难维护的问题新业务接进来只需要注册新的子 Agent不需要改主控代码。注册表里的记录大概长这样{ agent_id: order_agent, name: 订单信息查询专用Agent, capabilities: [订单详情查询, SKU信息解析, 订单状态变更], input_schema: { order_id: string }, output_schema: { status: string, data: object, confidence: float }, allowed_tools: [order.query.detail, sku.query.info], timeout_seconds: 15, max_retries: 2 }3.4 结果回传与最终汇总子 Agent 执行完毕后回传一个结构化结果字段包括 status、summary、data、confidence。主 Agent 根据这些字段决定怎么汇总如果某个子 Agent 的结果 confidence 偏低主 Agent 会要求它补充说明或者重新执行。最终输出由主 Agent 统一生成避免了多个子 Agent 各自输出一份风格不一致的报告。我们在实际使用中发现这个统一出口的设计特别重要。它不仅让用户面对的是一个整体而不是一堆 Agent 的拼凑结果还让后期做审计、做反馈闭环都有了明确的锚点。用户的每一次反馈都能对回到某一次计划、某一个子任务、某一个子 Agent 的某一次输出上。4. 企业级落地最容易被忽略的工程细节4.1 状态管理与上下文隔离MultiAgent 系统本质上是一个分布式异步系统状态管理做不好后患无穷。我们给每个任务建了一个状态对象包含 task_id、plan、execution_status、context_buckets 几个核心字段。所有子 Agent 的输入输出都围绕这个状态对象读写。这里最想强调的一点是上下文隔离。子 Agent A 执行中产生的中间数据默认只存在于自己的私有上下文只有当它显式写入共享状态区的时候主控才能把它交给子 Agent B。这么做的原因是防止幻觉扩散——如果 A 产生了一个错误结论而 B 无条件接受了这个结论错误就会沿着链路传播下去最后出来的结果根本没法查。上下文隔离还有一个好处节省 token。子 Agent 的 Prompt 只包含它需要的私有上下文和必要的全局摘要而不是全部历史会话。不要让子 Agent 背着整套会话记录干活否则最后一个子任务永远在超长上下文里挣扎。4.2 可观测性没有 Trace 的 MultiAgent 是黑盒MultiAgent 是异步事件流不能用传统翻日志找关键字的方式排查问题。我们从第一版开始就定下了铁律每一次规划、每一次子 Agent 调用、每一次工具调用都必须产出结构化事件事件里带 request_id 和 task_id这样才能把一次任务的完整轨迹串起来。上线第一天必须接齐指标、日志、链路追踪三件套。我们重点盯的指标包括规划耗时、子 Agent 执行耗时、工具调用成功率、重规划次数、上下文 token 消耗。曾经靠这些指标在几分钟内定位了一个看起来没有报错但整体耗时特别长的任务最后发现是一个子 Agent 等了 14 秒超时而它的超时时间被配置成了 30 秒相当于每次调用都白白浪费了一次超时等待。4.3 容错与降级设计部分失败不能整体重来每个子 Agent 调用都有超时控制超时后触发重试重试策略采用带抖动指数的退避避免多个子 Agent 同时重试打爆下游系统。重试仍然失败后走降级逻辑如果该子任务不阻塞后续链路就标记为 skipped并在最终结果里向用户说明缺失了哪部分信息如果阻塞触发重规划重规划达到上限整条链路挂起转人工队列。核心原则就一句话任何一步都不能让整条链路的 token 白白烧掉。我们见过不少团队一个子任务失败了不处理主 Agent 还在那儿硬等最后整条任务挂死用户那边只看到一个超时。合理的降级路径比完美的模型输出更重要。4.4 权限管控主 Agent 没权子 Agent 最小权限子 Agent 的工具白名单不只是功能上的约定必须落地到内部的权限体系。我们给每个子 Agent 分配一个独立的服务账号服务账号只有最小权限。主 Agent 本身没有任何工具权限它只能通过调度层调用子 Agent。这个设计的直接好处是即使某个子 Agent 被 Prompt 注入攻击损失也被限制在它自己的工具集范围内不可能通过主 Agent 横向移动到其他系统。我们在一次内部演练中真的模拟过这种攻击效果是边界守住了但同时也发现只要有一个子 Agent 的工具集过宽边界就会出现漏洞因此权限最小化必须落到每一个子 Agent 上而不是只约束主 Agent。5. 实测踩坑记录与完整排查链路5.1 Token 爆炸规划循环陷入假执行死循环首次压测时我们发现跑一条长链路任务token 消耗异常高一次任务烧掉的成本远超预期。一开始以为只是模型输入太长直到拉出规划事件才发现同一个任务在完整执行过程中重规划次数被触发了几十次而且每次都像模像样地拆了新的子任务但实质上一直在原地打转。顺着这个线索继续查根因出现在 confidence 字段上。子 Agent 在成功返回结果后经常带着一个 confidence: low 的标记主 Agent 的统一策略是一看到 low 就要求重做而重做的子 Agent 又把整段上下文和工具返回内容重新接收了一遍token 直接翻倍数量多了以后就成了灾难。修复方案分两步走。第一步调整 confidence 的使用规范只有执行发生异常、输出明显偏离预期、或数据源头不完整时才允许标低正常执行默认标 high。第二步子 Agent 重做时只携带摘要上下文不再携带完整工具返回内容让重做的成本降下来。改完之后单任务平均 token 消耗降了四成左右。5.2 上下文污染子 Agent 之间传染错误结论另一个典型问题是上下文污染。某次线上任务里Agent B 生成的数据里带着 Agent A 的错误结论。最初看事件日志两边执行都是成功的也没有任何报错但结果就是不对。通过链路追踪还原现场后我们看到了问题全貌。Agent A 虽然结论错误但它把这个结论写进了共享状态区Agent B 读取共享状态后因为 Prompt 里没有你要质疑上游数据的指令模型默认倾向于沿用已有信息错误就这样被悄悄放大了。这也是为什么现在的共享状态区里每条数据都强制附带来源字段和置信度同时子 Agent 的 Prompt 里加了一条硬性规则如果依赖的数据置信度偏低必须在输出里显式标注基于低置信度数据。加了这条规则之后主 Agent 看到标注会返回上游重新执行把错误在源头就掐掉。这个改动没有增加任何模型能力只是靠系统约束把错误传播路径截断了最终准确率的提升却非常明显。5.3 权限分不清服务账号权限比工具白名单大得多有一次灰度测试一个子 Agent 调用了它不该调的接口当时第一反应是 Prompt 没写清楚让子 Agent 越权了。但把同样 Prompt 放到沙箱里反复测怎么都复现不出来。后来去查服务账号权限发现这个子 Agent 对应的服务账号拥有一组过大的权限工具白名单在代码里限制了但底层账号权限配置没跟上。也就是说子 Agent 在调度层被白名单约束住了但它拿到账号凭证之后在接口层面依然有大范围调用能力。模型在极端情况下被引导调用越权接口时底层的权限体系根本没拦住。修复方案很直接工具白名单和服务账号权限做双绑定每次服务启动时自动校验两者是否一致不一致直接拒绝启动宁可让服务不可用也不带着隐患上线。这个坑让我们把安全配置从上线前检查一遍升级成了原则上强制一致性校验。5.4 优化后的直观效果这几个问题修完之后我们又跑了两轮压测和一轮线上灰度整体指标变化很明显。下面是我们内部统计的一组相对数据不是绝对精确值但趋势很能说明问题指标修复前修复后单任务平均 token 消耗基准下降约 40%链路级重规划率约 18%约 5%人工介入率约 12%约 3%子 Agent 一次执行成功率约 74%约 92%人工介入率从 12% 降到 3% 是最关键的成果。这意味着系统真正从需要人盯着跑变成了可以放心交给它跑。要知道MultiAgent 类项目在团队里能走多远看的不是 Demo 多炫而是维护成本降到什么程度降不下来就会被砍掉。6. 这套架构之后还能往哪里演进6.1 从固定规划到自适应规划目前的规划器依赖一套规则和模板子任务的拆解方式基本固定。我们在探索的方向是让规划器从历史执行数据里学习自动调整拆解粒度。比如有的任务链路稳定、结果可靠就可以拆得更粗一点减少调度开销有的任务经常出问题、经常需要重规划就自动拆得更细让每一步都有明确的验证点。另一个方向是给主子 Agent 架构加一层记忆系统让每次执行的经验能沉淀下来。比如某个子 Agent 在处理特定类型的订单时经常返回低置信度主 Agent 下次遇到同类任务就会自动降低对它的信任权重甚至提前转人工。这套机制做好了系统会越用越聪明而不是每次都在同一个地方跌倒。6.2 给打算做企业级 MultiAgent 的团队几句真心话如果你正准备把一个 MultiAgent 项目推到生产我的建议是先把规划器做扎实再把主从架构做清晰最后再谈模型选型和效果优化。绝大多数项目翻车不是模型选得不好而是控制结构太弱、状态管理太乱、可观测性几乎没有。还有一点经验是Agent 的 Prompt 不能当作文档来维护要当代码来维护它应该有版本、有测试、有评审。我们每次改动主 Agent 或规划器的 Prompt都要先在离线数据集上跑回归对比输出结构和关键字段的准确率确认没有变差才允许上线。最后再分享一个小技巧给每个子 Agent 加上一个能力边界描述告诉它什么情况下应该拒绝执行而不是硬着头皮生成结果。很多模型幻觉都出在它不知道自己不该做这件事上把这个边界写到 Prompt 里比事后加校验规则省心得多。这套架构在得物内部跑稳定之后我们已经在把它往更多业务场景复制后续有机会再单独写一篇不同场景下的适配经验。
做 MultiAgent 的人很多真正敢把它放到生产环境里的团队没几个。这不是模型能力跟不上而是工程化难度被严重低估了。去年我们在得物内部启动了一个 MultiAgent 项目目标是让一组不同职责的 Agent 协作完成一条完整的业务链路。跑通 Demo 只花了三天但从 Demo 到稳定支撑真实业务前后折腾了接近两个月中途推翻了两版架构。最终沉淀下来的核心经验就是两件事用Plan 模式替代自由发挥式的 ReAct 连招用主子 Agent 协作替代全对等的多 Agent 网络。这篇文章把这套企业级 MultiAgent 落地方案掰开讲清楚。内容包含 Plan 模式的规划器怎么设计、主 Agent 与子 Agent 的职责边界和协作机制、状态管理与可观测性这些工程细节还有我们实际踩过的三个大坑和完整的排查链路。适合正在做 MultiAgent 应用、或者准备把 Agent 从 Demo 推到生产的团队参考哪怕你只是刚接触这个概念也能从中理解为什么很多开源项目跑得欢、一上生产就翻车。1. 为什么 MultiAgent 项目大多死在 Demo 阶段1.1 单 Agent 的瓶颈不是模型不够强而是上下文不够用企业级业务里一个复杂任务往往要跨多个系统、查多种数据、做多步决策。拿我们做过的一条工单链路来说用户发起售后申请系统要先判断是否符合退货条件再调取订单、物流、商品快照、历史售后记录综合给出处理意见最后还要生成一条工单同步给客服。如果让一个 Agent 从头做到尾它会在这个长链路里反复切换上下文一个小时内还没处理完上下文窗口就见底了。即便窗口塞得下模型也容易忘掉开头的信息出现做着做着就把用户需求改了的情况。单 Agent 不是不能做这些事而是它的上下文是单一连续的长链路会把它拖垮。这就像让一个实习生从销售、仓储、客服、财务的活全部一个人扛不是能力问题是精力终归有限。MultiAgent 解决的就是这个结构性问题把一个大任务拆成多个小任务让每个 Agent 只负责自己擅长的那一段。1.2 多 Agent 失败的三个典型特征我们调研和拆解了不少社区里的 MultiAgent 项目包括早期比较火、后来热度降下来的那些自主 Agent 项目。它们失败有三个共性特征。第一Agent 之间全对等任务没人兜底彼此之间的对话很容易聊跑偏。几个 Agent 凑在一起聊着聊着就偏了最后产出结果往往只能靠运气。第二没有明确的计划层每个 Agent 都是走一步看一步碰到分支情况就让模型临场发挥随机性非常大同样的输入跑两次结果可能完全不同。第三几乎没有工程化的观测和恢复能力。Agent 一旦进入错误分支整个链路只能靠人肉重启日志不结构化链路追踪不存在出问题之后去复盘成本极高。这三个特征本质问题不在模型而在于整个系统的控制结构太弱。这也是为什么我们后来果断放弃了第一版的全对等架构改成主从控制流。1.3 我们为什么敢在得物内部推 MultiAgent选择运营工单处理这个场景是因为它有几个特点链路长、依赖多个内部系统、对准确率要求高但对时延的容忍度相对较高。这类场景天然适合一个人做主编排、多个专项 Agent 干活的模式。如果连这种链路都处理不好那再往上做经营分析、风控决策之类更复杂的场景就更不用谈了。当时内部其实已经有成熟的大模型单点应用比如对话助手、信息抽取但都是单点能力属于会聊天不是会干活。我们想做一个真正能按流程完成任务的系统把模型从回答问题推进到完成项目。这个目标本身就决定了我们必须要有一套任务规划机制而不是让模型自由发挥。2. Plan 模式先想清楚再动手而不是边做边改2.1 从 ReAct 到 Plan一次踩出来的认知升级初版我们用的是 ReAct 模式模型每一步都先推理再行动。Demo 阶段跑起来很爽看起来很灵活但上了生产环境之后这种灵活性变成了灾难。一个真实任务可能涉及十几个工具调用ReAct 每步都要重新读一遍当前局面调用一多token 消耗是计划模式的数倍而且成本只是其中之一更麻烦的是它路径依赖太强。ReAct 的下一步完全取决于上一步的结果一旦某一步模型输出一个奇怪的选择后面就全跑偏了。你得靠日志去倒推是第几步出了问题而这通常要花掉比重新跑一遍还多的时间。后来我们调整思路换成 Plan-and-Execute先让模型把任务拆成一份明确的计划然后按照计划逐步执行执行过程中允许在特定节点重新规划但不会每个动作都重新想一遍。这个转变可以用一个类比来理解。ReAct 是员工接到任务后一边想一边干每干一小步都要停下来问老板我这么做对不对或者干脆自己猜Plan 模式是员工接到任务后先写一份方案给你确认方案通过后执行只在中间发现关键偏差时才回来找你。前者适合探索性强、没有标准流程的任务后者才适合企业里那些需要稳定交付的业务链路。2.2 规划器怎么设计任务拆分与依赖编排规划器是 Plan 模式的发动机。我们单独给它设计了一套 Prompt 模板并强制用结构化输出。它要做四件事识别用户请求中的实体与约束、把目标拆成若干子任务、标出子任务之间的依赖关系、为每个子任务选择最合适的执行者。规划器输出的 JSON 结构大概长这样{ plan_id: plan_20240617001, goal: 处理售后工单 SR20240617001判断是否满足退货条件并生成处理建议, tasks: [ { task_id: t1, description: 获取订单基本信息与商品SKU, depends_on: [], assignee: order_agent, estimated_steps: 3 }, { task_id: t2, description: 获取物流签收状态与时效数据, depends_on: [t1], assignee: logistics_agent, estimated_steps: 2 }, { task_id: t3, description: 结合订单和物流信息判断退货条件是否满足, depends_on: [t1, t2], assignee: policy_agent, estimated_steps: 4 } ] }为什么必须是 JSON 而不是自然语言因为自然语言计划没法稳定地去重、排序和校验。有了结构化输出我们才能在交给执行器之前先做一次静态校验检查依赖有没有环、有没有子任务没分配到执行者。这一步把大量低级错误挡在了模型调用之外而不是等模型执行到一半才发现计划是错的。2.3 计划执行与动态重规划计划不是执行一次就固定的。我们设计了两个触发重规划的条件一是执行某个子任务失败且重试两次仍然失败二是执行过程中拿到了关键信息发现后续任务依赖的基础变了。比如物流 Agent 查到订单其实还没发货那原来结合签收状态判断退货条件这个任务就失去了意义必须重新规划。重规划不是从零开始而是把已完成的任务结果作为上下文只对剩余任务做重新拆分。为了控制成本我们设了硬性上限一轮任务最多重规划两次超过之后整条链路转人工队列不再让模型瞎试。这里给所有团队提个醒动态重规划如果做得太积极本质上又回到了 ReAct 那种高 token 消耗模式所以规则一定要比想象中更保守。3. 主子 Agent 协作主控拆解执行者专注3.1 为什么不做全对等架构社区里很多 MultiAgent 示例是多个 Agent 自由对话让它们在对话中自发形成分工。这种模式在开放式写作、头脑风暴类任务里效果确实不错但企业内部系统不是这么运转的。企业内部天然有流程、有审批、有职责边界你不可能让一个商品信息审核 Agent 自己去调支付系统和退换货接口。全对等架构还有两个致命问题。一是责任不明确任务完成了说不清是谁的核心贡献任务失败了你找不到可以问责的环节。二是安全边界模糊所有 Agent 都拥有差不多能力攻击面被放大。所以我们最终确定了主子 Agent 架构主 Agent 只做编排和裁决子 Agent 只做执行身份和权限严格分离。3.2 主 Agent 的职责边界主 Agent 做四件事理解用户请求、调用规划器生成计划、把子任务分发给子 Agent、收集结果并产出最终结论。关键设计是主 Agent 不做具体的业务计算也不直接调业务工具。它只做编排和裁决。比如子 Agent 返回了一个不确定的结果主 Agent 要决定是让它重做、降级还是转人工。为了实现这个能力我们给主 Agent 的输入里增加了两个关键上下文当前计划状态表和已完成的子任务摘要。主 Agent 不需要理解每一个子领域的所有细节只需要理解计划是什么、状态是什么、结果是否可信。这个设计让主 Agent 的 Prompt 保持相对短也避免了主 Agent 因为上下文过长而忘事。3.3 子 Agent 的注册与调度机制子 Agent 不是写死在代码里的而是以注册表的形式存在。每个子 Agent 需要提供能力描述、输入输出 Schema、可访问的工具白名单、超时时间、最大重试次数。主控在分配子任务时先根据规划器产出的 assignee 字段去注册表里做精确匹配匹配不到就退化为能力描述向量检索再不行才走重规划。这一步解决了企业场景里工具越来越多、Agent 越来越难维护的问题新业务接进来只需要注册新的子 Agent不需要改主控代码。注册表里的记录大概长这样{ agent_id: order_agent, name: 订单信息查询专用Agent, capabilities: [订单详情查询, SKU信息解析, 订单状态变更], input_schema: { order_id: string }, output_schema: { status: string, data: object, confidence: float }, allowed_tools: [order.query.detail, sku.query.info], timeout_seconds: 15, max_retries: 2 }3.4 结果回传与最终汇总子 Agent 执行完毕后回传一个结构化结果字段包括 status、summary、data、confidence。主 Agent 根据这些字段决定怎么汇总如果某个子 Agent 的结果 confidence 偏低主 Agent 会要求它补充说明或者重新执行。最终输出由主 Agent 统一生成避免了多个子 Agent 各自输出一份风格不一致的报告。我们在实际使用中发现这个统一出口的设计特别重要。它不仅让用户面对的是一个整体而不是一堆 Agent 的拼凑结果还让后期做审计、做反馈闭环都有了明确的锚点。用户的每一次反馈都能对回到某一次计划、某一个子任务、某一个子 Agent 的某一次输出上。4. 企业级落地最容易被忽略的工程细节4.1 状态管理与上下文隔离MultiAgent 系统本质上是一个分布式异步系统状态管理做不好后患无穷。我们给每个任务建了一个状态对象包含 task_id、plan、execution_status、context_buckets 几个核心字段。所有子 Agent 的输入输出都围绕这个状态对象读写。这里最想强调的一点是上下文隔离。子 Agent A 执行中产生的中间数据默认只存在于自己的私有上下文只有当它显式写入共享状态区的时候主控才能把它交给子 Agent B。这么做的原因是防止幻觉扩散——如果 A 产生了一个错误结论而 B 无条件接受了这个结论错误就会沿着链路传播下去最后出来的结果根本没法查。上下文隔离还有一个好处节省 token。子 Agent 的 Prompt 只包含它需要的私有上下文和必要的全局摘要而不是全部历史会话。不要让子 Agent 背着整套会话记录干活否则最后一个子任务永远在超长上下文里挣扎。4.2 可观测性没有 Trace 的 MultiAgent 是黑盒MultiAgent 是异步事件流不能用传统翻日志找关键字的方式排查问题。我们从第一版开始就定下了铁律每一次规划、每一次子 Agent 调用、每一次工具调用都必须产出结构化事件事件里带 request_id 和 task_id这样才能把一次任务的完整轨迹串起来。上线第一天必须接齐指标、日志、链路追踪三件套。我们重点盯的指标包括规划耗时、子 Agent 执行耗时、工具调用成功率、重规划次数、上下文 token 消耗。曾经靠这些指标在几分钟内定位了一个看起来没有报错但整体耗时特别长的任务最后发现是一个子 Agent 等了 14 秒超时而它的超时时间被配置成了 30 秒相当于每次调用都白白浪费了一次超时等待。4.3 容错与降级设计部分失败不能整体重来每个子 Agent 调用都有超时控制超时后触发重试重试策略采用带抖动指数的退避避免多个子 Agent 同时重试打爆下游系统。重试仍然失败后走降级逻辑如果该子任务不阻塞后续链路就标记为 skipped并在最终结果里向用户说明缺失了哪部分信息如果阻塞触发重规划重规划达到上限整条链路挂起转人工队列。核心原则就一句话任何一步都不能让整条链路的 token 白白烧掉。我们见过不少团队一个子任务失败了不处理主 Agent 还在那儿硬等最后整条任务挂死用户那边只看到一个超时。合理的降级路径比完美的模型输出更重要。4.4 权限管控主 Agent 没权子 Agent 最小权限子 Agent 的工具白名单不只是功能上的约定必须落地到内部的权限体系。我们给每个子 Agent 分配一个独立的服务账号服务账号只有最小权限。主 Agent 本身没有任何工具权限它只能通过调度层调用子 Agent。这个设计的直接好处是即使某个子 Agent 被 Prompt 注入攻击损失也被限制在它自己的工具集范围内不可能通过主 Agent 横向移动到其他系统。我们在一次内部演练中真的模拟过这种攻击效果是边界守住了但同时也发现只要有一个子 Agent 的工具集过宽边界就会出现漏洞因此权限最小化必须落到每一个子 Agent 上而不是只约束主 Agent。5. 实测踩坑记录与完整排查链路5.1 Token 爆炸规划循环陷入假执行死循环首次压测时我们发现跑一条长链路任务token 消耗异常高一次任务烧掉的成本远超预期。一开始以为只是模型输入太长直到拉出规划事件才发现同一个任务在完整执行过程中重规划次数被触发了几十次而且每次都像模像样地拆了新的子任务但实质上一直在原地打转。顺着这个线索继续查根因出现在 confidence 字段上。子 Agent 在成功返回结果后经常带着一个 confidence: low 的标记主 Agent 的统一策略是一看到 low 就要求重做而重做的子 Agent 又把整段上下文和工具返回内容重新接收了一遍token 直接翻倍数量多了以后就成了灾难。修复方案分两步走。第一步调整 confidence 的使用规范只有执行发生异常、输出明显偏离预期、或数据源头不完整时才允许标低正常执行默认标 high。第二步子 Agent 重做时只携带摘要上下文不再携带完整工具返回内容让重做的成本降下来。改完之后单任务平均 token 消耗降了四成左右。5.2 上下文污染子 Agent 之间传染错误结论另一个典型问题是上下文污染。某次线上任务里Agent B 生成的数据里带着 Agent A 的错误结论。最初看事件日志两边执行都是成功的也没有任何报错但结果就是不对。通过链路追踪还原现场后我们看到了问题全貌。Agent A 虽然结论错误但它把这个结论写进了共享状态区Agent B 读取共享状态后因为 Prompt 里没有你要质疑上游数据的指令模型默认倾向于沿用已有信息错误就这样被悄悄放大了。这也是为什么现在的共享状态区里每条数据都强制附带来源字段和置信度同时子 Agent 的 Prompt 里加了一条硬性规则如果依赖的数据置信度偏低必须在输出里显式标注基于低置信度数据。加了这条规则之后主 Agent 看到标注会返回上游重新执行把错误在源头就掐掉。这个改动没有增加任何模型能力只是靠系统约束把错误传播路径截断了最终准确率的提升却非常明显。5.3 权限分不清服务账号权限比工具白名单大得多有一次灰度测试一个子 Agent 调用了它不该调的接口当时第一反应是 Prompt 没写清楚让子 Agent 越权了。但把同样 Prompt 放到沙箱里反复测怎么都复现不出来。后来去查服务账号权限发现这个子 Agent 对应的服务账号拥有一组过大的权限工具白名单在代码里限制了但底层账号权限配置没跟上。也就是说子 Agent 在调度层被白名单约束住了但它拿到账号凭证之后在接口层面依然有大范围调用能力。模型在极端情况下被引导调用越权接口时底层的权限体系根本没拦住。修复方案很直接工具白名单和服务账号权限做双绑定每次服务启动时自动校验两者是否一致不一致直接拒绝启动宁可让服务不可用也不带着隐患上线。这个坑让我们把安全配置从上线前检查一遍升级成了原则上强制一致性校验。5.4 优化后的直观效果这几个问题修完之后我们又跑了两轮压测和一轮线上灰度整体指标变化很明显。下面是我们内部统计的一组相对数据不是绝对精确值但趋势很能说明问题指标修复前修复后单任务平均 token 消耗基准下降约 40%链路级重规划率约 18%约 5%人工介入率约 12%约 3%子 Agent 一次执行成功率约 74%约 92%人工介入率从 12% 降到 3% 是最关键的成果。这意味着系统真正从需要人盯着跑变成了可以放心交给它跑。要知道MultiAgent 类项目在团队里能走多远看的不是 Demo 多炫而是维护成本降到什么程度降不下来就会被砍掉。6. 这套架构之后还能往哪里演进6.1 从固定规划到自适应规划目前的规划器依赖一套规则和模板子任务的拆解方式基本固定。我们在探索的方向是让规划器从历史执行数据里学习自动调整拆解粒度。比如有的任务链路稳定、结果可靠就可以拆得更粗一点减少调度开销有的任务经常出问题、经常需要重规划就自动拆得更细让每一步都有明确的验证点。另一个方向是给主子 Agent 架构加一层记忆系统让每次执行的经验能沉淀下来。比如某个子 Agent 在处理特定类型的订单时经常返回低置信度主 Agent 下次遇到同类任务就会自动降低对它的信任权重甚至提前转人工。这套机制做好了系统会越用越聪明而不是每次都在同一个地方跌倒。6.2 给打算做企业级 MultiAgent 的团队几句真心话如果你正准备把一个 MultiAgent 项目推到生产我的建议是先把规划器做扎实再把主从架构做清晰最后再谈模型选型和效果优化。绝大多数项目翻车不是模型选得不好而是控制结构太弱、状态管理太乱、可观测性几乎没有。还有一点经验是Agent 的 Prompt 不能当作文档来维护要当代码来维护它应该有版本、有测试、有评审。我们每次改动主 Agent 或规划器的 Prompt都要先在离线数据集上跑回归对比输出结构和关键字段的准确率确认没有变差才允许上线。最后再分享一个小技巧给每个子 Agent 加上一个能力边界描述告诉它什么情况下应该拒绝执行而不是硬着头皮生成结果。很多模型幻觉都出在它不知道自己不该做这件事上把这个边界写到 Prompt 里比事后加校验规则省心得多。这套架构在得物内部跑稳定之后我们已经在把它往更多业务场景复制后续有机会再单独写一篇不同场景下的适配经验。
