TL;DR：Claude Code 5/28 釋出 dynamic workflows，跟 Opus 4.8 同一天上。表面是「可以開 1,000 個 subagent」，我覺得真正有意思的是這個鏡頭：在 workflow 裡，Claude 不是執行者，是 orchestrator script 的「作者」——它寫出那段 JS，丟給 runtime 跑，自己只看最終結果。這個位置感的變化我覺得比那個數字耐看。

我是在追 Opus 4.8 的 release notes 的時候注意到 dynamic workflows 這條。它表面上是「subagent 上限拉高、能 parallel 跑」，但把 官方 docs 跟 Anthropic 那篇 blog 的延伸版本 讀完，重點其實不在數字——它真正調動到的是「Claude 在 agentic 流程裡扮演什麼角色」。這篇想把那個鏡頭講清楚，順便寫幾個我看完還沒想通的問題。

不是把 loop 加粗，是把 loop 搬走

subagent 原本的心智模型是這樣：你下一個 prompt，Claude 拆解、開幾個 helper 去做、helper 把結果回給 Claude、Claude 再決定下一步。這個 loop 對小任務沒問題，可是只要 helper 數量上去（比如一次要看二十個檔案、做一輪 cross-check），loop 就會卡在 Claude 自己身上：context window 變成 logbook，每個 helper 的 output 都堆回來，到後面想思考都沒空間。

直覺會以為 dynamic workflows 就是把這條 loop 加粗，讓 Claude 一次能管更多 helper。其實不是。它把整條 loop 拔出來、搬到一段 JS 裡跑，Claude 從「執行 orchestration」變成「寫出 orchestration」——差別就在這。

把 Claude 想成 orchestration 的編譯器

這是我目前覺得最好用的鏡頭，雖然不太確定有沒有比喻過頭。

傳統的 agentic flow，Claude 是 runtime：你給它任務，它一步一步算下去，每步都在它的 context 裡發生。dynamic workflow 把這件事拆成兩階段：Claude 先當「編譯器」，把你的需求轉成一段 JS 程式碼——這段程式碼描述了 orchestration 該怎麼跑、誰先誰後、結果怎麼匯整。然後另一個 runtime（這次是 Claude Code 內建的 workflow runtime）負責執行這段 JS。

這個鏡頭一旦套上去，幾件本來看起來零散的設計就會自動對齊。為什麼上限是 1,000、concurrent 16？因為 runtime 在跑、它看得到全局，可以擋。為什麼中間結果都在 script 變數裡？因為 runtime 跑 script 的時候那本來就是 JS object，不需要塞回 LLM context。為什麼一段 workflow 可以存起來變 /<name> 重複用？因為它本來就是一個檔案，存哪都一樣。這些都是「Claude 不是 runtime」這件事的自然推論。

順便講，這也是為什麼觸發詞叫 ultracode，這個命名其實挺準的：它真的在請 Claude 多寫一點 code、少當一點 agent。

為什麼這個位置感的變化我覺得重要

到 2026 這個階段，agentic system 最常撞到的牆其實不是模型不夠聰明，是 context window 撐不住。Helper 越多、loop 越深、log 越長，到某個點就不是在 reasoning，是在管理一堆 buffer。把 plan 從 context 裡拔出來、放到一個獨立的 runtime 裡跑，這件事拖到現在才出來說真的有點意外，可能因為大家都還陷在「LLM 自己決定下一步」這個 framing 裡。

官方 docs 那個對照表把這件事寫得很乾淨：

Subagents Skills Agent teams Workflows
誰決定接下來跑什麼 Claude，turn by turn Claude，照 prompt Lead agent，turn by turn 腳本
中間結果放哪 Claude 的 context Claude 的 context 共享 task list 腳本變數
什麼東西可重用 worker 定義 指令本身 team 定義 orchestration 本身
規模 一輪幾個 同上 幾個長跑的 peer 每 run 數十到上千

這張表盯最久的是「中間結果放哪」這一欄。Context window 變成 logbook，是寫 agentic system 的人反覆在講的問題：那篇 13 行 skill 的解剖 聊過 skill 的 context 邏輯，plan 跟 state 能不能分開一直是個懸著的點，workflows 就是把這個分開直接做掉了。技術上看其實沒多新穎，distributed system 早就在做（早年的 prior art 那篇有提過）。新的是「把這個分離塞進 LLM agent 的 product surface 裡」。

那個 /deep-research 是什麼

