複雜工作流程的任務拆解策略

Task decomposition strategies 是複雜工作流程的架構層級視角，也是 Claude Certified Architect Foundations（CCA-F）考試 Domain 1 套用於任何非平凡 agent 系統的核心思維框架。任務說明 1.6 要求考生「為複雜工作流程設計 task decomposition strategies」，而由於 Agentic Architecture and Orchestration 佔整體考試比重的 27%，task decomposition strategies 在考生面對的大多數情境中都會直接或間接出現——這是一份 60 題、120 分鐘、720 分通過的考試。Code Generation with Claude Code 和 Multi-Agent Research System 這兩個情境叢集，尤其仰賴正確的分解選擇——固定循序流水線（fixed sequential pipeline）或 dynamic adaptive plan、per-file 本地處理或 cross-file 整合處理、coordinator-as-planner 或靜態連結的 chain。

這份學習筆記涵蓋 CCA-F 架構師需要精通的 task decomposition strategies 全貌：為何要分解（降低每個 agent 的認知負擔、啟用平行執行、緩解 attention dilution）、兩種主要分解方式（由上而下的階層式分解與由下而上的功能式分解）、粒度校準（子任務太大會壓垮單一 agent，太小則淹沒於協調開銷）、依賴關係映射（循序 chain 與獨立的平行軌道）、子任務介面設計（分解步驟之間的乾淨 input/output 合約）、遞迴分解（當子任務本身仍過於複雜時）、coordinator-as-planner 模式、計畫驗證、靜態與 dynamic 分解的選擇（考試測驗頻率最高的軸）、fan-out 平行性、反模式（chatty 子任務、循環依賴、上下文遺失），以及考試所援引的實務情境錨點（CI/CD 程式碼審查、舊有測試覆蓋率擴展、multi-agent 研究整合）。CCA-F 認知深度標記清楚區分架構判斷到何處為止、實作層級細節從何處開始。

為何要分解？降低每個 Agent 的認知負擔與啟用平行執行

每個你會交給 Claude 處理的非平凡工作流程，都內含一個隱性選擇：把整個問題灌入單一 prompt，或是將它切割成一序列（或一張圖）的較小問題。Task decomposition strategies 就存在於這兩個極端之間的空間。Anthropic 自家的 prompt 工程指引說得明確——透過 chain 複雜的 prompt 可以提升效能，因為每個子步驟能讓 Claude 把完整注意力聚焦在一個收窄的目標上，而不是把注意力分散到許多鬆散相關的要求之中。

架構師分解工作流程有三個核心理由：

1. 注意力聚焦。 一個要求 Claude 同時讀取十二個檔案、檢查安全問題、重寫三個模組、起草遷移計畫、並撰寫 PR 描述的單一大型 prompt，產出的答案將會在每個維度上淺嘗即止，沒有任何一個維度真正深入。把工作分解成聚焦的子步驟，讓每個步驟獲得完整的 context 預算與推理預算。
2. 可靠性。 較小的步驟更容易驗證。若某個子步驟失敗，你只需要重試或重新路由該步驟，而不必重跑整個 pipeline。錯誤範圍維持在本地。
3. 平行性。 彼此獨立的子步驟可以在不同的 subagent session 上同時執行，對於「平行審查此 repo 中每個檔案」之類的任務，可大幅縮短實際耗費的時間。

CCA-F 考試反覆測驗你是否認識到，decomposition 是一個架構決策，而非一種操作習慣。當情境說「一個 Claude Code session 被要求審查三十個檔案並產出統整摘要」，考試上正確的答案模式涉及分解——而不是更長的 system prompt、不是更大的 context window、不是降低 temperature。

分解方式：由上而下的階層式 vs 由下而上的功能式

CCA-F 認可兩種主要的分解成形方式：

由上而下的階層式分解（Top-Down Hierarchical Decomposition）

從目標出發。拆成主要階段。再把每個階段拆成具體的子任務。持續往下，直到每個葉節點都是單一 agent 能以高度信心完成的工作單元為止。這是定義清楚的交付物的自然形狀：「上線一個功能」、「稽核一個 codebase」、「產出一份研究簡報」。

由上而下的分解是指令式的——架構師（或扮演架構師角色的 coordinator agent）在執行開始前就把樹狀結構排好。它和 prompt chaining 與 plan mode 天然配合。

由下而上的功能式分解（Bottom-Up Functional Decomposition）

從現有能力出發——你已有的工具、subagent 定義和 MCP servers。問「這些基礎元件能組合出什麼有用的東西？」然後向上推導到目標。這是探索式工作流程的自然形狀，此類工作流程的目標模糊：「在這個日誌串流中找出異常」、「探索提升測試覆蓋率的方式」。

由下而上的方式和 dynamic adaptive decomposition 天然配合，因為它接受計畫在執行過程中隨著學習到的資訊而重塑的可能性。

如何在兩者之間做選擇

