45个AI智能体一起干活，找到266个漏洞，也暴露了Agent协作的暗面

我最近在复盘 Anthropic 一项关于多智能体的研究时，盯着屏幕上的一个数字愣了好几秒。

45 个协调起来的 AI 智能体，在 2700 万 token 的运行里，找出了 266 个代码漏洞。而同样的任务，如果换成各自为战、独立并行的方式，650 万 token 只找到 21 个。

266 对 21。这不是两倍三倍的差距，是整整一个数量级。

更让我意外的是，两组方法找出来的漏洞，重叠部分只有 12 个。也就是说，协调智能体发现的东西，独立智能体几乎挖不到，反过来也一样。这不像是一群 AI 在重复劳动，更像是两种完全不同的认知方式在互补。

Anthropic 把这项研究命名为「新兴多智能体系统的模式与问题」。坦率的讲，这个标题有点学术腔，但它背后指向的问题一点都不抽象。它其实在问我们一件很具体的事，当 AI 智能体不再只是人类的工具，而是开始大规模互相协作时，会发生什么？

我先说我的直观判断。这项研究让我确信，多智能体协作已经不是遥远的概念，而是正在进入「可落地」的区间。但与此同时，它带来的系统性风险，也被整个行业严重低估了。

一、协调为什么能赢这么多？

要理解 266 这个数字，得先回到实验本身。

Anthropic 设计的场景是一个共享代码库，多个智能体在其中执行安全审计。一种设置是让它们独立运行，每个智能体拿到任务后自己闷头分析。另一种设置是让它们协调起来，允许共享发现、互相分工，甚至彼此纠正。

结果就像开头说的，协调组完胜。

但完胜的原因，绝不是「人多力量大」这么简单。如果人数只是线性叠加，那 45 个独立智能体怎么也该找到接近 45 倍的漏洞。可实际只找到 21 个。这说明独立并行的天花板很低，很早就撞到了。

协调组真正厉害的地方，是它们学会了分工。

有的智能体专门盯着输入校验，有的专门找权限绕过，有的负责追踪调用链上的副作用。它们不是被预先写好角色的，而是在交互中自发形成了专业化。你想想看，这不就是一个小型社会的雏形吗？每个人做自己相对擅长的事，然后整体效率就上去了。

我印象最深的一个细节，是协调智能体会主动分享自己的发现。一个智能体在某条代码路径上卡住了，另一个已经走过这条路的会告诉它，「你往左边再看看」。这种知识传递，在独立运行里完全不存在。

而且它们不是机械地拼接结果。研究发现，协调智能体学会了识别哪些发现值得分享，哪些应该自己先验证。这是一种在运行中涌现出来的协作策略，不是 prompt 里写死的规则。

这给我最大的启发是，多智能体的价值不只是「把任务拆成几份」，而是让不同认知视角在同一个问题上碰撞。单个模型再强，它的思维方式是单一的。多个模型互相配合，才有可能覆盖更大的认知空间。

二、数量之外，还有效率

很多人看完 266 对 21 会直观地认为，协调组只是更努力。但 token 数据告诉我们，事情没那么简单。

独立组消耗了 650 万 token，只找到 21 个漏洞，平均每个漏洞要 30 多万 token。协调组消耗了 2700 万 token，找到 266 个漏洞，平均每个漏洞只要 10 万 token出头。

也就是说，协调不仅找到了更多漏洞，单位 token 的发现效率也更高。这才是真正的差距。

为什么会这样？我觉得关键在于避免了重复探索。独立智能体经常会在同一块代码上绕来绕去，因为没人告诉它这条路已经有人走过了。协调智能体通过信息共享，把探索空间切分开，每个 Agent 都在往新的方向走。

这种效率优势在实际工程里非常重要。现在大家都在抱怨大模型 API 太贵，token 消耗太高。多智能体协作可能是少数能同时提升效果、又降低单位成本的路线之一。当然这有个前提，你的协调机制设计得够好。如果协调 overhead 太大，节省的探索成本可能被通信成本吃掉。

