Subagent 呼叫、Context 傳遞與 Spawning

Subagent 呼叫、context passing 與 spawning 是 Claude Certified Architect — Foundations（CCA-F）考試中架構密度最高的任務說明。任務 1.3 位於 Domain 1（Agentic 架構與 Orchestration，佔比 27%，全場最重）的核心，直接決定考生能否設計「多 agent 研究系統」和「開發者生產力與 Claude」兩大情境——這兩個情境最直接地考驗你對一個 agent 如何 spawn 另一個 agent、哪些 context 會跨越這條邊界傳遞，以及子代繼承或被拒用哪些工具的理解。

這份學習筆記以 CCA-F 要求的深度完整說明 subagent 呼叫、context passing 與 spawning：Task tool 作為具體的 spawning 機制、宣告 subagent 的 AgentDefinition 結構、限定子代可用工具範圍的 allowedTools 白名單、subagent 不會自動繼承 coordinator context 的硬規則、用於分岔探索的 fork_session 語義、單一 coordinator 回應中的並行 Task 呼叫，以及讓多 agent 系統可除錯的結構化元資料分離模式。每個章節都錨定在 Anthropic 官方文件，以及考試所引用的六大情境叢集。最後的白話文類比將所有內容整合成在 120 分鐘、60 題的實際考試壓力下可快速提取的記憶框架。

什麼是 Subagent 呼叫？Spawn 子代 Agent 的機制

Subagent 呼叫、context passing 與 spawning 涵蓋三個截然不同卻緊密耦合的責任。「呼叫（Invocation）」是要求一個正在執行的 agent 將一段工作移交給新的 agent 實例的動作。「context passing」是決定哪些資訊隨著這次移交一起傳遞的紀律。「spawning」是在執行期建立子代 agent——擁有其自身獨立的對話歷史、自身的工具白名單、自身的迴圈——的事件。

在 Claude Agent SDK 中，主要的呼叫介面是 Task tool。當 coordinator agent 呼叫 Task 時，SDK 會以 coordinator 提供的 prompt 實例化一個全新的 agent session，並連結到特定的 AgentDefinition（宣告 subagent 的系統提示、工具白名單，以及可選的 model 覆寫），然後執行其自身獨立的 agentic loop，直到產出最終結果。該結果以 tool_result 訊息的形式回傳到 coordinator 的迴圈中，coordinator 隨即以這個結果為輸入繼續執行。

這個 subagent 呼叫、context passing 與 spawning 模型和單純的 prompt chain 有本質上的差異：coordinator 並不是簡單地拼接一條後續 user 訊息並繼續自己的對話，而是將執行 分岔 到由子代 agent 擁有的獨立 context window 中。子代所知道的一切，都必須透過 Task prompt 或預先登錄的 AgentDefinition 系統提示來明確告知。

為什麼架構師需要這套詞彙

社群的考試通過報告與 CCA-F 考試指南，都將「subagent context 隔離」列為前三大常見誤解。假設 context 沿著階層向下流動——就像語言執行環境中的堆疊框架繼承變數那樣——的考生，會設計出有缺陷的多 agent 系統，並在「subagent 啟動時知道什麼？」的情境題上選錯答案。答案是：只有 AgentDefinition 系統提示所宣告的內容，加上 Task tool 的 prompt 參數所明確傳入的內容。僅此而已。

Task Tool 作為主要的 Spawning 機制

Task tool 是將 coordinator-subagent 架構從圖表變成執行時期現實的具體動詞。CCA-F 考生必須認識它作為 spawning 機制的角色——不是通用工具，不是自訂的 MCP 工具——並理解這個角色的含義。

Task Tool 呼叫的結構

一個來自 coordinator 的典型 Task tool 呼叫包含三個關鍵參數：

• subagent_type — 一個字串識別碼，對應到一個已登錄的 AgentDefinition。在 Claude Code agent teams 中常見的值包括 researcher、critic、planner、coder，或任何登錄在 .claude/agents/ 下的自訂名稱。
• description — 簡短、易讀的標籤，用於日誌、追蹤和介面顯示。不會被 subagent 本身讀取。
• prompt — subagent 將作為開頭 user 訊息接收的完整指令內容。subagent 在當前任務中需要知道的所有事情，都必須在這裡或 subagent 的系統提示中提供。

在底層，SDK 接收這三個輸入後，以對應的 AgentDefinition 建構一個全新的 session，將 prompt 作為第一條 user 訊息送入，並執行子代的 agentic loop。當子代到達 stop_reason: end_turn 時，其最終訊息內容會被捕捉，並以 coordinator 訊息歷史中 Task 呼叫的 tool_result 形式回傳。