交付物明確、路徑已知時選由上而下；交付物需要探索、或工具組合本身是最有趣的變數時選由下而上。成熟的系統通常兼而有之：由上而下的骨幹，加上在特定階段內由下而上的自適應分支。

粒度校準：子任務太大 vs 子任務太小

Task decomposition strategies 中最難判斷的，是選擇子任務的正確粒度。

太大

子任務太大的徵兆：

• 單一 prompt 必須同時處理數個不相關的關注點（安全性 + 效能 + 風格）。
• Subagent 被給予了太多工具，無法判斷該使用哪個。
• 輸出因為注意力被太多目標分散而變得淺薄。
• 你無法用一句話為該子任務寫出通過／失敗的判斷標準。

太小

子任務太小的徵兆：

• 協調開銷（生成 session、傳遞 context、收集結果）遠大於實際工作量。
• 子任務之間必須大量傳遞狀態，因為沒有任何事情能在本地決定。
• 圖中充滿只做單行轉換的節點，這些工作本可由單一 agent 直接完成。

校準後的中間點

一個尺寸合宜的子任務具備：單一清楚的目標、聚焦的工具集（兩到五個工具是實用的經驗法則）、能在數百個 token 內表達的 input 合約，以及結構化（JSON）或簡短自然語言的 output 合約。一個子任務若恰好產出一個可供審查的成果——單一 per-file 審查、函式層級的 patch、研究簡報的一個章節——幾乎總是粒度正確的。

依賴關係映射：循序依賴 vs 獨立平行軌道

確認好子任務之後，下一個架構問題是它們之間如何相互依賴。

循序依賴（Sequential Dependencies）

子任務 B 必須等子任務 A 產出結果後才能開始。例如：在取得 per-file 分析摘要之前，你無法撰寫整合計畫。循序依賴天然由 prompt chaining 服務——步驟一的輸出成為步驟二輸入的一部分。

獨立平行軌道（Independent Parallel Tracks）

不消耗彼此輸出的子任務可以同時執行。例如：分析三十個檔案的程式碼品質問題——每個 per-file 審查都是獨立的。平行軌道 fan-out 到多個 subagent session，然後 fan back in 到一個 coordinator 進行結果聚合。

混合（DAG）工作流程

真實的工作流程幾乎都形成有向無環圖（DAG）：早期的某些子任務平行 fan-out，它們的結果匯聚到一個整合步驟，再 fan-out 到下一個平行波段。精確的依賴關係映射，是讓分解可執行的關鍵。

映射決定執行形狀

• 純循序 chain → 步驟之間有明確交接的 prompt chaining。
• 純平行 fan-out → coordinator 透過 Task tool spawn N 個 subagent 並聚合結果。
• 混合 DAG → coordinator 按波段編排，遵循依賴邊。

子任務介面設計：乾淨的 Input/Output 合約

分解的可靠程度，取決於步驟之間合約的品質。介面馬虎，錯誤就會連鎖傳播。

Input 合約

子任務需要什麼才能完成工作，且僅限於此？Input 塞了太多不相關的 context，會分散 subagent 的注意力；提供不足則迫使 subagent 去推測或產生幻覺。好的 input 合約明確指出具體的成果物（檔案路徑、工單 ID、先前的摘要）、用一句話說明聚焦的目標，以及預期的 output 形狀。

Output 合約

子任務的輸出是後續消費者的輸入。只要下游步驟需要解析結果，結構化輸出（透過 tool use 的 JSON，或文字中明確的 XML 段落）就是首選。當下游步驟是另一個能詮釋散文的 Claude 呼叫時，自然語言輸出是可以的。

為何合約至關重要

Claude Code subagents 在隔離的 context 中執行——它們不繼承 coordinator 的完整對話歷史。Subagent 需要的一切，都必須明確地跨越合約邊界傳遞。忘記這一點是最常見的架構錯誤之一，也是 CCA-F 考試社群通過報告中反覆提及的痛點。

遞迴分解：當子任務仍然太複雜時

有時分解樹必須往下延伸超過一個層次。「審查此服務」這個子任務，本身可能需要再分解成「審查 controller 層」、「審查 domain 層」、「審查 persistence 層」——每個再進一步分解成 per-file 處理。

何時遞迴

當子任務仍然無法通過單一目標測試，或仍有太多工具需要推理時，就要遞迴。遞迴自然映射到 coordinator-subagent 的巢狀結構：頂層 coordinator spawn 各主要階段的中層 coordinator；每個中層 coordinator 再 spawn 負責個別工作單元的葉層 subagent。

何時停止遞迴

當子任務可以在單一聚焦的 Claude session 中以明確的通過／失敗標準完成時，就停止。繼續遞迴只會增加協調開銷，卻帶來不了更多聚焦。

深度上限

實務上，三層巢狀通常已足夠——根 coordinator、階段 coordinator、葉層工作者。更深入很快就會產生 context 傳遞的複雜度，其代價超過帶來的聚焦效益。

Coordinator-as-Planner 模式：讓 Claude 自行產生計畫

