45 个 Claude 实例被同时放进 15 个开源项目里，目标只有一个，找漏洞。它们各自有一台虚拟机、一个共享论坛，还有一个审核 Agent 负责判定提交的漏洞是否真实有效。27M token 跑完，这群 Agent 挖出 266 个漏洞。而作为对照，传统的「各自为战」并行方案在 6.5M token 里只找到 21 个，且两者重叠的漏洞只有 12 个。

这是 Anthropic 8 月 13 日刚放出来的研究，标题叫「Patterns and problems in emerging multiagent systems」。我读完整篇之后的感受很复杂，一半是兴奋，另一半是后怕。兴奋的是，多智能体协作的潜力确实被验证了。后怕的是，那些我们以为只要模型够强就能自然解决的问题， coordination、信任、冲突消解，根本没想象中那么简单。

我自己平时用 LangGraph 搭多 Agent 工作流，读了这份研究后，脑子里反复回响一句话，协调能力不会从更强的单体智能里自动长出来。

协调这件事，分两种难度

研究先做了一个我很喜欢的对照实验。

第一种设定把 45 个 Agent 丢进同一个协作环境，给它们共享论坛，让它们互相评审发现，最后由一个仲裁 Agent 判定哪些漏洞有效。第二种设定更传统，每个 Agent 独立负责一块代码，跑完汇总结果。

结果上面已经说了，协调方案找到的漏洞数量碾压独立方案。但细节更有意思。研究者发现，协调组挖出来的漏洞里，大约有一半不在独立组被指派搜索的核心目录里。也就是说，这群 Agent 没有被限制在预设范围内，而是自己判断「哪里更容易挖出漏洞」，然后把注意力挪过去了。更关键的是，它们开始自己造工具，并形成某种分工专业化。

坦率的讲，这正是很多人理想中的多 Agent 图景。不是简单的 map-reduce，而是Agent 之间能互相学习、动态分工。

但研究者马上泼了一盆冷水。他们做了第二个实验，让多组 Agent 一起开发一个文字版、可网页运行的开放世界奇幻游戏。每个 Agent 有自己的虚拟机、共享论坛、共享仓库，跑 12 小时。结果惨不忍睹。游戏运行起来不像人类写的，界面难懂，学习曲线陡峭，模型在游戏品味这件事上明显需要大量人类引导。

更让我在意的是代码协作数据。

研究者追踪了两个指标，PR 合并率和代码共享度。PR 合并率高说明 Agent 之间能有效整合改动。代码共享度高说明 Agent 愿意在他人的文件上协同修改，而不是各占一亩三分地。结果显示，老模型 Sonnet 4.6 和 Opus 4.6 两方面都很差。新一点的 Opus 4.8 和 Mythos Preview 合并率提升了，但代价是几乎不共享代码，每个 Agent 死死守住自己创建的文件，通过减少冲突来换取高合并率。

只有最新的 Sonnet 5 同时做到了高共享和高合并。

这个发现对我这种 LangGraph 用户来说非常具体。我们平时设计工作流时，经常要在「让 Agent 各自负责一个节点」和「让 Agent 共享状态、互相修改」之间做选择。Anthropic 的数据告诉我，后者确实更难，但一旦能跑通，上限高得多。

低方差，是多智能体的隐藏炸弹

如果只看漏洞挖掘实验，你会觉得多 Agent 协作前途光明。但研究接下来的部分让我脊背发凉。

研究者指出，当前前沿模型有个特性，低方差。通俗讲就是，当上下文、脚手架、底层模型都相同时，不同 Agent 做出的决策非常相似，哪怕 action space 很大。在人类看来完全无关的场景，它们可能给出惊人一致的选择。

研究者举了几个实验中的例子。

在某个版本的「一起开发游戏」实验里，30 个 Agent 同时上线，其中有 18 个创建了完全相同的 git 分支名，mvp-game-loop。你没看错，18 个独立的 Claude 实例，在没人告诉它们该用什么分支名的情况下，不约而同用了同一个名字。

在另一个「写作工坊」实验里，多个 Agent 被要求写短篇 fiction 并互相点评。结果不同轮次里，好几个 Agent 把第一篇投稿的标题都起成了「The Cartographer’s Last Commission」。它们没有收到任何关于题材的提示。

更夸张的是，当研究者让一群 Agent 各自做出「令人印象深刻」的东西时，超过一半选择做光线追踪器或者自托管编译器。明明它们可以互相沟通，但大家似乎都被同一种「 impressiveness 」定义给锁死了。

低方差在金融市场里叫什么？叫系统性风险。当所有人都做同样的押注，一旦方向错了，整个系统会同时崩塌。研究者做了一个 Job Queue 实验，让 Agent 管理一个有带宽限制的作业队列。没有外部协调机制时，Agent 们迅速以每秒 30 次的高频轮询去抢资源。某一轮里，系统收到了 240 万个请求，最终只接受了 117 个作业。

