2026 年 5 月 28 日，Anthropic 把兩件事捆在同一天發佈：Claude Opus 4.8，跟 Dynamic Workflows in Claude Code。
新模型本來就會有人寫文章拆解，但 Dynamic Workflows 才是我覺得這次發佈真正的 game changer。Anthropic 在公告裡丟出一個 demo：Bun 作者 Jarred Sumner 用 Dynamic Workflows 把整個 Bun runtime 從 Zig 重寫成 Rust，11 天、~75 萬行、99.8% 測試通過率。
這不是「Claude 寫了一段 code」這種尺度。這是過去要拿出 quarter 規劃、開大型 task force 處理的工作量。當然 HN 上立刻有人質疑「mechanical refactor agent 也能做」「這 75 萬行 vibe-coded Rust 到底誰維護」，但作為一個概念驗證，這個尺度在以前是不可想像的。
這篇我想做的不是 review，是拆解：Dynamic Workflows 內部到底怎麼跑？這個 Bun port 的 5 個 phase 各做了什麼？跟舊的 Agent Teams 比差在哪？對一般開發者來說，怎麼用、怎麼控制成本、會踩到什麼雷？
Dynamic Workflows 是什麼？三句話講完
第一句：你在 Claude Code 裡丟一個大任務，Claude 自己寫一份 JavaScript orchestration script。
第二句：runtime 在背景跑數十到數百個 subagent 平行工作，並有另一群 verifier agent 對抗式檢驗。
第三句：全部收斂後，主 session 拿到最終結果——你不用一直盯著螢幕。
跟前一代 Agent Teams 比，差異很關鍵：Agent Teams 是「Claude 開幾個平行對話」，每個 agent 還是吃同一個 context；Dynamic Workflows 是「Claude 寫一個外部 JS 程式」，這個程式自己管狀態，agent 不必擠在同一個 context 裡。
earlyterms 的描述很精準 ：「The orchestration logic — loops, branches, intermediate state — lives in code rather than Claude's context window.」
換句話說：workflow 把 Claude 從「context 受限的對話機器」變成「能寫程式調度自己的 orchestrator」。這是質的差異，不是量的差異。
Runtime 硬限制：你寫 prompt 之前要知道的
MarkTechPost 整理出來的 4 條 hard limit ：
| 限制 | 數值 | 意義 |
|---|---|---|
| 同時 concurrent agents | 16 | 你以為跑 100 個平行，其實同時間只有 16 個在算 |
| 單次 run 總 agent 數 | 1,000（hard cap） | 超過就停 |
| Script 能碰 filesystem 嗎 | 不行 | orchestration JS 不能讀寫檔，只有 agent 能 |
| Script 能碰 shell 嗎 | 不行 | 同上 |
Progress 自動 checkpoint，中斷可 resume。這條很重要——跑 4 小時的長任務不會因為 session 斷掉而要從頭來。
為什麼 16 / 1000 這個數字？
Anthropic 沒講，但我推測有兩層原因：
- API rate limit 跟 Anthropic 自己 capacity 的考量：1000 agent 同一個 session 跑，每個都吃 token，平均一個 workflow run 燒掉幾百 K token 是常態。
- 品質衰減：Anthropic 內部一定做過實驗，超過某個並行數，verifier agent 的對抗式 review 就 catch 不住所有 hallucination。1000 / 16 看起來是「品質 / 成本 / latency」三條曲線的甜蜜點。
觸發方式：兩種寫法
第一種：Prompt 裡有「workflow」這個字
# Claude Code prompt
> create a workflow that migrates every internal fetch() call to the new HttpClient wrapper, updating tests as you go
只要 prompt 包含 workflow，Claude Code 會問你要不要起一個 dynamic workflow。
第二種：開 ultracode 模式
# 在 Claude Code 裡
/effort ultracode
ultracode 等於 effort: xhigh + 自動 workflow orchestration。寫 prompt 不用提 workflow，Claude 自己判斷該不該啟動。
/deep-research 也是 Anthropic 預先寫好的內建 workflow，問問題時直接用 /deep-research <topic>，幾分鐘後拿到一份多 agent 平行檢索 + 對抗式驗證的研究報告。我自己用過幾次，比 Perplexity 跟 ChatGPT Deep Research 都實在——但 token 燒得很兇，Max plan 額度容易被吃。
Bun port 五階段拆解
回到 Anthropic 那個 demo case。官方公告 跟 natural20 的深度分析 把整個流程拆成 5 個 phase，我整理如下：
Phase 1：Rust lifetime 標註
One workflow mapped the correct Rust lifetime for every struct field in the Zig codebase.
Zig 沒有 Rust 那種 borrow checker 跟 lifetime annotation——Zig 是手動管 memory 的。Rust 移植第一步是給每個 struct field 標出正確的 lifetime（'a、'static、'self 等），這對人類工程師來說超花時間。
第一個 workflow 跑數十到數百個 agent，每個 agent 拿一塊 Zig source code 分析 ownership 流，輸出對應 Rust 結構的 lifetime annotation 設計。
這個階段最容易被忽略：這不是寫 Rust，是寫 Rust 之前的「型別系統設計」。Claude 在這個 phase 等於做了一份 high-level architectural design document。
Phase 2：檔案級平行移植
The next workflow wrote every.rsfile as a behavior-identical port of its.zigcounterpart, hundreds of agents working in parallel with two reviewers on each file.
這是「批次翻譯」階段——每個 Zig 檔對應一個 Rust 檔。數百個 agent 平行跑，每個 file 配 2 個 reviewer。
兩個 reviewer 的設計很妙。一個負責「語意正確」（這段 Rust 跟原 Zig 行為一致嗎），一個負責「Rust idiomatic」（這個寫法是不是 Rust 慣用法）。雙審查機制是 Dynamic Workflows「adversarial verification」的具體應用。
注意：concurrent 上限是 16。所以即使邏輯上「數百個 agent 平行」，實際 runtime 一次只有 16 個在做工。剩下 queued。
Phase 3：Build + Test 修正迴圈
A fix loop then drove the build and test suite until both ran clean.
這是經典的 agentic loop：跑 build → 失敗看錯誤 → 修 → 重跑。Bun 既有 test suite 是「pass bar」，agent 一直循環直到 99.8% test 過。
這個 phase 才是 Dynamic Workflows 真正的價值——它把「我寫了一段 code、不確定對不對」這個過去需要人類拉 PR + reviewer + CI 來確認的工序，內建在 workflow 自己的 loop 裡了。
人類介入點只剩「workflow 結束後決定要不要 merge」。
Phase 4：Overnight 優化
After the port landed, an overnight workflow addressed unnecessary data copies and opened pull requests for final review.
第一輪 port 完成後，又跑了一個夜間 workflow 處理 unnecessary data copies——Rust 跟 Zig 的記憶體模型不一樣，直接翻譯出來的 Rust 會有很多無謂的 clone()。這個 workflow 自動找出來、改成 borrow 或 move，並開 PR 給人 review。
Phase 5：人類最終 review
剩下的就是 Jarred Sumner 本人。Anthropic 強調「the port is not yet in production」，所以這 75 萬行 Rust 還沒進 main branch。
跟 Agent Teams 差在哪？
Opus 4.6 的 Agent Teams 我用過一段時間。它解決的問題是「我想要 Claude 同時 review 3 個東西」這種尺度。Dynamic Workflows 是不同 league。
| 維度 | Agent Teams（4.6） | Dynamic Workflows（4.8） |
|---|---|---|
| 觸發 | Claude Code 設定 + tmux pane | Prompt 含「workflow」或 ultracode |
| Agent 上限 | 通常 3-10 個 | 1,000（同時 16） |
| Context 共享 | 共享同一個 main context | 獨立：JS script 管 state |
| 中斷恢復 | 不行 | 自動 checkpoint，可 resume |
| 對抗式 review | 沒內建 | 內建 verifier + refute agent |
| 適合任務 | PR review、design 對齊、debug 三個假說 | 大規模 migration、codebase audit、long-horizon refactor |
| Token 預估 | 數萬到數十萬 | 數百萬到上千萬（一次 run） |
兩個都還在 Claude Code 裡有用，但是不同層級的工具。
簡單的 rule：
- 「我想要 3 個 Claude 一起做」→ Agent Teams
- 「我想要 100 個 Claude 一起做、自己管狀態、自己驗證、跑一整天」→ Dynamic Workflows
實戰預算控制：怎麼不被燒光額度
這是 Dynamic Workflows 最大的雷。Bun port 那個 demo 燒了多少 token？Anthropic 沒公開。但用 1000 agent × 每個平均 50K token × verification overhead = 上千萬 token 級的 input + output。
對 Max plan 用戶來說，一次中型 workflow 就能把週額度吃光。怎麼控制？
1. 用 task_budget 設硬上限
Opus 4.7 引入的 task_budget public beta 沿用到 4.8。它跟 max_tokens 不一樣——max_tokens 是 per-request 硬上限，task_budget 是「整個 agentic loop」的 advisory cap。
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=64000,
output_config={
"effort": "high",
"task_budget": 500000 # 整個任務最多燒 50 萬 token
},
messages=[...]
)
Workflow 自己會看 task_budget 殘量，動態調整要不要 spawn 更多 subagent。沒設這個就等於放任 Claude 燒。實際參數名稱可能依 SDK 版本略有差異，使用前請對照官方 docs 確認。
2. 從小 module 開始試水溫
不要第一次用 Dynamic Workflows 就丟整個 codebase。先選一個 ~5,000 行的 module 跑跑看，看 token 燒法跟結果品質，再評估能不能 scale 到 100,000 行。
I Migrated to Claude Opus 4.8 那篇 migration guide 給出的建議很實際：「Scope tightly and start with one module, not your whole codebase」。
3. 別把 Dynamic Workflows 當 Fast Mode 用
4.8 同時推出的 Fast Mode（$10/$50 per million tokens，2.5× 速度 ）跟 Dynamic Workflows 是兩條不同的線。
| 你想要什麼 | 用哪個 |
|---|---|
| 同個 prompt 但更快回應 | Fast Mode |
| 一個 prompt 拆成 100 個平行子任務 | Dynamic Workflows |
| 大量探索性 query、不在乎品質但在乎速度 | Fast Mode |
| 大型 audit / migration、要 verifier 對抗式 check | Dynamic Workflows |
兩個都很貴，但用錯場景會更慘——例如把 Fast Mode 拿去跑 codebase audit，速度有但品質下降；把 Dynamic Workflows 拿去跑互動聊天，agent overhead 把 latency 拉到 30 秒。
4. 跑前先用 /deep-research 看 cost 樣本
Claude Code 內建的 /deep-research 是一個現成的 workflow demo。隨便丟一個研究問題給它，看它最後回報的 token 用量。這個數字可以當你估自己 workflow 的 baseline。
我自己粗估跑一個中型 deep-research，燒掉百萬等級 token、十幾分鐘是合理 ballpark；實際數字隨主題複雜度跟資料量浮動很大，要看你自己的 telemetry 才準。
命名巧合：Cloudflare 也叫 Dynamic Workflows
題外話，但很妙的事。
2026-05-01，Cloudflare 也發佈了名為「Dynamic Workflows」的產品——是一個 per-tenant durable execution library for Workers。跟 Anthropic 完全無關。
5 月 28 日 Anthropic 也發了 Dynamic Workflows，但兩家公司互不提及對方。
Two Products, Same Name: Why Cloudflare and Anthropic Both Chose 'Dynamic Workflows' in May 2026
兩家都是大廠，撞名不太可能是巧合——大概率是同一個技術 buzz term 同時被兩邊產品團隊鎖定。實務上要注意：你 google「dynamic workflows」會夾雜 Cloudflare 的東西。
我自己用 Dynamic Workflows 幾天的感想
對重度 Claude Code 用戶來說，Dynamic Workflows 改變了「我能做多大尺度的事」這個直覺。
過去我在 Claude Code 裡會自我設限：「這個 task 太大、context 裝不下、不要叫 Claude 做」。現在的判斷變成：「這個 task 太大 → 寫成 workflow 讓它自己拆」。
但有兩個雷：
第一：workflow planning 階段品質很受 prompt 影響。如果你給的 prompt 含糊、目標不清楚，Claude 寫出來的 orchestration JS 也跟著爛。我建議寫 workflow prompt 時先給 Claude 一份「task spec」，包含目標、約束、acceptance criteria，再叫它寫 workflow。
第二：verifier agent 不是萬靈丹。對抗式 review catch hallucination 的能力有上限——如果整個 workflow 的所有 agent 都基於同一個錯誤假設，verifier 也救不了你。Bun port 那個 case 之所以成功，部分是因為「behavior-identical port」這個 acceptance criteria 非常具體（既有 test suite 就是 ground truth）。對沒有明確 ground truth 的任務（產品設計、UX 決策），Dynamic Workflows 的可信度大幅下降。
寫到最後
Dynamic Workflows 不是「Claude 變強」，是「Claude 變成 orchestrator」。這個位置變動的意義比模型本體的 benchmark 進步重要很多——它把 Claude 從「我給它一個 task 它回我一段答案」變成「我給它一個專案它自己組軍隊跑」。
對個人開發者來說，這意味著「我可以承擔的 task 尺度上升一個量級」。對企業來說，意味著「過去要規劃 quarter 的 migration，現在規劃 sprint」。對 Anthropic 來說，意味著「我們不只賣 LLM，我們賣 LLM 編出來的軍隊」。
當然，Bun port 還沒進 production，這個 demo 是不是真的 work 還要時間驗證。HN 上「這幾十萬行 vibe-coded Rust 到底誰維護」的質疑很犀利。Dynamic Workflows 的成本曲線、品質曲線、適用場景，都還需要社群更多實戰才能畫清楚。
但工具已經出來了。下一個季度，會看到的不是「誰的 LLM 比較聰明」，是「誰的 LLM 比較會組軍隊」。Anthropic 在這條線上跑出了第一個能 demo 給大家看的版本，這個位置可能會撐很久。
夭壽，下次有人說「我寫了 100 萬行程式」，記得先問一句：「是你寫的，還是你的 workflow 寫的？」
延伸閱讀
- Anthropic 官方公告：Introducing Claude Opus 4.8（含 Dynamic Workflows 說明）
- MarkTechPost：Workflows Capped at 1,000 Subagents
- natural20：Claude Opus 4.8 Is Here, And Anthropic Is Turning Claude Code Into an AI Engineering Team
- earlyterms：Dynamic Workflows term page
- Linas's Newsletter：Claude Opus 4.8 Prompting Playbook
- genaiunplugged：I Migrated to Claude Opus 4.8. Here Are the 5 Things That Broke.
- Hacker News：Dynamic Workflows in Claude Code 討論串
- Claude API Docs：What's new in Claude Opus 4.8
- Claude Code Docs：Agent Teams（4.6 舊功能比對）
沒有留言:
張貼留言