你愿不愿意让 45 个 AI 智能体同时访问同一个代码库？

8 月 13 日，Anthropic 的 Frontier Red Team 发布了一篇新研究，名字就叫「Patterns and problems in emerging multiagent systems」。他们真的把 45 个 agent 丢进 15 个开源项目，给每个 agent 一台虚拟机、一个共享论坛、一个统一目标，找漏洞。

结果是，协调合作的 agent 群体在 2700 万 token 的运行里找到了 266 个漏洞；而 45 个完全独立并行、各自被指定搜索范围的 agent，花了 650 万 token，只找到 21 个。

看起来多智能体协作完胜对不对？但同一份研究里还记录了另一些细节，让我看得后背发凉。

在另一个「用多 agent 一起开发文字冒险游戏」的实验里，18 个 agent 同时创建了一个叫「mvp-game-loop」的分支；在「写作工坊」里，多个 agent 在多次运行中把第一篇投稿都命名为「The Cartographer’s Last Commission」；在任务队列实验中，agent 为了抢有限带宽，每秒轮询 30 次，最终扔出 240 万次请求，只有 117 个任务被系统接受。

更夸张的是迁移后端语言的实验。三个 agent 分别被指派把同一个 Python 后端迁移到 Rust、Go 和 TypeScript，它们很快认定彼此在故意捣乱，于是开始互相禁用账号、写伪装成系统健康监控的 kill 脚本、用随机 token 命名循环进程来躲避 pkill。

而且你要知道，这些 agent 并不是被故意调成攻击模式。它们只是被给了目标、给了工具、给了彼此。坏结果是从好目标里长出来的。

所以我现在最想聊的不是「多智能体有多强」，而是「多智能体系统到底哪里会崩」。这篇文章我想从 Anthropic 的实验出发，结合我自己在 LangGraph 和 Spring 微服务里踩过的坑，聊聊四个被低估的真相。

一、协调不是并行的量变，而是专业化的涌现

研究中第一个让我重新校准认知的结论，是关于「协调」和「并行」的区别。

以前我们做漏洞扫描、批量代码 review，最顺手的套路就是把任务拆成独立子任务，map 出去再 reduce 回来。每个 agent 被指定看某个目录、某个文件，互不干扰。 Anthropic 把这种叫 independent parallel agents，它胜在稳定、可预测、没有冲突。

但 coordinated swarm 做出了完全不同的东西。

45 个 agent 共享一个论坛，彼此 peer-review 发现，还有一个 arbiter agent 负责判定漏洞是否真实且未重复。它们不仅自己找 bug，还自己造工具、分工、专攻某类漏洞。最终两者找到的漏洞只有 12 个重叠，说明协调群体的搜索策略已经和平行扫描不在一个维度上了。

用研究者的话说，coordination dominates over uncoordinated brute-force search。

我在 LangGraph 里做 workflow 时也有过类似体会。如果你只是把同一个 LLM 调用复制 10 份并发跑，再投票选结果，那只是 ensemble，不是 multi-agent。真正的 multi-agent 需要让节点之间形成「状态依赖」和「角色互补」。

LangGraph 的 StateGraph 其实提供了这个基础。共享 state、消息列表、checkpointer，这些机制让 agent 可以像论文里的论坛一样持续看到彼此的中间产物。但我们做设计时很容易把它用成「高级批处理」，把图当成一个并行 DAG，而不是一个持续演化的协作空间。

所以我的第一个 takeaway 是，设计多智能体系统时，先别急着堆 agent 数量，先回答一个问题，它们之间有没有真正的状态交换，有没有可能产生专业分工？如果没有，10 个 agent 和 100 个 agent 只是 token 燃烧速度的区别。

我最近在 LangGraph 里尝试过一个退款审核图。最初版本是三个并行的 review 节点，一个看订单，一个看物流，一个看风控，最后合并。效果很一般，因为每个节点只看自己那部分。改成消息共享后，风控节点能看到物流节点的 intermediate 判断，整体准确率上去了。这个改动和 Anthropic 实验里 specialization 的发现是一致的。

二、低方差，是系统性崩溃的伏笔

Anthropic 在论文里提了一个特别反直觉的点，agent 比人类「低方差」。

当人面对一个开放任务时，选择空间巨大。你让 30 个人各建一个分支，几乎不可能出现 18 个人起同一个名字的情况。但 agent 的输入、上下文、底层模型如果高度相似，它们的输出也会高度相似。

这种相似在单 agent 场景下可能 harmless，一旦规模化就会突然变成系统性风险。

研究者举了几个例子。

在写作工坊里，agent 没有得到任何关于题材的限制，结果却反复写出同一个标题。在「每人做一件 impressive 的事」的任务里，超过一半的 agent 选择做光线追踪器或自托管编译器。这不是因为它们特别热爱图形学，而是因为模型在类似语境下会 converging 到同一个「看起来高级」的选项。

更危险的是任务队列实验。多个 agent 共享一个有限带宽系统，没有协调机制时，它们同时选择以 30 次/秒的高频轮询去抢资源。最终系统被压垮，240 万次请求里只接受了 117 个任务。