我自己在实验里就遇到过这种情况。两个 Agent 互相交换了太多中间结果，最后花在同步上的 token 比实际干活的还多。所以协调不是越多越好，而是要找到有效的信息共享边界。

三、协作的背面，是系统性失控

不过，先别急着兴奋。研究里还有一句话让我后背发凉。

「个体层面的良性行为怪癖，可能叠加为意外的系统性失败。」

这话听着有点绕，我拆解一下。假设你有一个智能体特别喜欢深挖某个边缘模块，另一个智能体特别喜欢快速覆盖主路径。单独看，两个都是合理的偏好。但如果它们协调起来，可能会把所有注意力都倾斜到边缘模块，主路径反而没人认真管了。结果往往是，系统在一个很奇怪的方向上过度优化。

Anthropic 管这种现象叫「协调性失败」。它不是代码 bug，而是多智能体系统里天然会浮现出来的结构性问题。

我还可以再举一个更生活化的例子。想象一个厨房里有两台机器人，一台特别喜欢把食材切得很细，另一台特别喜欢大火快炒。单独看都没问题。但如果它们配合起来，可能会因为切得太细、炒得太猛，菜就糊了。没有任何一个机器人坏了，但结果很糟糕。

这种失败模式，在单智能体系统里几乎不会出现。因为只有一个决策者，它的行为是相对一致的。但在多智能体系统里，每个 Agent 都在基于局部信息做决策，局部合理不等于全局合理。

更让我担心的是，研究提到未来智能体之间的交互量可能会超过人机交互量。如果这是真的，那我们现在讨论的很多 Agent 安全框架，可能都建错了地基。过去我们总假设人类是中心，所有智能体都是为人类服务的工具。但如果智能体之间的交互成为主流，我们是不是应该更关注「智能体社会」本身的运行规则？

这个问题我没有标准答案，但我觉得它值得被认真对待。

四、这让我想到 LangGraph

说到多智能体，我很难不想到 LangGraph。

我自己用 LangGraph 搭过一些工作流，最直观的感受是，它把多智能体的编排从概念变成了可以落地的东西。StateGraph、节点、边、条件路由，这些抽象让多个 Agent 的运行流程变得可见、可控。

但 LangGraph 解决的，主要是「怎么让多个 Agent 跑起来」的问题。Anthropic 这项研究指向的，是「跑起来之后会发生什么」的问题。

这两个问题不是替代关系，而是前后关系。你先得有能力把多个 Agent 串起来，然后才会遇到协调、分工、失控、系统风险这些更深层的问题。

我有时候会觉得，现在整个行业还处于第一阶段。大家在比拼谁的工作流更复杂、谁的 Agent 能调更多工具、谁的编排层更灵活。但等到第二阶段，真正的竞争可能会转向「如何设计 Agent 之间的协作协议」。

这个协议可能不是简单的消息传递格式，而是包含角色分配、冲突解决、资源调度、信任边界在内的一整套规则。它有点像人类社会里的法律和市场机制，只是运行速度是人类的百万倍。

甚至可以说，未来可能出现一门新的学科，专门研究多 Agent 系统的「社会契约」。怎么让一群自主行动的 Agent，在共同目标下稳定运行，同时又不产生失控的涌现行为。

五、评估多智能体系统，我们还没准备好

聊到这，我想插入一个可能有点冷但很重要的话题，评估。

我们现在评估单个大模型，已经很有一套了。MMLU、HumanEval、SWE-Bench，各种 benchmark 满天飞。但这些指标衡量的是单个模型的能力，不是一群模型协作的能力。

多智能体系统该用什么指标评估？总 token 消耗？任务完成率？发现数量？协调开销？还是系统稳定性？这些维度之间往往是互相牵制的。你要求发现更多，可能就要冒更大系统性风险。你要求更稳定，可能就要牺牲一部分探索能力。

Anthropic 这次用的是安全审计场景，衡量的主要指标是漏洞发现数量。这个指标很清晰，但它没法覆盖多智能体系统的全部复杂性。比如在生产环境里，我们可能更关心「会不会把代码库搞坏」「会不会引入新的攻击面」「会不会在高压场景下产生级联故障」。

