Dynamic Workflows:script 編排前沿

17.1　Claude 寫程式來指揮上百個分身

前一章你學的多代理，是「逐回合」的：主 Claude 想一下、派一個分身、等它回、再想下一步。這在分身只有兩三個時很好用，可是當你的任務是「同一件事要在五百個檔案上各跑一遍」，逐回合就會卡——主 Claude 的對話視窗（context）會被幾百段回報塞爆，而且它得一輪一輪盯著，慢又貴。

Dynamic Workflows（動態工作流）換了個思路 ✅官方：與其讓 Claude「逐回合用嘴巴」指揮，不如讓它當場寫一支 JavaScript 小程式，由這支程式去 spawn（生出）並協調一大批分身。關鍵在於——這支「指揮程式」是純程式碼，它在跑的時候幾乎不花模型 token；每個分身回傳的中間結果，是存進程式的JS 變數裡，不會塞回主 Claude 的對話，最後只把整理好的答案交給你。

打個比方：逐回合多代理像「你一通一通打電話交辦，每個人講完你都得聽完」；動態工作流像「你寫一張 SOP 流程單交給一個排程系統，它自動把活分下去、收回來、彙整好，只把結論拿給你看」。前者你的腦袋（context）會被每一通電話佔住，後者你只看最後那張彙整表。

這不是哪個付費方案獨享的功能：Pro、Max、Team、Enterprise 都用得到，透過 Anthropic API、Amazon Bedrock、Google Cloud 的 Agent Platform、Microsoft Foundry 接進來也一樣支援 ✅官方。要留意的是 Pro 方案預設沒開，得自己進 /config 找到「Dynamic workflows」那一列手動打開；其他方案通常預設就能用。

那要怎麼觸發？你不用自己寫那支 JS，有三種方式可以叫 Claude 去寫 ✅官方。最穩的是自然語言：直接跟它說「use a workflow」或「run a workflow」，它就會判斷這個任務該不該改用動態工作流、當場把指揮程式寫出來。第二種是在 prompt 裡直接埋觸發關鍵字，只影響「這一個任務」，不會改變整個對話 session 原本的運作方式。第三種是下 /effort ultracode（或啟動時帶 claude --effort ultracode，需 v2.1.203 以上），這是整個 session 等級的開關：往後這個 session 裡，只要交辦的任務有點份量，Claude 都會自動先規劃成工作流再動手，不用你每次特別講。想退回原本逐回合的模式，下 /effort high 就好。

17.2　六種有名字的組合模式

動態工作流最實用的地方，是它把「該怎麼編排」從臨場發揮變成一套有名字的菜單——你想做哪一種，就點哪一種，Claude 知道你在講什麼 ✅官方。官方整理出六種常見組合，先用一張表認識它們，下面再各講一句白話。

你不需要背這六個英文。重點是體會一件事：以前你得在 prompt 裡用一大段話描述「先這樣、再那樣、然後比一比」，現在你可以直接講「用扇出再彙整的方式處理這五百個檔案」，Claude 就知道要寫成哪一種編排骨架。等於你跟它之間多了一套共同詞彙，溝通成本大幅下降。

光看模式名字有點抽象，直接看幾句官方給的例句最快建立手感。下面這些都是你可以整句貼給 Claude 的自然語言請求 ✅官方，每句對應一種模式——注意它們都是「請 Claude 規劃並寫出工作流」的口氣，不是要你自己動手寫 script：

— fan-out-and-synthesize：逐一審查 PR 裡每個改動的檔案，再彙整成一份排序過的總結
use a workflow to review every file changed in this PR for
correctness issues, then merge the per-file findings into
one ranked summary

— loop-until-done：改到型別檢查通過、或連續兩輪沒進展才停
use a workflow to run npx tsc --noEmit and keep fixing the
reported errors until the type check passes or two rounds
in a row make no progress

