图 1：本文封面，四种协作模式一览。
这个系列今天的真题解析讲单 Agent 的短期与长期记忆——一个 Agent 怎么记住事情。这篇延伸讲另一个维度：一个脑子装不下、管不过来时，怎么组织多个 Agent 协作。主流框架官方文档把多 Agent 的收益归结为三点：上下文管理、并行化、能力边界清晰——没有一条是「多个模型更聪明」。多 Agent 的本质不是智力叠加，而是把上下文、角色与责任切开，后面的模式和时机都是这句话的推论。
分工并行：子任务互不依赖，就拆开同时跑。
最朴素的形态：调度者把任务拆成几份互不依赖的子任务，分发给多个执行者同时开工，最后汇总。比如「调研三个竞品的定价策略」，三份调研彼此独立，一个 Agent 串行做三遍不如三个并行各做一遍。这种模式买到两样东西：速度和上下文隔离——每个执行者只读自己那份资料，谁的窗口都不会被别人的中间产物撑爆。前提也写在名字里：子任务真的独立，一旦有依赖，并行就退化成接力。
层级指挥：主控拆解派活，工人逐层汇报。
任务大到需要层层拆解时，就长出层级：主控 Agent 只做计划、派活和验收，不亲自下场；下级工人各管一摊，做完汇报，主控再定下一步。这就是主管-工人（supervisor）结构，主流框架把它列为多 Agent 的默认形态。它治的病是「一支提示词管太多事」：让一个 Agent 既做规划又写代码又查资料，角色指令互相干扰，哪个都做不精；拆成层级后每层只背自己的目标。代价是主控成了单点——它拆错任务，下面全部白干。
辩论互评：生成者与评审者互相挑错。
一个 Agent 生成答案，另一个站在对立面挑错，必要时第三个做裁决，多轮往返直到收敛。这种模式买到的不是速度——它明显更慢更贵——而是可靠性：单 Agent 最大的问题是出错没人兜底，自查容易「看哪儿都顺眼」，换一个独立上下文来评审，盲区就小得多。适合错误代价高的场景：代码审查、方案比选、事实核查。关键设计点是评审者必须有独立视角——共享同一份上下文的评审者，挑错能力大打折扣。
流水线：工序固定，上一环的产出是下一环的输入。
检索、阅读、写作、校对——工序固定的任务，把每个环节做成一个专职 Agent，首尾相接成链。好处是职责极清晰：每环只干一件事，提示词可以打磨得很窄很深，出问题容易定位到具体一环，也方便单独替换优化。它适合高频重复的成熟业务流程，不适合探索性任务——工序还没摸清就硬切流水线，只会把不确定性锁死在错误的环节边界上。
什么时候升级：三种信号，一条都不中就别拆。
单 Agent 什么时候不够用？看三种信号。信号一，上下文装不下：要读的资料超过单个窗口的舒适区，硬塞进去注意力被稀释，输出质量下降。信号二，角色互相干扰：一支提示词里塞了「既是严谨审查者又是发散创意者」这类互相打架的指令，输出风格互相污染。信号三，可靠性不够：单点出错无人兜底，业务需要交叉验证。三条至少中一条，升级才划算；都不中时，单 Agent 配一支打磨好的提示词更简单、更便宜、更好调试。主流框架官方文档的口径与此一致：多 Agent 适合工具太多导致选择困难、需要大量专门上下文、或有严格顺序约束的场景。
图 2：四种模式的拓扑、适用场景与三条升级信号。
多 Agent 的代价：协调是要付钱的。
拆开的每一刀都要付费。token 成本直接翻倍：主控拆解一次调用、每个工人各一次、汇总再来一次，一次任务数倍于单 Agent 的调用量是常态。错误会传播：主控拆错任务，下游全错；上游产出垃圾，流水线环环放大。调试也更难：单 Agent 出问题看一条轨迹，多 Agent 要在一堆交互消息里还原是谁带偏了谁。用一段代码骨架感受这个结构（Node.js 22.15.0 实测，node multi-agent-demo.js）：主控把任务拆给两个 worker，各自只读自己那份上下文，并行执行后汇总：
async function worker(name, subtask, ownContext) {
await sleep(300); // 模拟一次模型调用
return { name, contextSize: ownContext.length,
output: `${name} 完成「${subtask}」` };
}
// 主控：拆解 → 并行分发 → 汇总，汇总者只收结论不读原始资料
const results = await Promise.all(tasks.map(
(t) => worker(t.name, t.subtask, t.ctx)));
实测输出：
并行模式：墙钟 301ms，各 Agent 上下文 4000 / 4000 字
串行模式：墙钟 602ms，各 Agent 上下文 4000 / 4000 字
并行省时约 50%
汇总者收到 2 份结论，合并输出；自身上下文仅 56 字
本次协作共 4 次模型调用，是单 Agent 一次调用的 4 倍
并行省了近一半墙钟时间，每个 Agent 只装自己那份资料，汇总者只碰几十字的结论——隔离的收益清晰可见；4 次调用对 1 次，就是「协调要付钱」的具体数字。
工程建议：先单 Agent，后看信号，模式可以混用。
落地顺序建议反过来走：先把单 Agent 的提示词和工具打磨到位，跑不动了再对照三种信号决定拆不拆；拆的时候按任务形态选模式——独立子任务用分工并行、需要管控用层级、质量敏感加辩论评审、工序固定走流水线。四种模式不是互斥的架构选型，而是可以嵌套的积木：层级骨架下，某一层内部可以并行，关键环节再插一道评审。多 Agent 系统的设计功力，不在用了多少 Agent，而在每一刀切得是否有理由。你的项目里有没有被硬拆开的多 Agent 结构？或者反过来，有没有一支提示词已经撑到该拆的信号了？欢迎聊聊你的判断。