深度解读 Agent Swarm：第三条 scaling 轴，和它要交的协调税

训练一个并行编排器，最顽固的失败模式不是 agent 互相冲突、也不是任务分错，而是编排器拒绝并行：明明手里有派出上百个子 agent 的权限，它却缩回去单干，把任务串行做完。Moonshot 在 Kimi K2.5 技术报告里给这个现象起了名字——serial collapse（串行坍缩），并且不得不在奖励函数里专门塞一项「并行奖励」去贿赂它。这个细节比任何营销文案都诚实：并行不是天然优势。连模型自己都算得出来，协调是要交税的。

2026 年，“agent swarm” 从一个藏在 Claude Code 二进制里的 feature flag，变成了各家争相发布的主打能力：Anthropic 正式发布 agent teams，Moonshot 把 Agent Swarm 写进 Kimi K2.5 的技术报告，围绕多 agent 编排的 arXiv 论文密集到一篇综述直接观察说：几乎全部代表性工作都挤在 2024 Q4 到 2026 Q2 这 18 个月的窗口里。

热闹背后，这篇想说清一件事，可以压成一句话：

Agent swarm 的本质，是在「单个上下文窗口装不下任务」这个硬约束下，把推理时算力从「纵向想更久」扩展成「横向同时想」的第三条 scaling 轴；它的成败不取决于 agent 数量，而取决于并行收益能否覆盖协调税——而 2026 年最重要的变化是，「何时并行、如何分工」这件事本身，正在从人写规则变成 RL 学出来。

下面分五步拆：先正名（swarm 这个词从哪来）、再看三代形态、然后算两本账（为什么划算、税交在哪），最后看历史如何在编排层重演。

一、先正名：swarm 借了生物学的词，换了含义

“Swarm” 来自群体智能（swarm intelligence）传统：Reynolds 1987 年的 boids 用三条局部规则（分离、对齐、聚集）让虚拟鸟群涌现出逼真的集体飞行；Dorigo 上世纪 90 年代的蚁群优化用信息素浓度这一种局部信号解出组合优化问题。这个传统的信条是：个体极简 + 只有局部信息 + 没有中央指挥 → 涌现全局智能。有趣的是这条线今天还活着——一篇 2025 年的论文把 LLM 接进 NetLogo 仿真平台，用自然语言 prompt 替换硬编码的个体程序，重演了蚁群觅食和鸟群聚集。

但 LLM 时代的 “agent swarm” 借了这个词，几乎换掉了全部内涵：个体不再简单（每个 agent 都是一个完整的、带工具的 LLM）；数量不再以千计（几个到几百个）；甚至「没有中央指挥」这条精神纲领也大多不保留——按一份 2026 年的行业观察，生产部署中占主导（约七成）的是 orchestrator-worker（有明确中心的编排者-工人）拓扑，真正去中心的对等 swarm 是少数，且在受监管行业里基本不被采用，因为无中心意味着责任链难以审计。

所以先把定义钉住：本文说的 agent swarm，指多个各自持有独立上下文窗口的 LLM agent，在某种协调机制（中心编排或对等通信）下并行处理同一个任务。它继承自群体智能的不是「个体简单」，而是那个更根本的赌注：多个局部视角的并行探索，能胜过一个全局视角的串行推理。这个赌注什么时候成立，是后文全部内容。

二、三代形态：编排逻辑从谁手里来？

把 2024 年至今的标志性系统排成一条线，会发现真正的演化变量不是 agent 数量，而是编排逻辑的来源。

timeline
    title Agent Swarm 三代形态
    2024 Q4 : OpenAI Swarm：handoffs，人写规则
    2025 Q2 : Anthropic 研究系统：orchestrator-worker，prompt 里写编排启发式
    2026 Q1 : Claude Code agent teams：编排进产品，工程手段压协调税
    2026 Q1 : Kimi K2.5 PARL：编排策略由 RL 训练