Task decomposition strategies 中一個強大的模式，是讓 Claude 自己產生分解計畫，而不是把計畫寫死。

運作方式

你給 coordinator agent 整體目標、可用工具，以及選擇性的約束條件概要。Coordinator 使用 extended thinking（或 plan mode）來列舉子任務、依依賴關係排序，並指定每個工具或 subagent 負責哪個部分。接著 coordinator 執行計畫，依計畫 spawn subagent 或呼叫工具。

何時使用

當工作的確切形狀事前無法預知時，使用 coordinator-as-planner——例如「為這個舊有 codebase 新增完整的測試」。Coordinator 必須先 map codebase、找出高影響力的區域，然後才能決定在哪裡寫什麼測試。沒有任何靜態計畫能在不先看過程式碼的情況下選出正確答案。

何時不使用

當工作流程可預測且重複——例如「審查 main 上的每個 PR，檢查 secrets 和授權問題」——靜態、預先撰寫的 chain 比每次重新規劃更省成本、更快速、也更可稽核。

計畫驗證：執行前確認分解的完整性

coordinator（或人類架構師）產出的計畫，在開始執行耗時的長時間工作之前，應該先加以檢視。

要驗證什麼

• 完整性： 原始需求中的每個目標，是否都對應到至少一個子任務？
• 不重疊： 是否有任何兩個子任務重複了工作？
• 可行性： 每個子任務是否擁有所需的工具、context 和權限？
• 邊緣案例覆蓋： 失敗路徑是否明確（若某個子任務回傳錯誤該怎麼辦）？

如何驗證

• Plan mode 在 Claude Code 中於任何工具執行前顯示擬議計畫，讓人類（或第二個 agent）有機會核准、拒絕或修改。
• Plan-checker agents — 由一個次要 agent 審查計畫，在第一個執行者開始前標記缺口。
• 小規模試運行（Dry-runs） — 在正式對三百個檔案執行之前，先在三個有代表性的檔案上試跑分解。

Dynamic Decomposition vs Static Decomposition：考試最愛測的那條軸

這是任務說明 1.6 中測驗頻率最高、也是考生最常答錯的區別。

Static（固定循序 Pipeline）Decomposition

計畫在執行開始前就完全確定。每個步驟、每個子任務邊界、每個工具指派，都事先已知。Prompt chaining 是標準實作方式：步驟 1 的輸出餵入步驟 2，步驟 2 的輸出餵入步驟 3。

Static decomposition 最適合：

• 形狀可預測的多面向審查。 例：「對此 PR 中的每個檔案，執行安全掃描、風格掃描和效能掃描，然後產出整合摘要。」工作範圍已知；形狀穩定。
• CI/CD pipelines，其中可重現性和可稽核性優先於靈活性。每次執行對同類輸入都應走過相同的步驟。
• 高量重複性工作，你希望成本和延遲可預測。

Dynamic（Adaptive）Decomposition

計畫在執行過程中浮現。早期子任務產出的資訊，重塑了後期子任務的形狀。Coordinator 是一個主動規劃者，在每次結果回來後修訂剩餘計畫。

Dynamic decomposition 最適合：

• 開放式探索。 例：「為這個舊有 codebase 新增完整的測試。」Coordinator 先 map 模組結構、找出覆蓋率低且生產風險高的區域、建立優先計畫，再把 per-module 測試撰寫委派給 subagent。任何靜態計畫都無法在不先查看程式碼的情況下選出正確的檔案。
• Multi-agent 研究系統。 Coordinator 閱讀一批初始來源，發現意外的線索，並 spawn subagent 追蹤最有潛力的方向。
• 事件應變與除錯。 下一步取決於當前步驟發現了什麼。

架構上的取捨

Static 可預測且可稽核；dynamic 靈活且具備情境感知。CCA-F 考試獎勵根據情境線索做選擇，而非憑個人偏好：

• 「可預測、可重複，每個 PR 走過相同的檢查」→ static / prompt chaining。
• 「開放式，我們不知道結構是什麼，直到看了才知道」→ dynamic / adaptive plan。

分解以實現平行性：找出 Fan-Out 機會

平行性是良好分解帶來的最大實務收益之一。

Fan-Out 模式

當子任務彼此獨立時，coordinator 透過 Task tool（或 Agent SDK 的 subagent spawning API）同時 spawn 它們。每個 subagent 在自己的隔離 context 中執行。Coordinator 收集結果，並在下游步驟中進行整合。

Per-File 本地分析 + Cross-File 整合處理

這個模式值得特別點名，因為它是程式碼生成情境中最主要的考試模式。當任務需要審查多個檔案時：

1. Per-file 本地處理（平行 fan-out）。 每個檔案獲得自己的 subagent，context 聚焦在單一檔案上。Subagent 深度分析該檔案，產出結構化的本地摘要。
2. Cross-file 整合處理（循序聚合）。 單一 coordinator 讀取所有 per-file 摘要，整合出橫跨多檔案的發現——共用工具函式、API 合約、不一致的模式——這些都是任何單一 per-file 處理無法看到的。

