Claude Code Dynamic Workflows 完整教學 — 讓 AI 自己寫腳本，在背景指揮上百個分身

把時間倒回去看，會比較容易看懂這次的改變到底大在哪。

一年多前，你想讓 AI 同時幫你做好幾件事，唯一的辦法是當人肉排程器。開三個終端機視窗，第一個叫它改 API、第二個叫它寫測試、第三個讓它跑 lint，然後你的眼睛在三個視窗之間跳來跳去，誰卡住了你補一句、誰跑完了你接著派下一個。AI 在做事，但調度它的是你，而且你一次只能盯住有限的幾個。

後來 subagent 出現，往前走了一步。Claude 開始能自己派分身去處理子任務，你不用再手動開視窗了。但這裡藏了一個很多人沒注意到的代價：每一個 subagent 做完事，它的中間結果都會回流到 Claude 主對話的 context window 裡。十個分身回來十份半成品，全堆在同一張桌子上，你寶貴的 context 就這樣被一堆「過程」吃掉，留給「真正在想的事」的空間越來越小。而且決定下一個該派誰，還是 Claude 在對話裡一輪一輪臨場判斷——它本質上還是個工頭，只是工頭從你變成了它。

到了四月的 Agent Teams，規模又上一個量級——16 個 Claude 實例真的同時開工，誇張到能合力寫出一個編譯 Linux kernel 的 Rust 版 C 編譯器。但骨子裡，它還是「很多個實例平行跑」這個思路的放大版。

然後 5 月 28 號，Anthropic 連同 Opus 4.8 一起，開放了 Dynamic Workflows 的研究預覽。這次變的不是數量，是調度這件事本身搬家了。

轉捩點：把「計畫」從對話搬進程式碼

先講清楚這個轉變，後面才看得懂為什麼是大事。

傳統 subagent 的調度邏輯，活在對話裡。Claude 每講完一輪，才決定下一步派誰、要不要重試、結果怎麼合併——這些判斷全都耗在它的「思考」上，而且狀態全擠在 context window。

Dynamic Workflows 把這套搬走了。你提一個需求，Claude 不直接動手做，而是先即時寫出一段 JavaScript 編排腳本——這段腳本描述：要開哪些 agent、誰先誰後、什麼條件下要迴圈、結果怎麼匯總、哪些要交叉驗證。寫完之後，交給一個獨立的 runtime 在背景執行，由它去把數十到數百個 subagent 開起來跑。中間那些半成品，存在腳本的變數裡，活在對話之外——不再回頭塞爆 Claude 的 context。

打個比方。傳統 subagent 像一個工頭站在工地中央，每個工人做完一個動作都跑回來跟他講一聲、等他下指令，工頭的腦袋很快就被一堆回報塞滿。Dynamic Workflows 則是工頭先坐下來畫一張完整的生產線排程表——幾號工位做什麼、做完流到哪、哪兩道工序要互相檢查——然後把表貼到牆上，工人照表自己跑，工頭只在關鍵節點看一眼、最後驗收。差別在於：前者的「計畫」是邊做邊想的口頭指令，後者的「計畫」是一份寫死的、可以被機器執行的文件。

這就是為什麼它要用程式碼，而不是繼續用自然語言。自然語言很適合表達「我想要什麼」，但它表達不好「迴圈 50 次、每次條件不同、失敗要重試兩次、三個結果取多數決」這種控制流。控制流是程式語言的母語。把編排寫成 JavaScript，不是為了炫技，是讓對的工具做對的事——意圖用講的，流程用寫的。

它能撐到多大

研究預覽階段的數字已經很驚人：一個 workflow 單次執行最多能協調 1000 個 agent，但同時並行的上限是 16 個——這個天花板是刻意壓的，為的是不要把一台普通的本機資源吃乾。所以你可以丟 100 個檔案讓它處理，它會排隊跑，大約 16 個同時動，做完一個補一個。