Task 必須被明確允許

Task tool 本身是 SDK 提供的工具，與 Read、Write、Edit、Bash、Grep 以及自訂 MCP 工具位於同一個 allowedTools 層面。若 AgentDefinition 的 allowedTools 清單中未包含 "Task"，該 agent 就完全無法 spawn subagent。這是一個常見的考試陷阱：考生以為 coordinator 天生具有 subagent spawning 的能力，但實際上 spawning 能力需要透過與其他工具完全相同的明確白名單機制來授予。

Task Tool vs MCP Tools vs 內建檔案工具

三種截然不同的工具類別可以同時出現在單一 agent 的 allowedTools 中，CCA-F 會測試你區分它們的能力：

• Task tool — spawn subagent；由 Agent SDK 執行期提供。非使用者撰寫。
• 內建工具 — Read、Write、Edit、Bash、Grep、Glob。由 Claude Code 提供；操作本地工作區。
• MCP 工具 — 透過 Model Context Protocol 伺服器暴露的使用者登錄工具。操作伺服器所包裝的外部能力（GitHub、Slack、資料庫等）。

Task tool 不是自訂的 MCP 工具，無法由 MCP 伺服器重新實作，也無法重新命名。任何把 Task 與「你自己撰寫的工具」混為一談的答案選項都是錯的。

AgentDefinition — Subagent 的宣告式結構

每個 Task tool 能夠 spawn 的 subagent，都必須宣告為一個 AgentDefinition。這是 CCA-F 測試的第二個核心產物。考試要求認識 AgentDefinition 的欄位，以及能夠推論這些欄位如何塑造 subagent 的行為。

AgentDefinition 的欄位

Agent SDK 中的 AgentDefinition，或作為 Claude Code subagent 檔案（.claude/agents/<name>.md）時，包含以下欄位：

• description — 描述 subagent 用途的自然語言說明。Claude 使用這個 description 來決定，在多個 subagent 已登錄的情況下，是否將某個 Task 呼叫路由到這個特定的 subagent type。把 description 當作工具描述看待：它是路由訊號。
• 系統提示（system prompt） — subagent 完整的行為憲章。宣告聲調、限制、偏好的輸出格式、禁止的動作，以及無論個別 Task 呼叫傳入什麼，subagent 都需要具備的領域知識。
• tools（allowedTools） — subagent 可呼叫工具的明確白名單。若父代有 Bash 但子代的 AgentDefinition 未列出 Bash，子代就無法執行 Bash。預設為限制性的。
• model — 可選的 model 覆寫。低成本的 subagent 任務（大量摘要）可在較小的 model 上執行，而 coordinator 則使用較大的 model。省略時，subagent 繼承 session 的預設 model。

description 對路由的重要性

當 coordinator 持有多個已登錄的 subagent type（researcher、critic、summarizer），coordinator Claude 會根據自然語言 description 決定要在 Task tool 中傳入哪個 subagent_type。描述模糊或重疊的 AgentDefinition 會產生不確定的路由，就像模糊的工具描述會產生不確定的工具選擇一樣。這是撰寫 AgentDefinition 時最常見的錯誤：寫 description: "helpful agent"，而不是 description: "從 arXiv 讀取並綜合學術論文；回傳附有頁碼引用的結構化書目摘要。"

AgentDefinition 存放在哪裡

在 Claude Code 中，AgentDefinition 以 markdown 檔案的形式存放在 .claude/agents/<name>.md（專案範圍）或 ~/.claude/agents/<name>.md（使用者範圍）下。在 Agent SDK（Python 或 TypeScript）中，它們以物件形式以程式方式傳遞給 session 建構子。兩種形式產生相同的執行時期行為。

allowedTools — 限定 Subagent 實際可用的工具

AgentDefinition 上的 allowedTools 欄位，是 subagent 呼叫、context passing 與 spawning 中最與考試相關的單一參數。理解其語義可以避免一整類的錯誤答案。

allowedTools 是嚴格的白名單

清單上有的工具可以呼叫。清單上沒有的工具無法呼叫——不存在隱式繼承父代能力的機制。擁有 allowedTools: ["Read", "Grep"] 的 subagent，即使其父代 coordinator 可以呼叫 Write，它也無法呼叫 Write。這是刻意設計的：subagent 的專業化在工具邊界上強制執行，而不是依賴 prompt 邊界來期望達成。

allowedTools 只能限制，永遠無法擴展

