Aklman · Library

— 08 / 第八章

多 Agent 编排 · 委托、交接与协作模式.

一个 Agent 解决不了的问题，未必需要一个更强的 Agent —— 也许需要三个各有专长的协作者。

10 分钟 · 初稿 2026.05 · v2 2026.06

你的研究助手现在能搜、能读、能算、有记忆。下一个诱惑是让它一个人扛下整个研究 —— 但一个 researcher 解决不了的难题，未必要一个更强的 researcher，也许要拆成几个各查一摊、再加一个挑刺的。这一章讲多 agent 的三种模式，以及更重要的：什么时候根本不该上多 agent。

— I

一个 agent 不够，未必要更强的 agent.

把一个 agent 喂得越来越胖 —— 几十个工具、超长 system —— 它反而更容易选错、更难调。有时候答案是分工，不是增强。 多 agent 适合两种情况：上下文太大，一个 agent 的窗口装不下整个任务；或者 技能差异明显，不同子任务需要不同的工具集和提示。把一个全能 agent 拆成几个专长 agent，每个的工具更少、提示更窄、也就更准。1注 1Anthropic · 「Building Effective Agents」（2024-12-19）—— 多 agent 编排模式：routing（先分类再路由）、orchestrator-workers（协调者拆任务分给 worker）；并反复强调先用最简单方案。 判断标准是分工边界清不清楚。边界清楚（客服 vs 退款 vs 技术），拆开值得；边界模糊、子任务互相纠缠，拆开只会在 agent 之间反复传话。

— II

三种协作模式：路由、编排、交接.

多 agent 不是一种东西，是几种结构。最常用的三种：路由、编排者-工人、交接。 路由：先用一次轻量分类，把任务送给对的专长 agent。编排者-工人：一个协调者把复杂任务拆成子任务，分给各个 worker，再汇总。交接：一个 agent 把任务连同上下文交给另一个 —— OpenAI Agents SDK 把它做成了一等原语。1注 1Anthropic · 「Building Effective Agents」（2024-12-19）—— 多 agent 编排模式：routing（先分类再路由）、orchestrator-workers（协调者拆任务分给 worker）；并反复强调先用最简单方案。2注 2OpenAI Agents SDK —— 把 handoff（交接）做成一等原语：一个 agent 可以把任务连同上下文交给另一个专长 agent。 OpenAI 的实践指南把这些再归两大类：manager（一个中枢 agent 把别的 agent 当工具调）和 decentralized（agent 之间 handoff 交接）。一句话记法 —— manager 模式里，连线是工具调用；decentralized 模式里，连线是交接。4注 4OpenAI · 「A Practical Guide to Building Agents」（2025-04）—— 把多 agent 归两类：manager（中枢 agent 把别的 agent 当工具调）与 decentralized（agent 之间 handoff 交接）；图喻：manager 的连线是工具调用，decentralized 的连线是交接。 
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 挑刺

研究助手的分工：拆角度 → 子 researcher → 汇总 → 挑刺

选哪种看任务形状：路由适合「输入种类明确、各走各的」，编排适合「一个大任务要拆开并行再合并」，交接适合「流程会在中途换专长」。别一上来就上最复杂的编排。

— III

多 agent 的代价，别为了多而多.

每多一个 agent，多一次上下文传递、多一份 token 账单、多一层难调的间接。多 agent 是解法，不是默认。 Anthropic 自己的多 agent 研究系统坦白：token 用量是单 agent 的数倍，而最难的部分是协调和上下文传递 —— 信息在 agent 之间交接时会丢、会变形。3注 3Anthropic · 「How we built our multi-agent research system」（2025）—— 多 agent 的真实案例与代价：token 用量数倍于单 agent，协调与上下文传递是主要难点。一个会在子 agent 之间反复传话的系统，慢、贵、还难复现 bug。 这不是 Anthropic 一家的观感。Efficient Agents（首个系统研究 agent 效率-效果权衡的工作）在 GAIA 上实测发现：很多模块是边际递减的，连记忆都「Simple Memory is Enough」—— 复杂度该按任务难度配，而不是默认拉满。5注 5Wang et al. · 「Efficient Agents: Building Effective Agents While Reducing Cost」（2025，arXiv:2508.02694）—— 首个系统研究 agent 效率-效果权衡：在 GAIA 上发现很多模块边际递减（连记忆都「Simple Memory is Enough」），复杂度应按任务难度配；其框架保留 96.7% 性能、成本几乎减半。 所以回到第一章那条线：先用最简单的方案。1注 1Anthropic · 「Building Effective Agents」（2024-12-19）—— 多 agent 编排模式：routing（先分类再路由）、orchestrator-workers（协调者拆任务分给 worker）；并反复强调先用最简单方案。多数问题，一个装备齐全的单 agent 就够了。只有当单 agent 真的撞到上下文上限或技能边界，多 agent 才开始划算 —— 而且要拆得边界清楚，不是拆得多。 动手 · 先证明你真的需要多 agent：
01

先用单 agent 顶到极限

把你想拆的任务先交给一个装齐工具的单 agent，记录它具体在哪失败 —— 是上下文装不下，还是技能选错。
02

只在失败点切一刀

按失败原因拆出最少的 agent（通常就两个），用路由或交接连起来，别上全套编排。
03

量一下代价

对比单 agent 和多 agent 的 token 用量与延迟。如果多 agent 没明显更好，退回单 agent —— 拆开本身不是成绩。

一个 agent 不够， 未必是它不够强，是你没拆对。.

One agent falling short isn't always weakness — it's the wrong split..

Aklman Library

— 讨论

讨论.

评论区初始化中…