Claude Code Dynamic Workflows 實戰指南 2026：動態工作流從啟用到六種 Orchestration Pattern

Claude Code v2.1.154 悄悄改變了 AI 輔助開發的規模邊界。原本需要開發者手動設計 orchestration 邏輯的平行工作流程，現在讓 Claude 自動生成一段 JavaScript script，在你的 context 之外獨立執行，最多協調 1,000 個 subagent 並行工作。

但「能做到」和「值得做」是兩回事。這篇指南不打算告訴你 Dynamic Workflows 有多強大，而是幫你搞清楚：什麼時候用、怎麼控制成本、六種 orchestration pattern 各適合什麼任務，以及哪些用法會讓你多花 50 倍 token 卻一無所獲。

根據 Anthropic 官方文件及社群實測，以下所有技術細節均已交叉確認。

TL;DR

• Dynamic Workflows 是「事件驅動的 orchestration 架構」，不是單純的平行執行
• 適合任務：10 個以上的獨立子任務、可並行處理、需要品質交叉驗證
• 不適合：探索性任務、需逐步確認、嚴格 token 預算的日常開發
• 成本放大 10-50 倍，但有四個具體控制策略
• 最快入門：/deep-research <問題> 五分鐘內體驗

什麼是 Dynamic Workflows？三分鐘概念釐清

大多數人第一次聽到 Dynamic Workflows，直覺反應是「就是讓 Claude 同時跑多個任務」。這個理解有一半對，但漏掉了最關鍵的部分。

認知翻轉：你以為 Dynamic Workflows 只是「讓 Claude 同時跑多個任務」，但它實際上是一個事件驅動的 orchestration 架構。Claude 生成的不是對話，而是一段 JavaScript script，由獨立 runtime 在 Claude 的 context 之外執行。

架構流程是這樣的：

你的 prompt → Claude 分析任務 → 生成 JS orchestration script
→ runtime 獨立執行 script → 依序呼叫 subagents
→ 結果儲存到 script variables → 完成後回傳給你

這意味著：1,000 個 subagent 的中間結果不會塞滿你的 context window，workflow 的狀態存在 script variables 裡，不是 Claude 的記憶裡。一旦你理解這個差異，後面的決策就很清楚了。

核心規格（來源：Anthropic 官方文件）：

• 最多 1,000 個 subagents / run
• 最多 16 個並行執行
• 需要 Claude Code v2.1.154+（claude --version 確認）
• 支援方案：Pro（需手動啟用）/ Max / Team / Enterprise（預設開啟）

Dynamic Workflows vs. 手動平行 Worktrees：何時用哪個？

很多已在用 Claude Code parallel worktrees 的開發者會問：要切換嗎？答案是：不是替代，而是不同規模的工具。

面向	手動 Parallel Worktrees	Dynamic Workflows
誰寫 orchestration 邏輯	開發者手動設計	Claude 自動生成 JS script
結果存放	每個 agent 的 context window	Script variables（不佔 Claude context）
中斷可恢復性	重啟整輪	Session 內可 resume
規模	受 context 限制	最多 1,000 agents / run
可重複執行	需重新設定	儲存為 /<command> 可重複觸發

兩者並非互斥：Dynamic Workflows 內部仍可在 worktrees 中運行 agents，用 worktree option 隔離文件修改。

三維決策矩陣

適合用 Dynamic Workflows 的情況：

• 任務可拆成 10 個以上的可並行獨立子任務
• 需要交叉驗證（adversarial verification）確保品質
• 任務本身可接受較高 token 成本
• 同一類型任務需要重複執行（儲存後重複觸發）

繼續用手動 worktrees 或對話的情況：

• 子步驟少於 5-10 個
• 需要逐步確認每一步的人工 sign-off
• 嚴格 token 預算限制的日常開發
• 探索性、創意性或早期設計階段任務

一個簡單的判斷標準：如果你正在思考「我可以把這個任務拆成幾個平行的子任務」，那 Dynamic Workflows 可能值得用；如果你在思考「接下來我要做什麼」，就繼續用對話。

三種觸發方式實作：從 workflow 到 /deep-research

Dynamic Workflows 有三種進入方式，複雜度依序遞增，你可以根據需求選擇。

方式 1：workflow 關鍵字（單次觸發）

在 prompt 開頭加上 workflow: 就能觸發 Dynamic Workflow：

workflow: audit every API endpoint under src/routes/ for missing auth checks

版本注意：

• v2.1.154 - v2.1.159：精確關鍵字為 workflow:，同時也支援自然語言觸發
• v2.1.160+：觸發方式更靈活，自然語言支援更完整（如「use a workflow to audit...」）

自然語言觸發在兩個版本都有效；版本間的差異在於精確關鍵字本身（v2.1.160 前用 workflow:，v2.1.160 後選項更多）。

另一個範例，適合 codebase migration：