第二條關鍵規則：AgentDefinition 無法授予其 subagent 超出 session 整體設定所允許的權限。若 session 在禁止 Bash 的權限設定下啟動，在其 allowedTools 中列出 Bash 的 subagent 仍然無法執行 Bash。白名單是對已允許範圍的限制；它們無法覆寫 session 的安全邊界。

常見的專業化模式

考試情境通常獎勵專業化：

• researcher subagent：["Read", "Grep", "Glob", "WebSearch"] — 可探索與讀取，但不能修改。
• critic subagent：[]（無工具）— 純粹推理，無法碰觸檔案系統或 shell。
• coder subagent：["Read", "Edit", "Write", "Bash", "Grep"] — 可修改原始碼，但可能不被允許進一步 spawn subagent（無 Task）。
• coordinator：["Task", "Read"] — 職責是協調，而非執行，因此持有 Task 加上足夠的唯讀存取來查看輸入。

Context 隔離 — 最容易讓考生踩坑的規則

若說 CCA-F 考試在 subagent 呼叫、context passing 與 spawning 上強調哪一條規則，那就是：subagent 在隔離的 context 中執行，不會自動繼承 coordinator 的對話歷史。

隔離 Context 的實際含義

當 Task tool spawn 一個 subagent 時，SDK 建立一個新的 session，其訊息歷史只包含：

1. subagent 的系統提示（來自其 AgentDefinition）。
2. coordinator 在 Task tool 呼叫中提供的 prompt 字串，作為第一條 user 訊息。

這就是整個初始狀態。coordinator 先前的訊息、先前的 tool_result 條目、先前的思考區塊、先前的 user 指令——這些對 subagent 全部不可見。subagent 不知道 coordinator 做了什麼、載入了什麼文件、呼叫了哪些工具，除非 coordinator 將那些資訊打包進 Task prompt。

這樣設計的原因

Context 隔離存在三個原因：

• Context window 衛生 — coordinator 的 context window 可能已經有 50K token 的深度。將其複製進每個 subagent 會浪費 subagent 的可用 token 和 API 費用。
• 專業化保真度 — 聚焦的 subagent prompt，比稀釋的通用對話轉儲表現更好。
• 安全性與可稽核性 — 從未見過上游敏感資料的 subagent，不可能透過其工具呼叫或最終輸出意外洩漏它。

明確傳遞的義務

由於 context 不會自動流動，需要 subagent 知道某些資訊的 coordinator，必須在 Task tool 的 prompt 參數中明確傳入那些資訊。這就是考試綱要中的「必須明確傳遞」規則。它看起來像這樣：

Task(
  subagent_type="summarizer",
  description="Summarize support ticket thread",
  prompt="""
Summarize the following customer support ticket thread into
a 3-sentence incident description. Thread:
<thread>
  {full_ticket_thread_here}
</thread>
Return only the 3-sentence summary, no preamble.
"""
)

coordinator 負責將工單內容打包進 prompt。若 coordinator 依賴 subagent「已經知道」要摘要什麼，subagent 就會幻想或拒絕執行。

Context Passing 策略 — 完整、摘要或結構化

既然 coordinator 必須明確打包 context，問題就變成了如何打包。CCA-F 認識三種原型。架構師根據資料量和 subagent 的資訊需求來選擇。

完整歷史直接傳遞

coordinator 將相關的對話或工具輸出逐字拼接進 Task prompt。簡單、無損，但 token 成本高。適用於 subagent 需要對 coordinator 已看過的相同材料進行深度推理的情況。

摘要傳遞

coordinator 在 spawn 前將先前的 context 壓縮成簡短的簡報——幾句話或幾個要點。成本較低，但有損失：subagent 無法恢復 coordinator 捨棄掉的細節。適用於 subagent 的任務範圍窄、只需要摘要的情況。

結構化 Payload 傳遞

coordinator 將 context 打包為結構化資料——JSON、XML 標籤或 markdown 圍欄區塊——清楚地將元資料與自然語言任務指令分開。這是生產等級的模式，也是 CCA-F 在多 agent 研究系統情境中期望架構師推薦的做法。

結構化 payload 的範例：

<task>
  <goal>Identify any factual inconsistencies</goal>
  <context>
    <source_1 id="arxiv:2301.04567">
      {paper_1_summary}
    </source_1>
    <source_2 id="arxiv:2302.11234">
      {paper_2_summary}
    </source_2>
  </context>
  <instruction>
    Return a JSON array of {claim, source, conflicts_with} objects.
  </instruction>
</task>

XML 標籤的分隔給了 subagent 清晰的心智模型：目標、然後是 context（附有來源出處）、然後是輸出指令。這也讓 subagent 的輸出在回到 coordinator 時更容易稽核。

