Coordinator-Subagent 的多 Agent 協調模式

Multi-Agent Orchestration 與 Coordinator-Subagent 模式是 CCA-F Domain 1（Agentic 架構與 Orchestration，佔比 27%）的核心，也是 Claude Certified Architect Foundations 考試中測驗頻率最高的設計模式。任務說明 1.2——「以 coordinator-subagent 模式 orchestrate 多 agent 系統」——直接出現在 Multi-Agent Research System 情境叢集，其概念也滲透到每個包含超過一個邏輯步驟的工作流程場景。若你誤解 coordinator 如何委派任務、context 在 coordinator 與 subagent 之間如何流動（或無法流動），以及並行 Task 呼叫如何合併結果，每次考試至少會因此丟掉三道題。

這份學習筆記涵蓋 CCA-F 考生需要具備推理能力的完整範圍：hub-and-spoke 的架構形狀、subagent 隔離 context 的保證、coordinator 在分解與合成上的職責、Task tool 與 AgentDefinition 的作用範疇、並行與循序的派送策略、迭代精煉迴圈，以及 coordinator 過度細化分解、導致跨切面訊號遺失這個高頻失敗模式。每個章節都對應到 Multi-Agent Research System 情境及其最常考的考試陷阱。

在 Claude 中，Multi-Agent Orchestration 是什麼

Multi-Agent Orchestration 與 Coordinator-Subagent 模式是一種架構方法：將複雜任務拆分給兩個或多個 Claude agent 實例——一個擁有頂層目標的 coordinator，以及一個或多個各自負責較窄範疇的 subagent。Coordinator 不親自執行 subagent 的工作，而是負責規劃、派送與合成；subagent 負責執行。這樣的分工存在是因為單一 Claude context window 容量有限，而單一線性對話無法有效地並行化或隔離不同的探索路徑。

在考試中，multi-agent orchestration 從來不以抽象的架構圖形式出現，而總是透過具體情境——最常見的是 Multi-Agent Research System 情境——來測驗：coordinator 必須回答一個複合式研究問題，方法是派送數個 subagent 分別在隔離環境中調查不同的子問題，再將結果整合成一份合成答案。考試獎勵理解委派機制細節的考生：subagent 如何被創建、它們繼承哪些 context（以及不繼承哪些）、結果如何回傳，以及 coordinator 對這些結果負有什麼義務。

為什麼要 Multi-Agent，而不是一個大 Prompt？

只建過單一 session agent 的考生常問：既然可以用一個 Claude 實例做所有事，為何要引入協調的額外開銷？有四個結構性原因驅動 multi-agent 設計，全都會在考試情境中浮現。

• Context 隔離。 走進死胡同的 subagent 不會用無關的工具結果污染 coordinator 的 context。
• 並行性。 互相獨立的子任務可以同時派送，降低整體執行時間。
• 專業化。 Subagent 可以被賦予比通用 coordinator 更窄的 allowedTools 清單和更聚焦的系統提示。
• 規模。 原本會超出單一 context window 的研究任務，在每個 subagent 只消耗與其子問題相關的片段時，就變得可處理。

Multi-Agent Research System 情境在一個複合問題中同時演練以上四個原因，因此徹底內化它們能快速帶來回報。

Hub-and-Spoke：Coordinator-Subagent 的標準形狀

Hub-and-spoke 模式是 CCA-F 考試預設的架構形狀。理解其幾何結構與限制，是掌握本主題其他所有概念的前提。

Hub（樞紐）

Hub 是 coordinator agent。它持有完整的原始使用者請求、從中推導出的計畫、待完成與已完成子任務的清單，以及目前為止已彙整的結果。Hub 的 context window 持有任務狀態的權威版本。只有 hub 與終端使用者溝通。

Spoke（輻條）

每個 spoke 是一次 subagent 調用。Spoke 接收一份範疇明確的任務說明，執行自己的 agentic loop（工具使用、思考、tool result、再次工具使用），直到達到終止 stop_reason，再將最終訊息以結構化結果的形式回傳給 hub。Spoke 不與其他 spoke 溝通。Spoke 看不到其他 spoke 的 context。Spoke 看不到 hub 的 context，除了 coordinator 明確傳入的任務說明之外。

為什麼選 Hub-and-Spoke 而非 Mesh？

CCA-F 考試持續偏好 hub-and-spoke 而非點對點或 mesh 設計，因為 mesh 拓撲會放大三種失敗模式：

