先聊点实际的。我们团队上一个项目的准则是“活儿干完为上”早前我自己搭 Agent 应用也走过纯 ReAct 的老路——模型每执行一步工具调用就“边想边做”虽然演示时很自然可一旦放上生产问题全来了上下文一长就开始“精神涣散”链路中断以后没人能说清中断点在哪出了岔子也只能对着 session 日志抓瞎。后来我们把整个架构推倒重做成“Plan 模式 主子 Agent 协作”这套企业级 MultiAgent 范式大概用了一个季度时间稳定下来。这套东西在得物技术团队里踩了不少坑今天把完整思路、核心机制和实操链路掰开揉碎讲一遍希望能给正在搞生产级 MultiAgent 的同学省点时间。MultiAgent 不是把几个模型实例拼在一起就完事。真正的问题在于怎么拆任务怎么传状态怎么让多个 Agent 像一个成熟团队而不是一盘散沙。我们最终选择“Planner/Executor 分离 层级化主从协作”的结构核心就一句话把决策集中到主 Agent把执行下放到子 Agent用结构化协议代替自然语言闲聊。下面从设计思路开始讲。1. 企业级 MultiAgent 的整体设计与思路拆解1.1 单 Agent 为什么扛不住复杂业务流先说结论不是单 Agent 能力不行而是它的工作方式跟企业级要求天然冲突。我见过很多团队在 Demo 阶段用单个 Agent 跑通“检索商品信息 - 生成文案 - 输出 JSON”这么一条链路效果看着还行。但一旦把业务维度拉起来比如同时接入商品库、优惠策略、内容审核、多语言翻译、会员画像五个工具问题就立刻暴露上下文灾难每个工具返回的结果都要塞进模型上下文几轮调用后 token 消耗爆炸模型开始“忘事儿”早先的工具返回被挤掉直接影响后续判断。指令遵循不稳定单 Agent 同时背着多个职责时模型的指令遵循率会明显下降。你让它先查库存再算优惠它可能直接在第一步就给你编一个库存数字。故障定位太难链路一旦超过 20 步每一步的输入输出都混在一个 session 里。线上报了个“生成结果不对”你得靠肉眼去翻对话历史然后逐轮复盘“是哪一次工具调用带偏了”这种排查方式放在生产环境基本等于灾难。扩展性锁死想加一个新领域的工具就要重新写一遍全链路 prompt想让某个环节换更强模型对不起你得把整个 Agent 拆了重来。这些问题的本质是单个 Agent 把“决策”和“执行”耦合在了一起。而我们在组织里做项目时从来不会让一个人既当项目经理、又当所有模块的实施工程师——大活儿一定会拆分让专人做专事。MultiAgent 要落地思路其实一样。1.2 Plan 模式为什么比纯 ReAct 更适合生产ReAct 模式是“每一步都让模型参考历史然后决定下一步动作”Plan 模式则是“先让模型把整件事的步骤全部列出来再按步骤执行”。用生活类比就是ReAct 像没做过攻略的自由行走到哪算哪灵活但容易迷路。Plan 模式像先定了行程表的跟团游路线清晰但偶发情况也得临时调整。实际操作下来Plan 模式在生产环境有几个压倒性优势第一成本可预测。模型生成计划是一次性开销后续执行阶段每个子任务都不需要把全量历史搬进上下文。我们实测同一业务场景Plan 模式比全量 ReAct 的 token 消耗平均低 40% 左右高峰期甚至省更多。第二链路可审计。计划本身是一份 JSON哪一步依赖哪一步、每一步用哪个工具、预期产出是什么全部结构化落盘。企业合规需求比如内容审核留痕直接就有据可查。第三支持人工介入。计划生成后可以由人在 UI 上修改、勾选、拦截至某一步这在大模型应用里极其重要——你不可能让模型对每个决策负全责关键节点必须有人审兜底。第四重试和断点续跑变得简单。执行到第 3 步失败记录好失败原因和上下文快照修完问题直接从第 3 步重来不需要重新跑全链路。1.3 主子 Agent 协作的实际分工逻辑当我说“主子 Agent”不是指一个 Agent 在里面“发号施令”另一个像执行机器人一样听话。真正的分工要点是主 Agent 只干三件事理解用户意图、拆解任务生成计划、调度并校验子 Agent 的结果。子 Agent 各自守一个领域比如“商品信息 Agent”只负责检索和解析商品结构化数据“内容生成 Agent”只负责根据输入生成文案“审核 Agent”只负责对生成结果做合规打分。每个子 Agent 的 prompt、工具集、模型参数都是独立优化的。主 Agent 不直接触达工具。工具调用全部下沉到子 Agent 层主 Agent 跟子 Agent 之间只通过结构化协议通信。这套设计的价值在于职责单一。每个子 Agent 的业务边界清晰prompt 可以做得非常专精模型也不需要在一个上下文里同时理解“电商 营销 法规 用户画像”这么多领域知识。主 Agent 反而更像一个中间调度层它不需要知道某个工具具体怎么调只需要知道“这个子 Agent 能产出什么、返回什么格式”。我们后来还发现一个额外的好处子 Agent 可以独立做灰度。想升级某个子 Agent 的模型版本或者优化它的 prompt直接对单个子 Agent 做 AB 实验就行完全不影响其他链路的稳定性。这在单一 Agent 架构里是做不到的。1.4 整体架构分层总览把上面的思路落到系统上我们内部把整个 MultiAgent 平台分成五层接入层承载用户请求和上游业务系统调用。统一鉴权、限流、请求上下文初始化。主控层主 Agent意图识别、Plan 生成、任务分发、结果汇总。这一层不碰任何领域工具。执行层子 Agent按领域拆分的多个 Agent 实例每个 Agent 配有专属工具和知识库负责具体任务执行。工具层内部 API、RAG 检索服务、数据库连接器、第三方服务封装。统一用一套标准输入输出协议包给上层。基础设施层模型网关、状态存储Redis DB、链路追踪、评测数据集、审计日志。这五层不是物理隔离而是逻辑隔离。好处是各层可以独立伸缩比如大促期间执行层子 Agent 实例可以扩容到平时的 5 倍主控层完全不感知也不需要跟着扩。2. 核心机制解析与实操要点2.1 Plan 的数据结构设计当计划本身成为一种数据协议Plan 模式的第一步是把“计划”从一种想法变成一种数据结构。我们在生产里用 JSON 表达计划核心字段如下{ plan_id: plan_2024001, goal: 生成一个商品详情页的完整内容包, steps: [ { step_id: step_1, name: 获取商品基础信息, agent: product_info_agent, input: {product_id: SKU10086}, depends_on: [], timeout_ms: 5000, retry: 2 }, { step_id: step_2, name: 生成商品营销文案, agent: copywriting_agent, input: {product_data_ref: step_1.output}, depends_on: [step_1], timeout_ms: 10000, retry: 1 }, { step_id: step_3, name: 文案内容安全审核, agent: content_review_agent, input: {draft_ref: step_2.output}, depends_on: [step_2], timeout_ms: 8000, retry: 0 } ] }字段背后的设计考虑比字段本身更重要agent 字段显式指定执行者而不是让模型自由选择。为什么因为模型“自主选择工具”这件事在生产环境被证明极不可靠。显式指定可以把决策空间缩小到一个正确选项大幅降低调度错误。depends_on 表达依赖关系让计划天然构成一个有向无环图DAG。这样调度器可以判断哪些步骤可以并行哪些必须串行。我们曾经为了省时间把不相关的步骤并行执行吞吐直接翻倍。每个 step 有独立的 timeout 和 retry粒度到单个任务避免整个流程被一个不稳定的子 Agent 拖死。这个 JSON 结构不是一次成型我们在迭代中加过很多字段比如 human_review_required、output_schema 等。原则是计划要包含执行所需的一切上下文宁多勿缺但字段必须标准化禁止自由文本。2.2 计划生成策略一次性规划与动态重规划怎么配合“先计划后执行”听上去简单实际有一个大坑计划在长链路场景下会失真。比如规划了 8 个步骤执行到第 5 步时发现第 3 步的结果质量太差根本没法作为后续输入这时候如果还硬着头皮往下走结果必然是错的。我们的解法是两层互补第一层渐进式规划。不要让模型一次性生成太多步骤的计划。根据经验5 到 8 步是一个安全区间。业务链路超过 8 步时就拆成多个 Plan 接力——主 Agent 先出一个粗颗粒度路线每完成一个小阶段基于真实执行结果再细化下一步计划。这个“规划-执行-反馈-再规划”的闭环比一次性长计划稳得多。第二层动态重规划触发机制。执行过程中一旦出现以下信号就触发主 Agent 重新生成剩余步骤计划某个 step 的执行结果返回 status failed且 retry 后仍然失败。子 Agent 返回的置信度confidence低于设定的阈值我们一般设 0.7。执行结果通过 schema 校验失败说明子 Agent 产生了超出预期的输出结构。用户在中途修改了需求比如“文案风格改成活泼一点”此时剩余计划必须重排。重规划不是从零开始而是保留已完成步骤的结果把“剩余目标 最新上下文”打包给主 Agent让它只对未执行的步骤做调整。这样可以避免因为一个小插曲导致所有已完成的工作作废。2.3 主子 Agent 之间的通信协议与状态管理这是整套系统里最容易被忽视但也是最容易出鬼的地方。子 Agent 返回给主 Agent 的结果必须是一个结构化报文我们内部管它叫Result 协议。核心字段长这样{ agent: copywriting_agent, step_id: step_2, status: success, confidence: 0.92, data: { title: 夏季新款轻薄防晒衣 UPF50, description: ... }, error: null, metrics: { tokens_used: 1200, latency_ms: 2300, model: gpt-4o-mini } }为什么必须结构化因为主 Agent 拿到自然语言描述的结果以后没法稳定地提取关键信息用于下一步。结构化 payload 直接解决了这个问题——主 Agent 不需要对结果做二次解析它只需要按照计划里的 input 映射关系从对应的 data 字段取值。另一个关键是状态管理。每个 Plan 和 Step 在系统里都有一个状态机流转路径是待执行pending- 执行中running- 成功succeeded待执行pending- 执行中running- 失败failed- 重试中retrying- 成功或最终失败状态机不是存在模型内存里的而是落在 Redis DB 里。这样即使执行 Agent 的进程崩溃状态也不会丢。我们復用了一套任务调度引擎来做这件事顺手解决了并发控制、超时检测、失败重试这些企业级必备能力。2.4 上下文管理共享什么、隔离什么、token 怎么分配多 Agent 系统里的上下文问题和单 Agent 不是同一个量级。我们的策略是分层上下文全局上下文用户需求、业务规则、产品信息基底。这些是 Plan 生成和执行全程可见的大小要控制在 2000 token 以内。步骤上下文当前 step 的输入包括依赖步骤的输出引用、子 Agent 的执行指令。私有上下文子 Agent 内部为了完成工具调用所消耗的检索结果、中间推理这些不出子 Agent 边界主 Agent 不感知。这个分层带来了一个直接收益每个子 Agent 处理一个小步骤时上下文窗口只需要装下“当前任务说明 输入数据”一般不超过 4000 token。相比单 Agent 动不动塞两三万 token 的做法模型推理速度更快、准确性更高、成本还更便宜。模型的 token 预算分配上我的经验值是这样的主 Agent 的规划阶段给 8000 token但实际产出结构只有 1000 左右子 Agent 的执行上下文则根据工具返回数据量动态缩放超长数据自动截断或分页拉取。这样做的好处是不怕子任务复杂就怕主任务上下文膨胀——主 Agent 的推理质量直接决定全局必须保证它轻装上阵。3. 实操过程与核心链路实现3.1 场景拆解以商品上架内容生产为例拿我们落地最典型的一个业务场景来说电商后台的商品上架内容自动生产。运营人员只需输入一个商品 ID系统自动完成四件事从商品中心拉取基础信息标题、图片、规格、库存。基于基础信息生成营销文案卖点提炼、场景描述、用户痛点呼应。将文案送内容安全审核检测是否有违禁词、夸大宣传、敏感表述。审核通过后调用素材平台生成详情页 JSON 包推送给运营确认。这个场景看似不复杂但单 Agent 跑的时候问题一堆文案生成 Agent 经常把商品规格写错审核 Agent 对“宣传边界”的把握不稳定最麻烦的是运营想看“为什么不通过”系统根本说不清楚。换到 Plan 主子 Agent 架构后整条链路变成了模块化流水线每个环节的输入输出都清清楚楚运营从“对着一坨生成结果猜原因”变成了“看哪一步报错就处理哪一步”。3.2 主 Agent 生成 Plan 的 Prompt 设计主 Agent 的规划质量直接决定整套系统的上限。下面是我们在生产环境里稳定运行的一个主 Agent System Prompt 骨架你是企业业务编排引擎负责把用户的业务目标拆解为可执行的子任务计划。 输入用户目标 可用子 Agent 列表 全局上下文。 输出JSON 格式的任务计划必须使用严格的 schema。 硬性规则 1. 每个步骤必须且只能指定一个子 Agent 执行。 2. 步骤之间若有依赖必须在 depends_on 字段体现。 3. 如果任务目标不明确先输出 clarification_required 状态禁止擅自假设。 4. 步骤数量控制在 3-8 个若实际链路超过 8 步先拆出最关键的阶段。 5. 每个步骤的 input 只允许引用前置步骤的 output 或全局上下文中的字段。 6. 区分串行依赖与可并行步骤在计划中显式标记 deprecated 空列表以支持并行执行。这个 Prompt 我们打磨了很多轮最有用的其实是那几个“禁止”条款。模型在规划时有很多坏习惯比如擅自拍脑袋定义一个不存在的 Agent比如把两个不相关任务硬塞进一个 step再比如生成出语法不合法导致解析器直接崩掉的 JSON。把这些坏习惯用否定句明确写死比反复强调“要准确”有效得多。3.3 子 Agent 的标准化执行实现子 Agent 的边界清晰后实现起来反而简单。我们的每个子 Agent 内部是一个“小号的 ReAct”但它只面对一个领域工具集固定、工具数量一般不超过 3 个。核心代码如下def execute_sub_agent(agent_config, task_input): 子 Agent 执行标准入口 1. 加载领域 prompt 和工具集 2. 运行 ReAct 循环限制最大轮数防死循环 3. 按 Result 协议返回结构化结果 messages [ {role: system, content: agent_config.system_prompt}, {role: user, content: json.dumps(task_input, ensure_asciiFalse)} ] max_rounds 5 # 最多允许 5 轮工具调用超出即终止 tool_results [] for round_idx in range(max_rounds): resp model_call(messages, toolsagent_config.tools, temperature0.1) if resp.tool_calls: for call in resp.tool_calls: tool_result invoke_tool(call.function.name, call.function.arguments) messages.append({ role: tool, tool_call_id: call.id, content: json.dumps(tool_result, ensure_asciiFalse) }) else: final_text resp.content # 对最终输出做 schema 校验不通过则进入重试或失败处理 return build_result( statussuccess, datafinal_text, confidenceextract_confidence(resp) ) return build_result(statusfailed, errormax_rounds_exceeded)几个实现要点temperature 控制在 0.1。子 Agent 是执行者不是创作者稳定性远重要于多样性。营销文案的“创意”应该在生成策略层面解决而不是靠调高温度碰运气。max_rounds 必须设。模型在 ReAct 循环里非常容易陷入“调用工具 - 返回结果 - 再调用同一个工具”的死循环设一个硬上限是防止 token 燃烧的最后防线。置信度提取。我们在子 Agent 的 system prompt 里要求模型在返回结果时附一个 confidence 分数0 到 1用来衡量它对结果正确性的把握。主 Agent 再根据这个分数决定是否要重跑或转人工。3.4 人工审核 Fallback 链路怎么搭企业级系统里人工兜底是刚需。我们在主 Agent 调度层做了一个拦截机制计划中的每个 step 都可以标记 human_review_required。被标记的节点在子 Agent 执行完成后不会自动进入下一环节而是进入一个待审核队列由运营人员在审核页面上“通过 / 驳回 / 修改”。人工审核的最优粒度是step 级而不是 plan 级。原因很简单整单审核意味着要么全信 AI 的结果要么全盘推翻step 级审核则允许运营只修正文案这一步保留已通过的拉取结果既提升效率又保留人的控制力。实现上我们用了消息队列做异步通知审核人通过某个 step 后事件触发调度引擎继续 execute 下游依赖步骤。这套机制上线后运营觉得“AI 助手更听话了”因为它不再是给一个黑盒结果而是可以插手每一步的过程。3.5 评测和灰度上线从 Demo 到生产的最后一公里很多团队死在“Demo 能跑但不知道准不准”这件事上。我们的做法是建一套离线评测流水线准备 200 到 500 条真实历史业务请求作为种子集每条标记预期产出和正确结果。每次变更改 Prompt、换模型、调参数都先跑离线评测对比成功率、耗时时长、token 消耗、人工修正率四个指标。上线阶段先接 5% 流量跑影子模式只记录不改数据跑 24 小时对比影子输出和线上实际结果。影子对比通过后再逐步放开到 10%、50%、100%。有一次我们想更换文案生成子 Agent 的底层模型离线评测显示新模型成功率更高、token 消耗还少正当准备全量切换时影子模式暴露出了问题新模型在特定品类比如保健品上频繁输出合规风险文案。这个坑离线评测完全没测出来因为种子集里该类目样品不足。影子模式救了我们一次从那以后我们在种子集建设上专门加了类目均衡约束任何模型升级都必须保证各业务类目都覆盖样本。4. 常见问题与排查技巧实录4.1 高频问题速查表症状根因排查思路解决方案计划生成通过但执行卡死计划里 step 的依赖关系成环解析 DAG 检测环调度引擎加环检测遇到环直接报错子 Agent 返回结果格式错乱模型没有严格按 schema 输出查看子 Agent 原始响应确认是解析层还是模型层问题增加输出 schema 结构化工具强制修正或二次解析修正客户端拿到结果一直转圈某 step 超时导致整条链路挂起查 trace 定位超时节点调高 timeout 或拆分该 step 到更细粒度子 Agent 之间传递数据失真主 Agent 在取字段时映射错误核对 input 字段 ref 是否与 dependencies 对齐用契约测试锁定各 step 的 input/output schema人工审核后不同步事件通知没走对主题查看审核回调与调度引擎之间的 MQ 消费情况增加消费幂等处理和补偿重试成本飙升上下文太长或重试次数过多查看 metrics 里的 tokens_used 和重试次数优化上下文截断策略对高失败步骤先做根因修复再调高重试4.2 链路追踪没有全套 Trace 的 MultiAgent 没法运维MultiAgent 系统里一个用户请求可能横跨主 Agent、多个子 Agent、多次工具调用一旦出问题拿不到完整调用链等于大海捞针。我们给每个请求预先分配一个全局请求 IDtrace_id主 Agent 生成 Plan 时把 plan_id 绑定上去每个 step 再生成独立的 step_id所有 Agent 的输入输出日志、token 消耗、耗时、模型名全部挂在这些 ID 下面。具体排查时我习惯直接看两个视图全局视图整个 Plan 的状态流转哪几个 step 相互依赖、哪个 step 失败影响了哪些下游。单步视图某个具体 step 内部模型和工具之间到底发生了什么——哪个工具返回了什么、模型在那一轮做了什么决策。没有链路追踪之前排查一个问题平均要 20 分钟有了之后10 分钟以内基本能定位到底层原因。这块投入产出比极高值得每个 MultiAgent 团队第一时间做。4.3 几个扎心但有用的调优经验第一别迷信“更强的模型”。我们在某些子 Agent 上对比过 70B 级模型和商用小模型的差异发现差距很小但成本和延迟差了快 3 倍。子 Agent 任务聚焦后模型大小的影响被功能性 prompt 和工具设计大幅稀释性价比反而成了更重要的指标。第二计划的重规划不是越频繁越好。重规划本身需要再调用一次主 Agent又有额外 token 和延迟成本。我们给重规划加了冷却机制同一个 plan 里重规划间隔至少 30 秒且最多触发 2 次。这步限制直接防止了“模型进入‘反复横跳’状态”的奇葩场景。第三子 Agent 的幂等性要放在第一位。工具调用在分布式环境里一定会遇到超时重试如果子 Agent 调用的工具不是幂等的重试就会产生重复数据或者脏数据。我们的做法是给每个工具调用强制传 request_id工具端用 request_id 做去重否则宁可报错也不要覆盖写入。这条被验证是生产事故最多的一类根因。5. 一点个人体会这套 Plan 主子 Agent 架构跑到现在我最大的感受是MultiAgent 的难点从来不是“怎么让模型学会自己决策”而是“怎么设计一套系统约束让模型的决策权被合理地关进笼子里”。主 Agent 有规划权但没有执行权子 Agent 有执行权但没有越界权人永远保留最终审核权——权力分立的架构才是 MultiAgent 在企业环境里稳定落地的内功心法。最后分享一个小技巧Planner 的计划里可以加一步summarize_milestone每隔几个子 Agent 执行完毕后让一个轻量级模型把中间结果压缩成几百字的摘要再喂给下一步。这个操作对控制长链路的 token 成本以及防止上下文语义稀释效果立竿见影。如果你正准备把 MultiAgent 推上生产建议优先试这个改动。