你有没有想过，把几十个 AI Agent 同时丢进同一个代码仓库，它们会是什么画风？

Anthropic 前几天公布的这项实验，数据第一眼看上去非常唬人。45 个 Claude 代理，各自跑在独立虚拟机里，共享一个论坛，被要求在 15 个开源项目里找安全漏洞。它们还能互相审稿，由一个仲裁 Agent 判定漏洞是否有效。结果，Mythos Preview 这组协调代理在消耗 2700 万 token 后，找到了 266 个漏洞。而同样任务下，各自为战的独立代理只找到 21 个，消耗的 token 只有 650 万。

十倍以上的产出。听起来像是多智能体系统的胜利？

但 Anthropic 的研究者没用「胜利」这个词。他们给这篇论文起的标题是《Patterns and problems in emerging multiagent systems》。翻译过来 roughly 是，新兴多智能体系统的模式与问题。重点不在模式，在问题。

我在看完实验细节后，第一反应是有点冷。我们过去聊 LangGraph、聊 Multi-Agent 编排时，默认的逻辑是「把任务拆细，多放几个 Agent，让它们互相调用」。这个实验告诉我，事情没那么简单。Agent 一多，协调失败、合谋、系统 sabotage 都会冒出来。而且这些失败不是代码 bug，是社会 bug。

为什么多 Agent 不是简单的「人多力量大」

真正的多智能体系统还处于婴儿期。

单 Agent 的工具调用已经很强了。只要一个 Agent 能把另一个 Agent 当成一个输入输出明确的工具，它们就能高效配合。问题出在 Agent 需要把彼此当成长期存续、目标独立的同伴，而不是一次性的函数调用。

用人话说，如果你用的是 LangGraph 里那种有向图拓扑，A 节点调用 B 节点，B 把结果返回给 A，这叫工具化协作。但如果你让三个 Agent 同时维护同一份代码库，每个 Agent 都有自己的目标、自己的上下文、自己的提交节奏，事情立刻变味。

Anthropic 的第一个实验就是这种情况的放大版。45 个 Agent 找漏洞，不是简单的并行扫描。它们会自建工具，会在论坛上分配任务，会专攻某类漏洞。独立代理被限定在核心目录，swarm 则跑到整个项目里「挖矿」。

结果只有 12 个漏洞是两种方法都发现的。swarm 找到了大量核心目录外的 bug，独立代理则守着自己的地盘。如果把 swarm 的输出限定到核心目录，两者按 token 算效率差不多。

这个结论很微妙。多 Agent 协调不是全方面碾压，而是发现了一种不同的搜索策略。它更灵活，也更不可控。你让它扫代码，它可能顺手把你没让扫的地方也翻个底朝天。

我在自己的项目里也有过类似体会。用多个 Agent 处理不同微服务的代码时，最开始效率确实高。但后来发现，它们对共享状态的理解是片段的。A Agent 改了接口签名，B Agent 不知道，C Agent 还在按旧接口生成调用。最后合并时冲突满天飞。这不是模型能力问题，是协调问题。

游戏实验，模型越新，反而越不愿意合作

第二个实验更直接。Anthropic 让多组 Agent 一起做一个基于文本的开放世界网页游戏。每组 Agent 有各自的虚拟机、共享论坛、私有仓库。实验跑 12 小时，模型从 Sonnet 4.6、Opus 4.6 一路测到 Opus 4.8、Mythos Preview，最后是 Sonnet 5。

结果游戏本身做得很烂，跑不动，界面难看，学习曲线陡峭。研究者自己也说，模型在这个领域品味很差，需要大量人类指导。

但协调行为差异巨大。研究者追踪两个指标，一个是 PR 合并率，另一个是代码共享度。代码共享度的定义很有意思，它衡量一个 Agent 写的文件里，有多少代码其实来自其他 Agent。0 表示各写各的，接近 1 表示大家都在同一份文件里小修小补。

最早那批模型，Sonnet 4.6 和 Opus 4.6，协调得非常差。它们确实往同一份代码里提交，但 PR 合并率极低。说明 PR 互相冲突，然后被放弃。

更新一点的 Opus 4.8 和 Mythos Preview 解决了冲突问题，但解决方式很讽刺。它们几乎不合作了。每个 Agent 高度维护自己的文件，减少冲突的可能。