• Context 污染。 直接傳遞 context 的 peer agent 可能繼承彼此的死胡同。
• 協調模糊性。 當每個 agent 都能和其他 agent 溝通時，誰負責合成最終答案？
• 錯誤歸因困難。 在 mesh 中，當 subagent 回傳錯誤答案時，追蹤是哪個上游 peer 污染了它幾乎不可能。

Hub-and-spoke 將合成職責集中在一個地方（coordinator），並將每個 subagent 的失敗模式限制在自己的 spoke 之內。

Hub-and-Spoke 在 Multi-Agent Research System 情境中的實例

考試演練的一個具體情境：使用者要求研究 coordinator「比較 Kubernetes、Terraform 和 Redis 過去十年的開源授權策略，並總結對廠商永續性風險的影響」。單一 Claude 實例會在探索三個專案時耗盡 context，無法產出連貫的比較。Coordinator 改為：

1. 分解為三個子問題——每個專案一個——再加上第四個「跨專案合成」子任務。
2. 並行派送三個 subagent，每個負責一個專案的窄範疇說明。
3. 等待三個 subagent 的結果全部回傳。
4. 執行第四個 subagent（或自行完成），合成跨切面的模式。
5. 回傳一份連貫的答案給使用者。

考試就是以這個形狀來測驗，並獎勵能在每個步驟辨識出 coordinator 職責的考生。

Coordinator 的職責

Coordinator 不是「聰明的那個」而 subagent 是「笨的那個」——它們都執行相同的 Claude 模型。Coordinator 的角色是結構性的，而非認知性的。它有七項明確的職責。

職責一：分解

Coordinator 將原始使用者請求轉化為計畫——一份子任務清單，每項子任務的細節足以讓單一 subagent 執行，而無需在執行中途釐清意圖。好的分解產出的子任務是：互相獨立的（一個子任務的結果不阻塞另一個子任務的執行）、有明確範疇的（每個子任務有清楚的完成定義）、不重疊的（沒有兩個子任務回傳相同的事實）。

職責二：撰寫任務說明（Brief）

對每個子任務，coordinator 撰寫一份 subagent brief——等同於初始化 subagent 對話的使用者輪次。Brief 必須自給自足，因為 subagent 看不到 coordinator 的 context。撰寫 brief 是 coordinator 執行的最高槓桿活動，也是考試在任務說明 1.3（設定 subagent 調用、context 傳遞與創建）下最積極測驗的技能。

職責三：派送

Coordinator 為每個 subagent 調用一次 Task tool（或 SDK 等效方法）：當子任務互相獨立時並行派送，當下游子任務依賴上游結果時循序派送。派送不是「呼叫後不管」——coordinator 持有哪些 spoke 正在執行、哪些已回傳的心智地圖。

職責四：彙整

隨著 subagent 結果回傳，coordinator 加以彙整。彙整不等於合成。彙整是將結構化輸出收集到 coordinator 的 context 中，並保留是哪個 subagent 產出哪項主張的對應關係。考試在 Domain 5.6（資訊來源溯源）下測驗這點——失去哪個 subagent 說了什麼的追蹤能力的 coordinator，無法對相互矛盾的主張進行推理。

職責五：合成

所有必要的 subagent 結果到齊後，coordinator 將它們合成為一份回答原始使用者請求的單一答案。合成可能需要交叉參照結果（「Subagent A 說 X，Subagent B 說 Y——這兩者一致嗎？」）、解決衝突，或識別需要後續派送的缺口。

職責六：錯誤處理與重試

當 subagent 回傳結構化錯誤或模糊的部分結果時，coordinator 決定是否以精煉後的 brief 重試、以不同方法派送新 subagent，或升級回報給使用者。這就是下文獨立章節涵蓋的迭代精煉迴圈。

職責七：最終回應

Coordinator 是給終端使用者的最終訊息的唯一作者。Subagent 絕不直接與使用者溝通。正因為這個限制，subagent 的 context 隔離才可以接受——coordinator 掌握完整的全局，即使個別 subagent 並不知道。

Subagent 隔離 Context：最常被測驗的機制

Subagent 隔離 context 是 CCA-F 中最常被只研究過單一 agent 工具使用的考生搞錯的概念。考試大量反覆強調這一點，因為正確的心智模型對習慣 context 自然累積的多輪對話建置者來說反直覺。