Docs 裡內建一個叫 /deep-research 的 workflow，你直接打它接一個問題，比如 「Node.js v20 跟 v22 的 permission model 有什麼變化？」 它就 fan-out 多個角度的 web search、抓資料回來互相比對、每個 claim 投票，投不過的丟掉，最後給你一份引用過的 report，session 過程不會被刷屏。

這也是 adversarial verification 第一個真正能跑的 demo。你看得到「兩個獨立 agent 對同一個 claim 各跑一次、看法不一就把它丟掉」這個 pattern，在 script 裡長什麼樣。

要用自己的 workflow 也行。在 prompt 裡用 ultracode 帶上任務，Claude 就會寫一份 JS 給你跑；跑得不錯的話可以存起來，之後就是一個自己的 /<name> 指令（會放進 .claude/workflows/）。也可以把 ultracode 設成整個 session 的預設，讓 Claude 凡事都先考慮起一個 workflow——但這樣 token 會吃比較兇，文件自己也點出來了，我大概不會這樣用。

Bun 那個案例我怎麼看

Anthropic 拿出來講 dynamic workflows 的代表性案例是 Bun runtime 從 Zig 重寫到 Rust。The Register 的報導 寫得最完整：5/14 Bun 主線 merge 了 PR #30412，6,755 個 commit、改動 2,188 個檔案、加入逾百萬行 Rust，Linux x64 glibc 上 99.8% 的 test 通過。從 PR 開到 merge 用 6 天。Jarred Sumner（Bun 作者，現在在 Anthropic）在 X 上講：「dynamic workflows 跟 adversarial code review 是這 6 天能成立的關鍵之一。」這是 dynamic workflows 正式公開（5/28）之前的內部用例。

數字我看了會嚇一跳，但有兩件事我想擺著一起講，不然就只剩 marketing 味。

一個是這個 port 用到的 workflow 結構其實滿乾淨的：先用一個 workflow 掃整個 Zig codebase、把每個 struct field 該用的 Rust lifetime 推出來；再用另一個 workflow 把每個 .zig 檔對到一個 .rs 檔，平行幾百個 agent 一起寫、每個檔案配兩個 reviewer；接著一個 fix-loop workflow 跑 build 跟測試直到綠燈；最後一輪夜跑去處理不必要的 copy，每個改動都開一個 PR。這些都是「script 來協調，agent 來做事」這個分工的自然展開。

但另一邊，社群在挑的問題也是真的。Merge 完的 tree 裡有超過 13,000 個 unsafe block，對照規模差不多的 uv 大約 73 個。99.8% test pass 是好聽的數字，可是 test 覆蓋率本來就不能涵蓋安全屬性——unsafe 區塊的潛在 UB 不會在現有測試裡跳出來。Rust build 目前還是 canary、v1.3.14 是最後一個 Zig 版本，這個 port 沒有上 production，後面會不會被退回去也都還說不準。

所以我自己是這樣看的：dynamic workflows 確實讓這件事可以發生，「6 天百萬行」這個事實本身不會因為 unsafe block 而被取消。但 unsafe block 也提醒了一件事——用大規模 LLM 改寫出來的 code，會長什麼樣、能不能撐住長期維運，這個問題現在沒人有答案，這個 PR 就是答案開始被寫出來的地方。值得追，不適合先信。

我接下來會看什麼

我不太想假裝 dynamic workflows 是 agentic system 的最終解。它還是 research preview，cost 控制是文件自己點出來的弱點（同一件事在 conversation 裡做跟在 workflow 裡做，後者貴明顯多），需要中間問人意見的任務也不適合（workflow 不能 mid-run 停下來問你）。Adversarial verification 在 agent level 是好東西，可是不保證夠——尤其是 reviewer 跟被 review 的 agent 共用同一個 base model 的時候，有些盲點兩邊都會有。

但「Claude 寫 orchestrator、不是 Claude 跑 orchestrator」這個結構性的位移，我覺得它的生命會比 1,000 這個數字長。半年內應該會看到別的 agent framework 把類似的形狀做進去（LangGraph、AutoGen 都有相鄰的 building block，現在差的是這個明確的「LLM 生 plan，runtime 跑 plan」的分工）。真正耐看的大概不是 1,000 這個數字，是這個分工被擺上 product 表面這件事。

如果你有空，建議直接打開官方 docs 那張對照表自己讀一遍——四欄擺在一起，比我這篇講半天有用得多。

延伸閱讀