Chapter 02 · 工作原理与设计权衡
沿三条轴选择，与那笔 token 账
上一章建起拓扑 / 协调 / 通信三轴，外加控制与协议两层词汇——这章讲沿每条轴做选择时的取舍与代价，尤其那笔决定一切的 token 账。本章不教 API；所有判断的事实锚点来自 Anthropic 两篇工程文章（2024–2025），正文均标了出处。
本章你要建立的心智模型
- 多 agent 贵在哪、贵多少——每个 subagent 一份独立上下文 + 协调轮次，叠出约 15× token；本质是「用更多 token 换并行广度」。
- 拓扑选择是一道四维取舍——可控性 / 灵活性 / 可扩展性 / 调试难度，supervisor、swarm-handoff、hierarchical 各落在不同角。
- 协调机制的两极——中心调度有瓶颈但可观测，去中心 handoff 灵活但会失控；通信上的上下文隔离防互相干扰，但隔离过度会丢共享信息。
- 一份诚实的「别用多 agent」清单——子任务强依赖、要共享大量中间态、步骤可预先枚举时，单 agent 或固定 workflow 更对。
·整体架构：一张图看清代价从哪来
把三条轴放进一张运行图里：supervisor 编排、并行 subagents 各带一份隔离的上下文、最后汇总。这章后面每一节，都是在这张图的某条边上做权衡——所以先盯住边界画在哪、token 往哪流。
2.1为什么多 agent 贵
多 agent 的成本 = 子任务数 × 每个 subagent 一份上下文 + 协调轮次——叠出约 15× 单次对话的 token。
01 章把三条轴当词汇表铺开，读起来像「多 agent 是更强的架构」。这一节先泼一盆冷水：多 agent 默认不是免费的升级，它有一笔可量化、且远比直觉大的账。这笔账是后面四节所有取舍的共同分母——不先看清它，拓扑、协调、通信的每个选择都会被「反正多 agent 更好」的错觉带偏。
钱花在哪：三笔可拆开的开销
把 01 章图 2.0 的边逐条算一遍，多 agent 比单次对话多出的 token 来自三处，缺一不可：
- 每个 subagent 一份独立上下文——subagent 要独立工作，就得各自带上系统提示、工具定义、任务描述、自己累积的中间结果。N 个 subagent 就是 N 份，互相不复用（§2.4 会讲这份隔离换来什么、又丢掉什么）。
- 协调轮次本身要 token——supervisor 拆任务是一次模型调用，汇总 N 路 finding 又是一次，且汇总时要把各路结果读进同一个上下文。任务越复杂，来回的调度轮次越多。
- 探索有重叠——并行 subagent 各自决定怎么做，难免有人查了重复的东西、走了相邻的路径。重叠的部分是纯浪费的 token，却是并行换广度的固有代价。
Anthropic 在《How we built our multi-agent research system》里报告了两个一起记才有意义的数：多 agent 系统的 token 用量约为单次对话的 15×；而在他们的分析里，约 80% 的性能差异由 token 用量本身解释。合起来读：多 agent 之所以在他们的研究任务上更强，很大程度不是因为「多个脑子」更聪明，而是因为它被允许烧掉 15× 的 token 去做更宽的探索。多 agent 的本质是一台「token → 广度」的兑换机。
所以分界线是「值不值 15×」
这把整章的第一道判断变得很具体：一个任务该不该上多 agent，先问它的价值撑不撑得起 15× 的 token。研究型、检索型、覆盖面优先的任务，多花 token 换更全的答案是划算的；而高频、低价值、答案唯一的查询，烧 15× token 去并行是经济上说不通的——Anthropic 在同一篇里明确把这类查询列为不该用多 agent 的场景。
| 方案 | 优势 | 为什么没选 / 代价 |
|---|---|---|
| 单 agent 串行 | token 省（约 1×）；只有一份上下文，无聚合复杂度；行为可线性追踪 | 没有并行，wall-clock 慢；单条上下文窗口会被长任务填满；探索广度受限于一条线程 |
| 多 agent fan-out | 并行省 wall-clock；探索广度大；每个 subagent 上下文独立，主线程不被填满 | 约 15× token；多一层协调要调度 + 汇总；探索重叠是纯浪费；调试要跨多份上下文（§2.4） |
这一节的代价就是它自己讲的那笔账，但代价不止于钱：15× token 同时意味着 15× 的失败面——更多的模型调用、更多容易跑偏的上下文、更长的调用链。token 账只是最容易量化的那一面；它放大的是整个系统的不确定性。这也是为什么后面三节都在讲「怎么把这份放大的不确定性收住」。
两个候选优化：(A) 把 subagent 从 3 个加到 6 个，覆盖更全；(B) 给现有 3 个 subagent 每个的 token 预算翻倍。在 Anthropic 那条「80% 性能差异由 token 解释」的经验下，哪个更划算？（提示：关键不在「加多少 token」，在「加的 token 会不会被浪费」）
展开答案（先停 10 秒再点）
两个都在加 token，所以都朝对的方向走——胜负在加的 token 有没有被有效利用。如果当前 3 个 subagent 的探索已经互有重叠，(A) 加到 6 个会让重叠更严重，新增 token 大量浪费在重复路径上；(B) 给每个更多预算，让它把自己那块查得更深，新增 token 更多转成新信息。
这道题的意义不在选 A 还是 B，而在戳破一个直觉：「加 subagent 数量」常被当成多 agent 的默认增强手段，但真正的杠杆是「token 花得有没有重叠」。先把任务切得不重叠，再谈加并行度——否则只是在为重复探索付 15× 的钱。
2.2拓扑选择权衡
拓扑不是「哪个最好」，是四维取舍——可控性 / 灵活性 / 可扩展性 / 调试难度，三种主流拓扑各占不同的角。
01 章 §1.2 把拓扑当词汇表列了四个变体（supervisor / hierarchical / mesh / sequential），只回答「谁决定下一步」。这一节回答下一个、也是真正要在选型时拍板的问题：同样能跑通的拓扑，代价分布完全不同。选错拓扑的后果不是「不能跑」，而是某一维度的代价在生产里突然爆开——可控性差的拓扑半夜失控、可扩展性差的拓扑一加 agent 就 token 翻倍。
运行方式：三种拓扑各自怎么决定下一步
- Supervisor（中心编排）——一个 orchestrator 拆任务、派给 worker、收回结果。所有控制流经过中心节点。这是 Anthropic Research、LangGraph Supervisor 的形态。
- Swarm-handoff（去中心交接）——没有中心，任一 agent 可以把控制权 + 上下文显式交接给另一个 peer，自己退出。这是 OpenAI Agents SDK 的 handoff 形态（01 章 §1.4 通信表里的 Handoff 那一行）。
- Hierarchical（分层嵌套）——supervisor 里再套 supervisor，递归分层。顶层管大块，子层管细分。适合任务天然有层级结构时。
| 拓扑 | 可控性 | 灵活性 | 可扩展性 | 调试难度 |
|---|---|---|---|---|
| Supervisor | 高——控制全过中心，能在一处加约束 | 中——新路径要改 orchestrator 逻辑 | 中——中心节点是瓶颈，agent 多了它先到上限 | 低——有唯一的可观测点，trace 从中心一条线读下去 |
| Swarm-handoff | 低——没有中心可下手，约束要逐个 agent 写 | 高——新 agent 接进交接网即可，无需动中心 | 高——无中心瓶颈，加 agent 不挤同一个点 | 高——控制在 peer 间横跳，trace 是网状的，难复现 |
| Hierarchical | 中——每层可控，但跨层约束要逐层传 | 中——分层清晰，但层级结构本身是硬编码的 | 高——按层切分，能扛大任务 | 中高——层数越多，协调开销和 trace 深度同步上涨 |
四列里没有哪一行全占优——supervisor 拿可控 + 好调试，付灵活和扩展；swarm 拿灵活 + 扩展，付可控和调试；hierarchical 拿扩展，付协调开销。选型实质是在问「这个任务最不能承受哪一维度的代价」：要审计 / 要随时叫停的场景（金融、合规）选可控性高的 supervisor；要快速接入异构 agent、不在乎全局视图的选 swarm;任务天然分层、规模大的选 hierarchical。
拓扑的代价是「换轨成本」：一旦系统建在某个拓扑上，约束、可观测、failure-handling 都顺着它长。从 supervisor 迁到 swarm 不是改几行——中心节点里那套调度和约束逻辑要拆散重写进每个 peer，trace 体系也要从「一条线」改成「一张网」。所以拓扑是早期就要拍准、且最贵改的决定。04 章会把 supervisor 拓扑失败 和 mesh / 去中心拓扑失败 拆成具体症状——那是这一节四维取舍在生产里失手时的样子。
团队说「我们用 hierarchical 拓扑，因为它可扩展性最好」。这个理由够吗？还该追问什么？
展开答案（先停 10 秒再点）
不够。可扩展性是 hierarchical 的真优点，但它附带两笔账：每多一层就多一轮调度（协调开销 = 直接的 token 开销，回到 §2.1），且跨层约束要逐层传递——顶层定的「不许调用外部写接口」这条规则，得在每一层 supervisor 都重申，漏一层就失控。
该追问的是：任务真的有天然层级吗？如果任务其实是扁平的一堆并行子任务，硬套 hierarchical 只是凭空多出层级、多付协调 token，却没换来对应的结构收益——这时一层 supervisor 的 fan-out 更对。拓扑要匹配任务的形状，不是匹配「哪个词听起来更能扩展」。
2.3协调机制权衡
协调的两极——中心调度有瓶颈但可观测、可加约束；去中心 handoff 灵活但会失控、难复现。
01 章 §1.3 把协调和拓扑分成正交两轴——拓扑回答「谁说了算」，协调回答「怎么 split & merge」。这一节聚焦协调轴上最尖锐的一道权衡：调度权放中心，还是让 agent 自己交接。它和 §2.2 的拓扑高度相关却不等同——supervisor 拓扑天然走中心调度，swarm 拓扑天然走去中心 handoff，但「调度逻辑」本身的取舍值得单独看清，因为它决定了系统出问题时你能不能查得动。
运行方式：调度权在中心，还是在边上
中心调度——一个 orchestrator 持有全局视图，决定每一步派给谁、何时收手、N 路结果怎么合。所有调度决策集中在一处，于是这一处既是瓶颈（所有流量过它，它先到上限），又是唯一的可观测点和约束注入点（要加「最多 5 轮」「禁止某工具」，在中心加一次就全局生效）。
去中心 handoff——没有全局视图，每个 agent 自己判断「我处理不了，交给谁」，把控制权 + 上下文交接出去。好处是灵活：加一个新专家 agent，只要让相关 agent 知道可以交接给它即可，无需改动一个中心。代价是没有谁掌握全局——交接会成环（a 交给 b、b 又交回 a）、会出现没有任何 agent 认领的悬空、整条交接链也没有统一的终止判断。这三类失控都没有一个中心节点来兜底。
| 方案 | 优势 | 为什么没选 / 代价 |
|---|---|---|
| 中心调度（orchestrator 持全局） | 可观测——一处读完整调度史；可控——约束 / 终止 / 预算在中心加一次即全局生效；好复现 | 中心是瓶颈，吞吐和上下文都先到它的上限；中心逻辑变复杂后自身成为单点风险 |
| 去中心 handoff（peer 自交接） | 灵活——接入新 agent 无需动中心；无瓶颈——调度分散到各节点 | 会失控——交接成环 / 悬空 / 缺统一终止；没有全局视图，故障难复现，约束要逐 agent 重写 |
去中心 handoff 最常见的失手不是「交接错对象」，而是没人为整条交接链设统一的终止条件。中心调度里终止判断天然只有一处；去中心后，终止变成每个 agent 各自的局部判断，于是「a 觉得该交给 b、b 觉得该交回 a」的环就没有任何一方负责打断。04 章 §4.1 mesh 拓扑失败 把这个失控展开成具体症状——本质就是这一节「去中心 → 失去全局终止权」的代价落地。
中心调度的代价是它把「可观测 + 可控」和「瓶颈 + 单点风险」绑成一组——你拿不到前者而不付后者。当 orchestrator 的调度逻辑随业务越长越复杂，它本身就从「最好调试的点」慢慢变成「最复杂、最易出 bug 的点」。去中心 handoff 的代价则是把这份复杂度摊给了可观测性：系统更灵活了，但出问题时你失去了那个能一眼读完全局的位置。两条路都没有「既灵活又可观测」的免费档——这正是要在选型时显式拍板的原因。
客服系统:用户问题在 billing / tech / account 三个专家 agent 间流转。选中心调度还是去中心 handoff？再追加一个条件——「每次转接都要留可审计的记录」，答案变吗？
展开答案（先停 10 秒再点）
只看「三专家分流」，去中心 handoff 很自然——这正是 OpenAI Agents SDK handoff 的典型场景（01 章 §1.4），加一个新专家只要接进交接网。
但加上「每次转接要可审计」这条，天平就倾向中心调度，或至少一个轻量中心来记账：去中心 handoff 没有全局视图，要在每个 agent 里各自正确地写审计日志、还要保证交接链不悬空不成环，工程负担和出错面都更大;中心调度天然有一处看得见每一次转接，审计记录顺手就有。这道题的意义是：协调机制的选择常被「灵活性」单独推着走，但一旦出现「可审计 / 可控」的硬需求,中心调度的可观测优势就重新变成决定性的。
2.4通信与上下文隔离
上下文隔离防互相干扰，但隔离过度会丢共享信息——目标是传「够用且不过量」的上下文。
01 章 §1.4 把通信当词汇表列了四种消息形状（group chat / handoff / event bus / shared state），回答「消息长什么样」。这一节回答更深一层、也更难调的问题：每个 subagent 到底该看见多少别人的上下文。这不是「传不传消息」的二选一,而是一根连续的旋钮——拧太松，subagent 互相看不见、做出冲突的隐含决策;拧太紧（全员共享所有上下文），又回到 token 爆炸 + 互相干扰。这根旋钮直接连着 §2.1 那笔 token 账：传得越多越贵。
运行方式：隔离是一根旋钮，不是开关
图 2.0 里每个 subagent 外那圈虚线，就是上下文隔离边界。它解决的核心问题是 context clash（上下文互相干扰）：如果所有 subagent 共享同一份不断膨胀的对话历史，A 的中间猜测会污染 B 的判断，且每个 agent 每一步都要把全部历史读一遍——token 平方级增长。隔离把每个 subagent 关进自己干净的上下文，于是各自专注、token 线性。
但隔离有反方向的失手。subagent 各自独立工作时，会基于自己看到的那一小块做出隐含决策——而隐含决策需要共享前提才能彼此一致。隔离过度，subagent 就在缺共享前提的情况下各做各的，汇总时无法对齐。所以隔离不是「开 / 关」，是一根要调到「够用且不过量」的旋钮。
| 隔离档位 | 解决的痛点 | 引入的代价 |
|---|---|---|
| 隔离过松（全员共享全部上下文） | 没有信息丢失，谁都看得见全局 | context clash——他人中间态污染判断;token 随历史平方级膨胀（直接放大 §2.1 的账） |
| 隔离过度（subagent 完全互不可见） | 各自上下文最干净、token 最省、最专注 | 隐含决策无共享前提，汇总时彼此冲突、无法对齐 |
| 够用且不过量（共享前提 + 各自隔离） | 既防干扰、又防冲突；token 花在刀刃上 | 要工程判断「哪一块是必须共享的前提」——这一步没有自动答案，是设计活 |
判别很实用：会改变 subagent 隐含决策的，是共享前提，必须传（整体目标、统一口径 / 术语、彼此要对齐的接口约定、已定的全局约束）;只是某个 subagent 的工作过程，是私有上下文，不该传（它的中间草稿、它查到的原始材料、它的推理链）。把前者传成共享、后者留在隔离里——既不撞 context clash，也不让隐含决策跑偏。传错方向（把私有过程当共享传）就是 §2.1 那笔 token 账失控的最常见来源之一。
「够用且不过量」这档的代价，是它把一个判断推给了设计者：哪一块算「必须共享的前提」没有自动答案。传少了，subagent 隐含决策冲突;传多了,token 浪费 + 干扰回升。这条线还会随任务漂移——同一套 agent 换个任务,该共享的前提就变了。所以上下文隔离不是配一次就完的参数,是要随任务调、且要靠 trace 持续验证的设计决策。04 章 §4.6 通信失败 收集的就是这根旋钮拧错档时的具体症状。
两个 subagent 并行为同一个产品页写文案:A 写标题区、B 写功能列表。把隔离拧到「完全隔离、各写各的」会出什么问题?该共享的「够用前提」是哪一小块?
展开答案（先停 10 秒再点）
完全隔离会出隐含决策冲突:A 把产品定位写成「专业、冷静」,B 在功能列表里用了活泼、口语的语气——各自看自己那块都合理,拼到同一页就割裂。这正是图 2.2 中间那一档的失败:缺共享前提,隐含决策无法对齐。
该共享的「够用前提」是那一小块会改变双方隐含决策的东西:产品定位 / 目标受众 / 语气口径 / 关键术语怎么称呼。把这一小段共享给两个 subagent,其余(A 的标题草稿、B 查的功能细节)继续各自隔离。注意这一小块前提的 token 成本极低,却挡掉了最贵的失败——返工重写。这就是「够用且不过量」的实操:不是少传,是只把改变决策的那部分共享。
2.5何时不该用多 agent
三种信号说「别用多 agent」——子任务强依赖、要共享大量中间态、步骤可预先枚举。
前四节讲的都是「用多 agent 时怎么选」,但最省成本的设计决策往往是根本不用多 agent。多 agent 默认背着 §2.1 那笔 15× 的账;如果一个任务不需要它换来的并行广度,这笔账就是纯亏损。Anthropic 在《Building Effective Agents》里反复强调的正是这条:能用更简单的方案(单次调用、固定 workflow)解决,就不要上 agent;能用单 agent,就不要上多 agent。这一节是一份诚实的「别用」清单——能识别这三种信号,比会调任何拓扑都更省钱。
三种「别用」信号
- 子任务强依赖——后一步必须等前一步的结果才能开始(B 依赖 A 的输出、C 依赖 B 的输出)。强依赖意味着无法并行,而并行正是多 agent 唯一值 15× token 的理由。强依赖链该走单 agent 串行:一条线程顺序累积上下文,后段天然看得见前段。
- 要共享大量中间态——任务要求所有步骤持续看见彼此的大量中间结果(联合写一份前后必须严格一致的长文档、增量编辑同一份代码)。这种任务把 §2.4 的隔离旋钮逼到「过松」那一端——要么全员共享(token 爆炸 + 干扰),要么隔离(决策冲突),两端都坏。单 agent 一份累积上下文反而最自然。
- 步骤可预先枚举——流程是固定的、已知的、可以提前画成流程图的(抽取 → 校验 → 转换 → 入库)。步骤已知就不需要 agent 在运行时自主决策下一步——一个固定的 workflow(代码编排的有向流程)更可控、更可测、更便宜。Anthropic 明确区分:有固定路径用 workflow,需要模型自主决定路径才用 agent。
| 看到这个信号 | 不该用多 agent 的原因 | 更对的方案 |
|---|---|---|
| 子任务强依赖(B 等 A、C 等 B) | 无法并行,多 agent 换不来广度,只剩 15× 的纯成本 | 单 agent 串行——一条线程顺序累积上下文 |
| 要持续共享大量中间态 | 把隔离旋钮逼到坏端:共享则爆炸 + 干扰,隔离则冲突 | 单 agent——一份累积上下文最自然 |
| 步骤可预先枚举(固定流程) | 不需要运行时自主决策,agent 的灵活性是负担 | 固定 workflow——代码编排,可控可测更便宜 |
| 子任务独立 + 覆盖面优先 + 路径需运行时决定 | 这才是多 agent 唯一值 15× 的场景 | 多 agent fan-out(回到 §2.1–§2.4) |
最贵的失手不是「拓扑选错」,而是在一个本该用 workflow 的固定流程上套了多 agent。流程本来确定、可测、便宜,套上多 agent 后凭空多出 15× token、多出一层运行时不确定性(模型在某步「自主」决定走偏的风险),还把一个本可单元测试的流程变成了难复现的多 agent 系统。「这个任务的下一步,到底需不需要模型在运行时决定?」——这一问能挡掉绝大多数不必要的多 agent。答案是「不需要」就用 workflow。
这份清单本身也有代价:它要求在动手前先诚实评估任务形状,而不是默认「上多 agent 显得更先进」。判断「子任务到底强不强依赖」「中间态到底要不要持续共享」「步骤到底能不能枚举」需要对任务的真实理解——这一步偷懒,就会要么错过该并行的机会,要么为不该并行的任务付 15× 的账。换句话说,「别用」的判断力和「怎么用」的判断力一样,都得靠对任务的深入分析换来。
「把一篇长报告翻译成五种语言」——五种语言互不依赖,看着像并行 fan-out 的完美场景。但这个任务真的需要多 agent 吗?
展开答案（先停 10 秒再点）
五路翻译确实互相独立,满足「子任务独立」。但它撞上了另一个信号:步骤可预先枚举——「对每种语言,调用一次翻译」是一个完全固定、已知的流程,没有任何一步需要模型在运行时决定「下一步做什么」。
所以更对的方案是固定 workflow + 并行调用(代码里一个循环 / 并行 map,对五种语言各发一次翻译请求),而不是「多 agent」。这里的关键区分:「并行」和「多 agent」不是一回事——并行只是同时发多个调用,任何 workflow 都能做;多 agent 额外意味着「让模型自主决定下一步、agent 之间协调」,而这个翻译任务一点都不需要。把「需要并行」误当成「需要多 agent」,是最常见的过度设计——白付一层协调的 token 和不确定性。
§跨概念综合：四条轴串成一个决定
场景:「为一个新发布的开源框架,自动生成一份带引用的技术评测报告」。要广泛检索(文档 / 源码 / issue / 社区讨论),交叉验证,最后产出一份连贯的报告。把这一章四条轴串起来过一遍——它们不是四道独立选择题,是同一个系统的四个维度,且彼此互相约束:
- 该不该用多 agent(§2.5 + §2.1)——检索环节子任务独立(查文档 / 查 issue / 查讨论互不依赖)、覆盖面优先、且「查到这一步该不该再深挖」需要运行时判断。三个条件都指向「值 15× token」。结论:检索环节用多 agent;但报告撰写环节子任务强依赖(全篇要前后一致),该退回单 agent——一个任务内部,两段用不同方案。
- 拓扑(§2.2)——检索环节要可控、要能在一处汇总、要可审计(报告带引用,得追溯每条结论来自哪次检索)。可控性 + 可观测优先 → 选 supervisor,不选 swarm。
- 协调(§2.3)——supervisor 拓扑天然走中心调度:orchestrator 拆检索子任务、设统一终止(查够 N 个来源即停)、在中心记下每条 finding 的来源(直接服务「带引用」的需求)。这正是 §2.3 里「有可审计硬需求时中心调度的可观测优势变决定性」那条。
- 通信与隔离(§2.4)——每个检索 subagent 隔离自己的上下文(各查各的,不互相污染),但 supervisor 要把一小块共享前提传给所有 subagent:评测的统一维度 / 口径(性能 / 易用性 / 生态…),否则各 subagent 按不同标准评,汇总时无法对齐。隔离调到「够用且不过量」。
这四步不是平行填表,是有因果链的:§2.5 的「值不值 15×」是总开关(关掉就没有后面三步);一旦 §2.2 选了 supervisor,§2.3 的中心调度几乎就被锁定;而「报告带引用」这个业务需求,反过来又强化了 supervisor + 中心调度的选择(只有中心看得见每条结论的来源)。能把「检索段用多 agent + supervisor + 中心调度 + 够用隔离,撰写段退回单 agent」这条完整链讲出来、并说清每一步为什么锁死下一步——这就是从「会用多 agent」到「理解多 agent」的那道线。
§本章 self-check
先合上教程,把你能想到的答案写在纸上或编辑器里。写完再点开答案对照——直接点开等于把这一节当再读一遍。
- 多 agent 约 15× token 的开销,具体来自哪三处?Anthropic 报告的「约 80% 性能差异由 token 解释」推翻了关于多 agent 的什么直觉?
- supervisor、swarm-handoff、hierarchical 三种拓扑,在「可控性」和「调试难度」两维上各排第几?为什么这两维往往同向?
- 中心调度和去中心 handoff,各自的致命代价是什么?为什么「可审计」这个需求会把天平推向中心调度?
- 上下文隔离「过松」和「过度」各撞上什么失败?「够用且不过量」具体指传哪一类信息、不传哪一类?
- (跨机制综合)给一个任务:「监控一个服务的日志,固定每分钟抓取一次,按既定规则分类成 5 类,异常类发告警」。该用多 agent 吗?把 §2.5 的三个信号逐个套上去判断,再说该用什么方案。
答案（先做完再展开）
- 三处:① 每个 subagent 一份独立上下文(系统提示 + 工具定义 + 任务 + 中间结果,N 个 subagent N 份不复用);② 协调轮次本身要 token(拆任务一次调用、汇总又一次,且汇总要把各路结果读进同一上下文);③ 并行探索有重叠(纯浪费)。它推翻的直觉是「多 agent 更强 = 多个脑子更聪明」——实际约 80% 的提升由「被允许烧 15× token 做更宽探索」解释,多 agent 本质是 token→广度的兑换机,不是智力叠加。
- 可控性:supervisor 高 > hierarchical 中 > swarm 低;调试难度(越低越好):supervisor 最低 > hierarchical 中高 > swarm 最高。两维同向,是因为它们都由「控制流是否经过一个中心点」决定:有中心(supervisor)就既能在一处加约束(可控),又能在一处读完整 trace(好调试);去中心(swarm)同时失去这两者。可控性和可观测性是同一个「中心点」的两面。
- 中心调度的致命代价:中心是瓶颈 + 单点风险(逻辑变复杂后自身成为最易出 bug 的点);去中心 handoff 的致命代价:失去全局——交接成环 / 悬空 / 无统一终止,且故障难复现、约束要逐 agent 重写。「可审计」推向中心,是因为审计要求「有一处能看见每一次转接 / 每条结论来源」,这正是中心调度天然具备、去中心要在每个 agent 里费力拼凑且易漏的能力。
- 过松(全员共享全部上下文)撞 context clash(他人中间态污染判断)+ token 平方级爆炸;过度(完全隔离)撞隐含决策冲突(缺共享前提,汇总无法对齐)。「够用且不过量」= 传那些会改变 subagent 隐含决策的信息(整体目标、统一口径 / 术语、要对齐的接口约定、全局约束),不传纯私有的工作过程(中间草稿、原始材料、推理链)。
- 不该用多 agent。逐个套 §2.5 三信号:① 步骤可预先枚举——「抓取 → 按规则分类 → 异常告警」是完全固定的已知流程,没有任何一步需要模型运行时决定下一步(命中,且最致命);② 子任务谈不上需要并行广度,分类规则是既定的;③ 不需要持续共享大量中间态。结论:用固定 workflow(定时任务 + 规则分类 + 告警),分类那步若规则模糊可以是单次 LLM 调用,但整体不需要 agent 自主决策、更不需要多 agent。把它做成多 agent 是典型过度设计:白付 15× token 和一层运行时不确定性,还把一个可单元测试的流程变得难复现。
给一个「混合任务」切出多 agent 段和非多 agent 段
需求:「为一份季度财报,自动生成一份给管理层的摘要 + 三张趋势图的文字说明 + 一段风险提示」。不要写代码——只回答四件事:(1) 整个任务里,哪一段该用多 agent、哪一段不该?用 §2.5 的三个信号说清每段的判断。(2) 该用多 agent 的那段,选什么拓扑(§2.2)?(3) 配什么协调机制(§2.3)?(4) 上下文隔离怎么调——哪一小块是「必须共享的前提」(§2.4)?
提示（卡住再展开）
先拆任务形状:三块内容(摘要 / 三张图说明 / 风险提示)的素材是同一份财报,但彼此基本独立(摘要不依赖图说明的措辞)——「子任务独立」成立,这一段可以并行。但要追问:写这三块需要模型运行时自主决定下一步吗?如果只是「对每块各写一段」,那更接近固定 workflow + 并行调用(§2.5 那道翻译题的同款陷阱:并行 ≠ 多 agent)。真正需要多 agent 的,是其中「从原始财报里挖出该写什么」的探索环节——哪些数字异常值得提、风险点藏在哪——这一步覆盖面优先、且要运行时判断深挖到哪。
所以一个合理切法:探索 / 挖掘段用多 agent(supervisor 拓扑 + 中心调度,因为财报摘要要可审计、要追溯每个数字来源),三块文字的撰写段用固定 workflow 并行(步骤可枚举,不需要 agent)。必须共享的前提:管理层关心的口径 / 这一季的主线叙事——否则三块各讲各的,拼起来没有统一主题。能把「探索段多 agent、撰写段 workflow」这条边界说清,就抓住了本章最难的那点:多 agent 的粒度是「任务段」,不是「整个任务」。