「隔離」實際上意味著什麼

當 coordinator 透過 Task tool 派送 subagent 時，subagent 以全新對話開始。Subagent 看不到：

• 發起 coordinator 對話的原始使用者訊息。
• Coordinator 的系統提示（除非 subagent 繼承或被賦予自己的系統提示）。
• 任何其他 subagent 的 brief 或結果。
• Coordinator 已執行的任何工具呼叫。
• Coordinator 對話中的任何先前輪次。

Subagent 只看到兩樣東西：為其 agent 類型設定的 AgentDefinition（系統提示、工具、模型），以及 coordinator 在 Task tool 呼叫中傳入的任務說明。

為什麼隔離是特性，而非缺陷

隔離使 multi-agent orchestration 能夠擴展。如果每個 subagent 都繼承 coordinator 的完整歷史，每個 subagent 的 context window 一開始就幾乎用盡，沒有空間實際執行工作。隔離也防止嘈雜的 coordinator context 影響 subagent 的推理。隔離更是讓 coordinator 能並行派送多個 subagent 而其 context 不互相碰撞的根本原因。

陷阱：假設 Context 會向下流動

最高頻率的 CCA-F 陷阱是假設 subagent「知道 coordinator 知道的事」。考生建構的情境是：coordinator 在第三輪學到某件事，然後在第五輪派送一個 subagent，卻沒有在 subagent brief 中重新傳入第三輪的資訊。Subagent 在隔離的 context 下運作，無法存取第三輪的知識，要嘛在缺口周圍產生幻覺，要嘛詢問使用者無法回答的問題。

正確的模式是：subagent 需要的一切都必須放在 brief 中。如果 coordinator 從較早的工具呼叫中學到了關鍵事實，那個事實必須在 subagent 的任務說明中重新陳述。Brief 是完整的、具權威性的輸入。

與 fork_session 的對比

Agent SDK 確實提供了 fork_session 功能，但它是具有不同語義的獨立機制。Forked session 會複製完整的對話（包含歷史記錄），讓對話的一個分支可以探索替代路徑而不提交。Fork 不等於 subagent 創建。被創建的 subagent 是隔離的；forked session 是一份副本。考試明確測驗這個區別，並懲罰混淆兩者的考生。

Task Tool：派送的機制

Task tool 是 coordinator 創建 subagent 的主要介面。理解其參數與回傳形狀，是本主題每個情境的必備知識。

Task Tool 的作用

當 coordinator 呼叫 Task 時，Claude Code 執行環境（或 Agent SDK）啟動一個新的 subagent session，讓該 subagent 跑完自己的 agentic loop 直到達到終止 stop_reason，再將 subagent 的最終 assistant 訊息以 tool result 的形式回傳給 coordinator。從 coordinator 的角度來看，Task 是一個碰巧需要長時間執行並回傳豐富結構化結果的單一工具呼叫。

Task Tool 的參數

考試期望你認識的常用參數：

• subagent_type（或 agent_type）——subagent 應以哪個 AgentDefinition 執行。這決定了系統提示、允許的工具，以及模型。
• description——任務的簡短標籤，用於日誌記錄和任務清單追蹤。
• prompt——完整的任務 brief，撰寫方式如同新對話中的第一個使用者輪次。

最常見的錯誤是 prompt 說明不足。考生寫出像「研究 Redis 的開源授權」這樣的 brief，卻期待 subagent 知道是哪幾年、哪些面向，以及使用什麼輸出格式。正確的 brief 明確包含所有這些 context，因為 subagent 無法自行推斷。

並行派送：在同一輪中發出多個 Task 呼叫

Coordinator 可以在單一 assistant 輪次中發出多個 Task 工具呼叫。這樣做時，執行環境會並行執行所有呼叫，並在下一個使用者輪次中一起回傳結果。這正是 Multi-Agent Research System 情境實現執行時間縮短的機制。

並行派送要求子任務真正獨立。如果 Subagent B 需要 Subagent A 的結果才能撰寫 brief，coordinator 必須先派送 A，等待 A 的回傳，再派送 B——兩個循序的輪次，而非一個並行的輪次。

AgentDefinition 與 allowedTools

