Claude Code 推出 Dynamic Workflows：100 個 Agent 怎麼不打架？

Anthropic 工程師 cat wu 在 X 上丟了一張圖：Claude Code 多了一個叫做 dynamic workflows 的功能，一條 prompt 就能協調上百個 agent。跟過去那種 multi-agent 跑著跑著順序就亂、agent 互相打架的狀況不同，這次官方強調的關鍵字是 strictly follows——嚴格執行。本文拆三件事：orchestrator 怎麼起手、implementer / verifier / fixer 三角怎麼運作、為什麼這套機制能讓你「敢相信順序」。

第一層：Orchestrator 起手

觸發機制很單純：你在 prompt 裡寫到「workflow」這個字，Claude 就會切換到 orchestrator 模式。它不會直接動手，而是先做一件事——把你的需求拆成 N 個 task，N 可以到上百個。

這聽起來不稀奇，但對比舊做法你會發現差別。以前你要在 Claude Code 跑多 agent，得自己寫 sub-agent dispatching 的邏輯：哪個 agent 先跑、誰拿誰的輸出、fan-out 之後怎麼匯流。Claude 幫你跑，但「協調」這件事還是落在你身上。

dynamic workflows 把這層抽掉了。Claude 自己生計畫，自己決定怎麼拆，你只負責描述目標。換句話說：你從「sub-agent 的調度員」變成「workflow 的下單人」。

第二層：Implementer / Verifier / Fixer 三角

這是整套機制最關鍵的設計。每一個 task 不是丟給一個 agent 就完事，而是跑一個三段式 pipeline：

第一段是 implementer——真正動手做事的 agent，負責把這個 task 該交付的東西做出來。

第二段是 verifier，而且是兩個並行的 verifier。為什麼要兩個？這是冗餘檢查的設計：單一個 verifier 可能漏判、可能跟 implementer 共享盲點，兩個並行能把假陽性、假陰性的機率壓下來。在 LLM 這種有機率特性的系統裡，這比加 retry 邏輯更穩。

第三段是 fixer。fixer 不會在 implementer 做完就動，它要等 verifier 給訊號。verifier 說「這裡有問題」，fixer 才針對問題修。這跟一般 ReAct loop 那種「邊跑邊想要不要繞路」是反過來的設計——這裡是「先檢查、有問題才修」，職責切得很乾淨。

三段跑完，這個 task 才算結束，結果回傳給最上層的 orchestrator。N 個 task 全部跑完，orchestrator 才把最終結果交還給你。

第三層：嚴格執行的保證

「strictly follows」這幾個字是這次發表的關鍵字，不是行銷話術。

一般你在用 multi-agent framework（LangGraph、AutoGen 之類）會遇到的痛點是：agent 跑著跑著開始「自由發揮」——它覺得這一步不重要就跳過、覺得那一步需要再想想就無限 loop。Plan 是 plan，執行是執行，兩件事中間隔了一個 LLM 的不確定性。

dynamic workflows 的做法是：plan 一旦由 orchestrator 生成，就不能跳步。每個 task 的 implementer/verifier/fixer 三段式也是固定的，沒有「跳過 verifier」這個選項。這就是「敢信任 100 個 agent」的前提——不是因為每個 agent 變強了，而是因為順序被鎖死了。

Multi-agent 不缺 agent，缺的是「敢相信順序」的機制。

這也是為什麼這個功能能撐到「上百個 agent」這個量級。少數幾個 agent 你還能人工盯，跑到一百個你只能信任機制本身。

結尾

Dynamic workflows 不是把 agent 變強，而是把「協調」這件事從工程師手上拿走。你過去花在 sub-agent dispatching、順序控制、錯誤恢復的時間，現在交給 orchestrator。

但這也代表你失去了「中途介入」的彈性。如果 plan 跑到第 50 步發現方向錯了，你只能等它跑完才修，還是 Claude Code 之後會開出「暫停 / 跳過 / 重新規劃」的控制權？這大概是這個功能成熟與否的下一個關鍵——嚴格執行很好，但工程師永遠想保留最後的 override 權。