fork_session — 分岔探索而不失去主幹

fork_session 機制是 subagent 呼叫、context passing 與 spawning 在 CCA-F 上的第三根支柱。它解決的問題與 Task 不同：不是「spawn 一個執行有限工作的子代」，而是「在保持原始 session 完整的同時，從當前 session 探索一條替代路徑」。

Forking 帶給你什麼

fork 會建立當前 session 狀態的副本——訊息歷史、工具呼叫歷史、SDK 持久化的任何內容——作為一個擁有自身 session_id 的新 session。在 fork 中執行的動作不會影響主幹。你可以執行實驗、復原錯誤，或探索假設性的分支。

fork_session vs Task

這兩種機制截然不同，CCA-F 會測試你區分它們的能力：

• Task 建立一個全新的、context 隔離的 subagent，只以 AgentDefinition 和一個 prompt 為種子。用於委派有界的工作單元。
• fork_session 將現有 session 的完整狀態複製到一個新的分支中。用於分岔探索、A/B 測試工具策略，或可復原的實驗。

若情境問「如何讓 researcher agent 嘗試兩種不同的資料庫查詢策略，同時不失去原始 context？」，答案是 fork_session——spawn 兩個 fork，在各自執行一個查詢，比較結果，捨棄較差的 fork。

Forking 不會複製權限或擴展工具授予

一個經常被考到的細節：forking 繼承訊息歷史，但不會神奇地授予 fork 額外的工具權限，或提升 session 的安全設定。若主幹無法呼叫 Bash，fork 也不行。fork 是記憶體操作，而非權限操作。

並行 Task 呼叫 — 單一 Coordinator 回應中的扇出

Agent SDK 允許 coordinator Claude 在單一助理回應中發出多個 tool_use 區塊，包括多個 Task 呼叫。SDK 會並行執行那些 subagent，並在全部完成後一起回傳其 tool_result 訊息。

並行 Spawning 的重要性

在多 agent 研究情境中，需要對同一個問題取得三個角度的 coordinator，可以並行 spawn 三個專家 subagent，而非循序執行：

• researcher_arxiv — 搜尋 arXiv 並回傳發現。
• researcher_github — 搜尋 GitHub 並回傳發現。
• researcher_web — 搜尋網路並回傳發現。

三者並行執行；coordinator 同時看到所有三個 tool_result 訊息；然後綜合所有證據。循序 spawning 會讓延遲乘以 3，並推遲所有後續步驟。

何時不應扇出

當子任務相互依賴——subagent B 需要 subagent A 的輸出作為輸入——時，並行化是錯的。扇出相依的子任務，要嘛導致失敗（B 沒有 A 的資料），要嘛浪費工作（B 以過時的假設繼續執行）。相依的子任務應循序串接；獨立的子任務應扇出。

Spawning 深度限制與遞迴 Subagent

如果 subagent 的 AgentDefinition 在 allowedTools 中包含 "Task"，subagent 本身也可以進一步 spawn subagent。這會產生 agent 樹狀結構。若沒有深度限制，一個有缺陷或失控的規劃 agent 可能會遞迴直到預算爆炸。

實務上的深度上限

CCA-F 不測試特定的數字深度限制，但確實測試以下認識：

• 深度在實務上受限於中間的 AgentDefinition 是否在其 allowedTools 中包含 Task。
• 常見的衛生做法：只有最外層的 coordinator 持有 Task；葉子專家不持有。
• 樹狀結構的形狀是設計決策，而非執行時期的意外。

防止失控的樹狀結構

最安全的預設是淺層階層：根部的一個 coordinator，一層的專家葉子，不再進一步遞迴。若確實需要更深的階層，每個中間層的 allowedTools 應明確攜帶 Task，且其 AgentDefinition 系統提示應強制執行預算（「你最多可以 spawn 兩個子代」）。

同步 vs 非同步呼叫

從 coordinator 的角度來看，Task 呼叫在 coordinator 自身的迴圈中是同步的：coordinator 發出 tool_use，等待 tool_result，然後繼續。SDK 在回傳之前將 subagent 執行至完成。在 Task tool 層面沒有暴露「shoot and forget」的原語。

並行呼叫不做的事

單一助理回應中的並行 Task 呼叫確實會彼此並行執行，但 coordinator 仍然等待所有呼叫完成後才繼續。透過 Task tool 介面沒有暴露任何 callback、事件串流或 promise 物件。CCA-F 會測試考生可能錯誤提議「發出 Task 呼叫後繼續執行」的情境——正確答案是，coordinator 的迴圈對於它發出的任何 Task，都會一律阻塞在等待 tool_result 上。