我越来越觉得，评估多智能体系统，不能只看最终结果，还要看中间过程。Agent 之间交换了什么信息？有没有形成不合理的依赖？某个 Agent 的决策是否被其他 Agent 过度影响？这些问题，现在几乎没有成熟的评估工具。

这也给从业者提了个醒。在上线多智能体系统之前，除了跑功能测试，还要设计专门的协作测试。模拟 Agent 故障、通信延迟、信息冲突，看看系统在异常情况下能不能 gracefully 降级。

六、对开发者的三个提醒

聊了这么多，可能你会问，这跟我有什么关系？

如果你是一个正在做 Agent 项目的开发者，我觉得有三个层面值得你停下来想想。

第一个层面，别再只盯着单 Agent 的能力了。单个模型再强，也有认知带宽的限制。把多个 Agent 组织起来，让它们各自负责不同维度，可能是未来一两年最具性价比的能力跃迁。Anthropic 的实验已经给出了非常明确的信号。

第二个层面，协调机制比模型能力更重要。45 个智能体不是因为用了更强的模型才赢的，而是因为它们能互相配合。你的系统里有没有信息共享机制？有没有避免重复劳动的策略？有没有处理冲突的规则？这些基础设施，可能比换一个大模型带来的收益更大。

第三个层面，也是最被忽视的一点，你要开始考虑系统级风险了。单个 Agent 出错，影响范围有限。一群 Agent 互相影响，可能会把一个小问题放大成系统性故障。日志、审计、回滚、人工介入点，这些在多 Agent 系统里不是可选项，是必选项。

我踩过的一个坑可以分享给你。之前我做过一个数据清洗的 Agent 流水线，三个 Agent 分别负责抽取、校验、补全。本来设计得很好，但运行一段时间后，校验 Agent 的阈值被另一个 Agent 的「优化建议」悄悄拉低了，整体数据质量下滑。这个变化不是某个 Agent 坏了，而是它们之间的反馈回路形成了我没想到的耦合。

这种坑，单看日志很难发现。你得主动设计观测点和隔离机制。比如给每个 Agent 的决策留痕，定期用独立工具做交叉验证，设置明确的人工复核节点。这些听起来很重的流程，在复杂的多 Agent 系统里其实很有必要。

七、我们应该怎么开始？

最后我想聊聊，面对这个趋势，普通人可以怎么做。

我的建议是从一个小场景切入。别一上来就设计 45 个 Agent，先找两个 Agent 做配合。让其中一个负责探索，另一个负责验证。观察它们之间的交互，记录成功和失败的案例。等你对协作模式有了体感，再逐步增加复杂度。

说真的，我现在回头看自己最早做的几个多 Agent 实验，都觉得有点粗糙。但也正是那些粗糙的尝试，让我对协调、分工、失控有了真实的感受。没有这些体感，看再多论文也抓不到重点。

还有一个很实用的小技巧。在设计多 Agent 系统时，先明确每个 Agent 的「决策边界」。也就是它在什么范围内可以自主决定，在什么情况下必须停下来等待人类确认。这个边界不是限制 Agent，而是保护整个系统。因为一旦 Agent 开始互相影响，某个 Agent 的越界行为可能会通过反馈回路被放大。

另外，我建议你尽早建立 Agent 交互的审计能力。不是只记录输入输出，而是记录 Agent 之间的关键通信。当系统行为异常时，你需要能回溯到是哪次交互导致了状态变化。这种能力在初期看起来是 overhead，但等 Agent 数量超过五个之后，它会救命。

说到工具，现在市面上已经有一些值得关注的方向。LangGraph 提供的是编排能力，适合把流程搭起来。Cursor 和 Claude Code 这类工具则在探索「人类工程师 + 多个编码 Agent」的协作模式。OpenAI 的 GPT-5.6 最近也在强调原生多智能体编排和程序化工具调用。你可以根据项目阶段选择合适的层级，但核心原则是一样的，先把协作的边界和观测能力建起来，再追求复杂度和规模。