這種兩階段形狀，勝過「把所有東西放進一個 prompt 審查」（attention dilution）和「每個 per-file 完全獨立、沒有整合」（遺漏 cross-file 的 bug）兩種做法。

平行性的限制

Fan-out 不是免費的。每個 subagent 消耗 API 配額，每個 spawn session 有啟動延遲，聚合成本隨結果數量增長。一個有用的心理上限是「當 N 大到 wall-clock 時間確實有影響時才平行化，但不要大到聚合本身變成另一個負擔」。

Attention Dilution：單次審查中最核心的風險

Attention dilution 是驅動大部分 task decomposition strategies 的失敗模式，在 CCA-F 核心技術要點中有明確點名。

Attention Dilution 如何顯現

• 單次審查二十個檔案，對每個檔案只產出一段讀起來像通用 checklist 的文字，而非真正的深入檢視。
• Coordinator 因為無法深入任何一個檔案，只是用不同的語言重複相同的高層次觀察。
• Cross-file 的 bug 被漏掉，因為 session 無法同時對每個檔案維持工作注意力。

分解如何解決這個問題

切分成 per-file 子任務，每個子任務的完整 context 預算聚焦在一個檔案上。然後加入一個專用的整合處理，其唯一的工作就是查看 per-file 的輸出並找出橫跨多檔案的模式。兩個窄焦點的處理勝過一個寬焦點的處理。

何時不需要為了注意力而分解

小型工作負載（兩到三個檔案）不需要分解——協調開銷超過了注意力效益。分解明顯勝出的門檻大約是五個以上的檔案，若檔案本身很大或 checklist 很豐富，門檻可以更早到來。

Prompt Chaining：Static Decomposition 的標準工具

Prompt chaining 是 static decomposition 最簡單、也是測驗最多的實作方式。

Prompt Chaining 適合的情境

• 任務有可預測的序列（分析 → 摘要 → 翻譯 → 格式化）。
• 每個步驟都有明確的 input 和 output。
• 可靠性和可稽核性比靈活性更重要。

Prompt Chaining 不適合的情境

• 下一步真正取決於當前步驟發現了什麼（改用 dynamic decomposition）。
• Chain 只是一個單一的平凡轉換，最好在一個 prompt 中處理。
• 子步驟彼此獨立，可以平行執行（改用 fan-out，而非循序 chaining）。

Dynamic（Adaptive）Decomposition：計畫在執行中浮現

Adaptive Loop

Dynamic decomposition agent 執行一個迴圈：

1. 根據當前狀態規劃接下來一到三個子任務。
2. 執行下一個子任務（直接執行或透過 spawn 的 subagent）。
3. 觀察結果，更新對剩餘工作的理解。
4. 根據剛學到的內容，重新規劃剩餘工作。
5. 當整體目標標準達成時退出。

實務範例：舊有 Codebase 的完整測試覆蓋率

這是 CCA-F 考試上 dynamic decomposition 的標準情境。Coordinator 先 map 目錄結構、找出現有覆蓋率最低且生產風險最高的模組、建立優先計畫，再把 per-module 測試撰寫委派給 subagent。靜態計畫無法在不先看過程式碼的情況下選出正確的優先順序。

Dynamic Decomposition 與 Plan Mode

Plan mode 是 dynamic decomposition 的一種輕量形式：Claude Code 在碰觸工具之前先規劃要做什麼，將計畫浮出給人類審核後再執行。Plan mode 適合當一位人類審核者需要看到並核准計畫的情境。完全自主的 dynamic decomposition，則適合迴圈必須在沒有人類在熱路徑（hot path）上的情況下執行。

Task Tool 與 Subagent Spawning 作為分解的基礎元件

Claude Code 和 Agent SDK 都暴露了 Task tool（以及相關的 subagent spawning API），這是分解的機械實作。

Task Tool

Task tool 讓 coordinator agent 能 spawn 一個 subagent 來處理範疇明確的子任務。Coordinator 提供子任務的描述，以及選擇性地提供 subagent 可使用的工具集合。Subagent 在隔離的 context 中執行——它看不到 coordinator 的對話歷史，只看到 coordinator 明確傳入的內容。

Subagent 作為分解單元

每次 subagent 呼叫對應到分解樹中的一個子任務。好的架構使分解與 subagent 邊界對齊——每個葉層子任務對應一次 subagent 呼叫，有乾淨的 input 和 output 合約。

Context 隔離是特性，不是缺陷

CCA-F 考試反覆測驗考生是否理解 subagent 的 context 隔離是刻意設計的。隔離防止 coordinator 累積的對話雜訊稀釋 subagent 的聚焦。Subagent 需要的一切，都必須明確傳入。如果你發現自己需要把 context「洩漏」跨越邊界，你的分解八成出了問題。

Cross-File 整合：將 Per-File 結果串接起來的那次處理