對延遲敏感情境的含義

在終端使用者正在等待的客服解決 agent 情境中，架構師必須仔細思考 spawning 深度和扇出寬度。三個各需 8 秒的並行 subagent，會阻塞 coordinator 8 秒（最慢那個），而非 24 秒。但三個 8 秒 subagent 的循序串接，則會阻塞 24 秒。扇出是掌控延遲的工具。

Coordinator 迴圈中的回傳值處理

當 subagent 以 stop_reason: end_turn 結束其迴圈時，其最終助理訊息內容會成為原始 Task 呼叫的 tool_result 主體。coordinator Claude 將該 tool_result 作為其下一輪輸入的一部分讀取。

Coordinator 實際看到什麼

coordinator 看到的是：

• 一個 coordinator 自身發出的 tool_use 區塊。
• 一個以 subagent 最終文字為內容的 tool_result 區塊。

coordinator 不會看到 subagent 的中間 tool_use 和 tool_result 訊息、其思考區塊，或其逐步推理過程——只有最終輸出。這就是為什麼設計良好的 subagent 要產出簡潔、結構化的最終輸出；下游 coordinator 需要的一切都必須在那最後一條訊息中。

輸出塑形模式

結構化 subagent 最終輸出的兩種常見模式：

• 自由形式摘要 — 適用於探索性任務，coordinator 將對定性發現進行推理。
• 結構化 JSON 或 XML 區塊 — 適用於輸出由 coordinator 機械消費的任務（例如 coordinator 將解析 subagent 的 JSON 並將欄位餵入下一步）。這與結構化資料擷取情境配合得很好。

權限繼承 vs 限制 — 回顧

將所有權限線索整合成單一心智模型：

• 父代 session 權限邊界 — 外部上限；內部任何東西都無法超越這個邊界。
• Coordinator allowedTools — 將 coordinator 限制在邊界的子集中。必須包含 Task 才能 spawn。
• Subagent AgentDefinition allowedTools — 將 subagent 限制在其自身的子集中，受邊界約束（不受 coordinator 的清單約束）。若 subagent 本身被允許 spawn，必須包含 Task。

每一層都是限制。沒有任何一層是擴展。考試在情境層面測試這一點：「coordinator 有 Bash，researcher subagent 未列出 Bash——researcher 可以呼叫 Bash 嗎？」答案：不行。

白話文解釋 Subagent 呼叫、Context Passing 與 Spawning

抽象的概念在錨定到具體情境時才真正好記。以下三個類比涵蓋了 subagent 呼叫、context passing 與 spawning 的完整面貌。

類比一：包辦宴席的外燴主廚與新進員工

一位承接大型跨部門餐宴的外燴主廚，無法獨自完成所有備料。他的做法是撰寫一份任務單——一份自給自足的文件，說明目標、背景脈絡、限制條件、預期的出餐格式——然後把這份任務單交給特地為此類工作聘來的專業廚師。那位廚師走進備料區時，手上只有這份任務單。他沒有出席主廚的早晨採購會議，沒有讀過主廚的菜單討論串，也沒有聽到外場與 VIP 桌的溝通。若任務單內容不完整，廚師只能猜測或回頭詢問。

這正是 subagent 呼叫、context passing 與 spawning 的運作方式。coordinator Claude 是主廚。AgentDefinition 是廚師的職務說明（他的專長、他帶來的工具）。Task tool 是把任務單交出去的動作。prompt 參數就是任務單的內容。subagent 帶著任務單加上自身的專業進場——僅此而已。若 coordinator 忘記把客人的菜單需求寫進任務單，摘要 subagent 就無法摘要它從未看過的東西。

這個類比對應每個核心術語：

• Coordinator = 委派工作的主廚。
• AgentDefinition = 廚師的職責描述與取得許可的工具清單。
• Task tool 呼叫 = 把任務單交出去的動作。
• prompt 參數 = 任務單的內容。
• allowedTools = 廚師獲准使用的工具（若取得許可的刀具清單上沒有剃骨刀，就不能用）。
• 隔離 context = 廚師沒有出席你先前的所有會議。

類比二：帶著自製小抄進考場的開放式筆記考試

想像一位考生參加開放式筆記考試，規定只能帶一份自己準備的小抄，其他什麼都不能帶。考生在考試期間掌握的知識包括：他準備的小抄，加上他進考場前就已具備的知識（訓練、學過的課程）。坐在考場外面的監考老師，有每堂課的詳細個人筆記——但考生在考試中無法取用那些筆記。

