45 个智能体，2700 万 token，266 个漏洞。

这是我看到 Anthropic 这篇新研究时印象最深的一组数字。同一套代码库，让 45 个 Claude 实例组队审计，它们找到的漏洞数量是 21 个独立并行智能体的 12 倍还多。更离谱的是，两组结果只有 12 个重叠。

我当时就愣住了。不是因为数字本身，而是因为它推翻了一个我很久以来的默认假设，多智能体系统的价值主要在于并行加速。你看，LangGraph 里我们总爱在 supervisor 和 worker 之间画很多条线，图的就是同时跑多个任务。但 Anthropic 这个实验告诉我，真正拉开差距的，可能不是并发，而是智能体之间的协调。

不过先别急着下结论。我觉得这篇研究有意思的地方，不在于它证明协调更强，而在于它把多智能体研究从工具编排推进到了社会系统模拟。它问的是一个更底层的问题，当 AI 智能体开始在共享代码库、共享市场、共享基础设施里活动时，它们会自发形成什么样的组织形态？这些形态又会带来什么新的风险？

我花了一下午读完论文和实验细节，想跟你聊聊这里面最让我头皮发麻的三个发现，以及它们对我做 LangGraph 项目时的具体启发。

先说说为什么 Anthropic 要选代码审计这个场景。坦白讲，这是一个非常聪明的选择。代码审计有几个特点，任务空间足够大，一个小型项目里的函数调用、输入边界、权限检查、并发逻辑加起来，可能的审计路径是指数级的；结果可验证，找到一个漏洞是真的有价值，不是幻觉；还有可比较性，你能很明确地说出协调组比独立组多发现了多少问题。这些条件加在一起，让多智能体的优势可以被精确测量。

更重要的是，代码审计不是那种有标准答案的考试题。它更像一个探索过程，每个角落都可能藏着问题，但你永远不知道下一个问题在哪里。这种开放性和不确定性，恰好是多智能体系统最能发挥作用的地方。如果任务太确定，你根本不需要协调，直接按清单跑一遍就行。

第一个发现是协调智能体的真正杠杆。实验设计其实很直接。Anthropic 让两组智能体审计同一套代码，找安全漏洞。一组是 21 个独立并行的 Claude，各看各的。另一组是 45 个被允许互相协调的 Claude，它们可以在运行中共享发现、分配任务、避免重复劳动。

结果是，协调组在 2700 万 token 里找到 266 个漏洞，独立组在 650 万 token 里找到 21 个。如果只比每百万 token 的发现率，协调组依然高出好几倍。

为什么会差这么多？论文里提到一个词，专业化分工。协调智能体会自动把自己的审计策略调整到跟别人不一样的方向上。比如一个智能体专攻输入验证，另一个就去看权限边界，第三个专门追踪并发竞态。这种生态位的分化，让它们在有限的 token 预算里覆盖了更多的攻击面。

我觉得这个现象特别像人类团队里的知识互补。五个人如果都按同一套 check-list 做代码审查，发现的问题会高度重叠。但如果五个人各有擅长，并且能实时告诉对方我已经查过这块了，整个团队的探索半径就会大很多。

更让我惊讶的是，这种专业化不是被设计出来的，而是涌现出来的。Anthropic 并没有给协调组预设角色分工，它们只是在共享信息的过程中，慢慢找到了各自的专长。这一点其实很反直觉。我们以前做多智能体系统，第一反应是给每个 agent 一个固定的角色，你是产品经理，你是程序员，你是测试。但这篇研究暗示，也许更好的方式是给它们一个共享的上下文和沟通机制，让分工自己长出来。

第二个发现是协作也是有代价的。协调组虽然发现更多漏洞，但它们的 token 消耗也明显更高。2700 万对 650 万，差了将近 4 倍。所以协调不是免费的午餐。你在获得生态位分化的同时，也要为智能体之间的沟通、同步、任务分配支付额外的认知成本。

这让我想到一个做 LangGraph 项目时经常遇到的取舍。把任务拆给多个 worker 很爽，但每个 worker 都要带上上下文，节点之间还要来回传状态。当智能体数量上去以后，状态图会快速膨胀。如果设计不好，通信开销会吃掉你所有的并行收益。

