↳ 以下能力與產品狀態來自目前 Claude Code 官方文件；決策規則、成本與失敗模式屬 ClaudeWorld 分析，不是效能保證。
選擇控制模型
五個介面，五種責任歸屬。
Subagents、Agent View、Agent Teams 與 Dynamic Workflows 用不同方式執行工作；Worktrees 則是能支援其中多種模式的檔案狀態隔離層。
模式 / 01 ● 已有官方文件
單次支線委派
Subagents
- 適用時機
- 一個邊界清楚的支線會產生大量搜尋結果、Logs、Tests 或檔案內容，不值得塞進主 Context。
- 誰協調
- 主對話負責委派與綜合。
- 通訊模型
- Worker 把結果交回 Caller；Peers 之間沒有 Team Channel。
- 狀態邊界
- 預設是新的 Context；需要修改時可再加 Worktree。
- 成本形狀
- 啟動成本，加上每個 Active Worker 的獨立 Context。
- 主要風險
- 若多階段必須共享同一份工作 Context，留在主對話通常更有效率。
官方來源 ↗ 模式 / 02 ◐ Research Preview
由人監督的 Sessions
Agent View
- 適用時機
- 你有多個互不依賴的完整工作，想先派出、查看狀態、回覆、Attach，再晚點回來。
- 誰協調
- 人類監督多個完整 Background Sessions。
- 通訊模型
- Sessions 回報給你，不直接彼此通訊。
- 狀態邊界
- 派出的編輯工作會使用各自 Worktree。
- 成本形狀
- 每個 Active Job 都是一套完整 Session 與 Quota 用量。
- 主要風險
- 它是營運控制台，不是 Peer-to-peer Team Protocol。
官方來源 ↗ 模式 / 03 ◐ Experimental
需要協調的同儕
Agent Teams
- 適用時機
- Workers 必須共享 Tasks、處理依賴、互傳訊息，或針對競爭假說彼此質疑。
- 誰協調
- Team Lead 負責規劃、指派與監督。
- 通訊模型
- 共享 Task List，加上 Teammate 直接通訊。
- 狀態邊界
- 不會自動替 Teammates 建 Worktrees；必須切開檔案 Ownership。
- 成本形狀
- 互動成本最高：每位 Teammate 一套完整 Context，外加協調。
- 主要風險
- 目前是 Experimental 且預設停用；更多通訊也可能變成雜訊，同檔修改仍可能互相覆寫。
官方來源 ↗ 模式 / 04 ● 已有官方文件
腳本化執行圖
Dynamic Workflows
- 適用時機
- 工作已超過少數 Workers 能管理的規模，或需要可重跑、可交叉驗證的固定執行圖。
- 誰協調
- JavaScript Workflow 保存執行計畫。
- 通訊模型
- 以結構化 Phase Output 與腳本驗證，取代自由形式的 Peer Chat。
- 狀態邊界
- 由 Workflow 與它啟動的 Workers 明確定義。
- 成本形狀
- 成本隨 Agent Runs 擴張；Budget 與 Failure Policy 必須先寫清楚。
- 主要風險
- 適合穩定的工作形狀，不適合中途需要人頻繁轉向的任務。
官方來源 ↗ 支援層 / FS ◇ 支援層
檔案狀態隔離
Worktrees
- 適用時機
- 兩個 Sessions 或 Subagents 可能同時修改同一個 Repository。
- 誰協調
- 搭配人類、Subagent 或 Session 控制模型使用。
- 通訊模型
- 沒有；Worktree 不負責協調 Workers。
- 狀態邊界
- 獨立 Checkout 與 Branch，共享 Repository History。
- 成本形狀
- 環境初始化、磁碟、Dependencies、Review 與 Merge 成本。
- 主要風險
- 它避免直接檔案碰撞，不會解決語意衝突、不安全行動或錯誤合併。
官方來源 ↗ 路由邏輯
依序問這五個問題
先使用能閉合責任的最小控制面；只有下一個答案真的需要，才加入更多 Workers。
- Q01
一個有邊界的結果，最後只需要回到這個主對話？
是 Subagents
隔離 Research、Logs、Tests 與聚焦 Review 的預設選擇。 - Q02
你想親自監督多個互不依賴的完整對話？
是 Agent View
編輯工作搭配 Agent View 建立的 Worktrees。 - Q03
Workers 必須互傳訊息或共同管理 Dependencies？
是 Agent Teams
只有 Shared Tasks 與 Mailbox 值得 Token 成本時才使用。 - Q04
工作形狀是否巨大、可重複，且需要交叉驗證？
是 Dynamic Workflows
把 Plan、Fan-out、Barriers 與 Validation 寫進程式。 - Q05
兩條支線可能修改重疊的檔案或狀態？
是 先切 Ownership · 再加 Worktrees
若 Ownership 無法切開，就把寫入階段改回循序。
平行化准入測試
每條支線都需要契約
Worker 不是計畫。Fan-out 前先把依賴、Ownership、Output 與 Merge 邊界寫清楚。
關卡 / 01 1
依賴獨立
任何支線都不必等待另一條支線尚未完成的輸出。
關卡 / 02 2
唯一 Ownership
每組檔案、狀態面或外部副作用只有一個 Owner。
關卡 / 03 3
有界回傳
回傳證據、Patch 或決策，不是未過濾的完整 Transcript。
關卡 / 04 4
狀態隔離
可能碰撞時使用 Read-only 工作或 Worktree。
關卡 / 05 5
單一 Merge Gate
由一位 Lead 綜合、測試、解衝突並驗證結果。
! 不要反射性地平行化
這些工作形狀，通常損失在協調的時間會比 Fan-out 省下的更多。
循序依賴鏈
B 必須取得 A 的結果；同時開始只會帶來等待或重工。
共享可變狀態
多個 Workers 同時修改相同 Files、Schema、Environment 或外部紀錄。
任務太小
啟動與綜合成本已經超過工作本身。
問題還不清楚
Workers 只會放大歧義，最後回傳互相無法比較的答案。
Budget 緊繃
每個 Active Context 都會使用 Quota；Concurrency 不是免費 Throughput。
參考派工
把證據平行化，把決策循序化。
安全的調查先平行收集獨立證據，再通過一次 Synthesis Barrier，最後才允許共享寫入。
任務 找出 Checkout Latency Regression 的原因，但不讓三個 Workers 搶著修改同一段程式。
FAN-OUT ↓
A / RUNTIME 檢查 Logs 與 Latency Metrics
回傳第一個分歧訊號、時間戳與證據。
B / HISTORY 檢視最近變更
回傳最小 Suspect Commit Set，並說明可能影響 Latency 的理由。
C / PATH 追蹤 Request Path
回傳量測或推論出的 Bottleneck Boundary；不要修改程式。
BARRIER → 綜合 → 單一 OWNER Lead 比較證據、選擇一個 Hypothesis、指派一位 Implementation Owner，最後執行 Tests 與 Production-shaped Verification。
PROMPT 範本 先找出彼此獨立的證據支線，只平行執行這些支線。每個 Worker 只能有一個有界回傳契約，且不能擁有重疊的寫入範圍。實作前先綜合證據，再由單一 Owner 修改並驗證。