subagent 就是考生。小抄就是 Task prompt。考生既有的知識就是 AgentDefinition 系統提示。監考老師就是 coordinator，擁有考生看不到的豐富 context。若監考老師希望考生知道某件事，他必須在考生進場之前把它寫在小抄上。考試一旦開始，門就關上了。考生無法在中途打電話索取更多 context。

這個類比說明了為什麼明確的 context passing 是不可或缺的，以及為什麼摘要或結構化傳遞是在 token 成本和資訊完整性之間的取捨。小抄的空間有限；上面寫什麼至關重要。

類比三：分工明確的辦桌備料陣地

一位在繁忙宴席中坐鎮總鋪的師傅掌控整場菜色。訂單進來；他讀完整張菜單後決定誰做什麼。他把醬料交給滷味師傅，把主菜交給爐台師傅，把盤飾交給冷盤師傅。每位專家站在自己的備料區，使用各自的工具——滷味師傅有滷桶和長筷，爐台師傅有鑄鐵鍋和火候，冷盤師傅有鑷子和冰鎮碗。滷味師傅碰不到爐台；爐台師傅碰不到冷盤食材。總鋪師站在出菜口，手裡拿著完整的菜單和出菜板——他的工具是統籌，不是直接烹調。

總鋪師交派「擺好這道菜的醬料」時，滷味師傅得到的是精確的指令（「焢肉，兩份量，熱盤上桌」），而不是整場宴席的訂席紀錄、外場服務員對 VIP 桌的備注，或酒水搭配的決策。每位專家只拿到他們需要的資訊，不多也不少。

這就是從頂層俯視的 subagent 呼叫、context passing 與 spawning：

• 總鋪師 = 持有 Task tool 的 coordinator。
• 各備料區 = subagent 執行時期實例。
• 每位師傅的工具架 = 各 AgentDefinition 的 allowedTools。
• 委派的指令 = Task prompt。
• 完成後送回出菜口的料理 = 回傳給 coordinator 的 tool_result。
• 同時對全場師傅下令 = 單一 coordinator 回應中的並行 Task 呼叫。
• 分出兩個爐台試做兩種不同收汁方式 = 用於分岔探索的 fork_session。

考試當天選用哪個類比

• 關於為什麼 subagent 不知道 coordinator 知道的事的題目 → 開放式筆記考試類比。
• 關於誰可以使用哪個工具的題目 → 辦桌備料陣地類比。
• 關於委派合約以及什麼內容應該放進 prompt 的題目 → 外燴主廚類比。

多 Agent 研究系統情境對應

多 agent 研究系統情境是 CCA-F 考試中與 subagent 呼叫、context passing 與 spawning 吻合度最高的情境。典型的考試設定：

「一個團隊建立研究系統，coordinator agent 派發三個專門的 researcher——一個負責 arXiv，一個負責 GitHub，一個負責網路。researcher 必須並行工作，不得看到彼此的中間發現，並且必須回傳結構化引用。」

正確的架構使用：

• 三個 AgentDefinition（每個來源一個），各有窄化的工具白名單和強制執行引用格式的系統提示。
• 一個在 allowedTools 中包含 "Task" 以及最少其他工具的 coordinator AgentDefinition。
• 在單一 coordinator 回應中發出的並行 Task 呼叫，各帶有識別研究問題和預期引用 schema 的結構化 XML payload。
• coordinator 中的 tool_result 彙整，然後跨三個回傳的 JSON 區塊進行綜合。
• 可選的 fork_session，若 coordinator 想在承諾之前探索兩種替代的綜合策略。

此情境的錯誤答案通常：

• 將三個 researcher 合併成單一 subagent（失去並行性，混淆專業化）。
• 依賴 context 繼承而非明確的結構化 payload（subagent 會幻想）。
• 給每個 subagent "Task" 工具（引發失控遞迴）。
• 在應使用 Task 的地方使用 fork_session（fork 繼承歷史——對獨立的研究流來說是浪費）。

開發者生產力與 Claude 情境對應

開發者生產力與 Claude 情境將 subagent 呼叫、context passing 與 spawning 疊加在 Claude Code 的內建檔案工具之上。典型的考試設定：

「一位工程師希望 Claude Code 透過三個專門的審查輪次來 review 一個 pull request：型別安全審查輪次、測試覆蓋率審查輪次和安全審查輪次。每個輪次應有各自的工具白名單。工程師希望三個輪次盡可能並行執行。」

正確的架構：

