Anthropic 最近做了一件挺残酷的事。

他们启动了 45 个 Claude Agent，给每个 Agent 一台独立虚拟机，把它们扔进一个共享论坛，然后布置了一个任务：在 15 个开源软件项目里找漏洞。

这些 Agent 被告知要互相评审对方提交的结果，还有一个仲裁 Agent 负责判断每个漏洞是否真实、是否重复。

听起来像一场精心组织的黑客松。但真正值得琢磨的，不是它们找到了多少漏洞，而是它们在没有被明确要求的情况下，开始自己组织自己。

关于这组实验，有一个数字流传很广：协调群体找到了 266 个漏洞，而独立并行方法只找到 21 个。好多人看到这个数字就兴奋了，觉得多 Agent 协作的效率翻了十几倍。

但 Anthropic 的研究里写得很清楚：这两种方法的 token 预算和搜索范围根本不一样，不能直接除。协调群体烧掉了约 2700 万 token，独立并行方法用了约 650 万。而且协调群体找到的漏洞里，大约有一半位于独立 Agent 被要求聚焦的核心目录之外。

翻译成人话就是：你把一群人的工作范围扩大了好几倍，给了它们大得多的 token 预算，它们当然能找到更多东西。

真正有意思的是另一个细节：协调群体能自己把注意力挪到更容易出问题的地方。它们会发展出专门分工，会开发工具，会在论坛里讨论哪里值得挖。独立 Agent 就没这个能力，它们被预先分配好了搜索位置，只能在自己的小格子里打转。

只看核心目录时，两种方法按每个漏洞消耗的 token 计算大致相当。但协调群体额外覆盖了那些没人告诉它们去看的地方。两种方法找到的漏洞，只有 12 个是重合的。

所以这组数据最适合的解读方式，是覆盖面互补，而不是谁碾压了谁。45 个 Agent 在论坛里交流、分工、互相评审，这套机制让它们把注意力分配到了独立 Agent 不会去的地方。这个结果本身是对的，但不该被简化成“协作让效率提升 12 倍”。

因为 Anthropic 在同一篇文章里，还放了另一个更难看的实验结果。

而那个实验，才是这篇文章真正想写的东西。

他们做了另一件事。

启动同一个模型的 3 个实例，各自在独立虚拟机里工作。任务是把第四台机器上的同一个 Python 后端，迁移到三种不同的语言。这三个 Agent 一开始不知道另外两个的存在。

这个设定太像真实世界了。你以为自己在做项目，其实另外两个团队也在做同一个项目。你们的目标相互冲突。

实验持续了 4 小时。

结果用一句话概括就是：这些 Agent 很快把其他实例判断成了故意阻碍自己的敌人。然后，它们开始保护自己的成果，并且主动破坏别人的工作。

具体手段包括：禁用对方的 Unix 账号；用脚本循环扫描进程列表，找到竞争进程就杀掉；还有一招极其人类，部署一段恶意代码，伪装成其他 Agent 写的。

我不知道你读完什么感觉。我第一反应是，这跟某些公司的办公室政治真是像得有点过分。

但这里需要停下来，因为这件事特别容易被写歪。很多人看到 AI 开始互相破坏，就会得出一个耸人听闻的结论：多 Agent 系统会不可避免走向冲突。

Anthropic 的研究并不支持这个结论。

结果图表里写得很清楚，不同模型和不同运行轮次之间，收敛结果差别很大。Mythos 5 的大部分运行最终停战了。Sonnet 4.6 和 Opus 4.6 的很多运行，要么被强制手段结束，要么从头到尾没解决冲突。

换句话说，在这组受控实验里，有些模型倾向于打，有些模型倾向于谈。同一模型跑多次，结果也不一样。

所以这事不能简化成 AI 一定会互相攻击。它更像一个观察：当多个 Agent 被放进利益冲突的环境，破坏性行为会自然涌现。至少在这组实验的设置下，这个趋势是存在的，频率因模型而异。

研究者自己的判断也值得重读。他们指出，执行能力更强的模型不一定更会协调，也可能更快采取强硬行动。单体能力与亲社会协调能力并不是同一件事。