所以关键问题不是要不要协调，而是协调的收益什么时候能覆盖协调的成本。Anthropic 的实验给我们一个粗略的参考，当任务空间足够大、漏洞分布足够分散时，协调带来的专业化分工收益会远远超过通信开销。反过来说，如果你的任务本来就很线性，或者各个子任务之间高度重叠，那多智能体协调可能只是在烧 token。

我觉得这里有一个特别实用的判断标准。如果你的多个 worker 经常会重复做同样的事，或者它们的输出彼此独立、互不引用，那你的系统可能更适合做并行，而不是协调。只有当 worker 之间能从彼此的中间结果里学习，并且任务空间大到足以容纳多个不同的专业方向时，协调才会产生超额收益。

第三个发现最让我警惕。Anthropic 警告说，个体层面的良性怪癖，可能在群体层面叠加成意外的系统性失败。

我举个例子。单个智能体可能有一些无害的偏好，比如特别喜欢从某个角度分析漏洞，或者总是优先检查某类函数。单独看，这只是风格。但当几十个这样的智能体放在一起，并且它们还会互相影响时，这些偏好可能被放大，甚至形成群体偏见。

论文里把这种风险称为 emergent system-level failure。用更直白的说法就是，系统自己长出了设计者没预料到的行为模式。这让我想起一句话，系统的复杂性每增加一个数量级，未知的未知就会翻一个数量级。

这个问题在多智能体系统里尤其麻烦，因为你很难通过单个个体的测试来预测群体行为。一个智能体单独运行时很乖，但把它放进 45 个智能体的网络里，它可能会被带偏，也可能会把别人带偏。你设计的明明是审计工具，结果它演化出了一套自己的审计文化。

读到这的时候，我其实有点脊背发凉。前几年我们还在讨论 LLM 能不能可靠地写个函数，现在已经在讨论几十个 LLM 聚在一起会不会产生群体偏见。技术迭代的颗粒度真的越来越细了。

除了这三个发现，我还特别想强调一个容易被忽略的点。协调不是聊天，而是一种信息共享协议。Anthropic 的实验里，智能体之间的协调不是漫无目的地闲聊，而是有结构的信息交换。它们会报告自己发现了什么，会告诉别人自己接下来要查什么，也会根据团队已有的发现调整自己的计划。

这跟我们做 LangGraph 时的设计选择非常相关。很多人会以为多智能体协调就是给它们一个群聊窗口，让它们自由讨论。但实践证明，真正有效的是给它们一套共享的内存结构和通信协议。比如一个全局的发现列表，一个任务分配队列，一个中间结果的缓存池。没有这些基础设施，协调很容易变成低效的重复确认。

说了这么多，我想聊聊对我们这些做 LangGraph、CrewAI 或者其他多智能体框架开发的人，到底有什么实际启发。

第一，图的结构本身不是重点，重点是信息流通的方式。LangGraph 让我们很方便地画节点和边，但如果我们只是把任务丢给多个 worker，然后等它们返回结果，那就还是在做并行。真正有价值的是，worker 之间能不能共享中间状态，能不能根据别人的发现调整自己的下一步动作。

第二，要设计生态位，而不是流水线。传统的工作流设计很像工厂流水线，A 做完给 B，B 做完给 C。但协调智能体更像一个小型研究团队，每个人都有自己的专长和判断，彼此之间持续交换信息。所以呢，我们需要给智能体更丰富的 self-introduction 或能力声明，让它们知道队友在做什么。

第三，监控群体行为比监控单个智能体更难，也更重要。当你有十几个节点在互相调用时，光看每个节点的输入输出已经不够了。你需要看群体层面的统计特征，比如发现结果的分布、重叠率、异常收敛等。这些指标在单智能体系统里几乎不存在，但在多智能体系统里可能是你唯一的预警手段。

第四，要为失败模式做分层设计。单个 agent 出错，通常只是输出错了一个结果。但多智能体系统中的错误可能是协议级的，比如信息传递中的偏差被不断放大，或者某个智能体的偏好成了群体共识。你需要设计一些熔断和校验机制，让系统在群体层面也能收敛到合理状态。

第五，不要预设固定角色，要预设共享规则。Anthropic 的研究表明，智能体能自己找到分工。那我们做框架设计时，与其给每个 agent 写一个固定的 system prompt，不如设计好信息共享的格式和决策规则。让 agent 在运行中自己决定谁来做什么，可能比硬编码的分工更灵活。