Per-file 本地分析 fan-out 完成後，專用的 cross-file 整合處理負責整合出任何單一 per-file 處理都無法產出的發現。

Cross-File 整合做什麼

• 偵測跨檔案的模式：某個 API 合約在不同消費者之間的不一致使用、某個工具函式在多處重複實作、某個安全模式在部分模組有套用但在其他模組中遺漏。
• 調和矛盾：若某個 per-file 審查把某個 import 標記為未使用，而另一個 per-file 審查標記它為關鍵，整合處理負責判斷哪個才是正確的。
• 產出最終的聚合成果——PR 評論、架構備忘錄、優先行動清單。

為何必須是獨立的處理

如果你要求單一 agent 在同一個 prompt 中既讀取每個檔案、又產出 cross-file 整合，注意力就會被這兩項工作稀釋。兩個窄焦點的處理——每個都把完整注意力預算投入其單一工作——勝過一個寬焦點的處理。

整合處理的輸入

整合處理消耗的是 per-file 處理的結構化輸出，而不是原始檔案。即使底層 codebase 規模龐大，這也讓整合處理的 context 預算保持可管理的大小。

分解的反模式：Chatty 子任務、循環依賴、遺失的 Context

成熟的 task decomposition strategies 部分由其避免的失敗模式來定義。

反模式一：過於 Chatty 的子任務

子任務之間傳遞 megabytes 的 context 來補償過細粒度的問題。修正方式：加粗粒度，讓更多工作可以在單一子任務內部本地決定。

反模式二：循環依賴

子任務 A 需要 B 的輸出，B 又需要 A 的輸出。這通常意味著分解邊界劃錯了地方。修正方式：將 A 和 B 合併為單一子任務，或重新劃切邊界使依賴關係單向流動。

反模式三：邊界處的 Context 遺失

Coordinator 忘記把某個關鍵 context 傳入 subagent 的 input，subagent 不是回頭詢問（增加一輪往返），就是捏造一個看似合理的替代品。修正方式：明確地記錄並稽核每種子任務類型的 input 合約。

反模式四：只有分解、沒有重新組裝

一個 pipeline 產出 per-file 輸出後就停止，期待人類來做 cross-file 整合。如果人類永遠在場，這樣是沒問題的；但如果 pipeline 應該是自主的，這就是一個 bug。修正方式：在設計中永遠包含明確的聚合步驟。

反模式五：一刀切的分解

對每個情境都使用相同的固定分解模式，不管工作是可預測的還是探索性的。修正方式：依照前文概述的線索，按情境選擇 static vs dynamic。

白話文解釋 Task Decomposition Strategies

抽象的分解模式，一旦錨定在具體的情境中，就會變得直觀。以下三個類比涵蓋了 task decomposition strategies 的完整面貌。

類比一：辦桌宴席的分工 — Static Prompt Chaining

正在舉行辦桌的廚房，是 static 循序分解的實體呈現。備料師洗菜切料；煎台師傅煎炒肉品；醬汁師傅收汁勾芡；擺盤師傅裝盤上桌。每個崗位只有一件事要做，有自己的工具，以及可預期的交接給下一個崗位。菜單事先定義好這條 chain；每一桌的紅蟳米糕都走過同樣順序的崗位。沒有任何一個崗位試圖兼做其他崗位的事——那就是盤子上的 attention dilution。

這就是 prompt chaining：每個 Claude 子步驟是一個目標收窄、工具聚焦、交接成果乾淨的廚房崗位。多面向的 PR 審查也是一樣——安全崗位、風格崗位、效能崗位，以及最後的擺盤處理，產出整合後的審查。

類比二：整修老透天厝 — Dynamic Adaptive Decomposition

為舊有 codebase 新增完整測試，就像整修一棟你從未進去過的老透天厝。你無法在第一天就寫出完整的施工時程——你不知道哪些牆是承重牆、哪些管線已經老化、哪些房間結構還算健全。於是，工程總監花第一週勘查房屋，找出風險最高的問題，排定優先順序，然後才把各個施工班分配到不同的樓層和房間。當電工發現預期外的舊式配線，計畫再次調整。

這就是 dynamic decomposition。計畫一層一層地浮現——先勘查、找出優先項目、委派具體任務——並在任何子任務回傳改變全局的資訊時，自行重塑。對一棟從沒進去過的老屋子做靜態排定的施工計畫，會是一場昂貴的災難。

類比三：多科目的開卷考 — Attention Dilution

想像你在考一場涵蓋十個不同章節的開卷考，有九十分鐘寫一篇涵蓋所有章節的論文。試圖在一次連貫的全面掃視中關注全部十個章節的考生，寫出的論文會對每個主題都淺嘗即止，也會錯過章節之間的深刻連結。更聰明的策略是切分時間：每個章節二十分鐘做聚焦筆記，最後十分鐘做整合，把所有章節筆記連接成一篇連貫的論文。