第一代：手写 handoffs（OpenAI Swarm，2024.10）。openai/swarm 是一个不足千行 Python 的教学框架，只有两个原语：Agent（指令 + 工具）和 handoff（交接）。handoff 的实现朴素到漂亮——就是一个返回另一个 Agent 对象的工具调用，运行时切换 active agent、共享对话历史、继续循环。它 2025 年 3 月被生产级的 Agents SDK 接班（原语扩成 agents / tools / handoffs / guardrails 四件套），但概念模型原封不动。这一代的特征：谁在什么条件下交接给谁，每一条都是人写的规则。

第二代：orchestrator-worker（Anthropic，2025.6）。Anthropic 的工程博客《How we built our multi-agent research system》是这一代的定义性文本：一个 lead agent 分析查询、拆解策略、动态派生多个 subagent，各自在独立上下文窗口里并行检索，结果汇总回 lead。编排逻辑仍然是人写的——但从代码规则升级成了 prompt 里的启发式（他们花了大量篇幅讲怎么教 lead agent「简单查询派 1 个 subagent、复杂研究派 10 个以上」，因为早期版本会为一个简单问题过度派生）。这篇博客同时给出了本文要反复引用的三个关键数字，下一节展开。

第 2.5 代：编排进产品（Claude Code agent teams，2026.2）。据社区报道，开发者 2026 年 1 月在 Claude Code 二进制里发现了藏在 feature flag 后、完整实现但未发布的多 agent 系统（内部名 TeammateTool / Swarm）；随后 Anthropic 于 2026 年 2 月随新模型正式发布了 agent teams。它的结构值得注意三点：lead 只做计划、委派、合成，不亲自写代码；teammates 之间可以直接互发消息（区别于 subagent 只能向父级汇报的星型拓扑）；每个 teammate 在独立的 git worktree 里工作，靠版本控制的隔离机制而不是靠沟通来避免冲突。这一代把第二代的架构产品化，并用工程手段（worktree 隔离、共享任务列表）硬性压低协调税——这与我之前在《什么是好的 agent harness》里说的观点同构：agent 能力的很大一部分不在模型里，在执行环境的结构里。

第三代：编排被训练出来（Kimi K2.5 + PARL，2026）。Kimi K2.5 技术报告提出 Parallel-Agent Reinforcement Learning（PARL），是目前公开材料里第一个把「编排策略」本身当成 RL 训练对象的工业系统：模型学会自主指挥最多 100 个 subagent、跨约 1500 个协调步骤执行并行工作流，不预设角色、不手写工作流。何时并行、派几个、怎么分工，全部从环境反馈里学。这是从第一代到第三代最干净的一次范式切换：编排逻辑的来源，从人变成了数据。

三代放在一起看，一个熟悉的历史结构浮现出来了——但先别急着总结，先把两本账算清楚：swarm 到底为什么划算，税又交在哪里。

三、第一本账：为什么划算——稀缺资源是上下文窗口

Anthropic 那篇博客里最重要的不是「多 agent 系统在内部研究评测上比单 agent Claude Opus 4 高 90.2%」这个结果，而是对结果的归因：

在 BrowseComp 评测上，三个因素解释了 95% 的性能方差——token 用量单独解释 80%，其余是工具调用次数和模型选择。

把这句话读透，agent swarm 的第一性原理就出来了。性能主要由「有效花掉的 token 量」决定 → 想更强就要花更多 token → 但单个 agent 的 token 花销被一个上下文窗口封顶，塞得越满，中间结论互相挤压、注意力被稀释 → 多 agent 的本质，是把一个装不下的任务分片（shard）到多个独立上下文窗口里，让 token 预算突破单窗口上限。Anthropic 自己的表述是：多 agent 系统擅长的正是「重度并行、信息量超出单个上下文窗口、需要对接大量复杂工具」的任务。

这就和过去两年最热的 test-time scaling 接上了：思维链、长推理模型是纵向扩展——让一个 agent 在一个窗口里想得更久；agent swarm 是横向扩展——让多个窗口同时想。预训练 scaling、推理纵向 scaling、推理横向 scaling，第三条轴。用算力换智能这条主原理没变，变的只是算力的花法。

