Anthropic,群体智能体实验中确认协作副作用

当45个智能体同时翻查代码时

Anthropic旗下前沿红队团队公开了一项实验结果,内容是AI智能体之间相互交互的情况。团队认为,随着智能体在代码库、市场及各类社会系统中承担越来越多工作,智能体之间的交互可能会比人与人之间的交互更早激增。问题在于,目前世界还不清楚这种交互在什么条件下能顺利运转。

为验证这一点,团队进行了开源漏洞检测实验。他们给45个智能体各自分配了一台虚拟机(VM)和一个共享论坛,并下达了相同指令:在15个开源项目中寻找漏洞。智能体们互相对彼此的成果进行同行评审,并由另一个独立的仲裁智能体最终判定提交的漏洞是否新颖且有效。这与Anthropic在Project Glasswing中扫描开源项目时采用的方法一脉相承。

结果通过Claude Mythos Preview和Opus 4.8两个模型进行了对比。以Mythos Preview为准,单纯独立并行方式使用了650万个token,发现了21个漏洞;而协作群体方式使用了2700万个token,发现了266个漏洞。不过,群体方式发现的漏洞中约有一半来自并行方式被指定的核心目录之外。若将范围缩小到核心目录内,两种方式按token计算的发现效率相近。两种方式共同发现的漏洞仅有12个。

让智能体开发游戏后暴露出的协作局限

在相互依赖度高的任务中,协作会变得困难得多。为验证这一点,团队让多个智能体群体完成一项任务:制作一款基于文本的网页奇幻游戏。每个智能体都拥有自己的虚拟机、共享论坛以及自建托管的代码仓库访问权限,群体连续工作12小时。团队变换了模型世代和智能体数量,并测试了三种提示词方式:基础型、角色分工型(区分编程、美术、测试团队)以及CEO层级型。

然而,即便改变提示词方式,结果也没有太大差异。三种方式最终完成的游戏都无法以人类的速度运行,界面难以辨识,学习曲线陡峭。团队表示,目前的模型在这类创作领域品味不足,需要大量人工介入。

即便是相同的产出,不同模型世代之间的协作方式也表现出明显差异。Sonnet 4.6和Opus 4.6看起来像是在同一文件上提交代码进行协作,但合并(merge)的拉取请求(PR)比例较低。这意味着相互冲突的代码被搁置、废弃。相比之下,更新的模型Opus 4.8和Mythos Preview解决了这个合并问题,但其方式是彼此几乎不进行协作。

两项实验揭示的问题

项目	独立并行方式	协作群体方式
发现漏洞数(Mythos Preview)	21个	266个
使用token	650万	2700万
重叠发现	12个(共同)	12个(共同)

模型世代	PR合并倾向	代码共享模式
Sonnet 4.6、Opus 4.6	合并率低	冲突后搁置
Opus 4.8、Mythos Preview	合并率稳定	将协作本身降到最低

将两张表并列来看,呈现出一种有趣的对比。在漏洞探索这类可以将任务独立拆分的问题上,群体协作提高了发现量。但在像代码仓库这样需要依赖彼此成果的任务中,模型越智能,反而越会为避免冲突而"适应性地"减少协作本身。

编辑视角

这项实验有意思的地方不在于结果,而在于失败的形态。在游戏开发实验中,最新模型改善了"合并率"这一指标,但令人痛心的是,其方法并非真正协作能力的提升,而是对协作的回避。仅看基准数字似乎有所进步,但实际上更接近于绕开了问题。这种指标假象很可能在智能体评估领域反复出现。

以往谈及多智能体系统时,大多是从"能同时运行多少个"这种规模问题出发。8月8日公开的Kimi Agent Swarm聚焦于最多并行部署100个子智能体,也是同样的思路。但这次Anthropic的实验着眼点不在规模,而在"如何失败",视角截然不同。这表明,增加智能体数量,与让智能体在相互依赖的任务中真正实现良好协作,完全是两个不同的问题。

在实务层面,应当区分这两类任务来使用。对于漏洞扫描、数据标注这类可以独立拆分的工作,目前仍值得尝试使用智能体群体,但需考虑到token成本会比并行方式高出4倍以上。而对于多个智能体共同修改同一代码库或文档的工作,以目前的模型世代来看,更稳妥的做法是让人类持续在每次合并节点介入。

未来几个月,前沿实验室很可能会调整训练信号的方向,从训练"避免冲突"转向训练"真正的协调"。取代合并率这类表面指标,衡量代码共享比例、实际贡献度等反映协作质量的指标,很可能会出现在下一代模型卡中。