把 MultiAgent 从 Demo 挪进生产环境是我这两年见过“翻车率”最高的技术工程之一。很多人拿着 AutoGPT 的效果惊艳全场一到真实业务场景就崩成筛子计划乱飞、Agent 各说各话、Token 成本飙到吓人、出了问题连锅都甩不清楚。这也是我看到得物技术团队分享的《企业级 MultiAgent 落地Plan 模式与主子 Agent 协作》时觉得特别值得拆一拆的原因——他们没聊炫技讲的都是把多 Agent 框架“摁”进业务系统里解决实际问题的方法核心就两个关键词Plan 模式、主子 Agent 协作。这篇文章里我会从架构选型逻辑、Plan 模式的运行机制、主子 Agent 的职责划分与通信设计、以及实际工程落地中的成本、校验、可观测性这些细节一层层掰开揉碎地讲。如果你正在做 LLM 应用后端、准备把多 Agent 接到真实业务流程里或者只是被“多智能体”这个概念吸引但不知道从哪下手这篇内容应该能给你一套可以直接参考的落地方案。1. 项目背景与架构选型为什么 Plan 模式在企业里能跑通1.1 从“会聊天”到“能干成事”MultiAgent 差在哪先说个现象。单 Agent单智能体做客服、做内容助手、做数据分析问答大家基本都摸出门道了一个大模型 合适的 Prompt 几个工具调用就能应付不少场景。但一旦任务链条变长、涉及多个系统、需要分步决策单 Agent 就开始露怯——要么上下文爆炸要么任务做到一半忘了初衷要么在一个小分支上反复横跳。MultiAgent多智能体的想法很自然既然一个人干不完那就上多个“人”分工协作。听起来很美实际做起来你会发现多 Agent 的难点根本不是“Agent 的数量”而是“协作的秩序”。我见过很多团队一上来就搭了四五个 Agent结果每个 Agent 都在抢同一个工具、都在维护同一份“记忆”主模型根本不知道该听谁的最后输出质量反而比单 Agent 更差。为什么因为大家直接把 Autonomy自主性拉满了。让每个 Agent 都自由发挥等于把公司里所有人都叫到一起开会但没有主持人、没有议题、没有决策机制——会开得再热烈也落不了地。得物技术那篇文章里点到一个关键企业级场景要的不是“各自为政的聪明人”而是“有队长、有分工、有流程的执行团队”。所以他们会选 Plan 模式会强调主子 Agent 的层级关系这不是保守是被生产环境教育后的理性选择。1.2 Plan 模式与自由式 Agent 的核心差异要理解 Plan 模式先得对比一下另一种风格Plan-and-Execute 的对立面大致可以叫“自由式 ReAct”。ReAct 的思路是“边想边做”模型观察到环境反馈决定下一步动作然后循环往复。这种方式在 OpenAI 的 function calling、LangChain 的 Agent 里很常见灵活性很高缺点也同样明显不确定性大、流程不可控、成本不可预期而且每一步都可能偏离原始目标。Plan 模式则更接近项目管理先定方案再分步执行。它把“思考”和“执行”解耦成两个阶段由主 Agent 先产出完整计划再逐一执行各步骤。这样做有几个直接好处可控。计划是显式的业务方能审查、能干预而不是只知道“模型正在思考”。可跟踪。每一步对应一个子任务出问题能定位到具体环节。省钱。不需要每一步都在全量上下文里来回翻滚计划阶段一次性规划执行阶段按步骤消费 Token。可兜底。计划里每一步都可以设前置条件、校验规则、失败策略工程上好做防御。当然Plan 模式也有代价——它牺牲了一部分“实时应变能力”。比如用户中途改需求或者步骤之间出现预料外的依赖Plan 模式需要额外的 Replan 机制来补位。所以真正生产级的 Plan 模式从来不只是“生成一次计划然后闭眼执行”而是一套有状态、可修正的执行体系这点后面我会展开讲。1.3 得物技术这篇文章里的两个关键词为什么值得单独拆“Plan 模式”对应的是一整套任务编排机制“主子 Agent”对应的是多 Agent 之间如何分权、如何沟通。这两个设计合在一起解决了我前面说的两类问题一是流程失控二是角色混乱。得物是电商业务他们的 MultiAgent 不是做聊天玩具而是接订单、售后、营销这些高敏业务场景。在这些场景里你不能接受模型“灵机一动”随便改规则也不能接受一个 Agent 把订单状态改到一半就“失忆”。所以他们在架构上强调主 Agent 只做规划和裁决子 Agent 只做执行和专业判断两者通过明确的协议通信。说白了就是把 Agent 从“不可控的实习生”培养成“听话且各有所长的专家”。这篇文章的价值就是把这套培养体系的关键节点都讲透我这边结合实际经验再帮大家补全落地细节。2. Plan 模式的工作原理与落地拆解2.1 Plan 模式的状态流转从意图识别到结果汇总一个生产可用的 Plan 模式流程上至少要包含这几个阶段意图识别、计划生成、计划确认、分步执行、结果汇总。注意“计划确认”这一步很多人会漏掉但在企业级场景里它特别重要。意图识别用户输入进来系统先判断用户到底想干什么属于哪个领域是否需要启用 MultiAgent。不是所有请求都要走完整计划链路简单问题直接答复杂任务才进入规划器。这一步本质上是“路由”能帮你省下大量不必要的 Token。计划生成主 Agent 根据用户目标、可用工具、已有业务规则生成一个结构化的执行计划。计划的粒度要适中既不能粗到“第1步处理订单”这种废话也不能细到“第1步打开数据库连接”这种低级指令。理想情况是粒度对齐到“可复用的业务能力单元”。计划确认计划生成后系统可以做两件事。第一规则校验比如检查是否存在非法操作、是否缺少必要参数第二在关键场景里推送给用户确认用户同意后才往下执行。这一步能挡掉大量幻觉和越权操作。分步执行每个步骤交给对应的子 Agent 执行执行结果回流给主 Agent主 Agent 决定继续、修正还是提前终止。结果汇总所有步骤执行完毕后主 Agent 汇总各步骤的结果生成面向用户的最终回答。这里的汇总不是简单拼字符串而是要按照用户原始目标“做总结、给结论、写建议”。我在实际项目里通常还会加一个“成果物结构化”的环节让计划、步骤结果、最终回复都对应一份 JSON 结构而不是一坨自由文本。有结构才有办法做校验、做日志、做后续的数据分析。2.2 计划生成的质量如何保证计划生成是整个 Plan 模式的地基计划错了后面执行得再漂亮也是白搭。我在几个项目里试下来有三个手段对提升计划质量特别有效第一给主 Agent 提供“可执行的动作清单”。不要让模型凭空想象能做什么而是把所有子 Agent 和工具列成一份结构化清单包含能力名称、入参、出参、适用场景。模型基于这份真实清单做规划幻觉率会大幅下降。这一步相当于给规划器做“边界约束”它只能在清单内组合方案。第二把历史成功案例喂给规划器做 few-shot。比如“售后退差价”这类高频场景直接把过去验证过的优秀计划作为示例写进 Prompt模型规划时会优先模仿成熟路径而不是每次从零创造。从零创造听起来很智能但质量方差大成本也高。第三计划生成后做一轮“自检”或者“轻量校验”。可以分两层第一层是硬校验检查计划中每一步是否引用了已注册的能力、参数是不是合法第二层是软校验用一个小模型或者规则引擎判断步骤之间有没有明显矛盾比如“先查订单再确认价格”如果顺序反了就要修正。这套“先约束再校验”的打法能把计划生成的准确率从不可控拉到可接受的水平。2.3 计划执行中的 Replan 机制计划做得再好现实世界总会有意外。企业级系统里的“意外”尤其多下游接口超时、子 Agent 返回了非法数据、用户中途新增了条件。这时候如果整个流程直接失败重来体验很差如果硬着头皮往下走结果更差。所以要有一个 Replan 机制。Replan 的概念不复杂当某个步骤执行失败或者步骤执行的结果与计划预期严重不符时主 Agent 会重新评估当前状态生成一份“修正计划”。修正计划不是完全推翻重来而是尽可能复用已经完成的中间结果只在出问题的节点做局部调整。打个比方你安排了一个三站出游路线第一站因为景区关闭没去成。Replan 不是让你回家重新规划全程而是把第一站换成附近另一个景点第二三站保持不变。要实现这种局部纠偏有个前提每一步的执行结果必须被沉淀成“可引用的中间状态”而不是执行完就丢。这也意味着Plan 模式天生需要一个可靠的“状态管理”底座通常用 Redis 或者数据库来存计划快照、步骤状态和中间产物。我踩过的一个大坑是Replan 时主 Agent 不知道之前步骤到底做了什么。后来学乖了每一步执行完都让执行子 Agent 把“输入摘要 输出摘要 关键参数”统一写回状态存储Replan 时把摘要和当前上下文一起交给主 Agent问题就解决了。3. 主子 Agent 协作机制详解3.1 主 Agent 职责编排、下发、校验、收敛在主从架构里主 Agent也叫 Planner、Controller、超脑是“大脑”但它不是一个什么都干的“全栈大脑”而是偏“项目经理”的角色。它的核心职责可以分成四块编排根据用户目标生成计划决定执行顺序、并行关系、依赖关系。下发把具体的步骤任务派发给对应的子 Agent并且把必要的业务上下文、参数、约束条件一并传过去。校验接收子 Agent 返回的结果判断结果是否满足预期。不满足就触发重试、Replan 或者告警。收敛所有步骤结束后把分散的子结果聚合成一个完整、连贯、用户可读的最终答案。这里有个容易混淆的点主 Agent 到底该不该“亲自干活”我的建议是尽量不干。主 Agent 一旦下场做具体执行它的注意力就会被局部细节拽走从而丧失全局视角。保持主 Agent 的“只规划和验收”的定位整个系统才不容易乱。当然这会导致主 Agent 的调用偏多、决策链路变长但换来的是稳定性和可控性在企业场景里是划算的。3.2 子 Agent 职责领域专家与局部上下文子 Agent也叫 Worker、执行器是真正和业务系统、数据库、第三方 API 打交道的人。它的设计有三个关键原则。第一能力单一。一个子 Agent 只负责一个领域不要搞“全能型选手”。比如订单子 Agent 只查单、改单、处理售后营销子 Agent 只算优惠、发券、查库存。能力越收敛Prompt 越好写工具选择越简单模型越不容易混乱。第二局部上下文。子 Agent 不需要知道整个任务的来龙去脉它只需要接收“这一步的输入”和“完成这一步所需的背景信息”。这样做一方面保护了 Token——别再让执行 Agent 读一遍 5000 字的长对话了另一方面也天然做了信息隔离——订单子 Agent 能看到订单详情但不需要也不可能拿到用户所有历史聊天记录这在合规上也有意义。第三结果结构化。我要求所有子 Agent 返回结构化结果不能只给一段自然语言。比如订单状态查询 Agent就应该返回一个 JSON里面写好状态字段、变更时间、操作人、异常信息。结构化结果让主 Agent 更容易做判断也让校验逻辑更好写。子 Agent 可以附带一句自然语言的“解释”但核心数据必须走结构。3.3 通信协议与任务票据设计主子 Agent 之间的通信一定不能是“自由聊天”。生产环境里我推荐用一种轻量的“任务票据”机制。你可以把它想象成工作流里的工单主 Agent 给子 Agent 派一张任务票据子 Agent 干完活后把票据回填结果。一张任务票据至少包含这些字段taskId全局唯一标识用于追踪和日志串联。parentPlanId对应的计划 ID方便追溯整条链。agentType由哪个子 Agent 执行。input执行这个任务所需的输入参数尽量结构化比如订单 ID、用户 ID、校验规则等。expectedOutput期望的返回结构可以是一个 JSON Schema。timeoutMs超时时间避免子 Agent 卡死。status待执行、执行中、成功、失败、需要复审。result执行完成后的结构化输出。error失败时的错误码和错误信息。这张票据在代码里可以抽象成一个类也可以用消息队列来承载。它的价值在于把 Agent 之间的“对话”降维成“数据传递”。数据传递可比自由对话好追踪、好重放、好测试得多。很多团队多 Agent 协作乱就是因为主从之间在“聊大天”而不是“传工单”。你品品后者是不是更符合企业级的气质。4. 企业级落地中的工程细节4.1 上下文隔离与信息汇总前面提到过局部上下文这里我再展开一下工程实现。假设你有一个很长的用户会话总共 8000 字然后你让售后服务子 Agent 去查订单你如果把 8000 字全传给它一次调用可能就烧掉几千 Token。为了控成本我会在主 Agent 前加一层“上下文处理器”它的职责是从长会话中把当前子任务真正需要的字段提取出来组装进任务票据的 input 里。比如需要的是用户 ID、订单号、用户唯一标识那就只传这几个字段而不是传整段聊天记录。同时主 Agent 自身接收的信息也要做汇总压缩。每执行完一个步骤我会把该步骤的关键信息提炼成“摘要卡”比如“步骤2已完成查询到订单状态为已发货预计送达时间为周四”。主 Agent 做 Replan 时读的是摘要卡而不是原始数据。这个习惯能让你在长任务里不丢失全局又不至于上下文爆炸。4.2 结果校验三防设计子 Agent 的执行结果能不能信在企业级场景里默认“不能全信”。我会对每个子 Agent 的结果做三层校验结构校验Schema Check按照任务票据里的 expectedOutput用 JSON Schema 验证字段是否齐全、类型是否正确。这层能拦截 80% 的问题。规则校验Business Rule Check把业务规则写死成代码规则做硬判断。比如“补偿金额不能超过订单实付金额”“优惠券不能重复发放”这些规则不能让模型自己判断必须由代码强制校验。模型可以提建议但拍板得靠规则。语义校验Semantic Check部分非结构化内容用一个轻量模型或规则引擎判断结果是否答非所问。这层也可以做成“AI 评委”专门审查子 Agent 的回复是否偏离原始指令。三层校验都通过结果才被标记为“valid”然后回传给主 Agent。任何一层不过都会触发重试或人工介入。这套“三防”设计是我见过能显著降低 MultiAgent 事故率的工程手段强烈建议照着搭一套。4.3 成本控制与模型路由MultiAgent 成本高很多人一开始没概念。我举个简单例子如果你全程都用最强模型去跑主从两层一次有 5 个子任务的业务请求可能光模型调用成本就够买好几杯奶茶。压成本常用的手段有几个模型路由Model Routing主 Agent 的规划能力要求高用强模型子 Agent 的领域执行相对固定可以用中档模型纯提取字段、格式转换用便宜快的小模型就好。我在项目里会把模型选择做成可配置项不同任务类型挂不同模型而不是全局写死。缓存复用公共知识类的内容可以走缓存不必每次都问模型。比如商品促销规则可以定期从库里拉取喂给 Agent而不是让模型每次“现场推理”。批量合并多个独立子任务能并行的就并行减少串行等待时间也能让 Token 使用更集中。但要注意并行的子任务如果共享同一个上下文要做好隔离避免数据串扰。成本控制在 MultiAgent 里不是“抠门”而是一种架构能力。你省下来的钱可以投入到更强的主 Agent 模型上整体效果反而更好。4.4 可观测性与链路追踪多 Agent 系统最怕什么黑盒。任务失败了你拉不到日志、看不到哪一步出错、不知道是模型问题还是下游接口问题。所以可观测性建设我从第一天就会做。核心做法是引入链路追踪每个请求进来时生成一个 traceId贯穿主 Agent、所有子 Agent 调用、所有工具调用。任务票据的 taskId 和计划 ID 也都关联到 traceId 上。这样用户反馈“我买了东西但没收到补偿”时你可以通过一条日志链路看到用户输入、计划内容、每个子任务的输入输出耗时、哪一步失败、失败原因是什么。同时我建议把关键节点的结构化信息落库建一张 Agent 运行记录表traceId、planId、taskId、agentType、输入摘要、输出摘要、耗时、Token 数、结果状态、错误信息。这张表不仅用于排查问题还能用于后续的 analytics哪个环节 Token 消耗最多、哪个 Agent 失败率最高、哪个场景经常触发 Replan。有了数据优化才有方向。5. 实操案例从 Plan 生成到主子 Agent 协同完成售后退差价5.1 场景背景与系统组件为了让大家看得更具体我拿一个电商售后场景来走一遍完整流程。场景设定某平台大促结束后用户 A 通过客服入口发起诉求“我上周买的手机这周降价了 300 块能退差价吗”这个诉求涉及查询订单、比对活动规则、确认价保政策、发起退款/补偿非常适合走 MultiAgent。我们假设系统里有这几个子 AgentorderAgent查询订单、订单状态、实付金额。priceAgent查商品当前价格、历史价格、降价幅度。policyAgent查价保规则、促销规则、补偿上限。refundAgent执行退款/补偿动作需二次确认。主 Agent 负责调度这 4 个子 Agent并把最终结果整理成用户能看懂的答复。5.2 主 Agent 生成的 Plan 示例用户输入进来主 Agent 的输出是一份结构化的计划大致长这样{ planId: plan_20250101_001, goal: 为用户A处理手机降价300元的价保退款申请, steps: [ { stepId: 1, agent: orderAgent, input: { userId: A, queryKey: 最近一笔包含该手机型号的订单 }, expectedOutput: order info }, { stepId: 2, agent: priceAgent, input: { skuId: 手机SKU, scope: 近30天最低价 }, expectedOutput: price diff summary, dependsOn: [stepId:1] }, { stepId: 3, agent: policyAgent, input: { orderType: 普通订单, buyTime: 得到订单购买时间, priceDiff: 计算出来的降价金额 }, expectedOutput: refund eligibility and limit }, { stepId: 4, type: confirm, content: 向用户确认是否执行退款操作 }, { stepId: 5, agent: refundAgent, input: { orderId: 订单ID, amount: 根据政策计算, type: 价保补偿 }, expectedOutput: refund result } ] }可以看到计划里每一步都绑定了具体的 agent、input、expectedOutput步骤之间有依赖关系。主 Agent 不会自己去查订单它只负责告诉 orderAgent 去查什么。5.3 主从 Agent 协同执行与结果汇总接下来系统按照计划依次派发任务票据。这里只展示一个子 Agent 的执行过程主 Agent 派给 orderAgent 的票据简化为{ taskId: task_10001, parentPlanId: plan_20250101_001, agentType: orderAgent, input: { userId: A, queryKey: 最近一笔包含该手机型号的订单 }, expectedOutput: { orderId: string, orderTime: string, payAmount: number, orderStatus: string }, timeoutMs: 5000 }orderAgent 执行完后返回{ taskId: task_10001, status: success, result: { orderId: OD20241228001, orderTime: 2024-12-28, payAmount: 5999, orderStatus: 已完成 } }主 Agent 拿到结果后做摘要并更新计划状态接着驱动 priceAgent、policyAgent 跑后面的步骤。全部步骤跑完后主 Agent 做汇总输出给用户的话术是“查询到您 12 月 28 日购买该手机实付 5999 元当前活动价 5699 元符合 30 天价保政策可退差价 300 元。是否为您提交退款申请”并且附上结构化的结果用于前端展示。5.4 中途插单与异常处理的执行路径如果用户在第三步时打断说“等等我还有一张优惠券没用能一起处理吗”这时候系统不能假装没听见也不能把所有步骤推翻。处理方式是这样主 Agent 收到新输入后先评估当前计划状态发现步骤 1 和 2 已完成于是生成一个“追加步骤”的修正计划插入到第三步之后比如增加一个 couponAgent 来核实优惠券价值再回到原定的退款计算。Replan 的产出是一份增量的计划更新而不是全量重来。如果某一步执行失败比如 priceAgent 返回超时主 Agent 会先做一次重试重试仍失败则触发应急预案。这里我一般会让主 Agent 把失败原因和当前上下文送到“兜底服务”由兜底服务决定是转人工、延迟处理还是走异步队列重新执行。总之Plan 模式在企业场景里的可靠靠的不是单一模型“聪明”而是这一整套异常处理机制的厚度。6. 常见问题与排查技巧实录6.1 问题速查表我根据实际跑生产环境的经验把最常见的几类问题整理成了一张速查表方便遇到问题直接对照。症状可能原因排查方向解决建议计划生成很离谱步骤间逻辑矛盾主 Agent Prompt 中可用能力清单不清晰检查注入主 Agent 的工具/子 Agent 描述精简描述用统一格式写清楚输入输出边界子 Agent 总是回答“我不知道”子 Agent 上下文里缺少必需的业务参数回头看任务票据 input 是否传递完整用规则引擎在派发前校验票据必填字段同一任务反复触发 Replan无法收敛计划步骤依赖关系定义错误查 plan steps 中 dependsOn 字段做依赖检查避免循环依赖和缺失依赖Token 成本快速增长主 Agent 或子 Agent 重复接收长上下文查每次调用的 prompt 大小和完整日志做上下文摘要只传局部信息两个子 Agent 结果互相矛盾两个 Agent 使用了不同的判断口径查看各自收到的上下文和工具返回值统一数据口径必要时加全局规则约束请求高峰时任务排队严重同步调用 LLM 导致阻塞看线程池和调用链耗时把 Agent 执行改为异步任务队列模式线上偶发返回非法 JSON模型输出不稳定看返回日志和异常堆栈加 JSON 修复层或用 JSON Mode/结构化输出6.2 关于测试和灰度发布的补充测试 MultiAgent 系统最大的痛点是“不确定性”。同一个输入模型可能每次输出不同的计划和结果。我的建议是不追求 100% 相同而是建立“结果可接受性”标准。测试集里每个用例人工先标注出哪些结果可接受、哪些不可接受然后用回归测试跑分。只要跑分保持稳定或提升就认为系统是健康的。上线路径方面强烈建议走“影子模式”先在线上环境旁路把真实流量复制一份喂给 MultiAgent 系统只记录输出不真正执行操作。观察一两周确认计划生成质量、错误率、Token 成本都达标后再逐步切真实流量。切流时也建议按场景灰度比如先放 10% 的售前咨询流量再放售后处理流量最后才放涉及资金操作的场景。另外提醒一个容易忽略的点多 Agent 系统的 Prompt 和配置一定要纳入版本管理。很多时候线上出问题查了半天最后发现是某个子 Agent 的 Prompt 被人手动改了一行。Prompt 也是代码也需要走 review、测试、发布流程越早规范越好。写在最后的体会把 MultiAgent 做进企业业务里和写一个 Demo 完全是两码事。我最大的体会有两个第一不要迷恋 Agent 的数量和智能程度先把“计划生成”和“任务票据”这两条骨架搭稳系统就不会乱到哪里去第二主从结构看起来很“不酷”但它把复杂性限制在了可管理的范围内。得物技术团队这篇分享把 Plan 模式和主子 Agent 协作这两个核心机制讲得很清晰我在这基础上补充的工程细节也是希望后来者少走点弯路。最后分享一个小技巧如果你刚开始搭这套系统别急着把所有 Agent 都写上先拿一个高频、低风险的场景跑通全链路——比如“订单查询进度播报”它不需要动钱、不需要改数据非常适合做 MultiAgent 的“hello world”。跑通之后你自然会知道下一步该往哪个方向扩展。