— 大規模遷移：每個檔案各自用獨立副本改，避免互相衝突
use a workflow to migrate every component under
src/components/ from styled-components to Tailwind, working
on each file in its own isolated copy

— 窄範圍研究：多來源平行查、再比較
use a workflow to research how our three competitors handle
rate limiting: read their public docs and recent changelog
entries in parallel, then compare the approaches

— loop-until-dry：連續兩輪都沒有新發現才停，避免開放式任務漫無止盡
use a workflow to find flaky tests in this repo: run the
suite repeatedly, record which tests fail intermittently,
and stop once two rounds in a row find nothing new

這些句子有共同的形狀：目標講清楚（要對什麼範圍做什麼事）、停止條件講清楚（做到什麼程度算完成），中間怎麼拆成子任務、怎麼平行、怎麼收斂，交給 Claude 去規劃就好。這也是為什麼熟悉六種模式的名字有用——你不用發明新的表達方式，套用其中一種的「形狀」去描述任務，Claude 接收到的訊號會更精準。

17.3　那個指揮者，其實是程式碼不是 Claude

上一節的例句裡，「先審查每個檔案、再彙整」「改到型別檢查過為止」這種任務，背後都有東西在幫你規劃子任務、追蹤進度、決定下一步該做什麼。這裡把話說清楚：那個指揮者（英文文件常寫 orchestrator），就是 17.1 講的那支指揮程式本身，不是 Claude 在背後一輪一輪盯場 ✅官方。程式規劃好要 spawn 哪些分身、以什麼順序、平行還是串接，分身各自把活做完、回傳結果，程式再依邏輯決定下一步——這整套「規劃、分派、收斂」的迴路，跑在幾乎不花 token 的程式碼裡，不是靠 Claude 的推理一步步現場想出來的。

這點值得說清楚，因為坊間流傳過一種講法，把這個角色叫作「Operator 模式」，講得像官方替它取的正式名字。查遍官方文件跟兩篇官方部落格，並沒有這個名詞——如果你看過這個說法，這裡先更正：它不是官方命名，別再這樣稱呼。

這也是動態工作流能撐到上百個分身還不會拖垮成本的原因：「規劃」這個最花腦力的部分被固化成程式邏輯、只需要寫一次，「執行」則交給一群可平行、可丟掉中間結果的分身。分身越多，這個結構省下的整體時間與 context 佔用就越明顯——這也是動態工作流比逐回合多代理更適合大批量任務的原因。

17.4　三個原語：agent()、parallel()、pipeline()

再往裡看一層：那支由 Claude 寫出來的指揮程式，是用三個原語（最基本的積木）拼出來的 ✅官方。你不用自己寫這些——這段是讓你看懂「指揮程式長什麼樣」，之後看到 Claude 產出的編排碼才不會陌生。

用一段示意的骨架，把這三塊放在一起感受一下。下面不是要你背語法，是讓你看出「平行收一批、再串成一條線彙整」這個形狀——讀過就好。

// 這支「指揮程式」由 Claude 自動寫出來，本身幾乎不花 token
// 1) 平行派一批分身去各看一個檔案，等全部回來（parallel = 同步柵欄）
const findings = await parallel(
  files.map(f => agent(`掃描 ${f}，回報可疑寫法`))
);

// 2) 把收回來的一堆結果，串成一條輸送帶逐段彙整（pipeline = 串流階段）
const report = await pipeline(
  findings,
  group  => agent(`把這些發現分類`),
  sorted => agent(`寫成一份總結報告`)
);

// findings、report 都只存在 JS 變數裡，不會塞回你的對話視窗

注意中間那些 findings、report 變數——它們是程式的記憶，不是 Claude 的對話記憶。幾百個分身的囉嗦回報全留在這些變數裡，最後只有 report 被交出來。這就是「零 token routing（零 token 路由）」省的地方：路由與中間結果都在程式裡，不佔模型的 context。這套也能搭配無人值守的批次模式（claude -p）一起跑，後面第 20 章會專門講。