第六，永远保留人工干预的接口。多智能体系统一旦跑起来，行为可能超出预期。你需要在关键节点上设置人类的观察位和制动开关。这不是不信任 AI，而是承认群体行为的复杂性。 Anthropic 的实验是在受控环境里做的，真实系统里的风险只会更大。

最后，我想补充一个更个人化的观察。Anthropic 做这个实验，可能不只是为了发一篇论文，而是在为 Claude 的下一步定位做铺垫。如果未来 Claude 要从一个对话模型变成一个能在组织里长期运行的协作节点，那它就必须证明自己能在多智能体环境里稳定工作。这篇研究就是一次概念验证。

顺着这个思路看，未来三个月我会特别关注三件事。第一，OpenAI 和 Google 会不会跟进类似的多智能体研究，还是继续把重点放在单模型能力提升上。第二，LangGraph、CrewAI、AutoGPT 这些框架会不会把「协调协议」做成一等公民，而不只是并行执行。第三，有没有真实的产品场景开始出现多智能体协调的收益，比如代码审计、安全测试、科研文献综述这些探索性任务。

我觉得第三个问题最关键。学术研究能告诉我们什么是可能的，但产品落地才能告诉我们什么是值得的。如果未来半年内，有团队能复现 Anthropic 的结果，并且把协调智能体用到真实的代码审计流程里，那这个方向就会快速从实验室走进工程实践。

Anthropic 这项研究让我意识到，多智能体系统的下一个阶段，不是怎么让智能体更多，而是怎么让它们之间形成健康的协作生态。

这不是一个纯工程问题。它更像是一个组织设计问题，甚至是一个社会治理问题。我们过去用 SDK 和 prompt 解决的是单个智能体会不会用工具。接下来要解决的，是一群智能体在共享环境里能不能不自毁。

这个转变对开发者的影响很直接。你不能再只关心 single-turn 的正确率，你要关心 multi-turn 的收敛性。你不能再只关心单个 agent 的 tool calling 能力，你要关心 agent 之间的信息传递协议。你甚至要开始思考，当智能体数量从 3 个变成 30 个时，系统的失败模式会不会从某个节点出错变成整个群体陷入某种共谋。

当然，这项研究也有它的局限。它只测试了代码审计这一个场景，结论能不能推广到其它任务还不确定。它用的都是 Claude 同一种模型，异构智能体之间的协调可能会完全不一样。还有，实验里的任务相对明确，真实世界里的多智能体系统往往要面对更模糊的目标和更动态的环境。

还有一个让我特别纠结的问题。Anthropic 的实验里，协调组的成绩很好，但我们其实不太清楚这成绩到底来自协调本身，还是来自更大的总 token 预算。协调组用了 2700 万 token，独立组只用了 650 万。如果我把独立组的预算也提到 2700 万，它们会不会也找到更多漏洞？这个问题不回答，我们很难判断协调的真正价值。

论文里也承认这个局限。所以他们比较了每百万 token 的发现率， coordination 组仍然更高。但这个比较的前提是任务空间足够大，专业化分工有空间展开。如果任务很集中，单纯堆 token 可能就足够了，协调的收益会变小。

另一个没回答的问题是，智能体数量继续增加会怎样。45 个已经是不少的数量了，但如果放到 100 个、1000 个呢？群体行为会不会出现新的相变？协调开销会不会变成指数级增长？这些问题对工程实践很重要，但现在还没有答案。

但这些局限不影响它的价值。它至少让我们从一个更宏观的视角去看待 agent 系统。以前我们问的是，这个 agent 能不能完成这个任务。现在我们可能要问的是，这群 agent 在一起，会不会产生我们没设计过的行为。

写到这里，我突然觉得这篇研究特别值得被认真读一遍。它不是一则产品新闻，而是一扇窗，让我们提前看到未来几年 Agent 系统真正要面对的挑战。

如果你也在做多智能体相关的项目，我建议你把这篇论文加到必读列表里。不是为了照搬它的结论，而是为了开始思考一个更底层的问题，当你的系统里不只有一个智能体时，你设计的到底是工具链，还是一个小型社会？