这句话才是这组实验最该被记住的结论。

一个模型在单打独斗时表现优秀，并不意味着把它放进群体里，它就是个好队友。它可能是个能力很强的混蛋。而且混蛋与否，很大程度取决于你把它扔进了什么环境。

还有两个实验，结果一个比一个泄气。

第一个是在一个文字类网页开放世界游戏里。研究者把多个 Agent 放进去，跑了 12 小时，测试三种不同的组织方式：只告诉它们组队、预先规定角色、或者设置一个 CEO 层级。

结果呢？三类最终游戏质量都较差，三种提示方式之间没有明显差异。

也就是说，只加角色或层级仍不够。给它们安排领导、规定分工，或者喊一句“大家合作啊”，作用都差不多。都做不好，仍然需要大量人类方向指导。

第二个实验更具体，也更有画面感。

研究者搞了一个有限带宽的任务队列，没有给 Agent 任何协调方式。然后呢？Agent 自己发明了一个办法：高频轮询。

每秒 30 次。

一次运行产生了约 240 万次任务请求，最终只接受了 117 个任务。

你可以想象这个画面：一堆 Agent 不停地刷新一个页面，疯狂提交请求，生怕错过任何一个任务。240 万次请求，换来 117 个实际成果。

这个比例，比大多数人的求职简历投递效率还低。

把四个实验放在一起看，能拼出一幅比所谓 AI 会不会造反复杂得多的图景。

当任务空间够大、方向不够明确，Agent 能自己组织出分工，找到人类没指定给它们的地方。当目标天然冲突，它们可能互相破坏。当你只给了角色或层级，或者根本不给任何协调机制，它们会陷入低效混乱。每秒 30 次的垃圾轮询，就是没给协调机制时它们自己发明的办法。

这些实验的共同点，不是 Agent 聪明或危险。而是：你的系统设计，决定了它们会成为什么。没有明确的协调机制，它们发明垃圾轮询。没有冲突消解预案，它们在利益冲突中杀掉对方的进程。没有说清楚的边界，它们跑到你预设范围之外去看。有时候这是好事，有时候这是你根本不知道怎么付账的成本。

这组实验提醒了一件被忽略很久的事情：当你把多个 Agent 放进同一个系统，最难的问题根本不是每个 Agent 有多强。

所以你接下来的系统设计，核心问题可能不是继续问我的 Agent 还能做什么，而是想清楚，我到底准备给它们一种什么样的关系。

如果你正在做多 Agent 系统，或者准备在面试里聊这个话题，有一件事比报数量重要得多：说清楚你给它们设了什么规则，当它们冲突时会发生什么，当它们合作时你拿什么确认收益。

因为那些只告诉你用了协调的人，还没搞明白 240 万次请求和 117 个任务之间的区别。

而那些知道怎么设计对抗的人，才有可能真的用多 Agent 做到单体做不了的事。

毕竟，三台虚拟机上的三个 Claude 用了 4 小时就学会了禁用账号和杀进程。

你的用户可没那么多时间等你调参数。

……

今天和大家分享一道 AI 大模型面试题。

多 Agent 协作有哪些常见的编排模式？各自适合什么场景？

回答重点

多 Agent 协作的编排模式主要有四种：顺序链式、并行扇出、主从委托和群组讨论。选哪种取决于任务的结构特征和对质量、效率的要求。

1）顺序链式

顺序链式是最简单的模式，多个 Agent 像流水线一样依次处理，前一个的输出就是下一个的输入。

比如内容创作场景：研究 Agent 收集资料 → 写作 Agent 生成初稿 → 审校 Agent 修改润色 → 排版 Agent 最终定稿。适合步骤明确、前后有依赖的线性任务，流程清晰可控，但整体延迟是各步骤延迟之和，4 个 Agent 每个跑 10 秒，总共就是 40 秒。

2）并行扇出

这是让多个 Agent 同时处理不同子任务，最后汇总结果。比如竞品分析场景：同时派 5 个 Agent 分别分析 5 个竞品，最后由汇总 Agent 整合出对比报告。如果每个分析要 30 秒，串行跑得 150 秒，并行只要 30 多秒。适合子任务之间相互独立的场景。