這正是 per-file 本地分析加上 cross-file 整合。每次「章節處理」對一個檔案投入完整注意力。整合處理對整合工作投入完整注意力。兩個窄焦點的處理勝過一個寬焦點的處理，因為注意力是有限資源，分割就代表損耗。

考試當天選用哪個類比

• 「可預測的 pipeline，每次執行形狀相同」→ 辦桌宴席類比 → prompt chaining / static decomposition。
• 「開放式，必須先看才能規劃」→ 整修老透天厝類比 → dynamic / adaptive decomposition。
• 「審查多個檔案，輸出感覺很淺，或遺漏了 cross-file 問題」→ 開卷考類比 → per-file 分解加整合處理。

情境演練：Code Generation with Claude Code

Code Generation with Claude Code 情境叢集是六個 CCA-F 情境之一，也是任務 1.6 題目的常見出沒地點。

情境形狀

一個 Claude Code session 被要求審查一個橫跨十幾個檔案的 pull request，並產出單一的整合審查評論，涵蓋安全性、風格和可維護性。

錯誤的分解

單一 prompt：「審查每個檔案的安全性、風格和可維護性，然後寫出整合評論。」注意力被十二個檔案乘以三個關注點稀釋，產出的觀察很淺，也遺漏了 cross-file 問題。

正確的分解

• Per-file fan-out： 每個檔案一個 subagent，每個 subagent 只針對該檔案產出涵蓋三個關注點的結構化本地審查。
• Cross-file 整合處理： 單一 coordinator 讀取十二份結構化審查，找出橫跨多檔案的主題、調和矛盾，並撰寫整合後的 PR 評論。

這個形狀直接對應 per-file 本地加 cross-file 整合的模式，也是 Claude 官方文件中推薦的架構。

情境演練：Multi-Agent Research System

Multi-Agent Research System 情境是 dynamic decomposition 題目的標準出沒地。

情境形狀

一個 coordinator 被要求針對開放式主題產出研究簡報。Coordinator 可以使用網路搜尋、內部文件檢索，以及 spawn 研究 subagent 的能力。

錯誤的分解

靜態 chain：搜尋 → 摘要 → 撰寫。Coordinator 在不先閱讀初始搜尋結果的情況下，無法事先知道哪些線索值得追蹤。靜態 chain 迫使產出一份淺薄的簡報，因為有潛力的線索被發現得太晚，來不及追蹤。

正確的分解

• 初始掃描： Coordinator 執行廣泛搜尋，閱讀頂層結果以 map 出整個領域。
• 線索識別： Coordinator 找出三到五條最有潛力的線索。
• 平行深挖： Coordinator 為每條線索 spawn 一個研究 subagent，每個都有自己的隔離 context 和聚焦工具集。
• 整合： Coordinator 把所有線索摘要聚合成最終簡報。

計畫在初始掃描之後才產生，而不是之前。這就是 dynamic decomposition。

情境演練：Claude Code 用於持續整合

CI/CD 情境叢集測驗架構師是否認識到，static、可重現的分解才是正確選擇的場合。

情境形狀

一個團隊希望 Claude Code 在 CI 上對每個 pull request 執行，並在整個組織內強制執行一致的審查標準。

正確的分解

靜態 prompt chain 在此幾乎總是正確的。每個 PR 的步驟都相同。可重現性和可稽核性佔主導地位。對每個 PR 動態重新規劃，會讓 CI 結果變得不確定，pipeline 也無法被審查。

為何不選 Dynamic？

CI 中的 dynamic decomposition 意味著每次執行都可能做不同的事，這打破了 CI 的核心合約——「相同輸入、相同輸出」。-p（非互動式）旗標、static chain 和明確的步驟定義，符合 CI 對可重現性的需求。

常見考試陷阱：CCA-F 利用的分解迷思

陷阱一：分解不會自動消除 Context 限制

常見的干擾答案聲稱分解工作流程總能解決 context window 問題。分解確實有幫助，透過給每個子任務聚焦的 context；但它不會神奇地讓 context 變成無限的。每個 subagent 仍然有 context window；把五十 megabytes 的程式碼塞進單一 subagent 的 input，和在整體式 agent 中一樣會失敗。分解是聚焦工具，不是儲存技巧。

陷阱二：Plan Mode 相關但不等同於分解

Plan mode 是 Claude Code 的一個功能，用於在執行前審查擬議計畫。Task decomposition 是關於如何切割工作流程的架構設計決策。Plan mode 可以套用在已分解的計畫上，也可以套用在整體式的計畫上。考試有時把 plan mode 呈現得好像它就是分解的全部——它不是。

陷阱三：Dynamic Decomposition 並非總是更好

社群通過報告反覆標記了在每個情境都選「adaptive」的直覺。對 CI/CD、高量結構化擷取，以及任何可預測性勝過靈活性的情境而言，adaptive 是錯的。讀情境線索——可預測性選 static，探索性選 dynamic。

陷阱四：Subagent Context 不是繼承的

假設 coordinator 的歷史會流入每個 subagent 的考生，設計出破損的系統。Task tool 和 Agent SDK subagent API 預設都隔離 context。這是提升聚焦的特性，不是需要繞過的缺陷。

