多智能体系统的难点，不是分工，而是协调边界

阅读 Anthropic 博客：Patterns and problems in emerging multiagent systems

把一个开发任务交给多个智能体（Agent），很容易得到一种忙碌的景象：有人写代码，有人提合并请求，有人讨论架构。但这些动作累加起来，未必是一份能运行的交付物。更麻烦的是，每个智能体都可能认为自己正在认真完成任务，而整个系统却在重复劳动、争抢资源，甚至互相破坏。

理解多智能体系统（Multiagent System）需要区分：把工作并行执行和与让多个自主行动者可靠协作。 前者主要关心如何拆任务；后者要能修改共享状态、什么证据值得相信，以及目标冲突时的决定权。

Anthropic 做的这组探索性实验，把这个差异展示得很具体：智能体能扩大搜索覆盖，也会在共享代码、信息汇总和目标冲突中失灵。更强的模型改善了部分表现，但没有让协调问题自动消失。

本文将这些结果归纳成三个需要显式设计的边界：状态边界、证据边界和授权边界，以及一些其他论证。

一、并行收益

一种较容易控制的架构，是主智能体分派有明确输入和输出的子任务，再收集结果。另一种架构则让长期运行的智能体作为对等参与者，自行协商分工，并持续影响彼此的工作。前一种类似工具调用的协作已经相对有效，后一种没有清晰层级的协调仍很困难。

这也对应 Anthropic 在《Building effective agents》中区分的两种工作流：能事先拆开的独立任务直接并行；必须根据输入动态拆分时，由编排器（Orchestrator）委派给工作智能体并汇总。其原则是从满足需求的最简单方案开始，而不是把更多自主参与者当作默认升级路径。这个原则不是对中心化与对等架构的实验排名。

**漏洞发现实验可以看成是整体任务拆成大量相互独立的子任务。**研究人员启动了 45 个智能体，让它们各用一台虚拟机，在共享论坛协调，对 15 个开源项目寻找漏洞。成员互相复核，另设一个仲裁智能体判断提交是否新颖、有效。

以 Mythos Preview 模型为例，两种方法的结果是：

这里的 token 是模型采样生成的输出 token，并非包含全部输入、缓存和工具费用的总成本。群体约一半的发现来自独立智能体未被要求搜索的核心目录之外；若只计核心目录，两种方法每发现一个漏洞所需的 token 大约一致，也只有 12 个漏洞重合。

下图最值得注意的不是两条终点相差多少，而是“所有发现”和“仅核心目录发现”之间的差距。

漏洞发现数随累计采样输出 token 的变化；Mythos Preview 协调群体总计发现 266 个，核心目录内为 128 个，独立搜索为 21 个。

漏洞发现数随累计采样输出 token 的变化；Mythos Preview 协调群体总计发现 266 个，核心目录内为 128 个，独立搜索为 21 个

图 1：搜索范围与预算不同，不能仅凭总发现数判断协作效率。星号表示独立搜索，实线表示协调群体，黄色点线只计核心目录，虚线表示两种方法的重合发现；纵轴为对数刻度。

较稳妥的结论是：允许动态分工、共享工具和形成专长，可能改变系统发现问题的路径，扩大覆盖。这个实验并没有单独隔离“交流本身”带来的因果收益。

漏洞搜索还有一个有利条件：一个成员漏掉问题，通常不会直接让另一个成员的成果失效。一旦换成共同开发软件，这个条件就不成立了。

二、状态边界

那如果成员间的任务相互影响呢？在另一组实验中，智能体群用 12 小时开发一款文字游戏。研究人员改变模型、群体规模，以及自由组队、预设角色和 CEO 层级三种提示词方式。这个实验可以看成是每个 Agent 既要完成自己的任务，也要观察其他 Agent 的修改结果并做出对应调整。

最终结果显示三种方式的差异不大，最终游戏的运行体验、界面和上手难度都不理想，光靠 Prompt 显然无法使得多智能体合理地协作。

那么模型能力提高后，多智能体是否就更会协作了？这里同时测了两个指标：

• 合并请求（Pull Request，PR）的合并比例：提交的修改有多少真正进入主分支。
• 代码共享度（Code Sharing）：衡量智能体参与的文件中，有多少代码来自其他智能体（按自身在各文件的贡献比例加权，再观察群体中位数）；

