团队在把 LLM 能力接到核心业务流程时最先跑通的往往是单 Agent 的 demo模型接几个工具能做问答、能写文案看起来什么都会。可一旦把任务拉长把工具接多问题就全出来了——任务一长就丢信息工具一多就乱调出错之后还很难定位是模型决策错了还是工具返回错了。最后我们转向了 MultiAgent 架构但落地过程中真正困难的不是多 Agent这三个字而是怎么设计 Agent 之间的协作秩序。这篇主要想聊我们在企业级场景里落 MultiAgent 时Plan 模式和主子 Agent 协作这套组合拳的设计思路、分工边界、工程化细节以及我们实际踩过的坑。1. 单 Agent 的天花板为什么是企业级的硬伤1.1 单 Agent 在长链路任务上的三类典型崩溃先说单 Agent 最让人头疼的三类问题这基本决定了企业级场景下单 Agent 方案注定走不远。第一类是信息衰减。大模型的上下文窗口虽然越做越大但真实场景里塞进去的往往是几十页的工单记录、多轮聊天历史、多个工具的返回结果。任务执行到一半模型经常表现得像是忘了最开始用户到底要什么尤其是在需要跨多轮工具调用才能完成的链路上早期沉淀的关键信息在后期决策里经常被稀释掉。第二类是工具调用的随机性。单 Agent 手里挂着十几个工具的时候模型在每一步选择哪个工具、传什么参数都是概率事件。任务简单的时候概率高任务复杂的时候一步选错后面全错而且错误还会累积。我们在测试里见过模型在明明该调查询接口的时候连续两次去调了写入接口这种错误在生成式推理里非常难根治。第三类是故障不可追溯。单 Agent 的决策链路是一个隐式的思维链它为什么选这个工具、为什么放弃那个分支事后很难通过日志清晰复盘。企业级应用出错是要有交代的模型推理过程本身是概率性的如果没有结构化的执行记录线上出了问题基本只能靠猜。1.2 企业级场景要的不是更聪明而是更可控为什么很多团队试过单 Agent 之后会放弃因为企业级场景对系统的要求跟个人效率工具完全是两回事。个人工具里Agent 猜错一次用户手动纠正一下就行。但企业流程里Agent 一旦接入生产链路就要满足三个硬约束可控性任务拆解的逻辑要能被业务方理解每一步执行的结果要能被校验可观测性任何一个节点出错都要能定位到具体是哪个 Agent、哪个输入、哪个时间点出的问题可治理性权限要隔离、成本要可控、不同职责的 Agent 要有清晰的边界。这三个约束叠加起来单 Agent一个模型搞定一切的形态天然不满足。它把规划、调用、验证、纠错全部揉在一个概率模型里企业无法在中间插入人工审核节点也没法针对某个环节单独做策略升级。1.3 MultiAgent 的本质是实现复杂任务的职责拆分MultiAgent 架构能解决这个问题本质上不是让模型变聪明了而是把一件复杂的事拆成了多个简单的事再由不同的 Agent 分别完成。拆开之后每件事都变得足够小、足够专注模型在每一个子任务上的成功率大幅提升而且每个环节都能单独观测、单独治理、单独升级模型。但拆开也有拆开的问题谁来拆拆完怎么分结果怎么合这就是 Plan 模式和主子 Agent 协作要解决的问题。2. Plan 模式让 Agent 先想清楚再动手2.1 Plan 模式与 ReAct 的根本差异在 MultiAgent 落地之前我们其实先跑通了 ReAct 模式。ReAct 的逻辑是思考一步、执行一步模型每轮观察工具返回结果再决定下一步动作。这种方式在交互性强、步骤无法预知的场景里很灵活但放到企业级流程里就暴露了问题它没有一个全局的执行蓝图每一次决策都是局部的一旦前面的步骤偏离预期后面很难拉回来。Plan 模式也叫 Plan-and-Execute先规划再执行思路是反过来的模型先不动手而是先基于目标和约束条件产出完整的执行计划再按计划逐步执行。我们用一个例子说明ReAct 模式像一个人边看地图边找路走一步看一步 Plan 模式像出发前先用地图软件规划好路线然后按路线走遇到修路再重新规划。企业级场景里Plan 模式天然更有优势。因为业务流程本身就是预先可拆解的比如客诉处理、订单审核、内容生产这些任务的步骤相对确定把执行蓝图显式生成出来无论是人工审核还是系统校验都有了抓手。2.2 一份 Plan 应该包含哪些结构化信息我们在设计 Plan 结构的时候一开始只是让模型输出一个字符串列表后面很快就发现不够用。模型输出的计划如果只是1. 做A 2. 做B执行层根本不知道每一步是谁负责、输入输出格式是什么、依赖哪个前置步骤。所以后来我们把 Plan 定成了结构化 JSON核心字段如下{ goal_summary: 对用户目标的简短重述用于后续步骤校验, steps: [ { step_id: 1, description: 解析用户工单中的问题分类, agent: classifier, input_schema: {text: string}, dependencies: [], validation_rules: [输出必须属于预置分类集合], fallback: 重新解析一次最多重试2次 }, { step_id: 2, description: 根据分类结果匹配处理策略, agent: policy_maker, input_schema: {category: string}, dependencies: [1], validation_rules: [策略必须来自策略库], fallback: 转人工审核 } ] }这个结构里最容易被忽略的是validation_rules。我们早期没加这个字段结果子 Agent 执行完返回的结果经常是看似成功、实际不对——比如让分类 Agent 从预设集合里选一个分类它自由发挥了一个集合外的标签。有了显式的校验规则主 Agent 可以直接做程序化校验不依赖模型再思考一遍结果对不对。2.3 企业级落地时Plan 模式的两个边界没踩过坑之前我们一度觉得 Plan 模式是万能的后来发现它的边界也很清晰。第一个边界是任务步骤严重依赖环境反馈。比如做数据抓取时目标网页结构未知只能边抓边看Plan 模式就没法生成靠谱的完整计划。这类场景反而是 ReAct 更合适。第二个边界是规划本身的成本。Plan 的生成要用强模型一次规划可能消耗几千 token如果任务本身就三步能完成Plan 化反而得不偿失。我们内部的判断标准很简单步骤预估超过 5 步或者涉及多个 Agent 协作才值得走 Plan 模式。3. 主子 Agent 协作把 Plan 变成可执行的组织分工3.1 主 Agent 和子 Agent 的职责边界Plan 只是蓝图真正执行需要主子 Agent 协作。这个架构大家听得比较多但主和子各自的边界到底是什么我们是在一次次踩坑中才慢慢划清楚的。主 AgentSupervisor负责三件事规划、调度、裁决。它拿到用户目标后生成 Plan执行时把 Plan 里的每个 step 分发给对应的子 Agent收到结果后判断是否合格、是否需要重新规划、整个任务是否结束。主 Agent 不直接操作业务工具它是一个管理者。子 AgentSub Agent只做一件事接收明确的子任务输入产出结构化的子任务结果。它不需要关心整个任务全貌也不需要自己判断下一步做什么只需要在自己的领域内做到最好。这两者经常被混淆的地方是主 Agent 到底要不要做业务我们早期版本里主 Agent 会自己动手做一些简单步骤结果就是主 Agent 的上下文越来越臃肿导致后续规划质量下降。后来定了一个死规矩主 Agent 永远只调度不执行所有实际操作一律下放给子 Agent。3.2 协作流程的关键节点分发、回收、裁决一个完整的协作流程大概是这样走的主 Agent 接收用户目标生成 Plan主 Agent 按依赖关系逐个取 step把step.description和input_schema组装成子任务对应子 Agent 执行子任务按约定格式返回结果主 Agent 先用validation_rules做程序化校验再对结果做语义判断校验通过进入下一步校验不通过按fallback策略处理重试、换策略、转人工所有 step 完成后主 Agent 汇总所有中间结果生成最终答案。这里有一个很多人忽略的细节子 Agent 返回结果时不只是返回答案还要返回执行置信度。我们在子 Agent 的输出协议里加了一个confidence字段0 到 1。当置信度低于阈值时主 Agent 要主动触发重试或人工兜底而不是硬着头皮往下一个 step 传。这个字段看似简单却极大减少了上一步结果错了下一步还在错误基础上继续做的问题。3.3 一个客服工单处理的实际流转拿电商客服工单场景举个例子。用户提交了一条复杂投诉商品质量问题、物流超时、退款金额不对三个问题纠缠在一起。主 Agent 生成的 Plan 大概是子 Agentclassifier先做意图拆分把这个复杂工单拆成三个子问题子 Agentorder_lookup查询订单信息确认商品、物流、退款状态子 Agentpolicy_maker针对每个子问题匹配售后策略子 Agentresponse_writer汇总所有策略生成对用户的回复主 Agent 校验策略覆盖率确认三个子问题都有回应才允许回复下发。这个流程里每一步的输入输出都是受限的policy_maker接触不到用户原始投诉全文它拿到的只是classifier拆出来的结构化子问题描述。这样做的好处很直接——子 Agent 不会被无关信息干扰也不会读取到它权限范围之外的数据。3.4 主子 Agent 的职责速查维度主 Agent子 Agent核心职责规划、调度、整体结果裁决执行特定领域的子任务上下文范围全局目标 Plan 各子任务结果摘要仅当前子任务的输入与相关数据工具权限不直接操作业务工具只能操作授权范围内的工具输出内容最终答案 / Plan 修订 / 人工兜底请求结构化子任务结果 置信度可替换性通常用更强模型可用中等模型重点在领域数据与 prompt这个表看起来简单但真正执行的时候最难拿捏的是第二行上下文范围。我们早期没控制好子 Agent 都能看到全局上下文结果就是子 Agent 偶尔自作聪明去引用主 Agent 才知道的信息导致输出结果里出现幻觉内容。4. 工程落地时最难啃的三块硬骨头4.1 上下文传递的尺度问题这是我们把 MultiAgent 推向生产时遇到的第一个真正恶心的问题主 Agent 的上下文里包含了大量信息但子 Agent 应该看到多少一开始我们图省事直接把所有对话历史、用户信息、中间结果全部塞给子 Agent。结果模型在处理时权重被大量无关信息分散子任务的执行精度明显下降还白白浪费 token。后来我们做了一个context_window机制主 Agent 在分发子任务时只打包当前 step 需要的字段。这个机制的难点在于怎么判断需要哪些字段我们的解法是让 Plan 里的input_schema承担这个职责。主 Agent 生成 Plan 时就需要声明每个 step 的输入格式分发时由代码强制按input_schema过滤而不是让主 Agent 自由发挥。用代码约束模型行为而不是等模型自觉。4.2 失败重试与 Plan 重规划的策略子 Agent 在执行中一定会出错出错之后怎么办直接决定系统是优雅降级还是原地死循环。我们遇到过最崩溃的情况是主 Agent 发现子 Agent 结果不合格于是重新规划但重规划的结果又分发给同一个子 Agent子 Agent 再次失败主 Agent 再次重规划……循环了十几次整个过程耗费了几万 token任务最终也没完成。后来我们设计了三个防线重试次数硬上限单个 step 的重试次数默认 2 次超过就触发fallback重规划条件收敛主 Agent 不是每次失败都重新规划只有当前 Plan 的后续步骤受到影响时才重规划如果只是当前步骤失败优先重试或换子 Agent熔断开关整个任务的大循环次数上限为 5 次超过直接转人工避免 token 失控。这三个防线结合起来最核心的思路是不要让模型自己决定什么时候该停工程上要设置绝对的兜底阈值。模型的判断是概率性的停止条件应该是确定性的。4.3 可观测性给每一步执行留痕MultiAgent 系统上线之后老板最爱问的问题就是这个任务为什么花了这么久这个单子为什么被系统误判了没有结构化的日志这些问题根本答不上来。我们的做法是给所有主子 Agent 的交互都打标准日志核心字段包括plan_id一次完整任务的唯一 IDstep_id当前步骤 IDagent_name执行 Agent 标识input_digest输入内容的 hash方便追溯数据版本output_digest输出内容的 hashlatency_ms耗时token_usage消耗的 token 数confidence子 Agent 执行的置信度status成功 / 失败 / 重试 / 转人工。有了这些日志我们才能在出问题时用plan_id把所有步骤串起来还原一次 MultiAgent 任务的完整执行链路。这也是企业级落地和实验室 demo 最大的区别之一。5. 一次重规划风暴的排错实录5.1 现象同一个任务反复重规划直到熔断我拿我们实际经历过的一个案例来说。当时我们在做商品信息审核流程主 Agent 会先规划提取商品信息 → 识别违规项 → 生成审核结论三步再分发给对应的子 Agent。上线一周后线上监控告警某个渠道的任务失败率突然飙升到百分之三十仔细一看大量任务都触发了重规划熔断。打开日志发现主 Agent 在识别违规项这一步反复重规划但每次重规划之后子 Agent 还是失败。5.2 排查链路从日志到 Prompt 到代码排查第一步先看子 Agent 失败时的报错。日志显示子 Agent 的报错是input_schema 校验失败缺少 required field: image_urls。但主 Agent 的输入明明包含了图片 URL。第二步对比主 Agent 传给子 Agent 的实际数据。我们把input_digest对应的原始数据拉出来发现主 Agent 传给子 Agent 的是一段自然语言描述里面提到了图片链接见上文而不是结构化字段里的image_urls。第三步问题定位发生变化主 Agent 在生成 Plan 时填的input_schema是合法的但它在真正分发时没有严格按input_schema组装数据而是自由发挥用自然语言描述了。也就是说模型的规划层和执行层发生了脱节。第四步修复。我们没有去调 prompt 让主 Agent 更听话而是加了一段确定性的代码逻辑主 Agent 生成分发指令后先经过一个schema_enforcer组件用计划中声明的input_schema去解析它生成的内容。解析不出来就直接返回重试而不是把原始文本传给子 Agent。这是用代码兜住模型的随机性。5.3 这个坑背后的本质与延伸这个问题的本质是模型在规划时是一套思维在写分发指令时又是一套思维两个地方共用同一个上下文但表达方式可能不一致。我们在 MultiAgent 里引入中间结构就是为了让这种不一致尽早暴露在确定性代码里而不是留给下一个 Agent 去猜。类似的问题还出现在执行阶段。有些子 Agent 执行到一半会忘记自己是在完成 Plan 中的哪一步原因也是主 Agent 传给它的上下文里混入了太多无关信息。后来统一强制按input_schema裁剪子 Agent 从拿到输入的那一刻起就只能看到与当前子任务直接相关的数据这类失忆问题基本消失了。6. 几个不太会写进文档的落地心得最后写点我们实际摸索出来的经验不一定对所有团队适用但大概率能帮你少走弯路。第一Plan 的生成要舍得用好模型子 Agent 可以用中等模型。Plan 模式本质上是全局决策一次局部执行多次全局决策的质量决定了整个任务的上限所以主 Agent 值得用最强的模型比如更大参数的模型或带更强推理能力的版本。子 Agent 的任务相对封闭、输入输出格式固定用中等模型加上领域数据效果往往不输强模型成本却能明显降下来。第二在 Plan 里显式标注依赖关系。如果 Plan 里每个 step 之间没有显式的依赖声明执行层为了效率可能会并行执行所有步骤结果就是某些子 Agent 还没等到前置结果就开始工作产出一堆废数据。我们在 Plan 结构里加了dependencies字段执行引擎先做一次拓扑排序把能并行的并行、必须串行的串行整个流程的耗时就稳定了。第三子 Agent 的 fallback 要会打太极。早期我们设计的 fallback 都是重试一次后来发现有些错误重试一万次也没用。好的 fallback 应该面向结果而不是面向动作如果子 Agent 的分类结果置信度低与其重试分类不如转给另一个宽口径 Agent 做粗分类或者直接标记为需人工介入。重试只是手段拿到可靠结果才是目的。第四敢于加人工兜底不要让 Agent 死磕。企业级系统不是全自动才高级而是该自动的自动、该人工的人工。我们所有的 MultiAgent 流程都保留了转人工的通道这个通道平时看起来不够智能但关键时刻是整个系统不崩盘的保险丝。MultiAgent 落地的过程让我最深的一个体感是这套架构真正的门槛不在模型而在业务流程的拆解能力。你要是能把一个复杂流程讲清楚让不同角色各管一段、各司其职那模型只是在帮你把这段流程自动化而已你要是自己都没想清楚流程想让 Agent 自己帮你想最后得到的只会是一堆概率性的幻觉。把确定性留给代码和流程把不确定性留给模型去发挥这才是企业级 MultiAgent 能真正跑起来的关键。