陷阱五：Fan-Out 不是免費的

平行性在紙上看起來「免費」，但每個 subagent 消耗 API 配額，每次 spawn 有啟動延遲，聚合複雜度隨分支數增長。考試測驗考生是否認識到：fan-out 真正節省 wall-clock 時間的場合，和 fan-out 只是為了增加開銷的場合。

陷阱六：Per-File Fan-Out 後的 Cross-File 整合不是選配

fan-out 到 per-file subagent 後就停止、期待使用者閱讀十二份獨立報告的分解，沒有完成任務。架構師必須永遠設計整合處理。遺漏它是高頻的錯誤答案模式。

練習錨點：任務 1.6 情境題型模板

CCA-F 上關於 task decomposition strategies 的練習題，集中在五種形狀。詳細的多題演練在 ExamHub 題庫中。

模板 A：Static vs Dynamic 選擇（Code Generation）

一個團隊希望 Claude Code 用一致的 checklist 審查每個 pull request：secrets 偵測、授權合規、測試覆蓋率門檻。每個 PR 的檢查都相同。哪種分解策略合適？正確答案：static prompt chaining — 工作範圍可預測，可重現性和可稽核性佔主導地位。干擾答案聲稱 dynamic / adaptive（錯誤，因為情境訊號是可預測性）。

模板 B：Static vs Dynamic 選擇（舊有測試擴展）

一個工程團隊希望 Claude Code 為他們沒有寫過的舊有 Python codebase 新增完整測試。目標模組、優先順序和測試範疇事前不可知。哪種分解策略合適？正確答案：dynamic adaptive decomposition — coordinator 必須先 map codebase 並找出高影響力區域，計畫才有可能制定。干擾答案聲稱 static chaining（錯誤，因為計畫在看過 codebase 之前無法撰寫）。

模板 C：Attention Dilution 診斷（多檔案審查）

單一 Claude Code session 被要求在一個 prompt 中審查二十個檔案的安全性、風格和可維護性。輸出很膚淺，遺漏了 cross-file 問題。最可能的架構修正是什麼？正確答案：per-file 分解加 cross-file 整合處理 — 透過 fan-out 恢復 per-task 注意力，然後整合。干擾答案聲稱「更長的 system prompt」或「更大的 context window」（兩者都無法解決 attention dilution）。

模板 D：Subagent Context 隔離

Coordinator spawn 一個 subagent 分析特定模組，並假設 subagent 能看到 coordinator 先前關於專案慣例的討論。Subagent 忽略了這些慣例。根本原因？正確答案：subagent context 是隔離的；coordinator 沒有透過 Task tool input 明確傳遞慣例。干擾答案聲稱「模型太小，無法遵循指示」（錯誤的根本原因）。

模板 E：CI/CD 分解形狀

使用 Claude Code 的 CI pipeline 必須對每個 PR 執行相同的審查步驟，且行為需具確定性。架構師應推薦哪種分解模式？正確答案：使用 -p 非互動式模式的 static prompt chain — 可重現性佔主導地位。干擾答案聲稱「每個 PR 動態重新規劃的 coordinator-as-planner」（錯誤，因為它破壞可重現性）。

CCA-F 深度：任務 1.6 測什麼、不測什麼

CCA-F 對 task decomposition 的要求是架構層級、認知深度的認證。你需要為給定的情境識別正確的分解模式、認識 static-versus-dynamic 軸、找出 attention dilution，以及設計有明確合約的乾淨子任務邊界。

任務 1.6 對你的期待

• 認識何時要分解，以及何時單一 prompt 就夠了。
• 根據情境線索選擇 static（prompt chaining）vs dynamic（adaptive）。
• 設計 per-file 本地加 cross-file 整合的模式。
• 找出 attention dilution 的症狀，並以分解作為修正方式。
• 認識 subagent context 隔離是刻意設計的。
• 識別分解反模式（chatty、循環、context 遺失、從未重新組裝）。
• 將 CI/CD、Code Generation 和 Multi-Agent Research 情境與正確的分解形狀對應。

任務 1.6 不對你的期待

• 從零開始用 Python 實作自訂的 coordinator-planner 迴圈。
• 在程式碼層級調整 Task tool 或 Agent SDK spawning API 的特定參數。
• 在特定的模型版本或 fine-tuned 變體之間做選擇。
• 處理 streaming API 細節、視覺輸入或雲端供應商特定的部署（Bedrock / Vertex / Azure）。
• 計算分解後子任務的 token 預算或速率限制配額。

如果你的學習漂移到那些項目，你已經跨入考試範圍之外的領域。拉回到架構層級的判斷，繼續前進。

Task Decomposition Strategies 常見問題（FAQ）

CCA-F 考試中 prompt chaining 和 dynamic decomposition 的差異是什麼？