workflow: migrate all React class components under src/components/ to functional components with hooks, then run tests to verify

方式 2：/effort workflow（Session 全自動模式）

在 session 開始時輸入 /effort ultracode，Claude 會結合 xhigh reasoning，自動判斷哪些任務需要 workflow、哪些用一般對話就夠了。這個模式在 session 結束後會重置，不會影響下次啟動。

適合場景：你有一個複雜的工作 session，裡面混雜了探索性任務和執行性任務，讓 Claude 自己判斷哪些要 workflow。

方式 3：/deep-research（立即體驗，零設定）

最快的入門路徑：

/deep-research 台灣 2026 年 AI 新創融資趨勢，比較 Q1 和 Q2 的變化

這是一個內建的 workflow，會自動做多角度 web search、交叉驗證資訊、整合成帶引用的報告。不需要任何設定，不需要理解 orchestration，五分鐘就能感受 workflow 的差異。

執行後的操作

workflow 啟動後，你會看到 /workflows 視圖，幾個核心操作：

按鍵	功能
/workflows	查看所有 workflow 執行進度
p	暫停 / 繼續
x	停止（不損失已完成的工作）
s	儲存為 /<command> 可重複觸發

Pro 方案特殊步驟：需先進入 /config，找到 Dynamic workflows 那一欄手動啟用，否則 workflow 關鍵字不會有任何反應。

Enterprise 方案：需要 admin 先在 Claude Code admin settings 頁面啟用，使用者端才看得到選項。

六種 Orchestration Pattern 實戰場景

Anthropic 官方文件定義了六種核心 orchestration pattern。重要的認知：這六種 pattern 通常是組合使用的，不是單選。

1. Classify-and-act（分類執行）

邏輯：先依任務類型分流，再把不同類型交給對應的 agents 處理。

適合場景：

• 大量 GitHub issues 的 triage（按 bug / feature / question 分類，各自觸發不同流程）
• 客服 queue 分流（技術問題 vs. 帳務問題 vs. 功能建議）

workflow: triage all open GitHub issues in this repo, categorize by type (bug/feature/docs/question), assign priority (P0/P1/P2), and add appropriate labels

2. Fan-out-and-synthesize（分散合併）

邏輯：把大任務拆成平行子任務，各自執行後合併結果。

適合場景：

• 大型 codebase migration（同時處理多個模組，而非一個一個跑）
• 多個文件或 API endpoint 的統一審查

Anthropic 官方部落格提到的 Bun 案例：750K 行的 codebase port 任務，用 fan-out 把 codebase 切成多個模組，平行執行後合併，大幅縮短整體時間。

3. Adversarial verification（對抗驗證）

邏輯：同一個問題讓多個獨立 agents 各自回答，再讓另一個 agent 比對、驗證差異。

適合場景：

• Security audit（讓兩個 agents 各自找漏洞，第三個 agent 交叉比對）
• 高可信度研究報告（避免單一 agent 的確認偏誤）
• 生產級 code review（比單一 agent review 更難遺漏問題）

這是需要「確保沒有漏掉任何東西」時最有效的 pattern。

4. Generate-and-filter（生成篩選）

邏輯：先產生多個候選方案，再依評分標準過濾到最優解。

適合場景：

• 架構設計選型（產生五個方案，評分後留下最佳）
• API 設計評估（多個設計並行，過濾掉不滿足條件的）
• 命名方案、UI 設計選項等創意性任務的後期收斂

5. Tournament（錦標賽比較）

邏輯：pairwise 比較（A vs. B，C vs. D，最後贏家互比），直到選出最終答案。

適合場景：

• 多個實作方案的最終選擇
• 效能比較（五個演算法，錦標賽決出最快）
• 設計評估（不同的 UI pattern）

Tournament 和 Generate-and-filter 的差異：Filter 是用標準過濾，Tournament 是用對比選擇，前者適合有明確評分標準的情況，後者適合需要主觀判斷的選擇。

6. Loop until done（條件循環）

邏輯：持續觸發直到滿足指定條件。

適合場景：

• 修 bug 直到所有測試通過（不是手動一個一個跑）
• 程式碼重構直到 linting score 達到閾值
• 安全掃描直到沒有 critical 或 high 等級漏洞

workflow: fix all failing tests in src/__tests__/, run the full test suite after each fix, loop until all tests pass or you've tried 10 iterations

真實組合案例

大型 codebase migration 的完整流程通常是：

1. Fan-out：把 750K 行 codebase 按模組切開，16 個 agents 並行處理
2. Adversarial verification：每個模組的輸出讓獨立 agent 驗證，確保沒有引入新 bug
3. Tournament：有多種實作方式的模組，用 tournament 選出最終版本

不是「選一種 pattern 套到底」，而是按任務的不同階段組合。

Token 成本估算與管理

這是 Dynamic Workflows 最常被低估的面向。

