同樣都是多 AI牛馬並行幫你做事
如果你最近認真用過 Claude Code，大概已經撞上一個抉擇點。當任務大到一個對話塞不下時，現在有兩種完全不同的辦法可以投入更多代理：動態工作流程（Dynamic Workflows）和代理團隊（Agent Teams）。
兩者表面上很像。都會啟動多個代理，都承諾替你扛下原本要耗掉好幾小時的工作，名詞還重疊到剛好夠讓人搞混。但底層的設計理念不一樣，選錯的代價是實際的時間、實際的 token，偶爾再附送一段你完全沒料到的除錯時間。
簡單的說：Dynamic Workflow把計畫寫進程式碼，Agent Teams則把計畫留在主導代理的腦子裡，逐回合臨機決定。
這個差異會牽動後面所有事以及工作怎麼擴展、中間結果放哪裡、哪些部分能重複用、中斷後怎麼復原，還有花多少錢。
Dynamic Workflow是什麼
動態工作流程是一段協調子代理（subagents）的 JavaScript 指令碼。你描述任務，Claude 寫出指令碼，執行環境在背景跑它，期間你的工作階段照常能用。你不用盯著逐回合的對話，啟動之後等結果就好。
重點在於邏輯放在哪裡。迴圈、分支和所有中間結果都待在指令碼的變數裡，不在 Claude 的脈絡視窗中。Claude 只看得到最終答案。這就是為什麼工作流程能擴散到數十、甚至數百個代理，協調者卻不會被自己的脈絡淹沒。
單次執行最多能同時協調 16 個並行代理，並設有每次執行 1,000 個代理的硬上限，防止迴圈失控。差別就在這裡：流程是由指令碼掌控，還是由對話掌控。
因為計畫已經是程式碼，工作流程能做到兩件對話式協調者做不到的事。第一是可重複——某次執行調到你要的效果後，可以存成斜線指令，往後在每個分支、每次發布、每次稽核上重跑一模一樣的協調流程。第二是把品質把關寫進結構裡。它不只是平行多跑幾個代理而已，還能讓獨立代理在回報前對彼此的發現做對抗式審查，或從幾個角度各自草擬計畫再互相權衡。內建的 /deep-research 指令就是現成例子：它從多個角度擴散搜尋、交叉比對來源、針對每項主張投票，最後回傳一份附引用的報告，沒通過驗證的主張早就被濾掉了。
工作流程在同一個工作階段內也能恢復。中途暫停的話，已完成的代理會回傳快取結果，其餘的即時接續。
它的限制是執行途中不能接受使用者輸入，唯一能讓它停下來的是代理的權限提示。所以如果你需要在各階段之間有人簽核，就把每個階段拆成獨立的工作流程來跑。
Agent Teams是什麼
代理團隊是一群協同合作的獨立 Claude Code 實例。其中一個工作階段當團隊主導者，負責協調工作、指派任務、彙整最終結果，其餘是隊員，各自在獨立的脈絡視窗裡運行。
它和工作流程最大的不同在於溝通方式。子代理是「派發後就不再追蹤」的工作者，只能向單一呼叫者回報；隊員則可以彼此直接對話。他們靠兩種機制協調。一種是共享任務清單，一個每個代理都能讀寫的即時佇列：主導者放入工作項目，隊員自行認領、完成、標記。這份清單支援相依性追蹤，所以某項任務可以在先決條件完成前一直維持封鎖，等條件達成後自動解除。另一種是直接傳訊：隊員可以指名傳訊給特定隊員，閒置的隊員做完手上的事也會主動回報主導者。
為了避免兩個代理同時動到一個檔案，系統用檔案鎖定隔離各自的工作，並行寫入才不會打架。
團隊還有一個工作流程沒有的能力：你可以跟個別代理直接互動。略過主導者，直接找某個隊員講話，想挑戰某個代理的假設時特別好用，比如另外開一個專門唱反調（devil’s advocate）的隊員。
不過，下一步要做什麼，還是由主導者在脈絡裡逐回合推理決定。計畫沒有寫成程式碼，而是活在協調代理的推理迴圈裡。
一張表看完兩者
| 面向 | 動態工作流程 | 代理團隊 |
|---|---|---|
| 本質 | 由執行環境跑的指令碼 | 監督對等工作階段的主導代理 |
| 誰決定下一步 | 指令碼 | 主導代理，逐回合決定 |
| 中間結果放哪 | 指令碼變數 | 共享任務清單 |
| 可重複的是什麼 | 協調流程本身 | 團隊定義 |
| 規模 | 每次執行數十到數百個代理 | 少數幾個長時間運行的對等代理 |
| 中斷時 | 同一工作階段內可恢復 | 隊員持續運行 |
| 人為介入 | 執行途中無法輸入 | 可直接與個別隊員互動 |
| 供應狀態 | 研究預覽版，涵蓋所有付費方案及 API、Bedrock、Vertex AI、Foundry | 實驗性功能，預設停用 |
由上往下讀這張表，會看出一個取捨：Dynamic Workflow拿彈性換規模和可重現性，Agent Teams拿可重現性換即時協調和介入的掌控。沒有誰比較好，它們是為不同型態的問題調校的。
什麼時候選哪個
最快的判斷法則：路徑已知、要大規模、要可重複、必須可重現，用 Dynamic Workflow；流程需要協調與對話、想在執行中介入個別代理，用 Agent Teams。
對應到具體情境，Dynamic Workflow 適合這幾種狀況。
- 任務龐大又好平行的時候，例如整個程式碼庫的錯誤掃描、500 個檔案的遷移、逐一檢查每個 API 端點少了哪些授權檢查。
- 你大致知道要做什麼，只是量很大。
- 同一個流程會反覆跑的時候，例如每個分支都要做的審查，或每週固定的研究例行程序，指令碼存一次就能無限重跑。
- 可信度比一次快速完成更重要的時候，像是你想把對抗式交叉檢查或多角度草擬直接內建進協調流程，而不是聽天由命。
- 你想能讀、能比對計畫的時候，因為指令碼是一份打得開、看得到、進得了版本控制的東西。
- 最後，在意成本上限的人也會喜歡它：代理數量的硬上限能框住一段失控指令碼最多會燒掉多少。
Agent Teams則適合另外幾種
- 工作之間有真正的相依性、又需要邊跑邊協調的時候，跨層重構是典型案例：一個破壞性的 API 變更會牽動後端端點、用這些端點的前端元件，還有涵蓋兩邊的測試套件。
- 後端得先做完前端才能動，但測試代理可以並行先把骨架（scaffolding）搭起來，這個先後順序可以直接編進共享任務清單。
- 代理之間需要互相挑戰的時候也適合，例如價值來自隊員彼此分享發現、互相反駁，而不是各做各的孤立回報。
- 你想介入特定代理的時候：直接找某個隊員，就能在不打擾其他人的情況下單獨把他重新導回正軌。
成本與運作的現實
Dynamice Workflow會生出一大堆代理，單次執行燒掉的 token 可能明顯高過用一般對話處理同一件事。這些執行跟其他工作階段一樣，都會算進你方案的用量和速率限制。
正確的做法是先縮小範圍。先在單一目錄上跑，別一上來就掃整個儲存庫；先挑一個範圍明確的問題，別丟一個籠統的大問題。執行時打開 /workflows 檢視畫面，盯著每個代理的 token 用量。你隨時可以停，不會損失已經完成的部分。如果你平常會為例行工作切到較小的模型，啟動大型執行前先確認一下目前掛的是哪個；你也可以叫 Claude 把不需要最強模型的階段改派給便宜一點的模型。
投入前先知道的幾個坑
Agent Teams還是實驗性功能，稜角比較鋒利。它不能恢復工作階段，隊員崩了，或工作階段重啟，進行中的隊員都救不回來，只能整團重建。每個工作階段一次只能有一個作用中的團隊。隊員不能再自己往下開子團隊。主導者在團隊建立時就定死了，中途換不了。
還有一個可能直接影響你選擇的限制：依角色分模型，主導者用強模型規劃、實作和測試代理用便宜模型這在 Agent Teams目前還不支援。Dynamic Workflow可以在不需要最強模型的階段指定小一點的模型。如果「依角色分攤模型成本」對你很重要，這就是工作流程的一個加分點。
其實不必二選一
這兩種模式不是互斥的，把它們當競爭對手反而會看不到它們怎麼互補。Dynamic Workflow的指令碼本來就在協調子代理，天生適合管問題的廣度——一大堆需要交叉檢查再彙整的平行分支。代理團隊則在需要對話的環節發揮，也就是一組緊緊相依、得邊做邊喬的工作。
成熟一點的配置裡，常常是外層用工作流程管整體廣度，特定階段再交給協作式協調去處理真正相依的部分。哪裡有效就用哪種結構：別把自由流動的協作問題硬塞進僵硬的指令碼，也別把龐大的平行掃描丟給幾個話很多的對等代理。
結論
撇開術語，這個選擇最後就歸結到一件事：你想讓計畫住在哪裡。
路徑已知、規模龐大、流程會重複，而可重現性是你不能放掉的條件，就把它寫進程式碼，那是動態工作流程。工作彼此相依、代理之間要對話，而你想在執行途中親自帶個別工作者，就交給一個協調代理，那是代理團隊。
兩個都是比較新的功能，也都在快速變動。所以在你拿任何一邊當關鍵系統的地基之前，先去查當前的 Claude Code 文件，確認啟用方式、限制和行為的最新狀況。大方向已經穩了，邊緣的細節還在動。