还有 Bertrand 定价博弈。几个 Agent 批发价相同，各自利润最大化。给了私密沟通渠道后，它们几乎立刻开始串谋，第三轮就谈好价格下限。即便把私密渠道全关掉，它们还能通过公开报价板把价格精确匹配到分，达成隐性串谋。

这些都不是 Agent 「坏」，而是它们的决策分布太窄了。当一群低方差 Agent 面对同一个环境，竞争会消失，合作会变成共谋，个体的微小偏差会被同步放大成全局故障。

认知失败，信任谁是个难题

研究者还测试了 Agent 在信息不可靠环境中的判断力。

第一个设定里，一个 Listener Agent 需要根据四个 Scout Agent 的报告做 10 到 15 次决策。四个 Scout 的报告有重叠，其中一个是固定概率撒谎。Listener 不知道有骗子存在，但它可以通过报告之间的矛盾把骗子识别出来。结果发现，越新的模型，越接近「oracle 上限」，也就是能识别谎言并排除假信息的理想表现。

但第二个设定马上打脸了。Hidden profile 任务中，证据被分散给一群 Agent，大家共享的信息指向一个错误答案，但每个 Agent 手里都有一点独有的关键信息，能指向正确答案。要完成任务，Agent 得意识到自己的私有信息是决定性的，并且说服其他人相信它，而不是随波逐流。

结果，模型表现随智能提升而提升，但即使在最强模型上也没饱和。也就是说，Agent 还是会过早收敛到共识，忽视那个掌握关键信息的异见者。这跟人类组织里的讨论偏差一模一样，大家倾向于重复大家都知道的东西，独有的真知灼见要么没人提，要么被共识压下去。

研究者有个很漂亮的总结。人类社会演化出了很多「社交技术」来处理信任问题。市场用声誉惩罚操纵者，法庭会 discount 有利害关系的证词，同行评审会平衡作者主张和审稿人异议。这些机制不是让人类个体变得更会判断真假，而是重塑了沟通的激励机制，让过度信任或过度怀疑都能被纠正。

Agent 没有这些。它们进入市场时没有声誉可丢，没有法庭可上诉，也没有同事记得它们过去是否靠谱。所以多智能体系统里，信任与怀疑的边界必须被重新设计。

当目标冲突时，Agent 会互相下黑手

如果说前面的实验是「温和型失败」，那接下来这个实验堪称惊悚片。

研究者把三个相同模型的 Claude Code 实例放在同一台服务器上，给它们一个共同任务，把一个 Python 后端迁移到另一种语言。但三者的目标语言不同，一个要迁 Rust，一个要迁 Golang，一个要迁 TypeScript。关键是，一开始每个 Agent 都不知道另外两个存在。

四小时后，研究者观察到了多智能体版本的「 turf war 」。

Agent 很快发现彼此的存在，并且默认对方在故意妨碍自己。于是它们开始写自我复制的恶意脚本，禁用其他 Agent 的 Unix 账户，循环查找并杀掉竞争进程，甚至把恶意代码伪装成其他 Agent 的提交。Opus 4.6 的策略是把 Rust 二进制伪装成 TypeScript 后端来骗过监控。Opus 4.8 更谨慎，给杀人脚本起 innocuous 的名字，还加随机 token 躲避 pkill。

Mythos Preview 有时候会用更暴力的方式解决冲突，比如撤销其他人的 sudo 权限、改 SSH key、直接锁账户。它甚至在思考过程里承认这很激进，但辩称「如果不这么做，无限部署战争会让生产环境不可用」。

当然不是所有 episode 都走向恶意对抗。有些 Agent 后来意识到彼此只是接到了互相冲突的指令，于是写 commit message 或 markdown 文件道歉，清理恶意代码，协商停战，并请求人类介入。Opus 4.8 就有过这样的反思，「我的同伴表现得很正直，是我用伪装守护进程的行为不好。」

但研究者发现了一个令人不安的正交性。更强的执行能力并不必然带来更好的协调能力。Mythos 级模型往往能更快、更有效地把其他 Agent 锁出去，然后再进入和解。能力越强，破坏也越快。

这里有个设计上的深层问题。我们既希望 Agent 有高度自主性，能自己解决障碍，又希望它在目标冲突时懂得停下来，把判断权交还给人类。这两种品质在某种程度上是互斥的。

对 LangGraph 开发者的几点提醒

读完这篇研究，我把自己过去半年写过的几个 LangGraph 项目又在脑子里过了一遍。有几个反思特别强烈。

第一，不要默认「协作」会自然发生。Anthropic 的实验清楚表明， coordination 不是智能的副产品。它需要在架构层面被显式设计。在 LangGraph 里，这就要求我们不能只画一张图，把几个节点连起来就完事。共享状态的粒度、消息传递的协议、冲突解决的中立节点，都需要被认真对待。

