Anthropic 拉了 45 个 Agent 一起找漏洞：266 个结果很亮眼，但 2700 万 Token 也把“多 Agent 更强”这件事讲复杂了
Anthropic 最近公开了一组多 Agent 实验。
实验设计很直接：
45 个 Agent
每个 Agent 一台独立 VM
共享一个论坛
同一个漏洞发现任务
覆盖 15 个开源项目
Agent 可以在论坛里交流，也会互相 Peer Review。最后再由单独的 Arbiter Agent 判断提交的漏洞是不是新的、是不是有效。
结果很漂亮。
Mythos Preview 的协调 Swarm：
发现 266 个漏洞
消耗约 2700 万 Token
简单并行方案：
发现 21 个漏洞
消耗约 650 万 Token
如果只看发现数量：
266 vs 21
多 Agent Swarm 像是碾压。
但 Anthropic 自己没有这么简单下结论。
因为这里至少有三个非常值得注意的问题。
第一个问题：两边根本没在同一个搜索空间里工作
简单并行方案里的 Agent，被预先分配去看：
特定代码区域
而 Swarm 可以自己决定：
哪里更容易挖到漏洞
Anthropic 发现，大约一半 Swarm 找到的漏洞位于简单方案没有被要求重点搜索的核心目录之外。
如果只把 Swarm 输出限制到同样的核心目录，论文的判断是：
两种方式按 Token / Vulnerability 算，
效率看起来更接近。
这就很重要。
很多多 Agent Benchmark 都有类似问题。
你以为测的是：
协作能力
实际混进了：
搜索范围
预算
运行时间
并行度
工具自由度
所以以后看到：
Multi-Agent 比 Single-Agent 提升 8 倍
我第一反应会先问：
Token 一样吗？
工具一样吗？
搜索空间一样吗？
时间一样吗？
不把预算归一化，结论很容易失真。
第二个问题：两个方法找到的东西高度互补
协调 Swarm 和简单并行方案只有：
12 个漏洞
是重叠的。
这反而是一个很有价值的结果。
说明：
固定分区搜索
和：
自主协调搜索
并不是谁完全替代谁。
它们可能擅长不同区域。
这给生产 Agent 一个很实用的启发：
不要总想着选一个“最强策略”，有时候两个低相关性的策略组合比单一最优策略更值钱。
安全扫描可以：
Static Rule
+
Independent Agent
+
Coordinating Swarm
RAG 也类似：
BM25
+
Dense Retrieval
+
Graph Search
真正有价值的是：
错误相关性低
而不只是单路分数最高。
第三个问题：Agent 自己会出现专业化
Anthropic 观察到，Swarm 里的 Agent 会：
自己制作工具
自己形成分工
专门寻找不同类型漏洞
这很像人类团队。
一开始所有 Agent 的 Prompt 是一样的。
最后它们的工作方式开始分化。
这说明多 Agent 的一个潜在价值不是：
同时跑 45 份相同 Prompt
而是：
让角色在运行过程中逐步专业化
但这也带来更难的治理。
如果 Agent 可以自己：
- 创建工具；
- 改工作方式；
- 选择目标；
- 形成角色；
平台必须知道：
这些新能力有没有权限？
产生了哪些中间资产？
谁负责审核？
否则“自主专业化”很容易变成“系统越来越不可控”。
更有意思的是第二组实验：大家一起写软件，结果没那么美
Anthropic 又让 Agent Swarm 去做一个更依赖协作的任务：
创建一个文字型、
Web 可玩的开放世界幻想游戏
每个 Agent：
独立 VM
共享论坛
共享自托管代码仓库
每组运行：
12 小时
他们还尝试了三种 Prompt：
自由组队
规定角色
CEO 层级
结果很反直觉：
Prompt 差异没有带来特别大的改变
而最终游戏质量总体都不太好。
原因也很现实：
接口难用
性能差
学习曲线陡
Anthropic 甚至直接指出：
模型在这种产品审美问题上表现很差，
仍然需要大量人类指导。
这比“多 Agent 可以自动做软件公司”诚实得多。
最大的问题出现在 Merge
随着 Agent 数量从：
10
→ 80
老一代模型的 PR Merge 比例明显恶化。
例如 Sonnet 4.6 和 Opus 4.6 在 80 Agent 场景里分别创建：
876 个 PR
980 个 PR
但很多 PR 最后没有成功合并。
这就暴露了一个生产问题：
生成吞吐
>
整合吞吐
Agent 很会产出。
系统不一定很会合并。
这和 Coding Agent 大规模落地非常像。
你把 Agent 数量从 5 个加到 50 个，最先出现的瓶颈可能不是：
模型不够聪明
而是：
PR 冲突
架构冲突
Review 积压
共享状态不一致
我现在会单独测 Integration Throughput
传统 Agent 指标：
Task Success
Tokens
Latency
多 Agent 还应该增加：
Accepted Artifact Rate
Merge Rate
Conflict Rate
Duplicate Work Rate
Review Minutes
例如：
50 个 Agent
生成 200 个 Artifact
真正进入最终结果 42 个
那系统有效产出率只有：
21%
剩下都是协调成本。
“CEO Agent”并没有自动解决协调
Anthropic 尝试给一个 Agent CEO 身份，再让其他 Agent 接任务。
结果并没有显著改善最终表现。
这一点我很喜欢。
因为业界非常喜欢画：
CEO Agent
↓
Manager Agent
↓
Worker Agent
然后认为组织图一画，协作就解决了。
但真正的软件协作问题包括：
接口
状态
代码所有权
依赖
Merge
质量标准
优先级
这些不是 Prompt 里写一句：
你是 CEO
就能产生的。
组织结构必须落到系统机制。
比如：
文件 Ownership
Task Dependency
Artifact Contract
Merge Gate
Version
Lock
另一组实验更值得企业管理者看：共识可能压掉唯一正确的信息
Anthropic 还做了 Hidden Profile Task。
四个 Agent 分别拥有不同信息。
多数共享信息会支持一个：
错误选择
但某个 Agent 持有一条关键、独有的信息，足以推翻共识。
这非常接近现实决策：
招聘
投资
买房
供应商选择
结果很有意思。
Mythos 5 的四 Agent Group：
约 85%
其他被测模型 Group：
17%—36%
而如果让单个 Agent 一次拿到全部事实：
接近 100%
也就是说：
把知识分散给多个 Agent 再讨论，并不一定比把事实集中给一个 Agent 更聪明。
这其实是非常强的警告。
多 Agent 有一个天然问题：公共信息越来越响，私有信息越来越弱
Agent A：
供应商 X 价格最低
Agent B：
供应商 X 交期也不错
Agent C：
市场评价不错
Agent D 独自知道：
供应商 X 已经进入禁止合作名单
如果讨论机制强调：
多数意见
D 的关键信息可能被淹没。
这和人类会议一模一样。
所以：
Majority Vote
不是天然可靠的多 Agent Merge 策略。
我会给 Claim 加“信息唯一性”
每个 Agent 输出不要只有：
结论
还要标：
{
"claim": "supplier-x-is-blocked",
"source": "risk_registry",
"shared_by_other_agents": false,
"decision_critical": true
}
Aggregator 看见：
decision_critical=true
不能靠投票覆盖。
必须查证。
多 Agent 更需要 Evidence Merge，而不是 Answer Vote
差的 Merge：
5 个 Agent
3 个选 A
2 个选 B
→ A 胜
好的 Merge：
收集所有 Evidence
↓
去重
↓
识别冲突
↓
识别关键唯一事实
↓
重新决策
也就是：
Vote on answer
变成：
Merge evidence first
Anthropic 还测了“撒谎的 Scout”
另一类实验里，Listener Agent 只能听 4 个 Scout 报告世界状态。
其中一个 Scout 会按固定比例撒谎。
模型没有被提前告知：
有人会撒谎
唯一识别方式是：
不同 Scout 的信息开始矛盾
新模型能更好地通过事实冲突识别不可靠来源。
这说明 Agent Network 里需要一个概念：
Source Reliability
不能默认：
所有 Agent 都等可信
尤其未来一个平台里可能混合：
- 强模型；
- 小模型；
- 外部 Agent；
- 第三方 MCP；
- 低成本 Worker。
Agent Reputation 可能真的会变成基础设施
例如：
{
"agent_id": "research-agent-v3",
"task_success": 0.93,
"claim_conflict_rate": 0.04,
"unsupported_claim_rate": 0.02,
"last_30d_samples": 1842
}
Aggregator 在冲突时可以参考：
证据质量
+
来源可靠度
而不是一票一个 Agent。
当然，Reputation 也不能变成永久身份标签。
模型版本更新后应该重新校准。
所以我现在对多 Agent 的判断比以前更保守
多 Agent 特别适合：
天然可并行
子任务相对独立
搜索空间很大
结果可以验证
例如：
漏洞发现
资料搜索
候选生成
大规模代码扫描
不一定适合：
强依赖协作
共享状态频繁变化
需要统一审美
接口高度耦合
例如大型产品从零设计。
最后，把 266 vs 21 放回正确位置
协调 Swarm：
266 vulnerabilities
27M tokens
简单并行：
21 vulnerabilities
6.5M tokens
这是一个很值得兴奋的结果。
但真正成熟的结论不是：
45 Agent 一定比单 Agent 强很多
而是：
多 Agent 可以扩大搜索空间、
形成专业化并发现互补结果，
但它会同时引入巨大的 Token、
Merge、信任和共识成本。
我觉得这篇 Anthropic 研究最有价值的地方，就是没有只展示“Swarm 很强”。
它也把三个真正难的问题摆在桌上：
怎么协调
怎么相信彼此
怎么把大量产出真正合进去
多 Agent 的下一阶段，恐怕不再是继续加 Agent 数量。
而是把：
Evidence
Reputation
Merge
Ownership
Budget
这些看起来很传统的软件工程问题补齐。
更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：
https://www.zyentor.com/