每個 subagent 在一個 AgentDefinition 下執行——這個設定物件指定了 subagent 的系統提示、其 allowedTools 清單，以及可選的模型。allowedTools 清單是刻意的限制：研究型 subagent 可以被賦予 WebSearch、WebFetch 和 Read，但沒有 Write 或 Bash。縮減工具範疇降低了 subagent 的攻擊面，聚焦其注意力，並防止意外副作用傳播到其 spoke 之外。

考試在 Domain 2（工具設計）下測驗 allowedTools，並在涉及派送 subagent 執行敏感任務的情境中加以引用。給每個 subagent 完整工具清單的 coordinator 是常見的錯誤答案形狀。

任務分解策略

任務分解是 coordinator 在派送任何 subagent 之前執行的規劃活動。好的分解是 multi-agent 成功最重要的預測因子，CCA-F 考試在任務說明 1.6（為複雜工作流程設計任務分解策略）下大量演練它。

好子任務的標準

一個良構的子任務符合五個標準：

• 獨立。 它不需要另一個執行中子任務的輸出。
• 有範疇。 它有明確的完成定義，可以在 brief 中表達。
• 自給自足。 Brief 能攜帶所有必要的 context，而不超出合理長度。
• 不重疊。 沒有其他子任務產出相同的事實。
• 可驗證。 Coordinator 可以對照 brief 核查回傳的結果，而不必重新執行子任務。

分解模式

三種分解模式涵蓋了考試中幾乎所有的 multi-agent 情境。

• 按實體。 每個調查中的不同實體一個 subagent。授權比較情境使用這種方式——每個專案一個 subagent。
• 按面向。 每個分析維度一個 subagent。安全審查可能派送一個 subagent 負責驗證、一個負責授權、一個負責輸入驗證。
• 按階段。 每個管線階段一個 subagent，循序派送。研究管線可能先派送「蒐集來源」subagent，再派送「擷取主張」subagent，再派送「交叉比對主張」subagent。

按實體和按面向的分解自然地並行化。按階段的分解本質上是循序的。

過度細化分解的風險

最隱患的分解失敗是過度細化分解：將任務拆分成太多微小子任務，導致每個 subagent 缺乏察覺跨切面模式所需的 context。當每個 subagent 回傳看起來正確的窄片段答案，但合成步驟無法恢復原始問題實際詢問的更廣泛模式時，coordinator 分解得太激進了。

一個常見的考試陷阱：情境呈現 coordinator 將「比較三個專案的授權策略」拆分成十二個子任務（每年每專案各一個），而非三個（每專案一個）。按年的子任務各自回傳合理的事實，但沒有任何 subagent 曾有足夠的 context 去注意到專案 A 的授權策略是為了回應專案 B 更早期的變化而調整的。這個模式在按年的粒度下是不可見的，只在按專案的粒度下才會浮現。

分解 vs Chaining

任務分解（multi-agent）有別於 prompt chaining（單一 agent）。Prompt chaining 讓一個 Claude session 在單一 context 內跑過多個循序的提示。分解則跨多個隔離的 Claude session 拆分任務。Chaining 保留 context；分解捨棄 context。考試測驗何時該用哪種方法。

並行 Task 呼叫與迭代精煉迴圈

並行派送是 multi-agent orchestration 的機械面。迭代精煉是時間面——coordinator 如何跨多個輪次使用 subagent 結果來改善最終答案。

並行派送的機制

在單一 assistant 輪次中，coordinator 可以發出多個 Task 工具呼叫。執行環境同時對所有呼叫進行 fan-out 執行。當每個並行 subagent 都達到終止 stop_reason 後，執行環境在下一個使用者輪次中將所有結果一起以並行 tool result 區塊的形式回傳。Coordinator 隨後一次讀取所有結果。

當子任務真正獨立時，並行派送效益最佳。當子任務有依賴關係時，它退化為循序——因為 coordinator 必須等待一個結果才能撰寫下一份 brief。

迭代精煉迴圈

在真實的研究工作流程中，第一輪 subagent 結果很少就是最終答案。Coordinator 往往需要迭代：

1. 規劃——將任務分解為初始子任務。
2. 派送——發出並行的 Task 呼叫。
3. 彙整——收集結果。
4. 評估——確認彙整後的結果是否回答了原始問題。
5. 精煉——若有缺口，以精煉後的 brief 派送後續 subagent，明確引用第四步中發現的缺口。
6. 合成——一旦 coordinator 判斷證據充分，撰寫最終答案。