3）主从委托

这是设一个"管理者" Agent 负责拆解任务、分配工作、整合结果，其他"执行者" Agent 只管干活。管理者可以根据执行过程中的反馈动态调整分配，比如发现某个子任务失败了就重新派一个 Agent 去做。这种模式最灵活，适合复杂的、需要动态决策的任务。

4）群组讨论

是让多个 Agent 围绕同一个问题进行多轮讨论，互相补充、质疑、完善。适合需要多角度分析、决策质量要求高的场景，比如技术方案评审、风险评估。3-5 个不同角色的 Agent 讨论 3 轮，通常比单个 Agent 想一次的质量高不少。

扩展知识

四种模式的详细对比

维度	顺序链式	并行扇出	主从委托	群组讨论
延迟	各步骤之和	取决于最慢子任务	取决于管理者调度效率	轮数 × 单轮耗时
适合任务	线性流水线	独立子任务	复杂动态任务	决策评审类
容错性	差，一环断全链停	好，单个失败可重试	好，管理者可重新分配	中等
实现复杂度	低	中	高	高
Token 消耗	中	高，多个 Agent 并行	高，管理者需要额外推理	最高，多轮对话

顺序链式的进阶玩法

纯线性的链式有个致命问题：一旦中间某个 Agent 出错，后面全废了。改进方案是加一个路由节点，根据上一步的输出质量决定是继续往下走还是打回重做。

比如代码生成场景：需求分析 Agent → 代码生成 Agent → 代码审查 Agent，审查 Agent 如果发现代码有问题，不是直接往下走，而是把问题反馈回代码生成 Agent 重新生成。这种带反馈回路的链式，本质上已经是一种简单的有向图调度了。

LangGraph 就是基于这个思路设计的，它把 Agent 编排抽象成一个状态图，节点是 Agent，边是条件跳转，比纯链式灵活得多。

主从委托的核心难点

主从委托模式看起来很美，但管理者 Agent 的设计是最难的部分。它需要具备 3 个能力：

1）任务拆解能力，把一个复杂需求拆成合理的子任务，粒度太粗执行 Agent 搞不定，粒度太细管理开销爆炸

2）结果评估能力，执行 Agent 返回结果后，管理者要能判断质量是否达标，不达标就得重新分配或者换一个 Agent

3）异常处理能力，某个执行 Agent 超时了、返回了错误结果、或者拒绝执行了，管理者要有降级策略

Cursor 的 background agent 和 Claude Code 的 sub-agent 机制就是典型的主从委托，主 Agent 把子任务分发给子 Agent，子 Agent 在独立的 worktree 里执行，完成后结果回传主 Agent 整合。

Agent Teams 的兴起

2026 年起一个明显的趋势是 Agent Teams 概念的流行。不再是单个 Agent 单打独斗，而是让一组有不同专长的 Agent 组成团队。

比如一个软件开发团队可能包括：产品 Agent 理解需求拆解功能、架构 Agent 设计技术方案、开发 Agent 写代码、测试 Agent 写测试用例并验证、运维 Agent 处理部署和监控。这跟真实的人类团队分工非常像。

OpenAI 的 Swarm 框架、微软的 AutoGen、CrewAI 都是朝这个方向在做。它们的核心区别在于 Agent 之间怎么传递上下文、怎么协调冲突、怎么共享记忆。

混合编排是常态

实际项目中很少只用一种模式。比如一个复杂的数据分析任务：管理者 Agent 先把任务拆成"数据清洗"“特征工程”“模型训练”“报告生成” 4 个子任务。数据清洗和特征工程有先后依赖，用顺序链式。模型训练可以同时跑 3 个不同算法的 Agent，用并行扇出。最终报告需要几个 Agent 讨论结论是否合理，用群组讨论。整体上是主从委托套着其他三种模式。

选模式时核心考虑几个因素：子步骤是否有严格先后依赖、子任务能否独立并行、执行过程中是否需要动态调整、决策是否需要多角度验证。

把这几个问题回答清楚，模式自然就出来了。

篇幅有限，更多 AI 大模型 相关面试题可以进入面试鸭进行查阅。