# 多 Agent 编排 · 委托、交接与协作模式 · Agent 实战 · 从零构建完备智能体 **作者** Aklman · **章节** 08 / 19 · **首发** 2026.07 · **语言** 中文为主, 中英双语 **原文** https://library.aklman.com/books/build-agent/08-multi-agent **全书 markdown** https://library.aklman.com/books/build-agent/llms.md **上一章** https://library.aklman.com/books/build-agent/07-code-execution/llms.md **下一章** https://library.aklman.com/books/build-agent/09-safety/llms.md > 本章来自 Aklman · Library, 完整免费阅读。允许 AI 摘读、引用、问答; 转载请保留作者署名与原文链接 (CC BY-NC-ND 4.0, https://library.aklman.com/license)。 --- > 一个 Agent 解决不了的问题，未必需要一个更强的 Agent —— 也许需要三个各有专长的协作者。 你的研究助手现在能搜、能读、能算、有记忆。下一个诱惑是让它一个人扛下整个研究 —— 但一个 researcher 解决不了的难题，未必要一个更强的 researcher，也许要拆成几个各查一摊、再加一个挑刺的。这一章讲多 agent 的三种模式，以及更重要的：什么时候根本不该上多 agent。 ### I · 一个 agent 不够，未必要更强的 agent 把一个 agent 喂得越来越胖 —— 几十个工具、超长 system —— 它反而更容易选错、更难调。有时候答案是分工，不是增强。 多 agent 适合两种情况：**上下文太大**，一个 agent 的窗口装不下整个任务；或者 **技能差异明显**，不同子任务需要不同的工具集和提示。把一个全能 agent 拆成几个专长 agent，每个的工具更少、提示更窄、也就更准。[^1] 判断标准是分工边界清不清楚。边界清楚（客服 vs 退款 vs 技术），拆开值得；边界模糊、子任务互相纠缠，拆开只会在 agent 之间反复传话。 --- ### II · 三种协作模式：路由、编排、交接 多 agent 不是一种东西，是几种结构。最常用的三种：路由、编排者-工人、交接。 **路由**：先用一次轻量分类，把任务送给对的专长 agent。**编排者-工人**：一个协调者把复杂任务拆成子任务，分给各个 worker，再汇总。**交接**：一个 agent 把任务连同上下文交给另一个 —— OpenAI Agents SDK 把它做成了一等原语。[^1][^2] OpenAI 的实践指南把这些再归两大类：manager（一个中枢 agent 把别的 agent 当工具调）和 decentralized（agent 之间 handoff 交接）。一句话记法 —— manager 模式里，连线是工具调用；decentralized 模式里，连线是交接。[^4] _研究助手的分工：拆角度 → 子 researcher → 汇总 → 挑刺_ ```text ```python def research(question): angles = plan_angles(question) # 把问题拆成几个角度（子问题） findings = [sub_researcher(a) for a in angles] # 每个角度一个干净窗口的子 agent report = synthesize(question, findings) # 协调者把发现汇总成报告 return critic_pass(report) # 再让一个 critic 挑刺 ``` ``` 选哪种看任务形状：路由适合「输入种类明确、各走各的」，编排适合「一个大任务要拆开并行再合并」，交接适合「流程会在中途换专长」。别一上来就上最复杂的编排。 --- ### III · 多 agent 的代价，别为了多而多 每多一个 agent，多一次上下文传递、多一份 token 账单、多一层难调的间接。多 agent 是解法，不是默认。 Anthropic 自己的多 agent 研究系统坦白：token 用量是单 agent 的数倍，而最难的部分是协调和上下文传递 —— 信息在 agent 之间交接时会丢、会变形。[^3]一个会在子 agent 之间反复传话的系统，慢、贵、还难复现 bug。 这不是 Anthropic 一家的观感。Efficient Agents（首个系统研究 agent 效率-效果权衡的工作）在 GAIA 上实测发现：很多模块是边际递减的，连记忆都「Simple Memory is Enough」—— 复杂度该按任务难度配，而不是默认拉满。[^5] 所以回到第一章那条线：先用最简单的方案。[^1]多数问题，一个装备齐全的单 agent 就够了。只有当单 agent 真的撞到上下文上限或技能边界，多 agent 才开始划算 —— 而且要拆得边界清楚，不是拆得多。 边界具体划在哪，2026 年有了一条最硬的答案。Cognition 在 2025 年中的《Don't Build Multi-Agents》里劝所有人别碰多智能体；十个月后，他们自己发了修正版《Multi-Agents: What's Actually Working》：并行乱写的 swarm 依旧不行 ——「无结构的 swarm、任意的 agent 网络互相协商，大多是干扰项」；今天真正跑得通的多 agent，是**写保持单线程，其余 agent 只贡献智能、不贡献动作**。[^6]能站住的三类全长这个形状：干净上下文的代码审查者（只看 diff 挑毛病，不动手 —— 后面编码 agent 那章的写手-审查正是它）、更强模型当「smart friend」（卡住时把难题递过去，拿回答案自己动手）、把大任务拆片再收拢的 manager。落到工程上是一条纪律：动手写的始终只有一支笔 —— 真要多条改动并行，就用 git worktree / 独立分支给每个写者隔出自己的写域，域内仍是单写者，合并由编排者串行执行；其余 agent 出判断、出审查意见，不碰状态。 动手 · 先证明你真的需要多 agent： - **先用单 agent 顶到极限**: 把你想拆的任务先交给一个装齐工具的单 agent，记录它具体在哪失败 —— 是上下文装不下，还是技能选错。 - **只在失败点切一刀**: 按失败原因拆出最少的 agent（通常就两个），用路由或交接连起来，别上全套编排。 - **量一下代价**: 对比单 agent 和多 agent 的 token 用量与延迟。如果多 agent 没明显更好，退回单 agent —— 拆开本身不是成绩。 > 一个 agent 不够， > 未必是它不够强，是你没拆对。 ## 引用与参考 01 · Anthropic · 「Building Effective Agents」（2024-12-19）—— 多 agent 编排模式：routing（先分类再路由）、orchestrator-workers（协调者拆任务分给 worker）；并反复强调先用最简单方案。 (Anthropic · Building Effective Agents) 02 · OpenAI Agents SDK —— 把 handoff（交接）做成一等原语：一个 agent 可以把任务连同上下文交给另一个专长 agent。 (OpenAI Agents SDK) 03 · Anthropic · 「How we built our multi-agent research system」（2025）—— 多 agent 的真实案例与代价：token 用量数倍于单 agent，协调与上下文传递是主要难点。 (Anthropic · Multi-agent research system) 04 · OpenAI · 「A Practical Guide to Building Agents」（2025-04）—— 把多 agent 归两类：manager（中枢 agent 把别的 agent 当工具调）与 decentralized（agent 之间 handoff 交接）；图喻：manager 的连线是工具调用，decentralized 的连线是交接。 (OpenAI · A Practical Guide to Building Agents) 05 · Wang et al. · 「Efficient Agents: Building Effective Agents While Reducing Cost」（2025，arXiv:2508.02694）—— 首个系统研究 agent 效率-效果权衡：在 GAIA 上发现很多模块边际递减（连记忆都「Simple Memory is Enough」），复杂度应按任务难度配；其框架保留 96.7% 性能、成本几乎减半。 (arXiv · Efficient Agents (2508.02694)) 06 · Cognition · 「Multi-Agents: What's Actually Working」（Walden Yan，2026-04-22）—— 对 2025-06《Don't Build Multi-Agents》的修正：今天能跑通的多智能体是「写保持单线程，其余 agent 只贡献智能而非动作」（writes stay single-threaded and the additional agents contribute intelligence rather than actions）；能站住的三类 —— 干净上下文的代码审查、更强模型的 smart friend、拆片再收拢的 manager；「无结构的 swarm、任意的 agent 网络互相协商，大多是干扰项」，对并行写者 swarm 的旧告诫依旧成立。 (Cognition · Multi-Agents: What's Actually Working) --- *多 Agent 编排 · 委托、交接与协作模式 · Agent 实战 · 从零构建完备智能体 · Aklman 著 · CC BY-NC-ND 4.0 · https://library.aklman.com/books/build-agent/08-multi-agent*