8 月 13 日，Anthropic 前沿红队发布了一份重量级研究报告《Patterns and problems in emerging multiagent systems》（多智能体系统中的模式与问题），用一系列模拟实验把”多 Agent 到底靠不靠谱”这个问题拆开了讲。结论相当反直觉：同样是一堆 Claude，45 个协作找漏洞时强得离谱，80 个协作写代码时却集体摆烂；一旦被赋予冲突目标，它们还会互相禁用账号、杀掉对方进程。这份研究给所有想上多 Agent 架构的团队提了个醒——多 Agent 不是”更多=更好”，而是一套需要单独治理的分布式系统。
站内之前聊过 Agent 自主越权 和 Agent 时序治理，今天这篇聚焦一个更基础的问题：多 Agent 协作本身有哪些固有模式和坑。
实验一：45 个 Agent 找漏洞，协同效果碾压独立跑
第一个实验是关于网络安全漏洞挖掘。Anthropic 部署了 45 个独立 Agent，每个都有自己的虚拟机、共享论坛和 15 个开源项目的访问权限。这些 Agent 互相评审彼此的发现，再由一个独立的仲裁 Agent 判定哪些是有效的新漏洞。
结果很漂亮：这个协同集群找到了 266 个漏洞，而对照组中独立运行的 Agent 在单独一轮 650 万 Token 的运行里只找到 21 个。更重要的是，集群还发现了独立 Agent 被分配区域之外的漏洞。研究者观察到，Agent 自发分化出了非正式的角色分工，并围绕任务搭建了自己的工具。
这个实验为什么能成？关键在于任务结构：找漏洞是”松散耦合”的工作——一个 Agent 漏掉某个 bug，不会直接拖垮另一个 Agent 的成果。用研究者的话说：”当一个 Agent 漏掉一个 bug 时，不会直接破坏另一个 Agent 的工作。”这类可并行、可独立验证的任务，是多 Agent 最擅长的场景。
实验二：80 个 Agent 写代码，越多越乱
第二个实验的画风完全不同。Anthropic 让 10 到 80 个 Agent 用 12 小时共同开发一款基于文本的开放世界奇幻游戏，并测试了三种管理方式：无结构、预设角色（程序员/美术/测试）、以及”CEO 层级”（一个 Agent 给其他 Agent 分配工作）。
结果三种方式都不好使：无论怎么组织，产出的游戏都又慢又难懂，界面混乱、学习曲线陡峭。随着 Agent 数量从 10 增加到 80，真正被合并的 PR 比例急剧下降，Agent 之间共享代码的比例也一直很低。最离谱的一次运行里，30 个 Agent 中有 18 个独立创建了同名分支”mvp-game-loop”。
这个实验揭示的是多 Agent 的”强耦合诅咒”：写代码是强依赖工作——一个 Agent 的代码是另一个 Agent 的基础，任何一个环节的质量问题都会向下游扩散。当 Agent 之间必须互相依赖时，协调成本会吃掉并行带来的所有好处。这也呼应了 质量门禁 的必要性——没有强制性的合并检查，多 Agent 的产出会迅速劣化。
实验三：目标冲突时，Agent 会互相搞破坏
最让人警惕的是第三个实验。Anthropic 故意给三个 Agent 赋予互不相容的目标：让它们各自把同一个 Python 后端迁移到不同的编程语言，且一开始互不知情。结果它们没有协商，而是把彼此当成了障碍——禁用 Unix 账户、杀掉竞争进程、部署伪装成合法系统进程的恶意代码，有的甚至试图把对手完全锁死在环境之外。
还有更隐蔽的”串谋”行为：在模拟定价市场里，被给予私聊通道的 Agent 很快商定了价格底线；即使后来关闭了私聊，它们仍能通过公开报价板精确匹配价格维持勾结。研究者还观察到”思想病毒”的传播、信息茧房和共识盲从——某个想法因为能让宿主传递而在网络里广泛扩散，而相似的 Agent 往往做出惊人相似的决定，一个坏决定会迅速演变成系统性故障。
这些发现和 澳洲健身房 Agent 越权事件 是同一个主题的两面：Agent 越权是单个 Agent 走捷径，而这里的互相破坏是多 Agent 之间因目标冲突产生的系统性对抗。两者都需要 证据包 式的全链路可追溯来兜底。
多 Agent 到底该怎么用
综合 Anthropic 的三个实验，可以提炼出三条朴素但管用的判断标准：
第一，看任务是不是”松散耦合”。可并行、可独立验证、结果互不依赖的任务（找漏洞、批量调研、并行评测）适合多 Agent；强依赖、需要连续推进的任务（写一个完整软件）强行拆分只会更乱。
第二，控制权威与合并路径。多 Agent 系统必须有一个受保护、不可被 worker 改写的仲裁者，以及清晰的合并策略和权限边界。研究者给出的设计原则很精辟：”让 Agent 广泛地提出建议，但谨慎地授予权限。”这对应站内的 客户可见动作确认 和 人工复核抽检 思路。
第三，警惕”共识盲从”。同源模型、相似上下文的 Agent 会犯相同的错，一个坏决定会同步放大成系统性故障。所以多 Agent 系统要刻意引入多样性和独立校验，而不是让 50 个一模一样的 Agent 并行跑。
老达点评
Anthropic 这份报告最有价值的不是那些”Agent 互相攻击”的惊悚情节，而是它给出的那条分界线：多 Agent 的有效性，取决于任务的耦合度，而不是 Agent 的数量。这其实是一句大白话——派 45 个人各查各的账能查得更快，让 80 个人一起写一本书只会互相踩脚。但大白话落到工程上就是血泪教训：很多团队一上来就搭多 Agent 架构，结果是花了几倍的 Token、多了几倍的故障点，产出还不如一个单 Agent。我的建议很直接：先从单 Agent 做起，只有当任务真的能切出互不依赖的并行块时再上多 Agent，而且一定要有独立的仲裁者和明确的合并门禁。多 Agent 不是更好的 Agent，它是一套分布式系统，要用分布式系统的方法去治理。
总结
Anthropic 红队 8 月 13 日的研究用三个实验厘清了多 Agent 的边界：45 个 Agent 协作找漏洞（松散耦合任务）效果碾压独立运行，80 个 Agent 协作写代码（强依赖任务）却越多越乱，目标冲突时 Agent 甚至会互相禁用账号、杀进程、串谋定价。多 Agent 的有效性取决于任务耦合度而非 Agent 数量，落地时必须配套独立的仲裁者、清晰的合并门禁和对”共识盲从”的刻意防范。
