Claude Code Dynamic Workflows：能做什麼、該怎麼用，和 Windsurf / Codex 的差別

昨天晚上，我把一個舊的 React 專案從 Webpack 改造成 Vite 時，面對五百多個需要修改 import 路徑的檔案，我突然意識到一般的 chat-based AI 助手根本不夠用。這不是靠一兩次對話就能優雅搞定的改動。為了解決這類大規模重構，Claude Code 推出了 Dynamic Workflows，直接把 AI 代理的協調過程變成了一段段在背景默默跑的 JavaScript。

兩者最大的差別在於：一般的 session 是 Claude 在對話中走一步想一步，而 Dynamic Workflow 則是預先規劃，把接下來怎麼走的步驟跟邏輯直接寫進程式裡。

---

所以，Dynamic Workflows 到底是什麼？

官方文件把它定位成一個由 Claude 根據使用者任務描述，自動生成的 JavaScript script。這個 script 用來大規模調度並行（parallel）的 subagents，它可以在背景執行，也支援重新跑、中斷恢復以及狀態管理。

目前這項功能還在 preview 階段，需要將 Claude Code 更新到 v2.1.154 以上，並且需要付費帳號開通 Anthropic API access；另外 Amazon Bedrock、Google Cloud Vertex AI 和 Microsoft Foundry 也都陸續支援。官方的說明頁面可以參考：Claude Code workflows。

---

在開發中，它能解決什麼問題？

拋開那些天花亂墜的 AI 術語，實戰中它主要有以下四個應用場景：

1. 整個專案（Repository-wide）的靜態掃描

如果你的任務不是修改單一檔案，而是想檢查整個專案裡所有 API endpoints 的錯誤處理、找出實作不一致的 Hook、或是找出沒補單元測試的地方。這時 Dynamic Workflow 就可以同時派出好幾個 subagents 分頭去撈資料、核對，最後把報告收攏回來，不用我們自己一行行去翻 code。

2. 大規模的 Codebase 搬移（Migration）

像是把 500 個檔案的舊 React API 參數改名、整個 Vue 專案做 major version migration、或者修改全域的 import 路徑。Workflow 會把「搜尋檔案、分組處理、寫入修改、執行驗證、不通過就自動 retry」的整套動作，包進一個自動運作的循環裡。

3. 需要互相校對的複雜任務

當任務不是非黑即白，而是需要先產出一個 Draft，再派另一個 agent 去抓 bug，最後由第三個 agent 根據規格書做對齊。這種需要「多方對照、交叉驗證」的任務，跑 Workflow 會比在單一對話框裡通靈還要穩健得多。

4. 多 Agent 的架構編排

有些任務如果只讓一個 agent 一直做下去，它的 context 很快就會被大量的 log 檔案或無用代碼塞滿。Workflow 允許我們實作分工：一個 agent 專門撈資料，一個專門寫 test case，一個負責動手改 code，最後一個負責 output 結構化的 results，讓主對話框保持乾淨。

最實用的點在於，你拿到的不只是一次性的生成代碼，而是一套「可以重複跑、可以版控」的流程指令。

---

什麼時候該用？什麼時候不建議硬上？

不建議硬上的情境：

改個小 typo、修一兩行 import，這種直接在 terminal 叫 Claude 改完就好。
在你的重構邏輯跟規則都還沒想清楚的探索階段。因為這時候寫 workflow 的 setup 成本，會遠高於任務本身的價值。

---

它跟 Windsurf 的 workflow 有什麼不同？

這兩個工具的名字很像，但設計思維完全不在同一個頻道上。

Windsurf 目前的 workflow 本質上是 Markdown 檔，屬於手動模式（manual-only）。在 Windsurf 中，你要用 Cascade 主動下 /workflow-name 去觸發它，AI 不會自己沒事跑去跑 workflow。因此，Windsurf 的 workflow 更像是「寫給開發團隊共用的 IDE 標準作業程序（SOP）模板」。詳細可以看官方文件：Windsurf workflows。

而 Claude Code 的 Dynamic Workflows 則是「執行時期動態產生的 JS 協調引擎」。它是在背景自動跑的，核心目的是為了在大規模任務中管理複數 agent 的狀態。

---

那跟 OpenAI Codex 的玩法一樣嗎？

有類似的地方，但 Codex 的執行邏輯我拆在另一篇：Codex exec：給腳本、CI 和自動化的非互動模式。

這裡先給個簡單的結論：

Claude Code：主打多 Agent 協調與可在背景重跑的 Dynamic Workflows。
Windsurf：是放在 IDE 裡、由開發者手動觸發的 Markdown SOP 模板。
Codex exec：則是專門用來跑自動化腳本、接 CI/CD 流程的非互動式（Non-interactive）指令執行器。

---

回歸本質：這類系統的底層是怎麼運作的？

不論各大廠商把 workflow 包裝得多神祕，底層都少不了以下幾層架構：

Context 組裝：把開發者的 prompt、專案的 AGENTS.md 規範、Git 歷史紀錄、修改檔案的 diff 以及 MCP 伺服器的回傳值，拼湊成一個狀態機。
Agent 循環（Agent Loop）：傳統的 Agent 是看一眼改一步，而 Dynamic Workflow 是把 loop 寫進 JS script，讓它自己判斷「如果編譯失敗，就去讀 error log，重新下 write 指令」。
安全與權限層：這點很重要。當 AI 開始在背景跑 JS 修改你的系統檔案時，必須有嚴格的 sandbox 隔離，否則一個無限迴圈或刪檔指令就可能把開發環境搞砸。
Git 工作樹（Worktree）隔離：這在多人/多 Agent 並行開發時特別好用，能確保每個任務都在獨立的分支跑，不會互相覆蓋檔案。

---

假如我們想動手刻一套，該從哪裡開始？

我不會先去花時間刻漂亮的 UI，我會先從這幾層基礎設施做起：

定義 Task 格式：用 JSON 明確定義 Task 的 input、output、相依任務（dependencies）和成功指標，讓 agent 有資料結構可以遵循。
執行器（Executor）：負責跑 Task，處理中斷重啟（checkpoint & resume）和失敗重試（retry）。
權限控制：切分 read-only、workspace-write 和 full-access。如果是危險的 shell 指令，一定要卡一關手動確認（manual confirmation）。
Git 隔離環境：自動幫 subagent 建立獨立的 Git worktree，改完再發 PR，避免弄髒主要的 main branch。

---

實戰中，我個人推薦的混搭法

需要協調多個 Agent 跑複雜任務：用 Claude Code 的 Dynamic Workflows。
需要團隊共享開發 SOP、在 IDE 裡手動觸發：用 Windsurf Workflows。
需要在 CI/CD pipeline 裡無人值守跑指令、撈結構化資料：用 Codex exec。

Dynamic Workflows 最有趣的地方，並非它的語法，而是它把整個開發現場的「協調工作」變成了可以重跑、可以版控的程式碼資產。這雖然不適合日常修小 typo，但在大面積改 code 的重構戰場上，它確實給了我們一種新的可能。