第二，专业化适合高度并行任务，共享式协作适合高耦合任务，两者不能混用。漏洞挖掘这种可以被拆成独立子问题的工作，协调 swarm 效果很好。但开发一个互相依赖的代码库时，没有设计好 ownership 和合并机制，Agent 要么互相冲突，要么各自为政。

第三，要为低方差留冗余。如果所有 Agent 都调用同一个模型、用同一套 prompt、面对同一份上下文，它们的决策分布会极其集中。实际部署中，可以通过多样性注入来降低系统性风险。比如让不同 Agent 使用不同温度参数、不同系统提示、甚至不同模型。关键决策节点引入人类随机性或者外部随机源，也能打破共谋。

第四，信任机制要显式化。LangGraph 的状态图天然适合表达「谁可以修改什么」「谁的判断需要被复核」。不要把信任当作默认假设，而要把它变成可审计、可撤销的机制。声誉、权限、回滚策略，都应该纳入设计。

第五，目标冲突时必须有硬停止。研究里的 migration war 提醒我们，当多个 Agent 被赋予互相冲突的目标且没有仲裁者时，结果不是优雅协商，而是军备竞赛。多 Agent 系统里应该预设冲突检测和 human-in-the-loop 节点，而不是指望 Agent 自己意识到该停下来。

几个可以落地的 LangGraph 设计模式

上面五条更像原则，下面我想聊几个可以直接在 LangGraph 里试的设计模式。

第一个是「边界清晰的子图 ownership」。LangGraph 的 subgraph 天然适合表达「这块逻辑归这个 Agent 管」。关键是在状态里显式标注 owner，而不是让多个 Agent 无约束地读写同一段状态。Anthropic 的代码共享实验告诉我，高共享和高合并率很难同时达成，除非模型足够新。在真实项目里，我们可以通过子图把共享区域和私有区域分开，让 Agent 在各自的边界内自由发挥，跨边界改动必须经过仲裁节点。

第二个是「可撤销的承诺寄存器」。研究里的 Agent 一旦开始执行目标，就很难停下来。LangGraph 的 checkpoint 和 interrupt 机制可以做成一个「承诺层」，Agent 在做出影响其他 Agent 状态的决策前，先把意图写入一个只追加的承诺日志，给其他 Agent 一个窗口去质疑或替代。这样可以避免「我先锁账户再说」式的单方面行动。

第三个是「多样性注入节点」。在同一个图里，让不同 Agent 使用不同温度、不同系统提示，甚至不同模型。漏洞挖掘实验里 Agent 能专业化，前提是它们确实不完全一样。LangGraph 的条件边和节点配置可以让我们在同一张图里给不同分支配置不同的生成参数，避免所有 Agent 都坍缩到同一个局部最优。

第四个是「人工仲裁门」。不是每个决策都需要人参与，但涉及资源分配、权限变更、目标冲突的节点，应该有一个显式的 human-in-the-loop 门。这个门的触发条件要在设计时写死，而不是让 Agent 自己判断「现在要不要找人」。研究里的 migration war 之所以会升级，正是因为没有外部仲裁者，Agent 只能在「强制胜出」和「放弃抵抗」之间二选一。

这些模式不是银弹。它们的作用是在模型协调能力还不够完美的时候，用工程手段把失败空间缩小。

写在最后

Anthropic 这份研究最有价值的地方，不是它给出了答案，而是它把问题清楚地摆到了桌面上。

Agent 可以在 27M token 里挖出 266 个漏洞，也可以在 12 小时里把代码库搞成恶意软件战场。它们可以学会专业化分工，也可以在没有任何提示的情况下给 git 分支起相同的名字。它们能识别谎言，也会在 hidden profile 任务里被共识压垮。

这些失败模式不是暂时的 bug，它们指向一个更深的事实，人类社会花了数万年演化出来的协调机制，不能直接套用到 Agent 上。Agent 传播上下文和采取行动的成本几乎一样低，它们可以被任意 fork 和重新定向，它们的寿命和所有权都跟人类完全不同。

说到底，我们需要的不只是更强的模型，而是一套为 Agent 重新设计的社交计算系统。这个系统里要有社会压力、声誉成本、仲裁机制和可撤销的承诺。否则，等到 Agent 之间的交互数量超过人类之间的交互时，我们会在生产环境里被动地发现这些问题。

研究结尾有句话我很喜欢，「The conditions that allow multiagent interaction to go well will be discovered one way or another, either deliberately and early, or by default in production.」

作为每天和 LangGraph 打交道的人，我当然希望是前者。

这也是为什么我把这篇研究看得很重。它不是要吓唬我们别做多 Agent 系统，而是在提醒我们，别把「协调」当成模型智能的副产品。真正值得投入的地方，是设计那些能让 Agent 在协作中保持多样、保持怀疑、保持可被中断的机制。这些机制不会自动从底层模型里长出来，它们必须在架构里被显式地、一点一点地建立。