Claude Code Dynamic Workflows：從功能介紹到與 Function Calling 的架構比較

什麼是 Dynamic Workflows？

Dynamic Workflows 是 Claude Code 在 2026 年 5 月底推出的新功能（research preview），同時隨 Claude Opus 4.8 一起發布。核心能力是讓 Claude 自己動態撰寫 orchestration script，在單一 session 內同時啟動幾十到幾百個平行 subagents，並在結果交給你之前自行驗證。

這不只是「更快的 AI 回答」，而是一個架構層的轉變。

運作流程

啟動後流程分五個階段：

1. Script 生成 — Claude 依照你的 prompt，動態產生一段帶有 loop、條件分支、中間變數的 JavaScript orchestration script
2. Fan-out — Script runtime 將工作平行分發給數十至數百個 subagents
3. 驗證 — 獨立的 adversarial agents 嘗試推翻各 subagent 的發現
4. Convergence — 反覆迭代直到答案收斂
5. 整合 — 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 輸出

核心差異對照

為什麼 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 預設關閉，需管理員啟用）。

兩種觸發方式：

1. 直接在 prompt 說「Create a workflow」
2. 開啟 Claude Code 設定中的 ultracode 模式，讓 Claude 自己判斷何時需要 workflow

注意：Token 消耗明顯多於一般 session，建議先用有限範圍的任務試手感。

小結

Dynamic Workflows 和 function calling 並非互斥——現實設計往往是：workflow 負責拆任務和並行，function calling 是每個 subagent 內部的執行機制。

如果你在設計 AI agent 系統，這個差異影響的是任務拆分的邊界設計：任務的「寬度」和「可並行性」決定要用哪一層。