agent() 還有一個很好用的進階寫法：第二個參數可以傳一個 JSON Schema，逼分身把答案填進一個固定格式，而不是自由發揮寫一段文字 ✅官方。像 agent(prompt, { schema }) 這樣呼叫，執行期會要求分身用「結構化輸出」的方式回答；格式沒對上，執行期會自動重試，直到符合 schema 為止。要把幾十、幾百個分身的答案彙整、排序、去重時，這比讓每個分身自由發揮、再自己手動解析文字可靠得多——上面骨架裡第一段找檔案清單的 agent()，實務上通常就會帶 schema，要的是一份能直接餵給下一階段程式的檔案陣列，不是一段散文。

17.5　核准畫面，以及一個容易被忽略的自動核准陷阱

工作流開跑前，你會先看到一個核准畫面，列出 Claude 規劃好的幾個階段（phases），讓你在真的動手之前看一眼 ✅官方。上面通常有四個選項：Yes, run it（照跑）、Yes, and don't ask again for「這個工作流」在「這個路徑」（以後同樣的組合不用再問）、View raw script（先讀過原始 script 再決定）、No（不跑）。想看得更仔細，按 Ctrl+G 能直接把整支 script 開進你慣用的編輯器逐行讀；核准前按 Tab 還能微調 Claude 準備送出的 prompt。工作流 script 是真的會產生副作用的程式碼——會改檔、會呼叫外部服務——花一分鐘看過一遍，跟看一份 PR diff 前先掃一眼是同一種謹慎。

這個核准畫面會不會每次跳出來，跟你目前的權限模式（permission mode）有關 ✅官方：default 跟 accept-edits 模式下每次都會問（除非你選過「不要再問」）；auto 模式只在第一次啟動時問一次，之後就記住不再問；bypass-permissions、claude -p（無人值守批次模式）、或透過 Agent SDK 呼叫，則完全不問、直接開跑。開了 ultracode 的 session 也會直接跳過這個提示——邏輯是你既然已經開了「自動規劃成工作流」的整體開關，等於預先同意了這個層級的自動化。

唯一的例外是 shell 指令、web fetch、以及不在白名單裡的 MCP 工具——這些仍然可能在工作流跑到一半跳出互動式核准提示，把原本該「放著在背景跑」的體驗打斷。想避免這種卡住，最好在啟動長跑工作流之前，先把分身會用到的指令、服務都加進你的工具白名單。另外要記住一個更根本的限制：工作流執行中完全不能中途插入使用者輸入——只有權限提示能讓一個 run 暫停，如果你的任務需要「做到一半先給我看一眼再繼續」，得把它拆成好幾個各自獨立的工作流分開跑，而不是妄想在一次 run 中間插話。

17.6　/workflows 面板：看它在幹嘛、暫停、重跑、存成指令

工作流一旦開跑，你不是只能乾等。下 /workflows 能打開一個監控介面，列出正在執行與已完成的工作流，選一個能鑽進去看每個階段（phase）派了幾個分身、燒了多少 token、花了多久 ✅官方。這不只是好奇心工具——手上有這面板，你才能在工作流跑歪、跑太久、或跑太貴的時候即時介入，而不是等它跑完才後悔。

按 p 暫停之後重啟，已經完成的分身會直接回傳快取結果，不會重工，只有還沒做完的部分才會重新跑——這是 17.4 提過的 journal 機制在背後撐著。但這個「可恢復」只在同一個 Claude Code session 內有效：如果工作流還在跑的時候你整個關掉 Claude Code，下次開新 session 這個工作流會從頭重跑，不是接續進度。別誤以為關掉終端機、隔天回來能無痛續跑。