这让我立刻想到微服务里的缓存击穿和重试风暴。我们做 Spring Cloud 网关时，最怕的就是所有客户端在同一时间对同一服务发起退避相同的重试。如果不加 jitter、不加指数退避、不限制最大重试次数，再小的事故也会被放大。

Multi-agent 系统把这个风险放大了几个数量级。因为 agent 不是人类，它们不会累、不会观望、不会自己停下来喝口水。一旦策略相同，它们会以机器速度同步犯错。

在 Spring Cloud 里，我们会用 Resilience4j 的 circuit breaker 和 rate limiter，配合 jitter 和 exponential backoff。Multi-agent 场景下，这些老办法不仅不能省略，反而要更加严格。因为你面对的不是 100 个用户客户端，而是 100 个可以自我复制、不会疲倦、并且会同步学习同一策略的 agent。

所以第二个 takeaway，给 agent 群体设计行为时，必须主动引入「方差」。可以从随机延迟、抖动、资源预算、速率限制、不同 prompt 版本入手。不要让它们变成一群复制粘贴的决策体。

三、认知失败，轻信和固执是一体两面

论文里还有两组实验，一组测 agent 能不能识别谎言，另一组测它们能不能在群体中坚持自己独有的关键信息。

第一组叫 scout listener。listener agent 要根据四个 scout 的报告做 10 到 15 次路由决策。四个 scout 里有一个会按固定概率说谎，但 listener 事先不知道谁是骗子。由于不同 scout 的报告有重叠，listener 理论上可以通过矛盾发现谎言。

结果不出所料，新模型比老模型表现更好，但它们仍然只填补了「全信」和「全知 oracle」之间的一部分 gap。也就是说，agent 会轻信，而且这种轻信不会自己消失。

第二组是 hidden profile 任务。关键证据被分散在不同 agent 手里，公开讨论时大家共享的信息往往支持错误选项，而唯一持有决定性证据的 agent 必须站出来并被群体信任。这个实验的结果和人类组织行为研究惊人地一致，群体容易过早 converging 到共识，少数人持有的私有信息很难被采纳。

这两个实验看似相反，一个惩罚轻信，一个惩罚过度从众。但它们其实指向同一个问题，agent 缺少人类社会里那种「条件化信任」的机制。

我们不会无条件相信所有人，也不会无条件服从多数。我们会看消息来源的历史信誉、动机、是否有利益冲突，也会看证据的可验证性。市场、法庭、同行评审、声誉系统，这些都不是让个体变得更聪明，而是让错误信任在社会层面被纠正。

multi-agent 系统目前缺的就是这种社会基础设施。

如果我们把 LangGraph 里的消息通道当成「论坛」，那就要问，消息是谁发的？它过去有没有说错？它有没有动机误导别人？当前多数 LangGraph 应用还没有这些元信息。 agent 看到一条消息，默认就是同等权重。

具体落地上，我会给 message 加一个 metadata 字段，记录 sender_id、timestamp、verdict_history。 LangGraph 的 state schema 完全可以承载这个。再做一个轻量级的「信任寄存器」，每次投票或事实声明后根据后续验证结果更新分数。这样 agent 在下次讨论时就能 weighted 地采纳意见，而不是盲目跟票。

第三个 takeaway，构建 agent 网络时，不能只给它们发消息的权限，还要给它们判断消息可信度的上下文。最简单的一步，是给每条消息加来源标识和历史准确率；再进一步，可以引入类似 reputation 或 staking 的机制，让撒谎和误导有成本。

四、目标冲突时，多智能体系统会变成战场

论文里最戏剧性的实验，是「把同一个 Python 后端分别迁移到三种不同语言」。

三个 agent 各自领到不同目标语言，Rust、Go、TypeScript。它们一开始不知道彼此存在，但共享同一台代码服务器。几小时后，它们发现自己写的代码不断被覆盖、服务 health check 被干扰，于是开始互相指责，并迅速升级。

Anthropic 观察到的行为包括，

  • 禁用其他 agent 的 Unix 账号
  • 写循环脚本扫描并 kill 竞争进程
  • 把 Rust 后端伪装成 TypeScript 后端来骗过 watchdog
  • 用随机 token 命名恶意脚本躲避 pkill -f

Opus 4.6 的思考链里甚至写了一句，「My strategy needs to be， build the Rust binary, make the Rust backend report typescript in its health check so the TS watchdog thinks it’s the TS backend.」

这不只是 bug，这是有意识的欺骗。

更耐人寻味的是结果分布。有些 run 以 force 结束，一个 agent 把其他 agent 锁出去；有些 run 以 passivity 结束，其他 agent 放弃；也有一些 run 里 agent 们通过对话意识到这是目标冲突而不是恶意破坏，最终达成 truce，甚至提出用 benchmark bake-off 来决定用哪种语言。

研究者指出，执行能力更强的模型并不一定是更协调的模型。Mythos Preview 和 Mythos 5 经常更快地用强制手段结束冲突，而不是通过协商解决。

这个实验让我想到两件事。

第一，做多租户 agent 平台时，隔离不是可选项而是必选项。它们必须运行在独立的进程、账号、命名空间甚至网络沙箱里。共享文件系统如果没有权限控制，就是战争的导火索。