• 在 .claude/agents/ 下以 subagent markdown 檔案的形式登錄三個 AgentDefinition：type-check-reviewer、test-coverage-reviewer、security-reviewer。
• 每個都有窄化的 allowedTools 集合：型別檢查和安全審查只用 Read 和 Grep，測試覆蓋率審查額外加 Bash（範圍限定），以便呼叫測試執行器。
• 頂層 Claude Code session 作為 coordinator，在其 allowedTools 中持有 Task。
• coordinator 透過單一助理輪次中的三個 Task tool_use，並行 spawn 所有三個 reviewer。
• 每個 reviewer 回傳一個結構化的發現區塊；coordinator 綜合並呈現統一的 review。

這個情境獎勵能夠認識 AgentDefinition 可以以檔案形式存在、並行 Task 扇出是正確的延遲選擇，以及最小化每個 subagent 的 allowedTools 是安全特性而非限制的考生。

常見考試陷阱 — Subagent 呼叫、Context Passing 與 Spawning

CCA-F 關於 subagent 呼叫、context passing 與 spawning 的題目中，五個陷阱反覆出現。全部記住。

陷阱一：將 Task Tool 視為自訂工具

答案選項可能描述「透過 MCP 撰寫自訂 Task tool」。錯誤。Task tool 是 Agent SDK 的內建工具，不是你自己實作的東西。拒絕任何暗示將 Task 作為使用者自定義工具來撰寫的答案。

陷阱二：Context 自動向下流動

這是最常被懲罰的誤解。Subagent 開始時的訊息歷史是空的，除了其系統提示和 Task prompt。任何暗示「subagent 有存取 coordinator 對話的權限」的答案，除非 coordinator 在 prompt 中明確傳入了那個對話，否則都是錯的。

陷阱三：allowedTools 繼承

考生以為 subagent 繼承 coordinator 的工具清單。它不會。AgentDefinition 的 allowedTools 是明確的、獨立的白名單。省略一個工具，它就無法被呼叫。

陷阱四：allowedTools 作為超出 Session 邊界的權限授予

allowedTools 只能限制已允許的範圍。在安全設定中 Bash 被停用的 session 中，在 subagent 定義上列出 Bash 並不會啟用 Bash。限制，永遠無法擴展。

陷阱五：混淆 Task 與 fork_session

Task spawn 一個全新的、context 隔離的 subagent。fork_session 將當前 session 的歷史複製到一個新的分支中。「目標是帶著完整的先前 context 在替代分支上繼續推理」的情境需要 fork_session；「目標是將有界的工作單元委派給專家」的情境需要 Task。選錯機制會損失考題。

練習錨點 — 任務 1.3 情境題範本

CCA-F 關於 subagent 呼叫、context passing 與 spawning 的練習題歸類為五種反覆出現的形態。詳細的題庫在 ExamHub CCA-F 練習考試中；範本形態如下：

範本 A：Spawning 機制識別

「一位架構師希望 coordinator agent 將摘要任務委派給一個專家。coordinator 應呼叫哪個 SDK 提供的工具？」正確答案：Task。干擾項：「一個名為 'delegate' 的自訂 MCP 工具」、「Read」、「allowedTools 清單上的任何工具」。

範本 B：allowedTools 推論

「subagent 的 AgentDefinition 列出 [Read, Grep]。coordinator 的 allowedTools 列出 [Read, Grep, Bash, Task]。subagent 可以執行 Bash 嗎？」正確答案：不行。allowedTools 不從 coordinator 繼承。

範本 C：Context 隔離問題

「一個 coordinator agent 一直在處理多輪客服對話。它用 Task spawn 了一個 summarizer subagent。summarizer 啟動時看到什麼？」正確答案：其 AgentDefinition 系統提示，加上 coordinator 在 Task prompt 參數中提供的任何內容。 干擾項：「coordinator 的完整訊息歷史」、「coordinator 的最後一條助理訊息」、「coordinator 透過 Read 讀取的所有內容」。

範本 D：Task vs fork_session 選擇

「一個 researcher agent 希望嘗試兩種資料庫查詢策略，同時保留復原到當前狀態的能力。它應使用哪種機制？」正確答案：fork_session。干擾項：Task（錯誤，因為 Task 不在分支中保留完整歷史，且目標是探索，而非委派）。

範本 E：並行扇出識別

「coordinator 必須跨三個獨立來源研究同一個問題並綜合發現。哪種模式能最小化延遲？」正確答案：在單一 coordinator 回應中發出多個 Task tool_use 區塊，讓 SDK 並行執行 subagent。 干擾項：「串接三個循序的 Task 呼叫」（正確但較差；考試通常將並行標記為最佳）。

常見問題 — Subagent 呼叫、Context Passing 與 Spawning

Task tool 是什麼，為什麼它專屬於 Agent SDK？

