Chapter 03 · Domain 1（权重 27%）

多智能体编排
coordinator–subagent、上下文传递与并行 spawn

多 agent 系统在考试里几乎只考三件事：通信拓扑（谁跟谁说话）、上下文边界（subagent 能看见什么）、分解质量（coordinator 拆得对不对）。三者的题眼都指向同一个人——coordinator。当一个多 agent 系统出问题时，先怀疑 coordinator，这是 Domain 1 命中率最高的一条直觉。

一、Hub-and-spoke：所有通信过 coordinator

官方架构是 hub-and-spoke（轮辐式）：coordinator 是唯一的中枢，所有跨 subagent 的通信、错误处理和信息路由都经过它。subagent 之间不直接对话。

                    ┌──────────────┐
                    │ coordinator  │  ← 分解 / 委派 / 聚合 / 决定调谁
                    └──────┬───────┘
          ┌────────────┬───┴────┬────────────┐
     ┌────▼────┐  ┌────▼────┐  ┌▼─────────┐ ┌▼────────┐
     │ search  │  │analysis │  │synthesis │ │ report  │
     └─────────┘  └─────────┘  └──────────┘ └─────────┘
          ✗ subagent 之间没有横向连线 —— 这是设计，不是遗漏

为什么要绕这一圈？guide 给了三条理由，每一条都可以单独出题：observability（所有信息流有唯一的观察点）、consistent error handling（错误恢复策略集中在一处，不必在每个 subagent 里重复实现）、controlled information flow（谁能看到什么由 coordinator 决定，而不是自由扩散）。

与 P4 的接口 — 「所有通信过 coordinator」有一个官方认可的例外：高频且简单的跨角色需求可以给一个 scoped 专用工具（如 synthesis agent 的 verify_fact），复杂情况仍走 coordinator。这不是打破拓扑，而是在拓扑上开一个有明确边界的小口子。判断标准是频率与复杂度的组合（官方样题 Q9 的 85% / 15% 分界），不是「方便」。

二、上下文隔离：subagent 什么都看不见

这是新手最常踩的坑，也是考试最爱考的一条：subagent 以隔离的上下文运行，不会自动继承 coordinator 的对话历史，多次调用之间也不共享记忆。

直觉（错的）	事实	后果
subagent 是「子进程」，能看到父级的上下文	它只能看到你写进它 prompt 里的东西	synthesis agent 拿不到 search 结果，只能凭空综合 → 幻觉
同一个 subagent 第二次被调用时记得第一次	每次调用都是全新的上下文	「接着上次的继续」这类指令无效
coordinator 说过的话 subagent 都知道	不知道	质量准则、格式要求必须每次显式重述

正确做法是把前序 agent 的完整发现直接写进 subagent 的 prompt——把 web search 结果和 document analysis 输出原样传给 synthesis subagent。传递时要用结构化格式把 content 与 metadata 分离（source URL、文档名、页码），否则 attribution 会在这一步丢失，后面 synthesis 再想补就补不回来了（provenance 的详细讨论见 ch14）。

三、spawn 的语法与并行

subagent 通过 Task tool 启动。有一条硬性配置要求经常出现在选项里：

coordinator = AgentDefinition(
    description = "Research coordinator: decomposes topics, delegates, synthesizes",
    prompt      = "…研究目标与质量准则，不是步骤脚本…",
    tools       = ["Task"]           ✔ 真实存在 · coordinator 的 allowedTools 必须含 "Task" 才能 spawn subagent
)

search_agent = AgentDefinition(
    description = "Searches the web for primary sources on an assigned subtopic",
    prompt      = "…",
    tools       = ["WebSearch"]      ✔ 真实存在 · AgentDefinition 可对每类 subagent 做 tool restriction
)

Task tool 已改名 Agent：考纲（TS 1.3）说 subagent 经 Task tool 启动、coordinator 的 allowedTools 须含 "Task"，本章和全书题目都按这个口径，考试也按这个口径作答。当前 Agent SDK 文档里这个工具叫 Agent：tool_use 块里的名字是 "Agent"，只有 system:init 的工具列表仍显示 "Task"；Claude Code v2.1.63 之前 tool_use 块里也叫 "Task"。文档示例写的是 allowedTools: [..., "Agent"]。

allowedTools 只管免确认，不管能不能用：没列进 allowedTools 的工具对 Claude 照样可用，需要审批的调用交给 permission mode 处理；Agent 本身属于运行前不询问的工具。所以「漏了它就派不出 subagent」不是当前产品行为。要把工具移出可用范围，用 disallowedTools；要按角色收窄 subagent 的工具，用 AgentDefinition 的 tools / disallowedTools。