Prompt chaining 是static 的：子 prompt 的完整序列在執行前定義好，每次執行都走過相同的步驟。Dynamic（adaptive）decomposition 是邊走邊重塑的：coordinator 規劃接下來一到兩個子任務、執行它們、觀察結果，並根據學到的內容重新規劃剩餘工作。Prompt chaining 適合可預測的 pipeline，例如有固定 checklist 的 per-PR 程式碼審查。Dynamic decomposition 適合開放式工作，例如在舊有 codebase 上擴展測試覆蓋率——正確的計畫在 coordinator 調查過程式碼之前無法確定。

架構師何時應選擇 per-file 分解加 cross-file 整合處理？

只要工作橫跨超過幾個檔案，且同時需要檔案內的深度（per-file 的安全性、風格、可維護性）和 cross-file 整合（API 合約一致性、共用工具函式重複實作），就選這個模式。對多個檔案的單次審查會觸發 attention dilution——輸出變得淺薄，cross-file 的 bug 被遺漏。Per-file fan-out 恢復每個檔案的聚焦注意力；專用的整合處理恢復橫跨多檔案的整合分析。當 N 大約是五個檔案或更多時，兩個窄焦點的處理勝過一個寬焦點的處理，若檔案本身很大，門檻可以更早到來。

什麼是 attention dilution，分解如何解決它？

Attention dilution 是當單一 Claude session 被要求同時關注過多檔案、目標或關注點時，輸出品質下降的現象。推理預算被分散到每個聚焦目標，每個目標只分得 Claude 實際能力的一部分。症狀包括淺層分析、在檔案間重複的通用觀察，以及遺漏的 cross-file 模式。分解直接解決這個問題，把超載的 prompt 切分成聚焦的子任務，每個都有完整的注意力預算用於其單一目標，然後在需要整合時加入明確的整合處理。

透過 Task tool spawn 的 subagent 是否繼承 coordinator 的對話歷史？

不。透過 Task tool 或 Agent SDK subagent spawning API spawn 的 subagent，在隔離的 context 中運作。它們只看到 coordinator 透過子任務描述明確傳入的內容。這是刻意設計的：隔離防止 coordinator 的雜訊稀釋 subagent 的聚焦，並讓子任務的 context 預算保持乾淨。假設繼承的架構師設計出靜默失敗的系統——subagent 遵循錯誤的慣例、捏造遺失的 context，或提出不必要的澄清問題。永遠把 Task tool input 視為該子任務的完整 context 傳遞。

Plan mode 和 task decomposition 的關係是什麼？它們是同一件事嗎？

Plan mode 和 task decomposition 相關但不同。Plan mode 是 Claude Code 的一個功能，讓 Claude 在碰觸工具之前提出計畫，給人類審核者核准、拒絕或修改的機會。Task decomposition 是關於如何把複雜工作流程切割成子任務的架構設計決策。Plan mode 可以套用在已分解的計畫上（有用的），也可以套用在整體式的計畫上（較無趣）。分解可以在有或沒有 plan mode 的情況下進行，取決於人類審核者是否在迴圈中。CCA-F 考試經常把兩者作為彼此的干擾答案——它們不能互相取代。

Dynamic decomposition 是否總是優於 static prompt chaining？

不。Dynamic decomposition 在開放式、探索性、事前無法確定計畫的任務上表現卓越。對 CI/CD pipeline、高量結構化擷取，以及任何可預測性、可重現性和稽核軌跡比靈活性更重要的工作負載而言，它是積極錯誤的選擇。在每個情境都選「adaptive」是 CCA-F 通過報告中最一致的錯誤答案模式之一。讀情境線索：可預測性和重複性選 static；探索性和開放式選 dynamic。兩者對不同的工作都是正確模式，考試獎勵將風格與情境匹配。

Task decomposition 中要避免的主要反模式有哪些？

CCA-F 情境中反覆出現五個反模式。第一，過於 chatty 的子任務：因為粒度太細而大量傳遞 context 來補償——加粗粒度。第二，循環依賴：A 需要 B、B 需要 A——重新劃切邊界或合併。第三，邊界處的 context 遺失：coordinator 忘記傳遞關鍵內容——稽核子任務 input 合約。第四，只有分解、沒有重新組裝的 pipeline——永遠設計整合步驟。第五，不管工作是可預測的還是探索性的，都使用同一個固定分解模式——按情境選擇 static vs dynamic。

延伸閱讀

• 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
• Chain complex prompts for stronger performance: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/chain-prompts
• Building effective agents (agentic loop patterns): https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop
• Create custom subagents (Claude Code): 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
• Subagents in the Agent SDK: https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• Plan mode and iterative refinement: https://docs.anthropic.com/en/docs/claude-code/plan-mode
• Claude Code CI/CD integration: https://docs.anthropic.com/en/docs/claude-code/ci-cd

Related ExamHub topics: Multi-Agent Orchestration with Coordinator-Subagent Pattern, Multi-Step Workflows with Enforcement and Handoff, Agentic Loops for Autonomous Task Execution, Plan Mode vs Direct Execution.