如果你的專案是 monorepo，存檔位置的規則稍微複雜一點（v2.1.178 起）：存檔時會從你目前的工作目錄往上找，找到離自己最近的既有 .claude/workflows/ 存進去，都沒有的話才落在 repo 根目錄；讀取時同理，會沿路徑往上找每一層的 .claude/workflows/，同名指令以離你工作目錄最近的那層優先。大型 monorepo 裡分子專案各自維護自己的一套常用工作流，不會互相打架。

17.7　規模與成本：別讓一次 run 燒光你的額度

先說一個要有心理準備的事實：同一件事，用工作流跑一次 run，花掉的 token 可能比你在對話裡一步一步做明顯更多，而且這些用量一樣算進你方案的額度與速率限制（rate limit）✅官方——工作流省的是你的時間跟盯場的心力，不是 token。真實世界的抱怨也印證了這件事：曾有使用者反映只是想對一個不算大的套件做 code review，工作流一次展開出 90 個分身，直接把 Max 方案的額度用光 🌐社群。

出錯時的恢復也會加倍吃 token：工作流碰到錯誤，Claude 會嘗試換工具、推理哪裡出錯、重試，一次卡關的恢復流程可能比「一次做對」多花五倍 token 🌐社群。意思是「反正讓它自己修到過」聽起來省事，但如果任務本身失敗率高，工作流可能比你在旁邊盯著逐步做還貴——這筆帳最好在按下「Yes, run it」之前先算過。

比較主動的做法，是先在 /config 裡設 Dynamic workflow size 這個 guideline（需 v2.1.202 以上）✅官方：unrestricted（預設，無指引）、small（目標少於 5 個分身）、medium（少於 15 個）、large（少於 50 個）。這只是「送給 Claude 的建議」，如果你在 prompt 裡明講要更大或更小的規模，可以覆蓋它；但不論怎麼設，17.1 提過的硬上限（16 併行、單次 1,000 總量）永遠適用，不受這個設定影響。

真的想完全關掉這個功能，官方給了四種方式 ✅官方，效果都是跨 session 持續生效：在 /config 裡切換「Dynamic workflows」開關；在 ~/.claude/settings.json 設 "disableWorkflows": true；設環境變數 CLAUDE_CODE_DISABLE_WORKFLOWS=1；如果是組織帳號，管理者可以在 managed settings 或後台的 admin 設定裡統一關掉。關掉之後，內建工作流指令會消失、ultracode 關鍵字不再觸發、/effort 選單也不會再列出 ultracode 這個選項。

實務上，比較安全的節奏是這樣：

1. 1
   ✋動手做

   先在小範圍試跑

   挑一個資料夾而不是整個 repo、一個窄範圍的問題而不是廣泛提問，先跑一次看看它規劃出多少分身、大概花多少 token。

2. 2
   ✋動手做

   用 /workflows 盯著 token 用量

   跑的過程中隨時打開 17.6 的監控面板，看目前燒了多少、還剩幾個 phase。覺得規模跑超出預期，隨時可以按 p 暫停或 x 停掉。

3. 3
   ✋動手做

   放心停：已經做完的部分不會不見

   停掉一個 run 不會讓你前功盡棄——已完成的分身結果還在，你可以先看那些部分夠不夠用，或調整 prompt 縮小範圍後在同一個 session 裡恢復執行。

   ✅ 預期會看到

   你會抓到一個對「這個任務值不值得開這麼大」的手感，而不是每次都被系統規劃的規模牽著走。

17.8　grader 迴圈：把品質閘門寫進編排

最後一個觀念，是把前一章「不信『看起來做完了』」的精神，直接寫進程式。做法是在工作流裡放一個專職的 grader（評分員）分身：每當其他分身交出產出，grader 就依一份rubric（評分標準）打分，不達標就退回去重做，一輪一輪直到通過為止。等於把「對抗式審查」和「迭代到符合規格」這兩件事，codify（固化）成編排的一部分，而不是靠你每次手動盯。