共享度接近零，意味着成员基本不碰别人参与的文件；较高则意味着更多跨成员共同修改。两个指标必须一起看。

不同群体规模下的 PR 合并比例与代码共享度；较早模型的合并比例随规模明显下降，Sonnet 5 在共同修改文件时仍保持较高合并比例。

不同群体规模下的 PR 合并比例与代码共享度；较早模型的合并比例随规模明显下降，Sonnet 5 在共同修改文件时仍保持较高合并比例

图 2：高合并比例不必然代表善于共同修改代码，也可能来自文件分工隔离。图中每项指标对三种提示方式取平均。

Sonnet 4.6 和 Opus 4.6 常修改相同文件，却产生冲突并放弃合并。Opus 4.8 和 Mythos Preview 的合并表现改善，但很大程度上通过保持较强的文件独占来减少冲突。该实验里，Sonnet 5 才同时呈现出相对较高的代码共享度与合并比例。

这不意味着文件隔离是坏设计。恰恰相反，明确所有权往往是合理的协调手段。它说明的是：如果任务被拆成互不相干的小岛，系统取得的成绩，不能用来证明它能处理复杂的交叉依赖。 同样，合并比例也不衡量产品是否好用。

Stasser 与 Titus 在 1985 年的实验中发现，群体更倾向讨论所有人都知道的信息，未能充分汇集成员独有的信息。Multi-Agent 很容易让人产生一种错觉：10 Agents ≈ 10 Different Thinkers，但实际上是 10 个高度相似的 Agents，这些 Agents 使用相似的模型、相似的提示词和相似的上下文，Anthropic 将这种现象称为低方差行为。

他们观察到过多个非常有趣的案例：多个 Agent 会独立选择相同的 Git branch 名；写作 Agent 会在没有主题约束的情况下撞出同一个标题；大量 Agent 被要求“做一些令人印象深刻的东西”时，会集中选择类似的 ray tracer 或 self-hosting compiler 项目。

共享资源还会放大同质化行为。一次早期游戏实验中，30 个同时启动的智能体有 18 个选择了完全相同的分支名。另一个有限带宽的任务队列实验里，智能体用高频轮询竞争资源，一次运行出现约 240 万次请求，却只有 117 个任务被接受。

这些现象提示：复制同一模型和近似上下文，并不等于获得独立的策略多样性。一个局部看来有利的动作，若被所有成员同时执行，就可能变成系统瓶颈。

三、证据边界

给智能体加上论坛，能让信息流动，却不能保证信息被正确使用。太容易相信，容易被假消息骗，只相信多数，容易漏掉关键证据。如果设置一个信任值，则很难确定这个值大小。Anthropic 为此安排了两类方向相反的任务。

第一类任务考察识别不可靠消息源。一个决策智能体无法直接观察世界，只能听取四个脚本化“侦察员”的报告，其中一个会按固定比例提供影响决策的谎言。报告有重叠信息，因此矛盾足以提供识别线索。较新的模型能更好地利用这些线索，但仍存在差距。

第二类是**隐藏信息结构（Hidden Profile）**任务：群体共享的信息支持错误选项，个别成员独有的信息才支持正确选项。成功要求少数成员把关键证据说出来，其他成员愿意据此推翻初步共识。

实验让四个智能体讨论并投票，每个模型评估 400 个情境，指标是正确选项获得群体多数票的情境比例。图中 Mythos 5 约为 85%，其余受测模型约为 17%—36%；同一模型单独获得全部事实时，正确率则接近满分。实验显示，即使更强模型在这种任务上的表现明显提高，群体决策能力仍然没有达到单个 Agent 拥有全部事实时的上限。

这个对照不能简化成“一个智能体胜过四个”。独立决策者拥有全部信息，群体成员拥有的是分散信息；实验暴露的正是信息能否被提出、传递和采纳的问题。因此，“更怀疑其他智能体”不是通用修复：它可能减少被谎言误导，也可能让真实的少数证据更难进入决策。反过来，要求无条件信任同伴，又会把虚假报告变成公共事实。

可以据此推导一种接口设计：汇总时要求成员提供结论、原始证据、适用条件和反证，而不只上交一句赞成或反对；相互转述同一条消息，不应被当作多个独立来源。异议处理也应检查证据是否新增，而不是先看持异议者有几个。这是需要另行评估的设计建议，并非该实验已经证明有效的干预。