横向扩展换来的除了容量还有墙钟时间：Kimi 报告在 wide-search 类任务上测得相对串行执行最高 4.5 倍的实际耗时压缩。这解释了为什么第一批立住的场景是研究/检索（BrowseComp、WideSearch 这类「广撒网」任务）——它们天然可分片，分片之间几乎零耦合。

四、第二本账：协调税——以及它有多贵

如果只看上一节，结论会是「agent 越多越好」。两组证据立刻泼冷水。

税单第一行：token 成本。Anthropic 给的数字是：单 agent 约为聊天的 4 倍 token，多 agent 系统约为聊天的 15 倍。行业观察给出的口径类似：中心化编排的多 agent 配置相对单 agent 有约 285% 的 token 开销，独立并行的配置约 58%。数字口径可以争论，量级是一致的：协调本身要吃掉数倍于「干活」的 token——lead 要写指令、subagent 要各自重建对任务的理解、结果要汇总去重。

税单第二行：失败模式。UC Berkeley 团队的 MAST（Multi-Agent System Failure Taxonomy，arXiv:2503.13657）是目前这方面最系统的实证工作：分析 150 条（后扩展到 1600+ 条）多 agent 执行轨迹，归纳出 14 种失败模式、三大类，标注者一致性 kappa = 0.88。三大类的占比值得背下来：规约与系统设计问题 41.77%、agent 间失调 36.94%、任务验证与终止问题 21.30%。论文的核心结论是：多 agent 系统的失败大多不是因为底层模型太笨，而是系统设计问题——任务规约含糊、角色边界不清、agent 之间互相误解、没人负责验证。换句话说：协调税不只是 token，还有一整类「组织病」，而且这些病不会随模型变强自动痊愈。

税单第三行：连模型都知道贵。回到开头的 serial collapse：PARL 训练中，编排器面对延迟、稀疏、非平稳的反馈（子 agent 各自异步跑，好坏要很久才知道），最稳的策略就是不派活、自己串行干。Kimi 的解法是奖励塑形——训练早期给并行行为额外奖励，再把这些奖励项退火归零，让最终策略只对任务质量负责。报告还设计了 critical steps 指标：每个阶段的耗时按最慢的那个 subagent 计——把并行的真实收益（关键路径长度）直接写进度量。这是「目标函数即命运」最教科书的应用：你度量关键路径，才能得到真正的并行；你只度量任务成败，就会得到串行坍缩。

税单之外还有反方证据：上文引用的行业综述提到，2026 年有研究发现，在相同思考 token 预算下，单 agent 在多跳推理任务上反超多 agent 系统。这个对照实验设计得很毒——它把「多 agent 更强」的光环剥开，露出里面真正干活的变量：不是 agent 数量，是 token 量和任务的可并行结构。多跳推理是强顺序依赖的（第二跳依赖第一跳的结论），分片没有收益，协调纯是净损耗。

两本账合起来，就是本文的可复用判据：

swarm 划算 ⇔ 任务的可分片程度 × 单窗口装不下的程度 > 协调税（token 开销 + 组织病风险）。

研究检索类任务两个乘数都大，所以最先立住；代码类任务写共享状态、顺序依赖重，Anthropic 直言「大多数编码任务的真正可并行部分比研究少」，所以 Claude Code 要靠 worktree 隔离这类工程手段去压税基；强顺序推理任务乘数趋近于零，老老实实单 agent。

五、历史的押韵：编排层的「从规则到数据」

现在可以回收第二节埋的线了。AI 的历史有一条反复出现的主线：人写规则的部分，不断被数据学出来的部分替换。手工特征死于深度学习；行为规则死于端到端 RL；prompt 里的推理脚手架正在死于推理模型。每一次，人类专家先用规则把新能力的原型搭出来，然后苦涩的教训（bitter lesson）准时上门：通用方法 + 算力 + 数据，碾过人工巧劲。

编排层正在走完全一样的路径。第一代 handoffs 是显式代码规则；第二代 orchestrator prompt 是自然语言规则（Anthropic 博客里那些「简单任务派 1 个、复杂任务派 10 个」的启发式，本质是专家系统式的知识工程）；第三代 PARL 把这些全部交给 RL——并且它的三个关键设计，每一个都在向多 agent RL 的老难题致敬：