成本現實：Dynamic Workflows 的 token 消耗可比一般對話高 10-50 倍。來自社群的實測案例：113 個 agents 執行了 1.95M tokens，耗時 12.5 分鐘。

成本區間大致如下：

• 窄任務（10 個以下 agents）：約 10k - 50k tokens
• 中型任務（20-50 個 agents）：約 200k - 500k tokens
• 大型 migration（100+ agents）：1M - 2M tokens 以上

四個控制策略

策略 1：先跑小範圍

不要第一次就跑整個 repo。先用一個目錄或一個模組測試，確認 workflow 的輸出符合預期後再擴大範圍：

# 先測一個目錄
workflow: audit API endpoints under src/routes/auth/ for missing auth checks

# 確認 OK 後再擴大
workflow: audit all API endpoints under src/routes/ for missing auth checks

策略 2：分層使用模型

在 prompt 中明確指定輕量任務使用 Haiku，複雜推理才用 Sonnet 或 Opus。依 Anthropic pricing 頁，Haiku 比 Opus 便宜約 15-25 倍（實際倍率依模型版本調整，請查閱當時的官方 pricing 頁）：

workflow: use haiku for classification and formatting tasks, use sonnet only for code generation and reasoning steps; audit all components under src/

策略 3：結構化 handoff

agents 之間只傳必要的結構化摘要，不傳完整 context history。這需要在 prompt 中明確說明你要的輸出格式：

workflow: for each module, output only: module name, issues found (list), recommended fixes (list). Do not include full code in the handoff.

策略 4：設定 token budget

在 prompt 中明確設定預算，讓 Claude 在限制內工作：

workflow: use approximately 10k tokens total; audit the most critical API endpoints first, stop when budget is reached

即時監控：/workflows 視圖顯示每個 agent 的即時 token 用量，可隨時按 x 停止，已完成的工作不會消失。

常見反模式：這樣用會出問題

根據官方文件和社群實測，整理出五個最常見的錯誤用法。

反模式 1：用 workflow 做探索性任務

問題：探索性任務結果難以預期，浪費大量 token 在無用輸出，而且你無法在中途調整方向。

正確做法：先用一般對話釐清方向和 approach，確認方向後再用 workflow 執行。Dynamic Workflows 適合「你已經知道要做什麼」的執行階段，不適合「還在想要做什麼」的探索階段。

反模式 2：不分段設計長 workflow

問題：Dynamic Workflows 的可恢復性是「session 內」，關閉 Claude Code 後重開新 session，必須從頭開始，不跨 session 恢復。一次跑太長的 workflow，中斷後全部重來。

正確做法：設計多個短 workflow，每個有明確的 input/output 邊界。例如把一個大型 migration 拆成「分析 + 規劃」「執行模組 A-E」「執行模組 F-K」三個獨立 workflow，每個完成後確認結果再觸發下一個。

反模式 3：讓所有 agents 用 Opus

問題：10-50x 成本放大，大多數 sub-tasks（分類、格式化、搜尋）根本不需要 Opus 的推理能力。

正確做法：只有需要複雜推理的 agents 才用 Opus 或 Sonnet，分類、格式化、資料擷取等輕量任務明確指定用 Haiku。

反模式 4：在舊版本用錯關鍵字觸發

問題：v2.1.154 - v2.1.159 的精確關鍵字是 workflow:，而不是其他變體。自然語言在兩個版本都有效，但如果你用了錯誤的精確關鍵字，Claude 只會用一般對話回應，且不會提示你觸發失敗。

正確做法：先 claude --version 確認版本。v2.1.160 前使用精確的 workflow: 前綴；v2.1.160+ 觸發選項更靈活。自然語言在兩者都適用。

反模式 5：把 workflow 當一般任務管理工具

問題：Dynamic Workflows 執行中無法插入使用者指令。如果你的工作流程需要「跑完第一步，我確認一下，再跑第二步」，Dynamic Workflows 的設計無法支援這種需求。

正確做法：把有人工確認節點的工作流程拆成多個獨立 workflow，每個 workflow 完成後手動確認結果，再觸發下一個。或改用手動 worktrees + 逐步對話的方式。

結論

Dynamic Workflows 改變的不是 Claude 能做什麼，而是「誰來設計工作流程」。過去需要開發者手動拼 orchestration 邏輯，現在這件事交給 Claude 做，開發者只需要知道「我有哪些任務要跑」和「我能接受多少 token 成本」。

最低門檻的入門方式：/deep-research <問題> 是零設定的體驗路徑，五分鐘就能感受 workflow 的差異。確認版本是 v2.1.154 以上後，用 /deep-research 試跑一個你實際關心的研究問題，看看 workflow 視圖裡的 agents 是怎麼協作的。

進階後，再按本文的決策框架，把你實際專案的 migration 或 audit 任務套進去。重點是先用小範圍測試，確認 token 成本在可接受範圍內，再擴大到整個 codebase。