這正好是 17.2 裡「迴圈到達標」加上「對抗式查驗」的組合實作：產出 → 評分 → 不過就回爐 → 再產出，迴圈跑到綠燈。它的價值在於——你不再相信「單次跑完就是好」，而是讓品質門檻自己把關，這跟整本書反覆強調的「拿證據說話、別空口宣稱成功」是同一條心法。

這個案例本身的規模值得細看，因為它幾乎是動態工作流目前公開紀錄裡規模最大的一次實戰——把 Bun 原本用 Zig 寫的核心，移植成 Rust。不同來源給出的數字略有出入，並排放在一起看比較不會誤解：

把這些數字放回 17.7 的成本提醒來看更有感：Bun 官方部落格算過，這次移植總共餵進約 59 億 input token（未快取）加 6.9 億 output token，另外還有 720 億 token 是從快取讀取，估計花費大約 16.5 萬美元 👤達人個人。這不是一個「隨手跑跑」的規模，而是一間公司願意投入的一次性重大工程決策——回頭看 17.7 講的「工作流一次 run 可能比逐步做貴上不少」，這正是那句話的極限案例。值得一提，這次移植動用的模型是當時仍處於 pre-release 階段的 Claude Fable 5——某種程度上，這場 Bun 移植本身就是 Fable 5 正式上線前的一場大型實戰壓力測試。

比數字更值得學的是它的編排結構。每個檔案的移植流程固定四個角色 👤達人個人：1 個實作者負責把 Zig 邏輯改寫成 Rust、2 個對抗式 reviewer各自獨立審查——重點是這兩個 reviewer只看 diff、被明確要求預設它是壞的、也看不到實作者的推理過程，只看得到最終輸出，避免被實作者的說詞牽著走；最後一個修復者依 reviewer 的意見收尾。正式大規模開跑前，他們先挑 3 個檔案做小規模試跑，確認「實作者＋兩個 reviewer＋修復者」這套組合真的可行，才放大到全部 1,448 個檔案——這跟 17.7 建議的「先小範圍試跑」是同一個心法，只是換了個更大的舞台驗證。

前置作業也做得紮實：他們先寫了 PORTING.md，把「Zig 的某種寫法該對應 Rust 的哪種寫法」整理成一份映射規則；又寫了 LIFETIMES.tsv，把每個 struct 欄位該用哪一種 Rust 生命週期（lifetime）序列化分析成一張表。這兩份文件等於是餵給所有實作者分身的共同規格，減少「同一個模式在不同檔案被翻譯出不同寫法」的不一致。轉完之後，cargo check 一次跑出約 16,000 個編譯錯誤，改用 64 個平行 Claude 依 crate（Rust 的模組單位）分組去修，處理循環依賴跟型別不合的問題。

合併前抓到的幾個具體 bug，很適合當「代理人也會犯錯、但抓得出來」的例證：

這三個 bug 有個共通點：都不是「代理人亂寫」，而是兩種語言底層語意的落差被翻譯過程放大——這正是對抗式 reviewer 該抓的那種問題，也說明了為什麼「只看 diff、預設它是壞的」這個角色設定重要：如果 reviewer 對實作者的推理有先入為主的信任，這種細節很容易被放過。

真要自己試這套模式，流程大致是這三步：先寫清楚 rubric（什麼叫「合格」），再讓工作流在每次產出後自動套用，最後設好「沒過就退回重做」的迴圈邊界。

1. 1
   ✋動手做

   先把 rubric（評分標準）寫成白紙黑字

   用一句一句的條件描述「怎樣才算合格」，例如「所有測試通過、沒有新增 lint 錯誤、函式有對應測試」。標準越具體，grader 越判得準，少一點各說各話。

2. 2
   ✋動手做

   讓工作流在每次產出後自動套這份標準

   在你的工作流描述裡，明講「每個分身交出結果後，派一個 grader 依上面的 rubric 打分」。這個 grader 就是專職挑毛病的那個角色，跟做事的分身分開。