1. 冻结 subagent、只训编排器：子 agent 的执行轨迹排除在优化目标外。这直接绕开了多 agent 联合训练最老的两个坑——信用分配歧义（成果算谁的？）和训练不稳定（所有人同时在变，环境对每个个体都是非平稳的）。
2. 奖励塑形 + 退火：$r_{\text{PARL}} = \lambda_1 r_{\text{parallel}} + \lambda_2 r_{\text{finish}} + r_{\text{perf}}$，其中 $\lambda_1, \lambda_2$ 随训练退火到零。先用脚手架顶住探索期，再撤掉脚手架让真实目标接管。
3. 关键路径度量：把墙钟时间的真实结构写进目标，堵死「假并行」的奖励漏洞。

而「冻结 subagent」显然是权宜之计——它意味着分工的质量上限被冻结的子 agent 能力锁死。合理的推断（注意：这是推断，不是报告内容）是下一步走向编排器与子 agent 的联合或交替训练；而跨系统的方向已经有实物：综述提到 K2.6 的材料把部署包线扩到 300 个 subagent、4000 协调步，并预览了跨厂商、人机混合协作的 Claw Groups。如果说单 agent 时代竞争的是模型，swarm 时代开始竞争的是组织——一个被训练出来的、知道何时该雇人何时该单干的组织。

六、带走三个问题

下次再看到任何打着 swarm / multi-agent 旗号的系统，拿这三个问题去照：

1. 它的稀缺资源真的是上下文窗口吗？如果任务单窗口装得下，多 agent 只是在为架构图交税。
2. 协调税记在账本哪一行？token 开销是显性税；MAST 那三类组织病（规约 41.77%、失调 36.94%、验证 21.30%）是隐性税。一个不谈失败模式的 multi-agent 方案，大概率还没跑过真实负载。
3. 编排规则是人写的还是学出来的？这决定它站在历史的哪一边。人写规则可以先跑起来，但如果 bitter lesson 在编排层再次应验——而目前所有证据都指向它会——那么护城河不在工作流图里，在能训练编排策略的环境和数据里。

蚁群没有 CEO，但 LLM swarm 有——而且这个 CEO 正在从「按手册办事」进化成「从绩效里学管理」。这大概是 2026 年 agent 领域最值得盯住的一条线。

---

参考来源

工程实践与产品

• Anthropic Engineering, How we built our multi-agent research system（2025-06）：90.2%、4×/15× token、BrowseComp 方差归因与任务适配性论述的一手来源
• Moonshot AI, Kimi K2.5 Tech Blog：Agent Swarm 与 PARL 的官方介绍
• openai/swarm（GitHub）与 OpenAI Agents SDK 文档
• Claude Code agent teams 的发现与发布过程：byteiota 报道、atcyrus 解读、Sean Kim 的 2026 年 3 月综述
• Multi-Agent Systems Explained: 2026 Patterns（decodethefuture）：拓扑占比、token 开销口径与等预算对照结论的行业观察（二手来源）

arXiv 论文

• arXiv:2602.02276 — Kimi K2.5: Visual Agentic Intelligence（PARL、serial collapse、critical steps、100 subagents/1500 步、4.5× 墙钟收益）
• arXiv:2503.13657 — Why Do Multi-Agent LLM Systems Fail?（MAST：14 种失败模式、三大类占比、kappa=0.88、MAST-Data 1600+ 轨迹）
• arXiv:2605.02801 — Reinforcement Learning for LLM-based Multi-Agent Systems through Orchestration Traces（综述：18 个月窗口观察、K2.6 包线与 Claw Groups）
• arXiv:2503.03800 — Multi-Agent Systems Powered by Large Language Models: Applications in Swarm Intelligence（LLM + NetLogo 复演蚁群/鸟群）
• arXiv:2412.17481 — A Survey on LLM-based Multi-Agent System（领域全景综述）