来源：Subagents in the SDK · Detect subagent invocation；Subagents in the SDK · Tool restrictions；Configure permissions · Allow and deny rules。查阅于 2026-10-16。

并行的关键在「一个响应里发几个」：coordinator 在单次响应中发出多个 Task tool 调用就是并行 spawn；分散在连续几个回合里发，就退化成串行。这是一个纯粹的机制细节，考试直接考过。

并行带来的不只是延迟收益。因为每个 subagent 上下文隔离，并行分支之间不会互相污染推理——这与 ch10 讲的「独立实例优于自审」是同一个道理的两种应用。代价是聚合成本：n 个分支回来的结果需要 coordinator 逐一对齐格式与来源，所以 subagent 的输出格式必须在 prompt 里规定死。

coordinator prompt 写什么

guide 的措辞很明确：coordinator prompt 应当写研究目标与质量准则（research goals and quality criteria），而不是逐步的过程指令（step-by-step procedural instructions）。理由是后者会锁死 subagent 的适应性——你写死了「先搜三篇论文再总结」，它就不会在发现该主题有权威综述时改变策略。

写目标与准则 ✔	写步骤脚本 ✘
"Produce coverage of all major sub-domains of the topic. Every claim must carry a source URL and publication date. Flag areas where sources conflict."	"Step 1: call search_agent with the topic. Step 2: pass the first 5 results to analysis_agent. Step 3: call synthesis_agent."
coordinator 可以按查询复杂度决定调谁、调几次	无论查询是什么都走完整流水线，简单查询浪费、复杂查询不够

与之配套的是 TS 1.2 的一条 skill：coordinator 应当分析查询需求并动态选择要调用哪些 subagent，而不是永远走完整流水线。

四、分解质量：coordinator 最容易坏的地方

官方样题 Q7 是整套样题里最能代表 Domain 1 出题风格的一道：所有 subagent 都「成功」了，报告却只覆盖了视觉艺术，遗漏了音乐、写作、影视。coordinator 日志显示它把 "creative industries" 只拆成了三个视觉类子题。根因在分解过窄，怪 synthesis / search / analysis 的选项全是甩锅（D4）。

把这个模式提炼成考场直觉：

每个 subagent 都成功、但结果不完整 → 看 coordinator 的分解，不是看 subagent。
结果重复冗余 → 看分解的划分：TS 1.2 要求按互不重叠的子主题或来源类型切分（partitioning to minimize duplication）。
结果有明显缺口但分解看起来合理 → 缺的是迭代精化循环：coordinator 评估 synthesis 输出找缺口 → 用定向查询重新委派 search/analysis → 再次调用 synthesis，直到覆盖充分。

第三条值得单独强调，因为它是很多人复习时漏掉的：多 agent 系统不是一趟直线流水线。coordinator 拿到 synthesis 的第一版之后有责任评估它、发现缺口、定向补齐、再综合。考场上，「一次性走完流水线就交付」的选项在覆盖不足类题目里通常是错的。

外部课程 · CertSafari — 本章 2 个考点（展开查看）

用于补读和错题复盘；第三方 AI 生成练习材料，非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对：2026-10-16。

考点回链 — 本章覆盖：TS 1.2（hub-and-spoke、上下文隔离、coordinator 的分解/委派/聚合职责、分解过窄风险、去重划分、迭代精化循环、动态选择 subagent）、TS 1.3（Task tool spawn、allowedTools 含 "Task"、显式上下文传递、AgentDefinition、单响应多 Task = 并行、目标准则型 coordinator prompt、fork-based 探索）。相邻考点：scoped 跨角色工具见 ch11，provenance 见 ch14，错误传播见 ch14。

本章题组

ch03 · Q1 · 准则 P1

Your research system produces reports whose citations frequently point to sources the web search agent never returned. Traces confirm the search agent returns well-formed results with URLs to the coordinator, and the coordinator invokes the synthesis agent with the prompt "Synthesize the research findings into a cited report." What is the root cause?

正确 BTS 1.3：subagent 不会自动继承 coordinator 的对话历史，前序发现必须显式写进它的 prompt。题干的 coordinator prompt 是一句空指令——它没带任何 search 结果。一个被要求「综合研究发现」却看不到任何发现的 agent，只能编。这是上下文隔离最经典的故障形态。