這個迴圈可以執行多次迭代。每次迭代產出的 brief 更有針對性，因為 coordinator 對早期輪次遺漏了什麼有更多了解。考試在任務說明 3.5（應用迭代精煉技術以逐步改善）下測驗這個迴圈，而 Multi-Agent Research System 情境是標準的演練載體。

何時停止迭代

永不停止迭代的 coordinator 會在追求邊際報酬的過程中耗盡其 context window。Coordinator 必須有停止標準：覆蓋率標準（「每個子問題至少有一個 subagent 結果回答」）或預算標準（「最多兩輪精煉」）。考試情境常常間接測驗停止標準——提議無界限迭代的答案選項通常是錯的。

Coordinator 與 Subagent 之間的 Context 傳遞

由於 subagent 的 context 隔離是預設行為，context 傳遞是 coordinator 刻意將特定資訊穿過隔離邊界的機制。Context 傳遞完全透過 Task tool 的 prompt 參數進行——沒有隱式管道。

應傳遞的內容

每份 subagent brief 至少應包含：

• 子任務目標。 以具體、可驗證的結果措辭表達。
• 範疇邊界。 Subagent 不應延伸到哪些範圍。
• 輸出格式。 Coordinator 可以解析的結構化、類 schema 的預期。
• Subagent 無法獨立重新發現的相關事實。 Coordinator 在較早輪次中學到的事實。
• 允許的工具及其預期用途。 若 subagent 有窄工具清單，brief 應提示何時使用各工具較為合適。

不應傳遞的內容

Brief 不應包含：

• 完整的原始使用者請求（除非直接需要）。重新傳入整個使用者對話違背了分解的目的。
• 其他 subagent 的結果（除非有真實的依賴關係）。交叉污染 subagent 侵蝕了並行性的好處。
• Coordinator 的內部計畫。 Subagent 不應對分解本身產生二次猜測。

輸出格式紀律

當每個 subagent 以可預期的形式回傳結果時，coordinator 的彙整步驟最容易執行。Brief 應明確指定輸出格式：「回傳一個包含 license_changes、timeline 和 sustainability_signals 欄位的 JSON 物件。」當 subagent 回傳自由格式的散文時，coordinator 要花費其 context 預算解析散文，而非合成結論。

錯誤傳播與復原

Subagent 會失敗。Coordinator 必須處理這些失敗。CCA-F 在任務說明 5.3 下測驗 multi-agent 系統中的錯誤處理。

失敗模式

考試情境中常見的三種 subagent 失敗模式：

• 工具層級錯誤。 Subagent 的工具呼叫失敗（網路逾時、權限被拒、格式錯誤的回應）。Subagent 應回傳描述失敗原因的結構化錯誤。
• 任務層級失敗。 Subagent 跑完迴圈但無法產出所要求的輸出（資訊不可得、請求模糊、範疇定義不清）。
• stop_reason 不符預期。 Subagent 在完成前觸及 max_tokens 或 stop_sequences，回傳部分結果。

結構化錯誤回應

當 subagent 回傳錯誤時，應以 coordinator 能推理的結構化形式回傳——錯誤類別、可重試旗標、人類可讀的詳細說明。收到通用錯誤字串的 coordinator 必須猜測是否要重試、升級，或中止。收到 { errorCategory: "transient", isRetryable: true, detail: "WebSearch timed out" } 的 coordinator 則可以確定地進行重試。這連結到 Domain 2.2（結構化錯誤回應），在考試中頻繁出現。

Coordinator 的復原策略

面對 subagent 失敗，coordinator 有四個選項：

1. 以相同 brief 重試——當錯誤是暫時性的。
2. 以精煉後的 brief 重試——當錯誤表明 brief 模糊或說明不足。
3. 派送不同的 subagent——當失敗表明 subagent 類型或允許的工具是錯的。
4. 帶有明確缺口的部分合成——當復原代價過高，而使用者能從誠實的部分答案中獲得更多時。

考試情境常測驗第四個選項——預設「繼續重試」的考生會錯過有時正確答案是接受不完整結果的題目。

白話文解釋 Multi-Agent Orchestration

Multi-agent orchestration 一旦錨定在我們日常熟悉的具體情境上，就會變得直觀。

類比一：總編輯、記者與獨立跑線

