第 04 章 · 多 Agent 协作

一个人打不过，就组队？

2026 年产业最热的方向，也是最容易被滥用的一招——什么时候该组队，什么时候单干，这一章给判据。

① 单 Agent 极限为什么想组队

→

→

→

→

按 → 开始 · 节点可点击直达

04-A · 单 Agent 的极限

为什么想组队

1

上下文装不下——大任务一个窗口不够第 03 章的延续：窗口再大也是稀缺资源（截断/压缩都有损）

2

串行太慢——一个 Agent 一步步磨读十个文件只能一个读完再读下一个——但它们本无依赖

3

单点视角——一个模型的思维定势走错方向时一路错到底，没有「另一个视角」来纠偏

组队怎么组？——最常见的基本形

深挖 Agent 循环详解 ↗

04-A · 组队基本形

主控 + 子 Agent

1

主 Agent 拆解任务、派生活像项目经理：定分工、收结果、做最终决策

2

子 Agent 各自独立上下文，干完只回传摘要读了一百个文件的是子 Agent——主窗口只收一句结论

3

上下文隔离是核心价值，不是附带效果脏活不进主窗口——第 03 章「外置」手段的组织化升级

听起来很美——先看甜头，再看苦头

04-B · 甜头与苦头

读密集 vs 写密集

读密集 · 适合组队互不干扰，天然并行

同时调研 10 个 API 的用法
并行 review 20 个文件找出隐患
给一批模块各写测试——各写各的

写密集 · 不适合组队同仓改码，互相踩脚

并行改同一个仓库——文件冲突互相覆盖
强依赖的改动要同步——交接即等待
多数日常编码任务落在这边（Anthropic 官方判断）

判断第一步：这个任务的读和写能不能拆开？

04-B · 甜头与苦头

组队的账单

1

官方数字：单 Agent ≈ 4× 聊天，多 Agent ≈ 15× Anthropic 工程博客的生产数据——组队起步就是四倍的乘数

2

交接链路拉长——延迟翻倍 派发、等待、汇总，每一段都是串行开销

3

背景要人手一份——每个 Agent 都要上下文同一份任务说明重复注入 N 次——重复成本随规模线性涨

花钱能换速度——但换不来可靠性，看三种失效

04-C · 三种失效

失效一：传话游戏

1

A 的假设传给 B，B 加理解再传给 C 学名 context fragmentation（上下文碎片化）——第 03 章讲过单机版

2

多 Agent 版更凶：每个 Agent 都有自己的 system prompt 与局部上下文「以为对方知道」——各自都按自己的假设补全缺失信息

3

对策：共享完整 trace，而非互相转述摘要后来者读原始记录——一步消除转述损失（Cognition 的原则）

第二种失效更反直觉——交流太多也会坏

04-C · 三种失效

失效二：过早共识

1

本应独立的 Agent 过早交流，趋同到同一个答案学名 premature consensus / consensus drift——注意：和传话游戏是两种不同的病

2

伪共识比分歧更危险 错的口径统一了——你失去了发现错误的那双眼睛

3

对策：关键决策前保持隔离，先独立再汇合独立采样 → 各自给结论 → 才讨论——隔离是为了保住多样性

第三种失效最朴素——组了队反而更慢

04-C · 三种失效

失效三：协调税

1

顺序任务上，多 Agent 变体全部退化 Google DeepMind / MIT 的大规模配置实验：规划、编码这类前后依赖的任务，组队显著变慢

2

等待、交接、对齐——每一样都是税 任务拆不开时，税比收益高——净亏

3

判断题：任务真的能拆成独立并行吗？ 拆不动就别硬拆——单 Agent + 好好做上下文工程，往往更优

失效讲完——那产业现在到底怎么用？

04-D · 产业现状

默认档，仍是单 Agent

1

Claude Code 的 Agent Teams：官方标注「实验性、默认关闭」 厂商文档还建议：顺序任务、同文件编辑用单会话更有效

2

主流形态：单 Agent 主控 + 按需派子 Agent 界面像一个 Agent，脏活重活在需要时才派生出去

3

原因：编排可靠性尚未解决 三种失效没有根治方案——默认档保守是工程理性，不是技术落后

但主战场已经打响——看真实战例

深挖可信 Agent 开发 ↗

04-D · 产业现状

2026：大规模战例出现

1

16 个 Agent 协作写出 10 万行 C 编译器 能编译 Linux 内核——耗时约两周；也保留了短板（个别边缘用例失败），引用时别只说好的一半

2

并行分身（Swarm）报道：端到端耗时大幅下降 各家在数周内密集上线多 Agent 能力——方向已成共识

3

账单同样真实：约 2 万美元 / 20 亿 input token 大规模并行的成本是量级式的——收益与开销都要摆上台面

所以回到那个问题：什么时候组队？

深挖 MegaFlow 论文 ↗ SWE-Universe 论文 ↗

04-D · 组队判据

四问之后再组队

问一 · 上下文装不下吗？子任务上下文大到一个窗口装不下——隔离才有价值

问二 · 并行读操作独立吗？调研、review、写测试——互不干扰的读密集活

问三 · 边界要隔离权限吗？只读的不给写权限、提交的绕不过审核——安全分工

问四 · 分工专职有收益吗？规划用强模型、执行用快模型、审查用另一家——各司其职

四问全「否」——老老实实单 Agent，做好上下文工程

04 · 终章

编排是开放问题

1

组队不是银弹——三种失效都有真实代价 传话游戏、过早共识、协调税——每一种都让结果偏离预期

2

产业姿势：默认单干，按需组队 默认档的保守，恰是对编排难度的诚实

3

Agent 越多，越需要看见它们在干什么 多 Agent 的失效发生在交互里——只看最终结果永远找不到原因

怎么看过程？下一章：轨迹分析——本平台的立身之本

下一章 · 轨迹分析 →