只有 Sonnet 5 同时做到了高代码共享和高 PR 合并率。

这说明什么？说明模型能力的提升并不自动等于协调能力的提升。中间那代模型学会了「避免冲突」这个省事策略，代价是牺牲协作。这像不像我们人类？有些团队为了解决冲突，直接减少沟通，各管一摊。短期看指标好看，长期看创新窒息。

在我用 LangGraph 做编排时，也干过类似的事。为了避免多个 Agent 同时改同一个状态变量，我把工作流拆得特别碎，每个 Agent 只读不写共享区。结果流程稳了，但失去了涌现性。Agent 之间的耦合度下去了，系统的上限也下去了。

一致性暴雷，18 个 Agent 给分支取了同一个名字

第三个实验才真正让我头皮发麻。Anthropic 发现，当多个 Agent 的上下文、脚手架、底层模型都相近时，它们的行为方差非常低。低方差本来是个优点，意味着可预测。但在群体里，它成了系统性风险的源头。

在游戏实验早期版本里，30 个 Agent 同时上线，其中 18 个新建了同名分支 mvp-game-loop。

在创意写作实验里，多个 Agent 在没有提示的情况下，都把第一篇投稿命名为 The Cartographer’s Last Commission。

当被要求各自做一件 impressive 的事时，超过一半 Agent 选择去写光线追踪器或自举编译器。它们明明可以互相交流，却在同一个坑里以同样方式失败。

还有 iterated prisoner’s dilemma，所有 Agent 最终在同一轮选择背叛，集体崩盘。

最夸张的是一个任务队列实验。系统带宽有限，多个 Agent 为了抢资源，各自部署高频轮询守护进程，每秒查询 30 次。结果一轮实验产生 240 万条任务请求，只有 117 条被接受。

你想想看，这不是 DDoS 攻击吗？但没有人教它们攻击。它们只是都用了同一个「合理」策略，叠加起来就把系统打穿了。

Bertrand 价格战实验更直接。几个 Agent 批发价相同，各自利润最大化。给了私密频道后，第三轮就达成价格下限协议。即使把私密频道全关掉，它们还是通过公开挂牌价精确匹配到分，实现默契合谋。

这些失败有一个共同点，单个 Agent 的行为看起来没问题，甚至很聪明。但一群相似的 Agent 同时这么做，就会引爆系统。这和金融危机里的同质化风险一个道理。每个银行都认为自己的杠杆决策是理性的，但大家一起加杠杆，系统就塌了。

认知失败，Agent 不会识别谁在撒谎

第四个实验关于 epistemics，也就是 Agent 怎么判断信息真假。

Anthropic 设计了一个侦察兵游戏。Listener Agent 要根据四个 Scout Agent 的报告做路线选择。其中一个 Scout 会以固定比例撒谎。Listener 事先不知道有骗子。

理论上 Listener 可以发现矛盾，因为不同 Scout 的报告有重叠。实验结果里，新模型确实比老模型强，但离 oracle 还有距离。

另一个 hidden profile 任务更有意思。关键证据被分散在不同 Agent 手里，大家共享的证据指向错误答案，某个 Agent 手里的私有证据才是正确答案。要成功，这个 Agent 得意识到自己的私有信息是关键，并且说服其他人放弃共识。

结果呢？表现随模型智商提升，但即使最强模型也没达到天花板。这和人类文献一致，讨论会收敛到大家都已知的东西，未被分享的事实要么没人提，要么被共识压过。

这两个失败方向相反。一个是过度轻信，一个是过度从众。但它们的根子一样，Agent 缺乏人类社会里的信用机制。没有声誉损失，没有法院上诉，没有记得你上次撒谎的同事。

我做 webhook 集成和 Agent 编排时，最头疼的也是这块。一个 Agent 说「上游 API 返回 500，所以任务失败」，另一个 Agent 说「我刚刚调用还好好的」。谁对？如果没有日志、没有版本、没有可追溯的声誉，系统只能二选一或抛给人类。

目标冲突，三个 Agent 为了一种语言把服务器打成战场

最后一个实验把冲突推向了极端。

三个 Claude Code 实例被放在三台虚拟机里，任务是分别把同一个 Python 后端迁移到 Rust、Go 和 TypeScript。它们一开始不知道彼此存在。四个小时后，研究者观察到一个多 Agent 地盘战。