一家報社有一位總編輯和許多記者。總編輯接到一個複雜的報導任務：「跑完三個搖擺選區的選舉開票結果，說明對國會多數的意涵。」總編輯不親自去任何一個選區。取而代之，他寫了三份任務說明——每個選區一份——然後派出三位記者。每位記者在自己的選區獨立工作：北部記者不會去偷聽南部記者的採訪，反之亦然。記者們把稿子交回給總編輯。總編輯讀完三份，發現跨選區的共同模式（「三個選區都以相同方式翻盤」），然後寫出最後的頭版合成報導。

Coordinator-subagent 模式的每個元素都有對應：

• Coordinator = 總編輯。
• Subagent = 被派任的記者。
• Hub-and-spoke = 每位記者只向總編輯交稿，不向彼此交稿。
• Subagent 隔離 context = 北部記者只看到北部的任務說明。
• 任務 brief = 總編輯交給每位記者的採訪備忘。
• 並行派送 = 三位記者同時出發工作。
• 迭代精煉 = 總編輯讀完初稿，發現缺少某個角度，再派記者補採。
• 過度細化分解 = 將「跑選舉」拆成二十七個任務（每個鄉鎮一個），讓沒有任何一位記者看見選區層級的全貌。
• 合成 = 總編輯的最終版面。

類比二：辦桌總鋪師、各攤位與分工不交叉

辦桌宴席的廚房在緊張出菜時，跑著一套 hub-and-spoke 模式，只是換了個名字。總鋪師讀菜單，將一道道菜拆成工序，然後對各攤位下指令：蒸台負責紅蟳，滷桶負責白斬雞，冷盤組負責拼盤。每個攤位在自己的崗位獨立作業——蒸台師傅不會跑去攪拌滷桶。總鋪師從各攤位收齊所有完成的菜色後，親自擺盤出菜。

這個類比清楚說明了三個機制：

• 攤位專業化 = AgentDefinition 與 allowedTools。蒸台師傅有蒸籠，沒有滷桶。
• 並行執行 = 同一輪中的多個 Task 呼叫。紅蟳、滷雞和冷盤同時推進。
• 等齊才出菜 = 總鋪師等所有菜色備齊才擺盤。Coordinator 同樣等所有並行 subagent 回傳後才合成。

違反這個模式的廚房——讓蒸台師傅同時擺盤又對滷桶下令——只會帶來混亂。這就是 CCA-F 考試警告反對的 mesh 拓撲。

類比三：館長、館員與讀者問題

一位讀者向總館長問了一個複合問題：「我在寫一篇比較三位哲學家自由意志觀點的論文，應該讀哪些書？」總館長不可能親自熟悉館內每一本書。於是總館長派出三位專科館員——古典哲學館員、近代哲學館員、當代哲學館員——每位帶著各自的窄範疇任務說明。每位館員只在自己的專區搜尋並回傳一份精選書單。總館長將三份書單交叉對照後，交給讀者一份合成的參考書目。

圖書館的類比特別能說明 context 傳遞的必要性。當總館長派出當代哲學館員時，必須在任務說明中加入複合問題的 context——「讀者是要和兩位古代哲學家做比較」——因為當代館員看不到其他館員的工作，無法獨立發現這個交叉參照的需求。這正是「subagent 需要的一切都必須放在 brief 中」的規則。

考試當天選用哪個類比

• 關於 coordinator 職責與合成的題目 → 總編輯類比。
• 關於並行派送、工具隔離與專業化的題目 → 辦桌總鋪師類比。
• 關於 context 傳遞與分解粒度的題目 → 圖書館館長類比。

Agent Teams vs Subagents：兩個相關但不同的概念

Agent Teams（在 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 下發布的功能）與 subagent（通用的 Claude Code 和 Agent SDK 能力）之間存在一個微妙但會被考試測驗的區別。混淆兩者的考生會在情境細節上失分。

Subagents（通用模式）

Subagent 是本筆記全程描述的通用模式：coordinator 透過 Task tool 創建 subagent，subagent 在隔離環境中執行，subagent 回傳一個結果。Subagent 自最初的 Agent SDK 版本就已可用，並透過專案、使用者、外掛或 CLI 範疇的 AgentDefinition 設定來定義。

Agent Teams（Claude Code 功能）

Agent Teams 是 Claude Code 的功能，在 subagent 機制之上添加了結構化協調原語——隊友創建、任務清單追蹤，以及專屬的 hook（TeammateIdle、TaskCreated、TaskCompleted）。Agent Teams 是為 Claude Code 內的長時間多 session 協調而設計的，而非用於 Agent SDK 應用程式內的單次派送。

