多 Agent 协作不是堆模型：Orchestrator-Worker 模式的工程落地

授权与合规声明本文为技术实操分享所有示例均在自建隔离环境中验证或为可复现的演示代码文中版本、命令与数据均标注来源无法核验的已标「待验证」不含任何攻击步骤、利用载荷与绕过手法。转载请注明出处。一、为什么单个 Agent 会撞到天花板很多人第一次把大模型做成 Agent是一个「万能 prompt 一堆工具」的单体一个系统提示词描述全部目标一个while循环反复调用模型直到任务结束。Demo 阶段很爽一到复杂任务就露馅。1.1 单体 Agent 的三道墙第一道是上下文窗口墙。所有中间思考、工具返回、历史轨迹都堆在同一段上下文里任务一长就被挤爆要么截断丢信息要么摘要丢细节。第二道是职责混杂墙。一个 prompt 既要做规划又要做执行还要做校验模型在三种角色间反复横跳输出稳定性明显下降。第三道是错误放大墙。中间某一步工具调用出错单体没有隔离边界错误顺着轨迹一路传染最后整轮任务失败且你很难定位是哪一步。1.2 协作的本质是「分权」多 Agent 协作不是「多叫几个模型」而是把「规划」和「执行」拆开一个负责拆解与调度多个负责把单一子任务做扎实。这正好对应工业界常用的 Orchestrator-Worker编排者-工作者模式。二、Orchestrator-Worker 是什么2.1 角色分工Orchestrator编排者只做三件事——把用户目标拆成可并行的子任务、把子任务派发给合适的 Worker、汇总 Worker 的结果。它不直接干脏活。Worker工作者每个 Worker 只认一个明确的子任务和一个窄职责例如「查数据库」「写代码」「做校验」上下文短、目标单一反而更稳。2.2 与单体 Agent 的判据差异判据很简单当任务能被拆成「彼此相对独立、可并行、结果可汇总」的子任务时协作模式胜出当任务强依赖、必须一步步串行推理时单体反而更可控。不要为了用协作而用协作。三、一个最小可跑的编排骨架下面是一段示意性的 Python 骨架核心是「拆解 → 派发 → 汇总」不依赖任何具体框架。⚠️ 代码待验证fromdataclassesimportdataclass,fieldimportasynciodataclassclassSubTask:id:strinstruction:strresult:strstatus:strpending# pending | done | failedasyncdefworker_execute(task:SubTask,llm_call)-SubTask:单个 Worker只完成自己的子任务。try:task.resultawaitllm_call(task.instruction)task.statusdoneexceptExceptionase:task.statusfailedtask.resultfERROR:{e}returntaskasyncdeforchestrate(goal:str,llm_call)-str:Orchestrator拆任务、并发派发、汇总。planawaitllm_call(f把下面目标拆成 3 个独立子任务每句一行{goal})subtasks[SubTask(idft{i},instructionline.strip())fori,lineinenumerate(plan.splitlines())ifline.strip()]# 并发派发单个失败不影响其他resultsawaitasyncio.gather(*(worker_execute(t,llm_call)fortinsubtasks))ok[rforrinresultsifr.statusdone]failed[rforrinresultsifr.statusfailed]summary_prompt汇总以下子任务结果给出最终答复\n\n.join(r.resultforrinok)finalawaitllm_call(summary_prompt)iffailed:finalf\n注{len(failed)}个子任务失败已隔离不影响其余结果returnfinal3.1 任务拆解的写法拆解提示词要输出「结构化、可独立验证」的子任务而不是一段话。建议让 Orchestrator 输出 JSON 列表每个元素带id与instruction方便后续追踪与重试。3.2 Worker 执行与回传Worker 拿到的是「单一指令 所需入参」返回「结果文本 状态」。注意它不持有全局目标这样上下文最短也最容易做单测。四、结果汇聚与冲突消解4.1 汇总策略汇总不是简单拼接。推荐两种分治汇总先并行得到子结果再交给一个汇总 Worker 做一致性对齐适合子任务答案可能冲突的场景。Reduce 式汇总把子结果分批两两合并最后得到单一结论适合结果量大的场景。4.2 失败隔离单个 Worker 失败必须「就地标记、不抛出」否则asyncio.gather任一异常会拖垮整体。上面的status字段就是为了这个——失败可观测、可重试、可降级。五、生产环境必须补的三件事5.1 超时与重试每个 Worker 调用都要有独立超时和有限重试且重试要带退避。Orchestrator 本身也要有总体超时避免一个卡死的子任务拖垮整轮。5.2 成本控制多 Agent 最大的隐性成本是「模型调用次数乘子」。给每个 Worker 指定合适的模型档位简单子任务用小模型并在 Orchestrator 层限制最大子任务数与递归深度防止任务爆炸。5.3 可观测每个子任务的入参、出参、耗时、token 消耗都要落日志。没有这些线上出问题你连「是哪个 Worker 飘了」都看不出来。配套资料这一章讲的超时、重试与成本控制仓库里整理了一份可直接套用的多 Agent 韧性设计清单扫码即可获取六、什么时候不该用多 Agent6.1 判据清单出现以下任一条先别上协作任务本身强串行、一步错步步错子任务之间频繁互相依赖拆开反而要不断回传上下文体量小、调用频次低单体 Agent 已经够稳。6.2 常见误用把「多 Agent」当银弹给每个环节都挂一个模型结果调用次数翻了好几倍、稳定性却没提升。记住协作解决的是「复杂度的拆分」不是「能力的叠加」。七、从 Demo 到上线的检查单7.1 上线前自查每个 Worker 是否有独立的超时与重试失败是否被隔离、可观测、可重试最大子任务数、递归深度是否设了上限汇总步骤能否处理「部分失败」7.2 复盘指标盯三个数整体任务成功率、平均子任务耗时、单轮平均模型调用次数。前两个要涨最后一个要压住三者一起看才有意义。配套资料文末这份资料包里有一份「多 Agent 上线检查单」的对照表和上面七章一一对应扫码即可获取附表 A本文引用事实与出处对照表事实/结论出处本文位置Orchestrator-Worker 是多 Agent 系统的常见编排模式通用工程实践待验证具体文档出处第二章单体 Agent 在长任务下面临上下文、职责、错误放大三类问题本文基于工程经验归纳第一章子任务失败需隔离避免gather异常拖垮整体Python asyncio 通用实践第三、四章多 Agent 会放大模型调用次数成本乘子本文基于工程经验归纳第五章附表 B术语速查表术语含义Orchestrator编排者负责拆解目标、派发与汇总Worker工作者只完成单一子任务的窄职责单元失败隔离单个子任务失败不影响整体的设计分治汇总先得子结果再做一致性对齐的汇总方式写在最后这篇用到的资料写这篇文章时我把多 Agent 协作的骨架、韧性设计和上线检查单整理成了可对照的清单顺手也整理了几份配套的东西多 Agent 编排骨架示例上面第三章代码的完整可运行版上线检查单对照表七章要点逐条可勾选成本控制配置模板子任务上限与模型档位设置示例资料是我自己整理的放在下面这个码上扫码即可获取资料较多建议先看「全套 AGI 大模型学习路线」再挑一个实战项目跟练。