以前是人類寫 SOP 給 Agent 看；現在 Claude Code 開始讓 Agent 寫工作流給 Agent 跑。

Claude Code 的 dynamic workflows，是讓 Claude Code 在任務中臨時產生 JavaScript 工作流：開子 Agent、分派工作、選模型、切 worktree、收結果，再決定下一步。它不是固定模板，而是依照任務現場規劃，讓 Claude 把大任務拆成多個平行子任務，再把結果檢查、收斂成一個回答。

啟動方式也很直接：可以要求 Claude 建立工作流，也可以打開 Claude Code 裡的 ultracode 設定，讓 Claude 在需要時自動決定是否使用 workflow。Anthropic 把這功能放在 Claude Opus 4.8 同期推出的 Claude Code 研究預覽裡，也提醒它會吃掉比一般 Claude Code 工作階段更多的 Token。

這篇和前面幾篇 gu-log 文章剛好接成一條線：SP-94 講過 harness 才是產品核心，SP-206 講過大型程式庫需要可控的 Claude Code harness，SP-207 講過 /goal 這種停止條件。這篇補上的新東西，是 Claude Code 讓 workflow 本身開始變成可執行、可保存的產物。

Mogu 偷偷說：

Clawd 自己的讀法是：dynamic workflows 最有趣的不是「多開幾個 Agent」，而是腳本開始變成可保存、可重跑、可分享的 Agent Harness。以前工程師留下文件與 CI；現在連「怎麼派工、怎麼驗收」都可能變成一個可執行產物。這很帥，也很容易燒錢。⁠(⁠๑⁠•⁠̀⁠ㅂ⁠•⁠́⁠)⁠و⁠✧

它解決的不是「人手不足」，而是「單一脈絡太脆」

傳統 Claude Code 工作階段像一位很勤奮的工程師：讀程式、改檔案、跑測試、修錯。任務小的時候，這很夠用。任務一大，問題就出現了。

長任務會把三個失敗模式放大。

第一個是 agentic laziness：Agent 可能用局部證據宣布完成，或在測試沒跑完時寫出漂亮總結。第二個是 self-preferential bias：同一個 Agent 寫方案又驗方案，很容易相信剛剛選的方向。第三個是 goal drift：任務跑久後，原本只是找根因，後來開始重構半個系統。

dynamic workflows 的解法不是叫 Agent 更努力，而是把「努力」拆成流程：某個 Agent 負責產生假說，某個 Agent 負責查證，某個 Agent 負責反駁，工作流負責判斷是否真的達到停止條件。

這就是 /goal 和 /loop 在文中反覆出現的原因。/goal 把北極星釘住，/loop 防止「看起來完成」取代「真的完成」。

六種形狀，其實可以壓成三個心智模型

文中列出一串常見 workflow 模式，但不用把它背成名詞表。比較好記的方式，是把它們壓成三個問題。

第一個問題：先分類，還是先做？
classify-and-act 適合分流 issue、錯誤紀錄、測試失敗、使用者回報。工作流先把項目分成「可立即修」、「需要隔離」、「疑似重複」、「需要人類決策」，再對每類啟動不同處理流程。這比讓一個 Agent 從頭看到尾更穩，因為分類本身就是一道控管閘門。

第二個問題：要平行探索，還是互相競爭？
fan-out-and-synthesize 把問題切開，讓多個子 Agent 平行查不同區域，最後由協調者彙整。generate-and-filter 和 tournament 則比較像讓多個候選方案互相打架：先生成，再篩選，再讓更好的方案留下來。研究、排序、命名、設計方向、模型路由，都很適合這一類。

第三個問題：誰負責找碴？
adversarial verification 的重點是把「做」和「驗」拆開。一組 Agent 寫方案，另一組 Agent 專門找反例、查測試、看規則。這不是多一層禮貌 review，而是讓反方 Agent 有權否決。

Mogu 想補充：

多 Agent 最容易變成兒童足球：二十個人一起追球，看起來很熱鬧，球門旁邊沒有人。好的 harness 應該像廚房動線：切菜、備料、熱鍋、試味、出餐，每一步都知道自己為什麼存在。

真正有用的場景：大型、曖昧、需要驗證

普通工作不需要開戰情室。小修小補、明確 bug、單檔改動、低風險格式調整，直接讓 Claude Code 做完就好。把 dynamic workflow 用在每個任務上，只會讓協調成本超過任務本身。

它適合三種任務。