D6 概率当保证违反 P3A：靠加重措辞让模型「不要编造它看不见的东西」——它没有可引用的真实来源，再严厉的指令也变不出来。缺的是数据，不是纪律。

D4 甩锅错位违反 P1C：题干已明确 search agent 返回的是 well-formed 带 URL 的结果，且这些结果送到了 coordinator。把根因指向一个被证明工作正常的组件。

D2 过度工程违反 P2D：双跑取交集把成本翻倍，而两次都看不到来源的 agent 会编造两批不同的假来源——交集可能为空，也可能碰巧重合。它甚至没有触及缺数据这个根因。

ch03 · Q2 · 准则 P5

Your coordinator currently delegates each subtask in a separate turn: it calls the search agent, waits, then calls the document analysis agent, waits, then calls a second search agent for a different subtopic. The three subtasks are independent and none needs the others' output. End-to-end latency is roughly the sum of the three. What change reduces latency?

正确 CTS 1.3 的原话级细节：并行 spawn 的机制就是 coordinator 在单次响应里发出多个 Task tool 调用，而不是分散在多个回合。题干把前提铺得很清楚——三个子任务互相独立，没有数据依赖，正是并行的适用条件。

D2 过度工程违反 P4A：合并成一个拿着三套工具的 agent，直接撞上 TS 2.3——工具过多会降低选择可靠性，且拿到专业外工具的 agent 倾向误用。为了省延迟牺牲了角色隔离。

D2 过度工程违反 P5B：Batches API 的适配轴是延迟容忍的非阻塞负载，它省的是成本不是延迟——最长 24 小时处理窗口且无 latency SLA。用它来降低交互延迟是机制与负载的彻底错配。

D1 凭空捏造违反 P1D：subagent 互相直接启动违背 hub-and-spoke 拓扑（TS 1.2 要求所有跨 subagent 通信经 coordinator，以保证可观测性、一致的错误处理和受控的信息流），而且这种横向调用机制并不存在。

ch03 · Q3 · 准则 P1

A research run on "regulatory approaches to autonomous vehicles" returns a report covering only US federal rulemaking. Logs show every subagent completed successfully, and the coordinator decomposed the topic into: "NHTSA rulemaking timeline," "US federal AV exemption petitions," and "DOT autonomous vehicle guidance." Which change addresses the root cause?

正确 DTS 1.2：三个子题全部落在美国联邦这一个维度里——分解过窄导致覆盖不全，与官方样题 Q7 同一模式。修复有两层：一是按真正互不重叠的维度划分（partitioning to minimize duplication），二是加迭代精化循环让 coordinator 评估 synthesis 输出的缺口并定向补齐。

D3 治标不治本违反 P1A：让 synthesis 标注缺口是有价值的（TS 5.3 的 coverage annotations），但它只能报告缺口，不能填补——subagent 从未被派去查国际监管，缺的数据不在系统里。诚实标注比假装完整好，但题干问的是「修复根因」，诊断不等于修复。

D4 甩锅错位违反 P1B：search agent 在它被分配的范围内工作正常——它被要求查 "NHTSA rulemaking timeline"，它查了。问题是任务本身，不是执行任务的 agent。

D3 治标不治本违反 P1C：把数量当质量。八个同样局限在美国联邦维度的子题，仍然覆盖不到音乐、写作意义上的「其他维度」——分解逻辑没变，加倍只是把同一个盲区查得更细。「并行不增加墙钟时间」这半句成立，但它掩盖了另一半：token 成本按 subagent 数量线性上涨，买到的却是同一片盲区的更高分辨率。

ch03 · Q4 · 准则 P5

Your coordinator's prompt reads: "Step 1: call search_agent with the user's topic. Step 2: pass the top 5 results to analysis_agent. Step 3: call synthesis_agent with the analysis. Step 4: call report_agent." Users report that simple factual queries take as long as deep research questions, and that when a topic has an authoritative survey paper the system still spends effort on scattered secondary sources. What should change?

正确 ATS 1.3 明确要求 coordinator prompt 写目标与质量准则而非逐步过程指令，理由正是保留 subagent 的适应性；TS 1.2 配套要求 coordinator 分析查询需求并动态选择调用哪些 subagent，而不是永远走完整流水线。题干的两个症状（简单查询也走满流程、有权威综述时仍散查）正是脚本化 prompt 的直接后果。