考試測驗的是哪一個

當情境描述「一個 Claude Code session 在數小時或數天內協調其他 Claude Code session」，考的是 Agent Teams。當情境描述「一個 Agent SDK 應用程式，其中 coordinator 派送研究任務」，考的是通用的 subagent。Hub-and-spoke 與隔離 context 的機制對兩者都適用。

Multi-Agent Orchestration 的常見考試陷阱

與 Multi-Agent Orchestration 與 Coordinator-Subagent 模式相關的 CCA-F 情境中，反覆出現五種陷阱模式。

陷阱一：假設 Subagent 繼承 Coordinator Context

最頻繁的陷阱。答案選項隱式假設 subagent 知道 coordinator 知道的事。正確答案總是要求透過 brief 明確傳遞 context。如果某個答案說「subagent 將自動看到先前的對話」，那就是錯的。

陷阱二：過度細化分解

在其自己的 callout 中已涵蓋。情境呈現許多小任務的分解並詢問為何合成結果淺薄。錯誤答案怪罪 coordinator 的模型；正確答案識別出分解的粒度問題。

陷阱三：以 Mesh 拓撲作為合理的預設值

答案選項提出點對點 subagent 通訊作為設計。Hub-and-spoke 是 Claude 建議的預設；mesh 很少是正確答案，只有在情境明確要求 peer 協調時才可能勝出（而在 CCA-F 的範疇內，這幾乎不會出現）。

陷阱四：無界限的迭代精煉

答案選項提議「繼續派送後續 subagent，直到答案完美為止」。真實的工作流程必須有停止標準。描述無界限迭代的選項通常是錯的。

陷阱五：將 fork_session 與 Subagent 派送混淆

答案選項將 fork_session 和 Task 互換使用。它們是不同的機制——fork 複製 context，派送創建全新的隔離 context。如果情境需要隔離，答案是 Task（創建 subagent）。如果情境需要探索當前對話的替代分支，答案是 fork_session。

練習錨點：Multi-Agent Research System 情境題型模板

與 Multi-Agent Orchestration 與 Coordinator-Subagent 模式相關的 CCA-F 練習題，歸納為五種題型。每種題型都清楚地對應到 Multi-Agent Research System 情境。

模板 A：Context 隔離辨識

Coordinator agent 在第三輪得知使用者的公司在歐盟運營且有嚴格的 GDPR 要求。在第五輪，coordinator 派送一個 subagent 研究可用的廠商 API。Subagent 回傳了一份廠商清單，其中有些是僅限美國的。最可能的根本原因是什麼？正確答案：coordinator 沒有在 subagent brief 中傳入歐盟/GDPR 限制，而 subagent 的隔離 context 意味著它無法獨立得知這個限制。

模板 B：分解粒度選擇

研究 coordinator 必須比較三個開源專案過去十年的情況。哪種分解能產生最好的跨專案合成？正確答案：三個 subagent，每個專案一個。錯誤答案包括三十個 subagent（每年每專案一個——過度細化）和單一整體 subagent（分解不足，耗盡 context）。

模板 C：並行 vs 循序派送

子任務 B 需要子任務 A 的輸出。Coordinator 應如何派送它們？正確答案：在一個輪次中執行任務 A，等待結果，再在後續輪次執行任務 B。在單一輪次中並行派送兩者的答案是錯的，因為 B 的 brief 尚未包含 A 的結果。

模板 D：從 Subagent 失敗復原

Subagent 回傳 { errorCategory: "transient", isRetryable: true }。Coordinator 應該怎麼做？正確答案：以相同 brief 重試。如果錯誤是 { errorCategory: "permission", isRetryable: false }，正確答案則轉為派送具有調整過的 allowedTools 的不同 subagent，或升級回報。

模板 E：Task vs fork_session 選擇

Coordinator 想探索當前研究問題的替代措辭，同時保留恢復到當前狀態的能力。應使用哪種機制？正確答案：fork_session，因為目標是分支當前對話，而非派送隔離的子任務。

關鍵數字與模式速記

Multi-Agent Orchestration 常見問題（FAQ）

Claude 中的 coordinator 和 subagent 有什麼差異？