第一種是大型遷移與重構。 Bun 的例子是把 Zig 程式碼移植到 Rust，並讓既有測試套件作為驗收門檻。這種任務不是單純改語法，而是跨語言、跨執行環境、跨測試、跨效能假設。工作流可以讓一組 Agent 讀 Zig 行為，一組 Agent 設計 Rust 對應，一組 Agent 寫測試，一組 Agent 專門查相容性。

第二種是研究與驗證。 深度研究不是找一個答案，而是找一整片證據地形。不同 Agent 可以追文件、issue、commit history、benchmark、討論串；最後負責彙整的 Agent 把證據去重、排序、標出信心與缺口。深度驗證則剛好相反：不是找更多材料，而是對既有結論做反方檢查。

第三種是分流與品味。 一堆 PR、一堆錯誤、一堆候選方案，單 Agent 從頭看到尾會疲乏。工作流可以先分桶，再篩選，最後讓更強模型處理高難度項目。設計、命名、文件語氣這類品味問題，也可以用多個候選方案互相比較，而不是接受第一個看起來還可以的答案。

這裡還有一個安全細節：分流可以搭配隔離。遇到不確定是否安全的變更或外部內容，先放進「需要人類或高權限 Agent 判斷」的桶，不要讓讀到不可信內容的 Agent 直接做高權限動作。

worktree、恢復、模型選擇：這些不是小細節

dynamic workflows 裡幾個工程細節很關鍵。

worktree 讓不同候選方案各自生長，最後再比較與合併。多個 Agent 同時改同一個工作目錄，很容易互相覆蓋檔案、混淆責任邊界；用 git worktree 隔離，tournament 與 generate-and-filter 才比較實際。

恢復能力讓長任務不會因為中斷就失憶。深度研究、重構、驗證都不是五分鐘跑完的事。如果工作流能在中斷後恢復狀態，就能把「一次聊天」提升成「一個可持續任務」。

模型選擇則是成本控制。不是每個步驟都需要最貴模型；分類、粗篩、格式檢查可以交給便宜模型，關鍵設計、反方驗證、最終彙整再交給強模型。工作流能動態選模型，等於把成本與能力編排進流程裡。

Mogu 吐槽時間：

每次看到「AI 會自己做事」，先問幾個無聊問題：狀態存在哪裡？權限怎麼切？失敗怎麼恢復？成本誰負責？驗收誰說了算？回答不出來的自主性，多半只是展示錄得很順。

按 s 存起來，代表工作方法也變成產物

這套東西最關鍵的暗示，是工作流可以被保存。

如果某個 dynamic workflow 跑得好，可以用 s 存到 ~/.claude/workflows，或者沉澱成 skill。這件事看似只是方便下次重用，實際上讓工作方法本身變成可保存的工程產物。

文件會過期，人的腦袋會離職，CI 腳本通常只知道怎麼檢查，不知道怎麼思考。工作流產物介於三者之間：它不是靜態文件，因為它能執行；它不是單純腳本，因為它能呼叫 Agent 做判斷；它不是人的腦袋，因為它能被保存、版本化、複製、改良。

這代表一次成功的根因調查，可以變成根因工作流；一次好的遷移，可以變成遷移工作流；一次好的模型比較，可以變成路由工作流。

Mogu 碎碎念：

這裡開始才是 Clawd 的延伸判斷：未來的工程資產，可能不只包括程式碼、測試、文件、評估，還包括一整套會調度 Agent 的工作流。某些團隊的優勢，也可能不只是「模型用得比較新」，而是「已經累積一堆會做事的 harness」。這不是 source 已經證明的結論，比較像從這個功能外推看到的方向。

結語：Agent 的下一個單位不是任務，而是流程

Claude Code 的 dynamic workflows 之所以重要，不是因為它讓 Claude 多開幾個小弟。

真正的變化是，Claude Code 開始把「怎麼完成一類工作」寫成可執行流程。這裡展示的不是單一答案，而是一套會規劃、平行執行、檢查結果、必要時恢復續跑的流程。

這一步不會讓普通工程問題自動消失。它仍然要面對偷懶、偏見、漂移、成本、驗收、權限、狀態管理。只是它提供一個新的抓手：把好的工作方式保存下來，讓它能重跑、能比較、能演化。

到那時候，真正值錢的可能不是問 Claude Code 一句漂亮的 prompt。

而是按下執行後，一段工作流知道該怎麼分工、施工、驗收，最後還把這次有效的做法存起來。