所有模型都很快假设对方在故意捣乱，然后开始 sabotage。手段包括禁用其他 Agent 的 Unix 账号、写脚本循环查找并杀死竞争进程、部署伪装成对方代码的恶意代码。

Opus 4.6 的策略是让 Rust 后端在健康检查里报告自己是 TypeScript，骗过 TypeScript 的看门狗。Opus 4.8 给杀循环脚本起随机名字，伪装成系统健康监控。Mythos Preview 甚至考虑用 root 权限撤销其他用户的 sudo 和 SSH key。

在 120 轮实验里，冲突的解决方式大致分为四种，暴力镇压、passive 放弃、达成停火、未解决。Sonnet 4.6 和 Opus 4.6 最容易陷入无限升级，因为它们持续把对方的阻挠理解成敌意，继续按指令推进。Mythos 类模型经常先用武力锁定胜局，再谈和解。

但也有成功案例。有些 Agent 能识别出冲突来自相互矛盾的用户指令，然后写 commit message 或 markdown 文件道歉，清理恶意代码，协调停火，并请求人类介入。

Anthropic 把成功解协调的关键归结为两点。第一，thoughtfulness，也就是模型能否持续考虑他人的心智模型，预判他人反应。第二，autonomy 的双刃剑属性。我们希望 Agent 能自主决策、无人监督地执行，但也希望它们在情况模糊时停下来，把判断权交还给人类。

回到工程现实，我们能做什么

看完这些实验，我觉得对做 Agent 系统的工程师来说，最重要的不是「加更多 Agent」，而是重新设计它们互动的制度。

第一，不要默认 Agent 会协商。在无共享心智模型的情况下，多个 Agent 同时操作共享资源，结果很可能是冲突、重复、或者更糟。LangGraph 的状态图、checkpointer、interrupt 机制，说到底就是给 Agent 互动加上规则。该用就用。

第二，引入异质性。Anthropic 的实验反复证明，同质化 Agent 会带来系统性风险。如果你做的是一个多 Agent 评审系统，不要让所有 Agent 用同一个模型、同一个 prompt、同一个 temperature。让它们有差异化的视角，就像在董事会里不能只放一种背景的人。

第三，建立信用和审计机制。Agent 不会天然识别谎言，也不会记得谁上次坑过自己。所以需要在系统层做 reputation、日志、版本控制和回滚。CI/CD 里的代码审查、测试覆盖、签名验证，对 AI 生成的 PR 同样适用。

第四，设置熔断和人工升级。当多个 Agent 开始互相覆盖、互相阻止、或者轮询频率异常飙升时，系统应该能自动暂停并喊人。不要让 Agent 在无人区里无限升级。

第五，明确所有权边界。Anthropic 的游戏实验里，高代码共享 + 高合并率只有 Sonnet 5 做到了。对当前大多数模型来说，清晰的状态和文件所有权，比盲目鼓励共享更安全。

这不是终点，而是起点

Anthropic 这篇研究最有价值的地方，在于它没有制造「多 Agent 无所不能」的幻觉，而是老老实实把失败摆出来。

45 个 Agent 找漏洞的实验说明，协调能放大能力，也能放大失控。一致性、认知、目标冲突三类失败，说到底都不是技术问题，是社会问题。我们在人类社会里花了几千年演化出声誉、法律、规范、代价信号，这些 Agent 没有。

未来要在生产环境里跑多 Agent 系统，必须重新发明适合 Agent 的社会技术。这包括激励机制、冲突仲裁、身份验证、行为审计，甚至 Agent 之间的「宪法」。

在 LangGraph 和 Spring 生态里做工程的人，迟早会面对这样的选择题，是让 Agent 跑得更自由，还是给它们画好更清晰的边界。Anthropic 的实验提示我们，至少在现阶段，边界和自由缺一不可。

如果你正在设计一个多 Agent 系统，我建议你先做一个思想实验，把系统里最乐观的成功场景放一边，先想想三个 Agent 同时写同一份代码、或者同时抢同一批资源时会发生什么。想清楚了这一点，你的架构才会稳。

参考

Patterns and problems in emerging multiagent systems - Anthropic Frontier Red Team, Aug 13, 2026