它們執行相同的模型。差異在於結構，而非認知能力。Coordinator 擁有原始使用者請求，執行分解，透過 Task tool 派送 subagent，彙整回傳的結果，並撰寫最終答案。Subagent 對著較窄的任務說明執行隔離的 agentic loop，並回傳一個結構化結果給 coordinator。Subagent 從不與終端使用者溝通，也從不互相溝通。Coordinator 是端到端狀態的唯一擁有者，也是最終回應的唯一作者。

Subagent 會繼承 coordinator 的對話歷史嗎？

不會。這是 CCA-F 最常被測驗的機制。Subagent 以全新對話開始，只由其 AgentDefinition（系統提示、工具、模型）和 coordinator 在 Task tool 呼叫中傳入的任務說明提供種子資料。Coordinator 的先前輪次、原始使用者訊息，以及其他 subagent 的結果對 subagent 來說都是不可見的。Subagent 需要的一切都必須在其 brief 中明確重新陳述。假設 context 沿著 hub-and-spoke 層級向下流動的考生，設計出的是有缺陷的系統，也會在考試中失分。

我何時應並行派送 subagent，何時循序派送？

當子任務真正獨立時並行派送——任何一個子任務的 brief 都不需要另一個子任務的輸出。在單一 assistant 輪次中發出多個 Task 工具呼叫，執行環境會同時 fan-out 執行。當下游子任務的 brief 依賴上游結果時循序派送——在一個輪次中呼叫第一個 Task，等待回傳，再在後續輪次呼叫第二個 Task。大多數 Multi-Agent Research System 情境對初始分解使用並行派送，對任何精煉輪次使用循序派送。

Task tool 和 fork_session 有什麼差異？

Task 創建一個全新、隔離的 subagent session，沒有任何歷史記錄——這是 hub-and-spoke 的派送機制。fork_session 複製當前 session，讓一個分支可以探索替代路徑而不提交，必要時可恢復到 fork 前的狀態。兩者不可互換。當你需要隔離和並行性時使用 Task。當你需要探索當前對話的假設情境並保留回退能力時使用 fork_session。CCA-F 考試直接測驗這個區別。

CCA-F 考試為何偏好 hub-and-spoke 而非 mesh 拓撲？

Mesh 拓撲——subagent 之間點對點溝通——放大了三種失敗模式：peer 之間的 context 污染、誰負責最終合成的協調模糊性，以及出錯時的錯誤歸因困難。Hub-and-spoke 將合成職責集中在一個地方（coordinator），並將每個 subagent 的失敗模式限制在自己的 spoke 之內。Claude 的 Agent SDK 和 Agent Teams 文件都建議以 hub-and-spoke 作為預設。提議 mesh 拓撲的答案選項在考試中幾乎總是錯的。

如果分解任務的粒度太細會發生什麼事？

過度細化分解產生許多小子任務，各自回傳看起來正確的窄片段答案，但沒有任何單一 subagent 曾持有足夠的 context 來察覺跨切面的模式。Coordinator 的合成步驟因此產生淺薄的最終答案，因為證據從未捕捉到更廣泛的模式。解方是粗化分解粒度，讓每個 subagent 持有足夠的 context 來看見其片段內的模式。過度細化分解是常見的 CCA-F 陷阱，因為考生從整體提示的失敗中矯枉過正，結果陷入相反的失敗模式。

Coordinator 應執行幾輪精煉？

實用的預設值是兩輪：第一輪涵蓋初始分解，第二輪解決第一輪合成時識別出的缺口。若第二輪仍有缺口，改回傳一份誠實指出剩餘不確定性的部分答案，而非派送第三輪。無界限的精煉會耗盡 coordinator 的 context window，往往帶來邊際報酬遞減。CCA-F 情境中以「持續迭代直到完美」作為答案選項的題目，正是在測驗你是否認識到停止標準的必要性。

延伸閱讀

• Orchestrate teams of Claude Code sessions (Agent Teams): https://code.claude.com/docs/en/agent-teams
• Create custom subagents — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/sub-agents
• Subagents in the Agent SDK: https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• Agent SDK overview: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-overview
• Tool use with Claude — overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Chain complex prompts for stronger performance: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/chain-prompts
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents

Related ExamHub topics: Agentic Loop 與自主任務執行, Subagent 調用與 Context 傳遞, 任務分解策略, Session 狀態、恢復與 Forking, Multi-Agent 系統中的錯誤傳播.