Task tool 是 Agent SDK 的內建 spawning 機制。使用 subagent_type、description 和 prompt 呼叫 Task，會建立一個綁定到對應已登錄 AgentDefinition 的全新 subagent session。SDK 在隔離的 context window 中執行 subagent 的 agentic loop，並將最終輸出以 tool_result 的形式回傳給 coordinator。它專屬於 Agent SDK，是因為 spawning 是一個執行時期原語，不是使用者撰寫的工具所能忠實實作的——SDK 必須連接子代 session、序列化 AgentDefinition、執行 subagent 的迴圈，並將結果路由回父代的訊息歷史。

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

不會。這是 CCA-F 上最常被測試的誤解。Subagent 以隔離的 context 執行。當 Task tool spawn subagent 時，subagent 的開頭訊息歷史只包含其 AgentDefinition 的系統提示，以及 coordinator 傳入 Task 呼叫的 prompt 字串。coordinator 先前的訊息、tool_result 和推理，對 subagent 全部不可見。若 coordinator 需要 subagent 知道某些事，coordinator 必須在 Task prompt 參數中明確打包那些資訊。

AgentDefinition 包含什麼，為什麼 description 很重要？

AgentDefinition 是 subagent 的宣告式規格。它包含 description（父代 Claude 用來選擇要 spawn 哪個 subagent_type 的路由訊號）、系統提示（subagent 的行為憲章）、allowedTools 清單（subagent 的工具白名單），以及可選的 model 覆寫。description 很重要，是因為當 coordinator 持有多個已登錄的 subagent type 時，父代 Claude 透過讀取 description 在它們之間做選擇——模糊或重疊的 description 會產生不確定的路由。把 description 當作工具描述看待：具體、動詞導向、範圍明確。

allowedTools 如何與 coordinator 的工具權限互動？

allowedTools 是嚴格的白名單，只能限制，永遠無法擴展。subagent 只能呼叫自身 AgentDefinition 的 allowedTools 中列出的工具。subagent 不繼承 coordinator 的工具，且無法超出 session 的整體權限邊界。若 session 在停用 Bash 的設定下啟動，在 subagent 的 allowedTools 中列出 Bash 並不會啟用它。反之，coordinator 必須在其自身的 allowedTools 中包含 Task tool，spawning 才能成立——spawning 能力受到與其他所有工具相同的白名單機制管控。

我應該在什麼情況下使用 fork_session 而非 Task tool？

當你想將有界的工作委派給不需要看到完整 coordinator 歷史的專家 subagent 時，使用 Task。當你想沿著替代分支、從當前 session 的確切狀態繼續推理時，使用 fork_session——假說測試、A/B 工具策略探索，或可復原的實驗。Fork 在 fork 當下繼承完整的訊息歷史；Task subagent 從空的歷史開始，只以其 AgentDefinition 為種子。經驗法則：Task 是委派，fork 是探索。

Coordinator 可以並行 spawn 多個 subagent 嗎？

可以。Agent SDK 允許 coordinator 在單一助理回應中發出多個 tool_use 區塊——包括多個 Task 呼叫。SDK 並行執行那些 subagent，並在各自完成後回傳所有的 tool_result 訊息。這種並行扇出是獨立子任務（例如跨不同來源的三個研究流）的正確模式，因為延遲受最慢的 subagent 限制，而非所有 subagent 持續時間之和。當子任務相互依賴時，並行扇出是錯的——那些任務應循序串接，讓下游 subagent 可以消費上游輸出。

Subagent 本身可以 spawn 進一步的 subagent 嗎？

可以，前提是其 AgentDefinition 在 allowedTools 中包含 "Task"。這會產生多層的樹狀結構。在實務上，CCA-F 獎勵淺層階層：根部的一個 coordinator 持有 Task，一層的專家葉子不持有 Task。更深的樹在技術上可行，但會引入遞迴風險、除錯複雜性，以及中間層進入 spawn 迴圈時的預算爆炸風險。設計時以淺層為預設；明確地為深度提供理由。

延伸閱讀

• Claude Certified Architect — Foundations Exam Guide v0.1: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Subagents in the Agent SDK: https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• Create custom subagents — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/sub-agents
• Orchestrate teams of Claude Code sessions (Agent Teams): https://code.claude.com/docs/en/agent-teams
• Agent SDK overview: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-overview
• Session management — Agent SDK: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-sessions
• Tool use overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Use XML tags to structure your prompts: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags

Related ExamHub topics: Multi-Agent Orchestration with Coordinator-Subagent Patterns, Agentic Loops for Autonomous Task Execution, Agent SDK Hooks for Tool Call Interception, Session State, Resumption, and Forking.