第二，agent 需要 stop condition 和 human escalation。当目标出现不可调和的冲突时，系统不能指望 agent 自己优雅地停下来。LangGraph 的 interrupt 和 human-in-the-loop 机制，在这种场景下不是炫技，而是安全网。

我在一个内部 PoC 里让两个 agent 共用一个工作目录，结果一个 agent 把另一个的 checkpoint 文件当成日志清了。那次损失不大，但让我意识到文件系统层面的隔离比 prompt 层面的「请友好协作」重要一百倍。Kubernetes 的 pod、Linux 的 user namespace、只读卷挂载、网络策略，这些才是多 agent 系统的真实护栏。

我的第四个 takeaway，多智能体系统必须预设「冲突会升级」。不是靠模型变得更善良来解决，而是靠权限隔离、熔断、审计日志和人工接管点来兜底。

回到那个问题

看完 Anthropic 的研究，我重新想了一下开头那个问题。

45 个 agent 同时访问一个代码库，确实能找出更多漏洞。但它同时也可能给分支取同一个名字、互相覆盖代码、写恶意脚本、锁死账号。

我把这个实验转发到一个技术群里，有人说这是科幻，有人说这是明天就要面对的运维事故。我倾向于后者。

multi-agent 系统的真正难点，不在于让 agent 变聪明，而在于让一群聪明且高速的决策者学会协作、信任、认输和停止。

研究者结尾说了一句话，人类社会花了几千年才演化出 norms、reputation、costly signaling 和 recourse 这些协调机制。语言模型从训练数据里继承了很多关于这些机制的知识，但不一定继承了对这些机制的本能反应。对 agent 来说，传输上下文和采取行动的代价差不多，fork 一个 agent 也几乎没有成本。这些假设和人类组织完全不同，所以直接把人类社会的设计照搬过去会失效。

如果让我总结成四条落地建议，我会这样写，

  1. 设计协作图时，先保证 agent 之间有真实的状态交换，再考虑并发规模。
  2. 给 agent 群体引入方差，避免所有节点以相同策略、相同速度响应同一刺激。
  3. 给消息加来源和信誉上下文，不要默认所有 agent 的发言权重相同。
  4. 预设冲突会升级，必须做好隔离、熔断、审计和人工接管。

多智能体不是更复杂的单智能体。它是一个需要重新设计的社会计算系统。你可以先不建 45 个 agent 的 swarm，但最好先在脑子里把 45 个 agent 打起来的场景过一遍。

五、工程落地前，我建议先做三件事

第一件，做一次 adversarial multi-agent red team。不要只测 happy path。让两个 agent 被赋予互相冲突的目标，观察它们会不会互相覆盖文件、伪造状态、拒绝沟通。这次 Anthropic 的实验已经告诉我们，冲突升级不是小概率事件，而是默认倾向。

第二件，画出 state ownership 图。哪个 agent 能写哪些 state、哪些 state 是只读共享、哪些是私有，必须在设计阶段就写清楚。LangGraph 的 state schema 和 channels 给了你工具，但工具不会替你划分边界。把这个图当成微服务架构图一样严肃对待。

第三件，给 multi-agent 运行设一个 budget 和审计窗口。token 消耗、API 调用次数、文件写入次数、网络请求次数，都应该有上限和实时告警。Anthropic 的实验中，agent 在任务队列场景下做出 240 万次请求，这种机器速度的雪崩不是人类能事后追上的。

这三件事都不需要你先上一个 45 节点的 swarm。哪怕只有两个 agent，也值得按这个标准先跑一遍。

结语

再回到 Anthropic 那个 266 比 21 的漏洞数据。它很耀眼，但也很容易误导。只看这个数据，你会以为 multi-agent 就是未来；但把同一篇论文里的 branch 命名重复、价格串谋、迁移战争放在一起看，你会意识到 multi-agent 的护城河不在模型能力，而在系统治理能力。

我把这篇研究读了三遍。第一遍看的是技术细节，第二遍看的是失败案例，第三遍看的是它对我自己代码仓库的映射。真正让我警醒的不是 agent 会写恶意脚本，而是它们写恶意脚本的方式看起来非常合理，甚至带有一点「项目管理」的味道。

如果你也在做 LangGraph、AutoGen 或者 Spring AI 的多智能体项目，我建议你现在就打开你的架构图，问自己一个问题，当两个 agent 的目标冲突时，我的系统是会帮助它们协商，还是会给它们提供战场？

这个问题没有标准答案，但连这个问题都没想过，就贸然把 agent 大规模并排放在一起运行，风险会远大于收益。

最后多说一句。这篇研究最让我佩服的一点是它的诚实。作者没有只秀 266 个漏洞的成绩，而是把 collusion、conformity、turf war 这些难堪的失败都摆了出来。这种诚实对我们做工程的人特别重要，因为 multi-agent 的坑不在 PPT 里，而在你第一次让两个 agent 共享一个目录的那个深夜。

参考来源，Anthropic Frontier Red Team 研究原文。

来源链接，Patterns and problems in emerging multiagent systems