最有說服力的，是 Bun 作者 Jarred Sumner 的案例。他用 Dynamic Workflows 把 Bun 從 Zig 移植到 Rust——大約 75 萬行 Rust、現有測試套件 99.8% 通過、從第一個 commit 到合併只花了 11 天。其中一個 workflow 專門負責替 Zig 程式碼裡每個 struct 欄位推算出對應的 Rust lifetime；下一個 workflow 則把每個 .zig 檔逐一改寫成行為一致的 .rs 檔，數百個 agent 平行動工，而且每個檔案都配兩個 reviewer 在旁邊盯。

注意那個「每個檔案兩個 reviewer」——這正是 workflow 跟「一堆分身亂跑」的本質差異。它不只是平行，它把「驗證」也寫進了編排：產出之前先彼此檢查、反覆收斂到答案對齊，才送到你面前。

怎麼觸發

實際用起來有兩種方式，都不複雜。

第一種，直接開口。在對話裡明講「幫我建立一個 workflow，去……」，Claude 會判斷這個任務適不適合，然後寫腳本。執行前它一定會先讓你確認——這不是那種你按了 enter 它就在背景燒掉一大筆 token 的東西，它會先給你看它打算怎麼跑。

第二種，開 ultracode。在 effort 選單裡把設定切到 ultracode，它會把 effort 拉到 xhigh，並且讓 Claude 自己決定什麼時候該動用 workflow。適合你已經信任它的判斷、想讓它在大任務上自動展開火力的時候。

兩件事要先知道：第一，它很吃 token，官方明講「可能比一般 session 消耗多得多」，所以第一次玩請從一個範圍明確的小任務開始，先摸清楚它大概花多少；第二，如果你在公司環境，組織管理員可以透過 managed settings 直接把這功能關掉，發現用不了先去問 IT。

什麼時候該用，什麼時候別用

不是每件事都該召喚一百個分身。判斷的關鍵在於：你的任務能不能「切成很多塊、每塊獨立做、最後再合」。

三類任務特別合適。一是大規模 codebase 稽核——平行去搜，每條發現各自獨立驗證，比你自己一個檔案一個檔案翻快得多。二是大型遷移——像上面 Bun 那種橫跨上千個檔案的框架替換，本來就是天然可平行的。三是需要高把握的關鍵驗證——同一件事讓多個 agent 用不同角度獨立做幾遍，再加對抗式測試，最後比對結果，比單跑一次可信得多。

反過來，如果你的任務是一條長鏈、每一步都得等前一步的結果才能動，那 workflow 幫不上忙，平行不起來。硬要用只是白燒 token。挑工具有個很可靠的直覺：複雜的方案一定是拿某個代價換來的，這裡換的代價就是 token 跟設定成本，任務沒大到值得這個代價，就別動用。

順帶一提，這條路不只 Anthropic 在走。Google 這次 I/O 推的 Antigravity 2.0 也在做多 agent 編排跟動態子代理，方向幾乎撞在一起。整個產業正在從「一個很強的 AI」往「一個會調度一群 AI 的 AI」移動——這個轉向值得你放在心上。

寫到這裡，誠實補一句

Dynamic Workflows 目前還是研究預覽，跟著 Opus 4.8 一起出來才幾天，很多邊角狀況（背景任務失控的處理、token 的可預測性）還要時間磨。上面 Bun 的數字是官方分享的標竿案例，不是你隨手跑就能複製的成績。

但就算把預覽的不確定性都算進去，那個底層的轉變方向是清楚的：AI 協作的下一關，不是讓單一模型更聰明，而是讓它學會把一個大問題拆成一張可執行的施工圖。當「計畫」開始長得像程式碼，你跟 AI 的關係，也悄悄從「對話」變成了「託付」——你交出去的不再是一句句指令，是一整個任務。下次你面前又出現一個大到不知從何下手的工程，也許值得先問它一句：這個，能不能變成一個 workflow？