D3 治标不治本违反 P1B：用字符数当复杂度代理，是把一个语义判断降级成了一个表面特征——短查询完全可以很难。而且它保留了脚本，只是加了一条硬编码捷径。

D3 治标不治本违反 P1C：调参没有碰到根因。流水线仍然对所有查询一视同仁，20 条结果反而让简单查询更慢、更占 context。

D5 吞错或炸链违反 P6D：让 subagent 自行决定是否终止流水线，既破坏了 hub-and-spoke（编排决策必须留在 coordinator，TS 1.2），又制造了新的静默失败面——某个 subagent 判断「够了」就截断，coordinator 无从知晓覆盖是否完整。

ch03 · Q5 · 准则 P6

Two subagents are assigned the subtopics "battery supply chain risks" and "raw material sourcing constraints." Reviewing output, you find roughly 60% of their findings are the same articles summarized twice, while adjacent areas (recycling economics, refining capacity) appear nowhere. What is the correct fix?

正确 BTS 1.2 直接点名这条 skill：跨 subagent 划分研究范围以最小化重复（分配互不相同的子主题或来源类型）。题干的两个症状是同一个分解缺陷的两面——重叠 60% 说明切分不互斥，邻近领域全空说明切分不完备。修分解，不是修下游。

D3 治标不治本违反 P1A：去重只是把浪费藏起来——两个 subagent 的调用成本已经花掉了，而且「recycling economics 没人查」这半个问题完全没被触及。

D1 凭空捏造违反 P1C：subagent 之间交换在途结果违背 hub-and-spoke——所有跨 subagent 通信必须经 coordinator（TS 1.2），横向通道并不存在。而且 subagent 上下文隔离，没有可以互相订阅的共享状态。

D2 过度工程违反 P5D：为了解决一个分解问题，牺牲掉本可并行的两个独立任务（TS 1.3 的单响应多 Task 并行），把延迟翻倍；exclusion list 还会随范围增长而膨胀。

ch03 · Q6 · 准则 P1

You add a new fact_check_agent and configure the coordinator to delegate verification to it. At runtime the coordinator never delegates; instead it answers verification questions itself, sometimes incorrectly. The fact_check_agent's AgentDefinition has a clear description and its own tools. What should you check first?

正确 DTS 1.3 的硬性配置要求：subagent 通过 Task tool 启动，coordinator 的 allowedTools 必须包含 "Task" 才能调用 subagent。症状与之完全吻合——coordinator 不是「选错了 subagent」，而是一个都没派，只好自己硬答。缺能力时先查能力配置。

D4 甩锅错位违反 P1A：描述区分度影响的是在多个候选中选错。这里 coordinator 一次都没有委派，问题在委派机制不存在，不在候选难分辨。

D1 凭空捏造违反 P1B：编了一个不存在的行为——模型不会为了省 token 而主动放弃工具调用。而且题干没有任何 context 压力的证据。

D4 甩锅错位违反 P1C：subagent 的工具是否够用，只有在它被调用之后才成为问题。这是在一个从未执行过的组件里找 bug。

当前产品里这个工具叫 Agent（system:init 列表仍显示 "Task"），且 allowedTools 只让所列工具免确认、不决定工具是否可用。本题按考纲作答，详见 ch03 的说明。来源：Subagents in the SDK · Detect subagent invocation；Configure permissions · Allow and deny rules，查阅于 2026-10-16。

ch03 · Q7 · 准则 P5

Your team has completed a shared codebase analysis session and now wants to evaluate two competing refactoring strategies against that same baseline, comparing the results side by side. Which session mechanism fits?

正确 ATS 1.3 / TS 1.7：fork_session 的定义用途就是从共享的分析基线创建独立分支以探索分歧方案（guide 的原例正是「比较两种测试策略或重构方案」）。两个分支共享基线、互不污染，正是并排比较所需。

D3 治标不治本违反 P5B：--resume 续接的是同一条会话线。在同一会话里先后评估两个方案，第二个方案的分析会被第一个方案的推理污染——这正是 fork 要解决的问题。

D2 过度工程违反 P2C：重跑两遍分析把成本翻倍，而且两次分析结果未必一致——「同一基线」这个前提反而被破坏了。现成的 fork 机制没用就先造轮子。

D2 过度工程违反 P7D：把两个方案压进同一个上下文里互相比较，既浪费了并行，又让两条推理线在同一个注意力预算里竞争——正是 P7 的注意力稀释场景。scratchpad 的正确用途是跨上下文边界持久化发现（TS 5.4），不是替代 fork。