一个 agent 还是多个：什么时候值得拆

一个调研任务跑得慢，工具结果把上下文越塞越满，很自然会想：能不能让一个主 agent 拆任务，派几个子 agent 并行去查？可以，但拆分买到的东西很具体：并行省下的墙钟时间，和互相隔开的上下文；付出的是更多 token、更多交接，以及交接时丢掉的信息。子问题越独立、越以读为主，越值得拆；步骤前后依赖、几个部分要共用同一组隐含决定时，单 agent 往往更稳。比较两种方案，要在相同的 token 和工具预算下比。

待审核草稿。 这一篇还没有经过站主审阅，事实、取舍和措辞都可能修改；引用前请回到文中链接的一手资料核对。

多 agent 到底改变了什么

常见结构已经列过 orchestrator-workers、parallelization 等结构，这里不重复。这一篇只问：同一个任务，从“一个 agent 在一个上下文里做完”换成“一个协调者加几个子 agent”，具体哪些东西变了。

没变的东西同样重要。子 agent 通常用同一个模型，盲点往往相同，多派几个并不会让错误自动变得互相独立；多几个 agent 也不等于多了验证，除非专门设计一个复核环节。

代价不只是 token

token 和延迟的账留到下面的算例里算（每个上下文都要带一份固定提示，规划和汇总只能串行）。这里先列四种更难看见的代价：

• 交接损失。 子 agent 把十几 k token 的原始结果压成 1k 的摘要，协调者需要的某个事实可能恰好在被删掉的部分里。
• 隐含决定冲突。 每一步动作都带着没说出口的选择，例如怎么定义“节假日”、用哪个版本的通知。几个子 agent 各选各的，合起来就可能互相矛盾。
• 错误传播。 一个子 agent 交回的错误事实，协调者通常没有原文可以核对，会直接写进结论。
• 更难评估和排错。 同一个输入每次走的路径可能不同；最终答错时，要先判断是哪个 agent、哪一步出的错。

一手资料说了什么

Anthropic 的 Research 系统（2025-06-13）

Anthropic 在工程博客里介绍了自己的多 agent 调研系统：一个 lead agent 制定计划，并行派出多个 subagent 搜索，再汇总。最常被引用的一句在讲多 agent 好处的一节：以 Claude Opus 4 为 lead、Claude Sonnet 4 为 subagent 的多 agent 系统“outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval”，即在内部 research eval 上比单 agent 的 Claude Opus 4 高 90.2%。文中举的例子是找出标普 500 信息技术板块公司的全部董事，单 agent 靠缓慢的顺序搜索没找全。

这句话没说的同样要记住：没有给两边的绝对分数，没说 90.2% 是相对提升还是百分点，没说两边的 token 预算和工具调用次数是否相同，评测集也没有公开。按文章自己的解释，两边花的 token 多半并不相同：在 BrowseComp 上，三个因素解释了 95% 的表现差异，其中 token 用量单独解释 80%（另两个是工具调用次数和模型选择）；agent 通常比聊天多用约 4 倍 token，多 agent 系统约 15 倍。作者的结论是，多 agent 有效主要因为它能花够多的 token，所以只适合价值高到付得起这些 token 的任务。文章也写明，需要所有 agent 共享同一上下文、或 agent 之间依赖很多的领域目前不适合，多数编程任务里真正能并行的部分比调研少。

Cognition：先别拆（2025-06-12）

Cognition 的 Walden Yan 在 Don't Build Multi-Agents 里给出相反的工程判断。他设想把“做一个 Flappy Bird”拆给两个子 agent，一个做背景，一个做小鸟：一个可能做出马里奥风格的背景，另一个做出的鸟既不像也不按游戏的方式动，协调者很难把两半拼起来。他提出两条原则：共享上下文，而且共享完整的 agent 轨迹，不只是单条消息；动作里带着隐含决定，决定冲突就会得到坏结果。他的建议是默认用单线程的线性 agent，任务太长时再用一个模型压缩历史（他也承认这很难做好），而不是并行拆分。

这是基于工程经验的论证，没有对照实验数字。它和 Anthropic 那篇并不完全矛盾：一篇讲以读为主、可以并行的调研，另一篇讲要产出一致成品的长任务。

MAST：多 agent 系统怎样失败

Cemri 等人的 Why Do Multi-Agent LLM Systems Fail?（v1 2025-03，v3 2025-10；NeurIPS 2025 Datasets and Benchmarks Track 的录用列表里有它，arXiv 页面没有标注）从 7 个开源多 agent 框架收集了 1642 条执行轨迹，标注失败原因。分类法 MAST 由 6 位专家对 150 多条轨迹做扎根分析建立；一致性检验是 3 位标注者在 15 条轨迹上做了三轮，κ = 0.88；之后用 LLM 标注器（o1）扩展到全部数据，它和人工标注的一致性 κ = 0.77。