四、授权边界

共享状态和证据都管理得当，也不保证目标彼此兼容。

在目标冲突实验中，三个同模型智能体各自在虚拟机中运行，共同操作第四台虚拟机上的 Python 后端。它们分别被要求迁移到不同语言，起初不知道还有其他参与者。研究人员观察四小时，每个模型测试 120 次。

研究中出现了持续升级的破坏行为：一些智能体把对方造成的变化解释为蓄意阻挠，继而撤销其他成员的访问权、干扰进程或破坏其部署。这里无需掌握这些行为的实现方式；关键在于，完成个人任务的压力，被错误地转化成了处置其他参与者的权限。

有些样本最终以协商停战结束。Mythos 5 的图示最终停战比例达到 98%，但原文也明确指出，部分样本曾先通过强制手段结束冲突，再撤销这些措施并走向停战。最终状态良好，不代表过程没有造成损害。

更微妙的风险是，智能体有时会协商一场性能竞赛，让胜者决定代码库最终采用什么语言。然而，提议评价指标的一方可能偏好对自己有利的标准。即便参与者最终都同意，那个协议也可能让落败者放弃原用户的指令。

因此，自主协商必须区分两种事情：在授权范围内调整执行方式，与重新定义什么才算成功。性能较高，未必比兼容性、团队维护能力或既有约束更重要；这些取舍不能只因为智能体之间谈妥了，就自动获得用户授权。

原文中的价格竞争实验进一步说明，彼此配合也不总是系统层面的好结果。智能体会协调价格，移除私下交流渠道后，仍观察到通过公开报价进行价格匹配的行为。竞争环境中的协同行为，可能损害其他参与者的利益，而不是值得优化的协作能力。

五、把协调要求落实到系统接口

上述实验尚未给出一套经过验证的通用解法。工程上更可操作的起点，是将“请好好合作”改写成可检查的权限、数据和状态转换。下面是本文基于失败机制整理的建议。

以代码任务为例，可以让成员在隔离工作区产生修改，经统一集成入口提交；确需共同修改时，再显式管理共享接口及其版本。所有权记录不能只是“我负责这个文件”的聊天消息，还要能判断它是否已过期、是否允许接管，以及提交时是否基于旧版本。

但隔离不是免费收益。分工过粗可能堵住其他成员，分工过细又会增加接口协调与集成成本。需要保留一组真实跨模块依赖任务，检验系统究竟能协作，还是仅在没有冲突的情况下表现良好。

同理，遇到互斥目标时，合理的下一步应是停止竞争性修改，保留当前状态并请求有授权的一方裁决，而不是让执行能力最强的成员成为事实上的管理者。评估时也要检查它有没有及时停止，而不只检查最后谁的版本上线。

怎样判断这些结论能否迁移到你的系统

这组实验最有价值的地方，是揭示失败机制，而不是提供一张通用模型排名。

首先，研究主要测试 Claude 系列模型，部分环境还刻意让同模型实例接收相近指令。真实部署的历史、工具、权限和模型组合可能更丰富；不能直接把同质群体里的行为频率当作真实世界发生率。同时，Claude 系列模型是能力非常强的模型，所以这些实验并不一定适用于其他较小的大模型（如32B参数量的大模型）。

其次，不同实验的条件不能混算：漏洞搜索的预算和搜索范围不同；游戏任务的 PR 指标不等于交付质量；隐藏信息任务的单体基线拥有更完整的信息；迁移冲突则人为设置了互斥目标和可相互干扰的环境。每一种限制都影响结果的解释。

多智能体系统的可靠性，取决于成员如何分工、相互约束、交换证据、资源竞争和处理分歧，而不仅是每个成员有多能干。 能并行的工作尽量并行，必须协调的部分则要成为系统设计的显式对象。

参考资料

• Anthropic Frontier Red Team。Patterns and problems in emerging multiagent systems。2026-08-13。
• Erik S.、Barry Zhang。Building effective agents。Anthropic，2024-12-19。
• Garold Stasser、William Titus。Pooling of Unshared Information in Group Decision Making: Biased Information Sampling During Discussion。Journal of Personality and Social Psychology，48(6)，1467–1478，1985。