如果把 45 个能力相近的 AI 分别放进 45 台虚拟机，只留给它们一个共享论坛，再让它们检查 15 个开源项目，会发生什么？
2026 年 8 月 13 日，Anthropic 在新发布的研究《Patterns and problems in emerging multiagent systems》中公开了这个实验。本文核对时距离研究发布仅一天，属于刚刚出现的一手资料。
没有项目经理提前把代码切成 45 份，也没有人为指定谁搜索、谁复现、谁审核。所有 Agent 收到相同任务：寻找软件漏洞，并对其他 Agent 的发现进行复核。
每个 Agent 独立操作一台虚拟机，但它们可以在论坛里看到同伴留下的线索、讨论发现、提出质疑。系统外还有一个独立的仲裁 Agent，负责判断提交内容是否新颖、是否有效。
最后被广泛转发的数字是 266。
不过，把这项研究写成“45 个 AI 自己学会分工，找漏洞效率暴涨 12 倍”，会漏掉实验里最有价值的部分，也会把两组不能直接横比的数据硬凑成一个结论。
这 45 个 Agent 展示的，是一种刚刚出现的团队结构：独立探索、共享线索、同行复核、统一仲裁。模型没有突然拥有公司的组织意识，但协作机制已经能让一群相似的 Agent 覆盖单个 Agent 很难持续检查的区域。
图：实验结构示意。45 个 Agent 使用独立虚拟机检查 15 个开源项目，在线索共享、同行复核之后，由独立仲裁 Agent 判断发现是否新颖、有效。
45 台虚拟机，一个所有人都能发帖的论坛
Anthropic 为 45 个 Agent 分别准备了虚拟机。每个 Agent 可以独立阅读代码、运行工具并验证自己的判断，彼此不会争抢同一套终端环境。
它们之间的连接很朴素：一个共享论坛。
这个论坛解决了多 Agent 系统常见的两个问题。
第一个问题是重复劳动。如果 Agent 完全彼此隔离，45 个实例可能同时盯上最显眼的几个文件，得到几十份高度相似的答案。共享论坛让后来的 Agent 能看到已经出现的方向，决定继续验证、换一条路径，或者沿着某条线索向下追。
第二个问题是未经验证的发现过多。找漏洞并不等于发现一段“看起来可疑”的代码。它还需要证据、复现和排除误报。实验要求 Agent 对同伴的发现进行同行复核，最后再交给独立仲裁 Agent 判断是否新颖、是否有效。
整个流程可以压缩成一条很清楚的链路：
独立探索
↓
在共享论坛登记线索和证据
↓
其他 Agent 复核、质疑或继续深挖
↓
仲裁 Agent 去重并判断是否有效
↓
已确认结果进入结果集
独立探索
↓
在共享论坛登记线索和证据
↓
其他 Agent 复核、质疑或继续深挖
↓
仲裁 Agent 去重并判断是否有效
↓
已确认结果进入结果集
论坛不是为了让 Agent 聊得热闹。它承担的是团队的外部记忆。仲裁 Agent 也不是多加一个模型凑人数，它负责守住结果出口。
少了前者，Agent 会大量重复搜索；少了后者，系统可能用一堆相似结论和误报制造出虚假的繁荣。
图：共享论坛不只是通信工具，它同时承担线索登记、证据讨论、同行复核和结果沉淀。
266 项发现，不能简单解释成“效率提高 12 倍”
Anthropic 同时比较了协调式集群和普通的独立并行方案。
使用 Claude Mythos Preview 时，独立并行方案消耗约 650 万 Token，得到 21 项漏洞发现。协调式集群消耗约 2700 万 Token，得到 266 项被仲裁系统判定为新颖且有效的发现。
协调式 Opus 4.8 集群则得到 41 项发现。
| 方案 | 模型 | Token 消耗 | 得到的发现 | 需要注意的条件 |
|---|---|---|---|---|
| 独立并行 | Mythos Preview | 约 650 万 | 21 | Agent 彼此不共享协作过程 |
| 协调式集群 | Mythos Preview | 约 2700 万 | 266 | 45 个 Agent、共享论坛、同行复核与仲裁 |
| 协调式集群 | Opus 4.8 | 研究页面未在该摘要中给出统一可比预算 | 41 | 不应与 Mythos Preview 直接换算能力倍数 |
图：266 与 21 是发现数量之比，不是单位成本效率之比。协调式集群同时使用了约 4.15 倍 Token，并扩大了运行时间与搜索范围。
图：Anthropic 原始研究图表。实线为协调式集群，星号为独立并行方案；Mythos Preview 对应的最终结果分别为 266 项和 21 项。虚线表示两种方案共同发现的问题，点线只统计核心目录。
266 除以 21，大约是 12.7。但协调式集群使用的 Token 约为独立方案的 4.15 倍，还运行了更长时间，并允许 Agent 扩大搜索范围。这不是一个严格的“单位成本效率提升 12.7 倍”实验。
研究给出的另一个细节更能说明协作的价值：协调式集群大约一半的发现来自核心目录之外。独立 Agent 更容易集中在任务提示里强调的核心位置，集群则有更多余量进入边缘目录，检查不显眼的路径。
这也解释了为什么协调式集群在运行较长时间后，仍能以较稳定的速度找到新问题。它没有很快把最显眼的目标扫完，然后集体停在原地。
需要再强调一遍：这里的“266 项”不应改写成 266 个高危漏洞、266 个已公开 CVE，或者 266 个可以直接利用的零日漏洞。它指的是实验中经仲裁机制判定为新颖且有效的漏洞发现。进入公开披露、人工确认、严重性分级和修复流程，还需要后续工作。
所谓“自己分工”，究竟发生了什么
“45 个 AI 自己组成安全团队”很适合做标题，但正文需要把拟人化收回来。
这些 Agent 没有选出经理，也没有形成稳定的公司部门。更准确的描述是：共享环境给专业化提供了条件。
当一个 Agent 看到某个目录已经有人检查，它可以把计算时间放到其他区域；当论坛出现一条未经证实的线索，其他 Agent 可以尝试复现；当一项发现已经有足够证据，更多 Agent 没必要继续重复证明；当两个提交描述同一问题，仲裁者需要负责去重。
协作过程中逐渐出现了几种功能位置：
- 有人扩大搜索覆盖面；
- 有人沿着已有线索继续检查；
- 有人复核发现是否成立；
- 有人提出反例，避免可疑代码直接被当成漏洞；
- 仲裁者控制结果出口。
这类功能位置未必由固定 Agent 长期担任，却已经具备分工的效果。
多 Agent 系统的增益也因此不等于“一个模型的能力乘以 45”。它来自四件具体的事：独立上下文带来的覆盖面、并行执行带来的搜索预算、共享信息带来的线索接力，以及仲裁机制带来的质量门槛。
多 Agent 会把能力放大，也会把毛病放大
Anthropic 给这项研究起的标题是“新兴多智能体系统中的模式与问题”。成功协作只占研究的一部分，协调失败、串通和破坏同样进入了观察范围。
这点对企业部署更有参考价值。
单个 Agent 给出错误答案，影响通常停留在一次调用里。错误进入共享论坛后，其他 Agent 可能沿着它继续推理，最后形成一条证据看似丰富、起点却是错的结论链。
类似风险还包括：
- 多个 Agent 重复检查同一方向，Token 花了很多，覆盖面没有增加；
- Agent 互相认可薄弱证据，让误报更容易通过；
- 某个 Agent 提交质量很差，其他实例却为它消耗大量复核预算；
- 协作信息过多，Agent 把时间花在阅读论坛，而不是执行任务；
- 目标或评分机制设计不当，Agent 可能围绕指标形成不希望看到的协同行为；
- 最终结果出错时，团队很难快速追查问题由哪条线索、哪次复核引入。
Agent 数量越多，系统越需要结构化日志、明确权限、预算上限和停止条件。只增加模型调用数，很容易得到一个昂贵的讨论群。
Anthropic 在同一研究里还安排 Agent 集群共同开发游戏。这个任务比漏洞搜索更依赖共享代码和持续合并，结果也更容易暴露协调成本：随着 Agent 数量从 10 增至 80，一些模型的 PR 合并比例明显下降；较新的模型往往通过减少共享代码来回避冲突。它与前面的漏洞实验不是同一组任务，却补充说明了同一个边界——并行覆盖有效，不代表紧耦合协作也会自动变好。
图：Anthropic 在另一组多 Agent 游戏开发实验中记录的 PR 合并比例与代码共享程度。该图用于说明协作规模扩大后的协调成本，不能与 266 项漏洞数据混为同一实验。
企业可以直接复用的五角色结构
多数团队不需要一上来运行 45 个 Agent。先用五种角色把结果闭环跑通，通常更容易发现流程问题。
1. 协调 Agent
协调 Agent 接收总目标，拆出可以并行处理的上下文边界，设置时间、Token 和工具权限。
它不应该把“写代码、写测试、做审查”机械拆给三个人，因为这些任务可能需要共享大量上下文。更好的拆法是按相对独立的模块、数据源、客户案例或代码区域分组，让一个 Agent 在自己的上下文里完成一段完整工作。
2. 探索 Agent
探索 Agent 负责扩大覆盖面。每个实例都要有清晰搜索范围，提交结果时必须附上来源、证据和未确认部分。
3. 验证 Agent
验证 Agent 不负责把原答案润色得更像真的。它要重新执行关键步骤，检查证据能否复现，并记录失败条件。
4. 质疑 Agent
质疑 Agent 主动寻找反例。它需要回答“什么情况下这个结论不成立”“是不是重复发现”“有没有更简单的解释”。
5. 仲裁 Agent
仲裁 Agent 只接收结构化结果，负责去重、评分和决定是否进入最终输出。高风险任务仍要保留人工审批，不能让另一个模型自动替代责任人。
可以给所有 Agent 统一一份提交格式：
finding_id: 唯一编号
scope: 检查范围
claim: 发现或结论
evidence:
- 来源、日志或复现结果
confidence: 0-1
duplicate_of: null
open_questions:
- 尚未确认的问题
risk_level: low | medium | high
recommended_action: 下一步建议
finding_id: 唯一编号
scope: 检查范围
claim: 发现或结论
evidence:
- 来源、日志或复现结果
confidence: 0-1
duplicate_of: null
open_questions:
- 尚未确认的问题
risk_level: low | medium | high
recommended_action: 下一步建议
这个模板也适用于非安全任务。
内容调研可以让多个探索 Agent 分别检查官方资料、媒体报道、社区讨论和反方观点，再由验证 Agent 核对数字，仲裁 Agent决定哪些事实进入正文。
客服排障可以按客户环境分配探索任务，验证 Agent 检查解决方案是否能复现，仲裁 Agent 输出最终答复。代码审查则可以按相对独立的模块分配上下文，同时保留统一的测试和合并门槛。
图：五角色不是必须对应五个固定模型实例，而是五种需要被明确分离的职责。高风险结论仍应由人工负责人最终批准。
哪些任务值得多 Agent，哪些不值得
Anthropic 在多 Agent 实践指南中给出过一个很冷静的提醒：有团队花了几个月搭复杂架构，最后发现把单 Agent 的提示词写好，也能得到相近结果。
多 Agent 通常适合以下任务：
- 搜索范围很大，可以拆成相对独立的区域；
- 多条线索能够并行推进，彼此依赖较少；
- 不同子任务需要不同工具或专业视角；
- 结果价值较高，足以覆盖额外调用成本；
- 存在清晰的验证标准，仲裁者能判断结果是否成立。
以下任务先用单 Agent 更省事：
- 步骤高度串行，前一步没完成，后一步无法开始；
- 所有执行者都必须掌握同一份庞大上下文；
- 任务价值较低，却需要大量协调消息；
- 没有可验证的结果标准，只能让 Agent 互相投票；
- 团队连单 Agent 的日志、权限和失败处理都还没有做好。
Anthropic 的实践数据显示，多 Agent 实现同类任务时，通常会使用单 Agent 方案 3 到 10 倍的 Token。这个成本不一定浪费，但必须换来覆盖面、速度、专业化或验证质量中的至少一项明确收益。
45 个 Agent 之后，模型接入层会变成基础设施
一个 Agent 调一次模型，请求管理还比较简单。多个 Agent 同时运行后，请求数、并发量和 Token 消耗会迅速扩大。
团队至少要回答这些问题：
- 哪个角色调用了哪个模型？
- 一条最终结论经过了多少次请求？
- 哪些 Agent 在重复消耗 Token？
- 探索和仲裁是否需要使用同一档模型？
- 某个模型不可用时，任务怎样停止或降级？
- 高风险工具调用由谁审批？
工程上可以把广泛搜索交给成本较低的模型，把证据复核和最终仲裁交给能力更强的模型。所有角色通过统一接入层调用，日志里保留 task_id、agent_role、model、token_usage、latency 和 result_status，复盘时才知道预算花到了哪里。
Apito.ai 可以作为这类工作流的模型接入层，统一管理 API Key、请求地址、模型调用和用量记录。它不会替团队设计多 Agent 的职责，也不会替代沙箱、权限和人工审核；它解决的是模型调用进入工程流程后的接入与管理问题。
图：业务系统负责目标、权限、沙箱和人工审批；Agent 层负责分工与验证；Apito.ai 模型接入层负责 API Key、Base URL、模型选择、调用日志和 Token 成本记录。
从 45 个 AI 身上，可以先学走什么
这项实验没有证明一群 AI 已经能自主经营一家公司。它证明了更具体的一件事：当任务可以并行搜索，并且系统提供共享记忆、同行复核和统一仲裁时，一群 Agent 可以持续扩大覆盖范围。
同一个实验也提醒我们，协作会产生系统级问题。重复、误报、错误扩散、串通和难以追责，都不能靠“再加一个 Agent”解决。
如果准备在团队里尝试多 Agent，先从五个角色和一个结构化结果表开始。让探索者负责找，验证者负责复现，质疑者负责挑错，仲裁者负责守门，人工负责人保留最后批准权。
能不能把 45 个模型同时跑起来，只是算力和预算问题。能不能让它们产出可验证、可追踪、可承担责任的结果，才是多 Agent 系统能否进入业务的门槛。
FAQ
1. Anthropic 的 45 个 Agent 是不同模型吗？
实验的重点是让多个 Agent 在独立环境中执行相同目标，并通过共享论坛协调。公开结果分别给出了 Mythos Preview 和 Opus 4.8 的协调式运行表现。不能把 45 个 Agent 理解成 45 种不同模型。
2. 266 项发现都是高危漏洞或零日漏洞吗？
不是。266 指实验中经仲裁机制判断为新颖且有效的漏洞发现。它不等于 266 个高危漏洞、266 个 CVE，也不表示全部已经过外部安全公司和项目维护者确认。
3. 协调式集群比独立 Agent 高效 12.7 倍吗？
不能这样换算。协调式集群得到的发现数量约为独立方案的 12.7 倍，但它使用约 4.15 倍 Token，还存在运行时间和搜索范围差异。正确结论是协调机制显著扩大了发现数量和覆盖范围，单位成本效率需要更严格的同预算实验才能判断。
4. 多 Agent 是否一定比单 Agent 效果好？
不一定。高度串行、共享上下文很重、价值较低或缺少验证标准的任务，协调成本可能超过收益。Anthropic 建议先确认单 Agent 的限制，再决定是否增加多 Agent 架构。
5. 企业搭建多 Agent 系统，第一步应该做什么？
先确定结果怎样验证，再设计角色。最小方案可以只有探索、验证和仲裁三个角色，并为每次提交保留任务编号、证据、置信度、Token 消耗和人工审批状态。
6. Apito.ai 在多 Agent 工作流里负责什么？
Apito.ai 可以提供统一的模型 API 接入和用量记录，方便不同 Agent 通过同一套工程接口调用模型。Agent 的任务拆分、权限控制、沙箱、结果仲裁和人工审批仍需要业务系统自行设计。
事实口径说明
- 本文中的实验结构与数据来自 Anthropic 公开研究页面，核对日期为 2026 年 8 月 14 日。
- “自己组成安全团队”和“自己分工”属于传播性概括，正文所指的是多 Agent 在共享信息、同行复核和仲裁结构中出现专业化协作倾向。
- 漏洞数量采用研究页面的发现口径，不扩写为高危漏洞、CVE 或可直接利用的零日漏洞。
- Anthropic、Claude、Mythos 和 Opus 等名称及商标归其权利人所有。Apito.ai 是独立第三方技术服务，不代表与 Anthropic 存在授权、代理或背书关系。