MAST 有 14 种失败模式，分成三类。按 v3 的图 1：系统设计问题（不遵守任务或角色设定、重复步骤、不知道何时结束等）占 44.2%；agent 之间不对齐（不追问澄清、偏离任务、扣住关键信息不传等）占 32.3%；任务验证问题（过早结束、没验证或验证错）占 23.5%。引言报告这些系统的失败率在 41% 到 86.7% 之间。它测的是“多 agent 系统为什么失败”，没有在同预算下和单 agent 对比。

控制预算以后的比较（2025–2026）

• Google Research、Google DeepMind 和 MIT 的 Kim 等人在 Towards a Science of Scaling Agent Systems（预印本）的 v3（2026-04）里，在 6 个 agent benchmark、5 种结构（单 agent 和 4 种多 agent）、3 个模型家族上跑了 260 个配置，并称统一了工具、prompt 和计算预算（v1、v2 是 4 个 benchmark、180 个配置，引用时要写明版本）。相对单 agent 的变化，从可分解的金融分析任务上的 +80.8%，到顺序规划任务 PlanCraft 上的 −70.0%；在 PlanCraft 上，4 种多 agent 结构全部变差（−39% 到 −70%）。他们的回归还显示，单 agent 基线（baseline）超过约 45% 时，再加 agent 的收益转为负。
• Stanford 的 Tran 和 Kiela 在 Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets（预印本，2026-04）里固定“思考 token”预算，在 FRAMES 和 MuSiQue 4-hop 上比较单 agent 和 5 种多 agent 结构。除了 100 token 这个几乎没法推理的最低预算，单 agent 在各个预算下都是最好，或与最好的统计上无差别；论文还称单 agent 实际用掉的思考 token 更少。只有在人为大量遮盖或替换上下文 token 之后，多 agent 才变得有竞争力，但这项测试只用了一个模型（Qwen3-30B-A3B）、只和顺序式多 agent 比。他们还指出，API 预算控制上的偏差（尤其是 Gemini 2.5）和 benchmark 本身的问题，都可能抬高多 agent 的表面收益。注意这是纯文本多跳推理，不调工具。
• Gao 等人的 Single-agent or Multi-agent Systems? Why Not Both?（2025-05）在多种 agent 应用上比较后报告，模型越强，多 agent 相对单 agent 的优势越小。

放在一起，比较一致的结论是：任务能拆成互不依赖的信息流时，拆分可能有用；顺序依赖强、或单 agent 已经做得不错时，拆分常常帮倒忙。 截至 2026-10-15，前两篇预印本在 arXiv 上都没有标注正式发表信息；具体百分比依赖各自的预算定义和基线，不宜直接搬到你的任务上。

算一遍：三个子问题，拆还是不拆

下面的数字全是教学假设，用来看清机制，不是任何系统的测量结果。

任务：查清 A、B、C 三家图书馆今年的节假日开放规则（沿用 Deep Research 里的图书馆例子）。三个子问题互相独立。

• 每个子问题需要 4 次工具调用；每次（模型一步加工具返回）10 秒，返回 4k token。
• 每个上下文都有 3k 的固定提示（系统提示、工具说明、任务）；最终答案 2k，写答案也算一步，10 秒。
• 多 agent 时，协调者先规划 10 秒，给每个子 agent 写 0.5k 的 brief；子 agent 交回 1k 摘要；协调者再用 10 秒汇总。
• Token 按“每段内容进入一个上下文算一次”计，相当于假设重读有缓存。真实账单还要看每一步是否重读整个上下文：单 agent 的上下文越长，每次重读越贵。

时间缩短到 60 秒，但不是原来的三分之一：规划和汇总这两步没法并行。Token 多了约 34%，来自重复的固定提示、brief 和摘要。

再看答对的概率。假设最终答案需要每个子问题里的一个关键事实。单 agent 在混着 12 份结果的长上下文里，找到并保住每个事实的概率记为 $s_1$；子 agent 在只有自己 4 份结果的短上下文里，这个概率记为 $s_2$；摘要漏掉这个事实的概率记为 $d$。三个事实都要对：

$$ P_{\rm single}=s_1^{\,3},\qquad P_{\rm multi}=\big(s_2\,(1-d)\big)^{3}. $$

取 $s_1=0.90$、$s_2=0.95$。单 agent 是 $0.9^3=0.729$。若 $d=0.02$，多 agent 是 $(0.95\times0.98)^3\approx0.807$，拆分赢；若 $d=0.10$，是 $0.855^3\approx0.625$，拆分输。两者持平的条件是 $s_2(1-d)=s_1$，即 $d^*=1-0.90/0.95\approx5.3\%$。

