什麼是 Dynamic Workflows？
Dynamic Workflows 是 Claude Code 在 2026 年 5 月底推出的新功能（research preview），同時隨 Claude Opus 4.8 一起發布。核心能力是讓 Claude 自己動態撰寫 orchestration script，在單一 session 內同時啟動幾十到幾百個平行 subagents，並在結果交給你之前自行驗證。
這不只是「更快的 AI 回答」，而是一個架構層的轉變。
運作流程
啟動後流程分五個階段：
- Script 生成 — Claude 依照你的 prompt，動態產生一段帶有 loop、條件分支、中間變數的 JavaScript orchestration script
- Fan-out — Script runtime 將工作平行分發給數十至數百個 subagents
- 驗證 — 獨立的 adversarial agents 嘗試推翻各 subagent 的發現
- Convergence — 反覆迭代直到答案收斂
- 整合 — LLM 只在這個時間點重新介入，輸出最終結果
值得注意的是：中間結果存在 script 變數裡，不進 LLM 的 context window。這是整個架構的關鍵設計。
與傳統 Function Calling 的差異
傳統 Function Calling（一來一回）
計畫存在 LLM 的 context window 裡。每一步都需要：LLM 讀完所有歷史 → 決定下一個 tool → 等執行 → 結果塞回 context，如此循環。
使用者
→ context + 決策 → tool_A 執行
→ 結果塞回 context + 決策 → tool_B 執行
→ 結果塞回 context + 決策 → tool_C 執行
→ 最終回答
Dynamic Workflows
使用者
→ LLM 生成 orchestration script
→ script 同時 spawn: subagent1 / subagent2 / subagent N
→ adversarial agents 驗證結果
→ 整合報告 → LLM 輸出
核心差異對照
| 面向 | Function Calling | Dynamic Workflows |
|---|---|---|
| 計畫存放位置 | LLM context（隱性） | Orchestration script（顯性程式碼） |
| 執行方式 | 序列為主 | 真正並行，最多 16 個同時跑 |
| 中間結果 | 全部塞進 context | 存在 script 變數，不消耗 context |
| 步驟規模上限 | context 撐滿就崩 | 單次執行最多 1,000 agents |
| 計畫穩定性 | 容易被 tool result 帶偏 | script 邏輯固定，不會跑偏 |
| 中斷恢復 | 需重頭來 | 進度持續儲存，可斷點續跑 |
為什麼 context 是根本問題？
傳統 function calling 設計裡有個很常見的問題：tool call 多了之後，LLM 開始「忘記」前面的指示，因為 context 被大量 tool results 塞滿，有效的注意力被稀釋掉了。
Dynamic Workflows 把中間狀態移出 context，LLM 只在「規劃」和「整合」兩個時間點介入，context 壓力幾乎不變。
應用場景
適合 Dynamic Workflows 的任務有一個共同特徵：可以水平切割，各 subagent 彼此獨立。
- 全 codebase 掃描：bug hunt、security audit、dead code 分析
- 大規模 migration：框架替換、API deprecation、語言 port（真實案例：Bun 從 Zig port 到 Rust，75 萬行，11 天）
- 高風險工作的多角度驗證：需要 adversarial 測試的重要決策
反過來，如果步驟有嚴格的依賴關係（A 的結果決定要不要執行 B），傳統 function calling 反而更直接。
如何啟用
目前是 research preview，支援 Max、Team、Enterprise 方案（Enterprise 預設關閉，需管理員啟用）。
兩種觸發方式：
- 直接在 prompt 說「Create a workflow」
- 開啟 Claude Code 設定中的 ultracode 模式，讓 Claude 自己判斷何時需要 workflow
注意：Token 消耗明顯多於一般 session，建議先用有限範圍的任務試手感。
小結
Dynamic Workflows 和 function calling 並非互斥——現實設計往往是：workflow 負責拆任務和並行，function calling 是每個 subagent 內部的執行機制。
如果你在設計 AI agent 系統，這個差異影響的是任務拆分的邊界設計：任務的「寬度」和「可並行性」決定要用哪一層。