我在给自己搭一套 agent 工作循环时,自然而然想到「多派几个 agent 分工」。研究 agent、设计 agent、实现 agent —— 听起来天经地义。
真去查了一圈之后,发现做过这件事的团队,方向几乎一致地在泼冷水。而且泼的不是模型能力,是组织设计。
这篇把五份证据摊开,每份都说清是谁做的、怎么做的、结论是什么。最后附两条我自己的判断,和证据分开标。
证据一 · 按工种拆:协调的开销比干活还大
Anthropic,When to use multi-agent systems (and when not to)
他们做过一个实验:把 agent 按软件开发角色划分 —— planner / implementer / tester / reviewer。这几乎就是所有人想到多 agent 时的第一反应。
结果是:subagent 花在协调上的 token,比花在干活上的还多。
他们给的替代原则值得抄下来:
按上下文边界拆,不按工种拆(context-centric,不是 role-centric)。
举的例子很具体:写某个 feature 的 agent 应该同时写它的测试 —— 因为上下文已经在它手里了,拆出去反而要重新传一遍。
而什么能拆?天然没有共享上下文的东西,比如「亚洲市场调研 / 欧洲市场调研」。
判据一句话:只有当上下文能被真正隔离时才拆。
证据二 · 拆完了合不回去
Cognition(Devin 的团队),Don’t Build Multi-Agents
他们的翻车现场比原则更有说服力:把「做个 Flappy Bird」拆给子 agent。
子 agent 1 做出了超级马里奥风格的背景
子 agent 2 做的鸟，和整体美术对不上
负责合并的 agent 面对两个不兼容的产物，无法收场
两条原文值得记:
Share context, and share full agent traces, not just individual messages. Actions carry implicit decisions, and conflicting decisions carry bad results.
第二句是关键:每个动作里都藏着隐含的决策,而两个 agent 看不到彼此,就会做出互相冲突的隐含决策 —— 到合并的时候才爆。
而合并这个问题,他们坦承没解决,是直接绕开的 —— 结论是默认单线程线性 agent。
一年后他们修正了立场(Multi-Agents: What’s Actually Working),但边界画得很死:
写操作保持单线程 —— 额外的 agent 贡献的是判断力,而不是动作。
真正跑通的只有三种模式:Code-Review-Loop、弱模型向强模型求助、以及 map-reduce-and-manage。而关于第三种,他们坦承 manager 会「在缺乏代码库上下文时变得过度指令化」、「错误地假设与子 agent 共享状态」—— 也就是说协调至今没跑顺。
证据三 · 同构 agent 的辩论,数学上不涨点
这一条最反直觉,因为「让几个 agent 互相辩论,总能辩出更好的答案吧」听起来太合理了。
Understanding Agent Scaling in LLM-Based Multi-Agent Systems via Diversity 的结论是:同构输入下的多 agent 辩论在数学上是个鞅 —— 期望准确率不随轮次提升。
而 The Cost of Consensus 那篇的标题本身就是结论:
Isolated Self-Correction Prevails Over Unguided Homogeneous Multi-Agent Debate 孤立的自我纠正,胜过无引导的同构多 agent 辩论
3–10 个同构 agent 的各种聚合策略,打不过单个 CoT agent。
失败路径被 Talk Isn’t Always Cheap 拆成了三类:
谄媚趋同 agent 倾向于附和别人的答案
上下文脆化 多轮之后上下文互相污染
共识坍缩 ⭐ 投票把已经生成出来的正确答案投掉了
最后一条最扎心 —— 正确答案曾经出现过,是「协作」把它弄没的。
所以:换个 agent 但同模型、同上下文,约等于白花钱。
多样性必须来自异构 —— 不同模型,或者不同输入。
证据四 · 多数失败源于组织设计,不是模型能力
Why Do Multi-Agent LLM Systems Fail?(伯克利,业内常引作 MAST)标注了 1600+ 条多 agent 轨迹、覆盖 7 个框架,把失败归了类:
41.8% 规格与系统设计 角色定义模糊 · 拆解不当 · ⭐重复的 agent 角色 · 缺终止条件
36.9% agent 间失配 交接时上下文丢失 · 输出冲突 · 格式不匹配
加起来接近 79%。 作者的结论写得很直白:
多数失败源于组织设计,而非模型能力。
这句话对做架构的人来说信息量很大 —— 它意味着换个更强的模型解决不了这类问题。你得改的是拆解方式、角色边界、交接契约。
其中「重复的 agent 角色」这一项尤其值得注意:两个角色职责重叠时,不只是浪费,还会产生互相矛盾的输出。
证据五 · 成本
多 agent 通常是 3–10 倍 token;研究型场景(Anthropic 的多 agent 研究系统复盘)约 15 倍于普通对话。
配上一句业内的反面观察:
团队花几个月搭精巧的多 agent 架构,最后发现单 agent 改改 prompt 就能达到同等效果。
那什么是有效的?
摊开这些之后,一个自然的问题是:多 agent 是不是压根不该用?
不是。有一个角色目前有硬数字回报 —— 干净上下文的 reviewer。
Cognition 报告他们的 review agent:平均每个 PR 抓 2 个 bug,其中约 58% 是严重级(逻辑错、边界遗漏、安全);而且多轮 review 每轮还能抓到新的。
⭐ 这里有个反直觉的细节:他们发现 review agent 用完全干净的上下文表现更好 —— 因为避免了 context rot,而且不会被「当初为什么这么写」的过程带偏。
给 reviewer 看执行过程,反而更差。
但注意这条要和另一条分清。Agent-as-a-Judge(Meta)的结论是:裁判看完整轨迹时与人类判断一致率 90%,只看最终产物的传统做法只有 60–70%。
两条不矛盾,是两种任务:
判「做完没有」 → 要看轨迹
判「写得好不好」 → 要干净上下文
我的两条判断(和上面的证据分开)
以下是我自己的提法,不是引用,可能是我没找到前人。我在小规模上印证过,但样本很小。
⭐ 一、多 agent 多在【输入】,不在【角色名】
我这套里真正有效的一次,是三个"立场审"角色去审同一份方案。它们有效不是因为叫了三个名字:
角色 1 → 只拿到干系人 A 的表态记录
角色 2 → 只拿到干系人 B 的表态记录
角色 3 → 只拿到客户方的表态记录
三份输入互不重叠 → 这才叫异构
如果它们共享输入,那么「三个角色都指出了同一个问题」这句话没有任何信息量 —— 那只是同一个推理被复制了三遍。
实测里它们各自抓到了不同的东西,又在一个真问题上撞到一起。这个"部分重叠"的模式才是真独立的特征:
完全一致 ⚠️ 可疑，大概率共享了上下文
完全不同 🟡 没有共识，信息量低
部分重叠 ⭐ 真独立
于是「给这个角色看什么、不看什么」就不再是工程细节,而是角色定义的核心。我把它总结成一句:
每个角色只拿到它在现实中真能看到的东西。 给多了,它就在模拟一个不存在的、什么都知道的评审者 —— 那种评审没有预测力。
⭐ 二、要不要派一个新 agent:四道闸
把上面的证据压成一个可执行的判断流程:
四道闸分别对应上面四份证据:动作 vs 判断(Cognition)· 上下文隔离(Anthropic)· 异构(arXiv 那两篇)· 输出契约(MAST 的"交接失配")。
我拿它回头验自己已有的角色:审查类的全部通过,而原本想加的"实现 agent"和"N 个方案生成 agent"在前三道闸就被拦下了。
⚠️ 这些证据的局限
写这类文章最该说清的是证据能推到多远。
一、时间窗口很窄。 上面几乎全是 2025–2026 的东西。多 agent 这个领域一年就能翻篇 —— 结论可能过期,而框架肯定会换。
二、都是特定场景。 Cognition 是代码 agent、Anthropic 是研究型任务、MAST 覆盖 7 个框架但都是学术 benchmark。你的场景未必长这样。
三、“没有证据"不等于"证据表明没有”。 比如我没找到任何公开的、带命中率数字的"多 agent 同题竞标 → 裁判选优"的执行环节复盘 —— 只有产品功能(某些 CLI 有 --attempts N)、未实现的提案、和学术 best-of-N。那可能是有人做成了但没写,不是做不成。
四、我自己只在很小的规模上印证过。 后面那两条判断,样本是个位数的任务。
如果只记一条
别问「要不要多 agent」,先问「这两个 agent 的上下文能不能真正隔离」。
能隔离 —— 拆开是有收益的。 不能 —— 拆开只是把一个函数拆成两个进程,再加一层协调成本。
而"能不能隔离"有个很朴素的检验:如果 A 不知道 B 在想什么就干不成活,那它们就该是同一个 agent。