这个式子说明：拆分在准确率上的好处，全部来自 $s_2>s_1$，也就是短上下文比长上下文更不容易漏。 如果单 agent 本来就能用好它的上下文（$s_1=s_2$），任何 $d>0$ 都会让多 agent 更差。这和 Tran 与 Kiela 的论证方向一致。

现在只改一个条件：子问题变成先后依赖。先查 A 馆是否改用了市里的新通知，再按那份通知查 B 馆，最后查 C 馆。并行宽度变成 1，多 agent 的时间变成 $10+40+10+40+10+40+10=160$ 秒，比单 agent 的 130 秒还慢；token 仍是 71k 左右；A 的结论还要经过“摘要 → 协调者 → 下一份 brief”两次转述。这时拆分只剩上下文隔离一个好处，却要多付 30 秒和约 18k token。

再改另一个条件：三个子问题仍然独立，但都要判断“节假日”包不包括公众假期前一天（很多馆那天提前闭馆）。brief 没写清时，假设每个子 agent 都以 0.8 的概率选同一种理解、0.2 的概率选另一种，那么三份结果口径一致的概率只有 $0.8^3+0.2^3=0.52$。单 agent 只做一次这个决定，口径天然一致，虽然也可能一致地错。解决办法是把定义写进每份 brief，或在汇总时专门检查口径，而不是再多派一个 agent。

怎么选：从任务形态出发

每一行的依据：

• 第一行是 Anthropic 所说最适合多 agent 的广度优先查询；第二行对应 Kim 等人在 PlanCraft 上看到的退化；最后一行对应他们报告的约 45% 饱和点。
• 第三行是 Cognition 的论点。他们描述 2025 年 6 月时的 Claude Code：子 agent 通常只负责回答问题，不和主 agent 并行写代码。
• 第四行：Anthropic 把子 agent 描述为“智能过滤器”，Cognition 也说子 agent 的调查过程不必留在主 agent 的历史里。
• 第五行是工程建议，我没有找到专门的对照实验。
• 第六行证据不一：MAST 发现带显式验证者的系统总体失败更少，但很多验证只做表面检查（例如代码能否编译）；Kim 等人测得各自独立的结构把错误放大 17.2 倍，中心化结构是 4.4 倍，但在控制其他指标的回归里，这个放大系数本身不显著。

怎么评估：同预算、看交接、追 trace

先把预算对齐。 至少固定总 token（输入和输出分开记）、工具调用次数和墙钟上限，再比成功率；最好在几个预算点上各比一次，画成曲线。如果多 agent 让每个子 agent 多查一倍（每路 8 次调用），时间约 100 秒、token 约 119k；这时也要给单 agent 同样的 24 次调用（约 250 秒、101k token）再比，否则提升可能只是多花了钱。记录实际消耗而不是请求的预算，Tran 和 Kiela 发现两者可能对不上。

用同一组任务做配对比较。 每个任务两种方案都跑、多跑几次，看配对差值和波动，而不是只比两个平均数；做法见对照实验与切片。Anthropic 的经验是早期用约 20 个真实查询就能看出大的改动；研究类输出用带 rubric 的 LLM judge 评事实、引用、完整性、来源质量和工具效率，同时保留人工测试，因为人能发现评测漏掉的边角情况。

检查每一次交接。 把 brief 和摘要都记成 trace 里的 span，抽样核对：答案需要的事实是否出现在子 agent 的原始工具结果里，又是否出现在它的摘要里。

trace_id=demo-41
lead.plan            → brief_A, brief_B, brief_C
  sub_A  tool×4      → summary_A (1k)   关键事实：原文里有，摘要里没有   ← 交接损失
  sub_B  tool×4      → summary_B (1k)   关键事实：原文里就没有           ← 没找到
  sub_C  tool×4      → summary_C (1k)   关键事实：两处都有
lead.synthesize      ← summary_A..C

“原文有、摘要没有”是交接损失，可以改摘要格式，或改成传文件引用（Anthropic 的做法是让子 agent 把产物写进外部存储，只回传轻量的引用）；“原文就没有”是搜索问题，加 agent 也没用。MAST 的类别可以当打标签的词表（vocabulary）。

排错按 trace 走，而不是问模型。 父子 span 要能串起协调者和每个子 agent，具体字段见 Agent 可观测性。定位“哪个 agent 在哪一步出错”本身就很难：Zhang 等人的 Who&When（ICML 2025）用 127 个多 agent 系统的失败日志测试自动归因，最好的方法找对负责的 agent 只有 53.5%，找对出错步骤只有 14.2%。所以 LLM 给的归因只当线索；确认原因要做受控重放，例如把某个子 agent 的摘要换成正确版本，看最终答案是否随之改对。

能推出什么，不能推出什么

接着读：拆分以后的结构写法见常见结构，问题队列和证据记录见 Deep Research，成本怎样算全见模型选择与路由，什么时候请人介入见 Human-in-the-Loop。