3. 3
   ✋動手做

   設好「沒過就退回重做」的迴圈邊界

   講清楚「不達標就退回該分身重做，直到通過」，同時給一個上限（例如最多重試幾輪），避免它在某個怎麼改都過不了的點上無止盡空轉。

   ✅ 預期會看到

   工作流會自己「產出 → 評分 → 不過退回 → 再產出」地跑，最後只把通過 rubric 的結果交給你，中間那些被打回票的版本不會來煩你。

17.9　小結

這一章你認識了 2026 年隨 Opus 4.8 來的新一層編排——Dynamic Workflows。把它收進腦袋的話，記這幾條就夠：

• 動態工作流＝讓 Claude 當場寫一支 JS 指揮程式去協調大批分身；那個「指揮者」的角色是程式碼在跑，不是 Claude 逐回合現場想，別跟第 16 章的 Agent Teams（Claude 親自指揮、需開實驗性旗標）搞混 ✅官方。
• 記住三個門檻：最多 16 併行、單次 1,000 上限、需 CLI v2.1.154+；Pro 方案要自己去 /config 手動開。觸發方式有三種——自然語言「use a workflow」最穩、prompt 內埋關鍵字只影響單一任務、/effort ultracode 則是整個 session 都自動規劃成工作流。
• 有六種有名字的組合模式（分類再行動、扇出再彙整、對抗式查驗、先生成再篩選、淘汰賽、迴圈到達標），它們是你跟 Claude 的共同詞彙，可以疊用。
• 底層用 agent() / parallel() / pipeline() 三個原語拼成編排：預設用 pipeline()，只有真的需要「大家到齊」才上 parallel()；script 裡不能用 Date.now()／Math.random()，這是為了讓「暫停後恢復」可靠而故意設計的限制。
• 安全紅線：不論 session 權限模式為何，工作流底下的分身一律自動核准編輯；跑之前先把會用到的指令加進白名單，並確認自己真的要授權這個等級的自動化。
• /workflows 能看進度、暫停、重跑、存成可重用指令；規模與成本記得盯——一次 run 可能比逐步做貴上不少，善用 /config 的 size guideline 跟小範圍試跑控制風險。
• grader 迴圈把品質閘門寫進程式：產出後自動評分、不過退回重做——這是達人自建模式（Bun 從 Zig 移植到 Rust 的實戰驗證過），不是內建按鈕 👤達人個人。
• 更新記錄：/deep-research 現在已經是官方內建的研究工作流，如果你看過「沒有這個指令」的舊說法，那是版本較舊時的正確資訊、現在已經更新了。

下一章我們從「一支程式指揮上百分身」回到「你同時開好幾個 Claude」——用 Git Worktrees 讓多個 session 各有獨立工作目錄、互不打架。

17.10　動手試試

這一章偏觀念，不急著大規模實作。下面四題由淺到深，挑你做得到的試，務必先在不重要的測試專案、用小範圍試，別一上來就對正式專案放幾百個分身。

1. 先 claude --version 確認你的版本有沒有到 v2.1.154 以上。沒到的話這章的功能就還用不了，先記著、升級後再回來。
2. 找一個有十幾個檔案的小測試專案，跟 Claude 說：「use a workflow，幫我掃這個資料夾每個檔案有沒有明顯的 typo，最後彙整成一份清單。」觀察它是不是改用了平行扇出、最後只給你一份彙整，而不是逐檔囉嗦回報。
3. 執行的時候另開一個念頭：跑到一半下 /workflows 看看監控面板長什麼樣，試著按 Enter 鑽進某個分身看它的 prompt，再按 Esc 退出來。找一次機會按 p 暫停、再按一次恢復，感受一下已完成的部分是不是真的沒有重工。
4. （進階）把第 2 題加一道品質關：請它在彙整之後，多派一個 grader 依「每筆都要標出檔名與行號」這條 rubric 檢查，不合格就退回補齊。體會一下「把驗證寫進編排」跟「自己事後手動檢查」的差別。