💡 核心結論速覽 (TL;DR)
- 動態工作流是什麼：Opus 4.8（2026/5/28 上線）在 Claude Code 推的研究預覽功能，由 Claude 自己寫一支 JS 腳本在背景編排子智能體，單次最多並行 16 個、總量上限 1,000 個 agent。
- 省的是「context」：中間結果存在腳本變數裡，只有最終答案回到你的對話，主視窗不會被塞爆、不會越用越慢。
- 燒的是「總帳單」：每個子智能體各有自己的 context window 各自吃 token，官方直接警告「單次最多 1,000 個 agent，成本飆很快」。
- 我的建議：任務能切成一堆獨立小塊才開（需 Claude Code v2.1.154+、Max/Team 預設開）；線性、互相依賴的任務別用，先小規模試、設好驗證關卡再放大。
先說一個我自己很有感的場景：你有沒有試過讓 Claude Code 跑一個大任務，跑到一半對話越來越長、回應越來越慢，最後它好像連自己前面講過什麼都記不太清楚？我每天泡在 AI 裡超過 10 小時，這種「越用越鈍」的挫敗感真的太熟了。
Claude 動態工作流（Dynamic Workflows）就是 Anthropic 想解決這件事的新招——讓 Claude 把大任務拆給一群子智能體並行去做，主對話只收最後結果。聽起來很美，但問題來了：這樣到底是幫你省 token，還是讓帳單燒更兇？這篇我用 AI 重度使用者的角度，把它的機制、開法、成本兩面刃和「該不該開」一次幫你拆清楚。
先別急著衝去打開它。我自己第一次看到「單次最多 1,000 個 agent」的時候，腦中閃過的不是興奮，是「這帳單會不會爆掉」。我們從頭看。
Claude 動態工作流是什麼？Opus 4.8 的「子智能體」到底在幹嘛
動態工作流是 Anthropic 隨 Claude Opus 4.8（2026 年 5 月 28 日上線，距離 Opus 4.7 只隔 41 天）在 Claude Code 推出的研究預覽功能。一句話講：你描述一個大任務，Claude 不再自己埋頭線性做，而是自己寫一支 JavaScript 腳本，在背景把任務拆成一堆子智能體（subagents）並行去跑，最後彙整成一份答案回給你。
這跟一般的 AI agent 不太一樣。如果你還在搞懂代理工具的基本概念，可以先看我整理的 用過三款 AI Agent 後才敢說的入門避雷指南，這篇預設你已經知道 agent 是什麼了。
動態工作流真正的關鍵字是「編排者—工人」（orchestrator-worker）。你可以想成：主 Claude 是工頭，它不親自砌牆，而是寫一張施工單，把「這面牆你砌、那扇窗你裝」分派給一群工人同時開工，自己只盯進度、最後驗收。每個工人（子智能體）都有自己獨立的 context window，彼此不互相干擾。
規格上有兩個數字要記住：同一時間最多並行 16 個子智能體，單次任務總量上限 1,000 個。也就是說 1,000 個是「這趟總共能派多少工」，但任何一個瞬間最多 16 個在動工，其餘排隊等空位。官方給的代表性例子是「跨數十萬行程式碼的 codebase 級遷移，從啟動到合併一條龍」——這不是拿來寫一封 email 的功能，是衝著大型工程去的。
如果你連 Opus、Sonnet、Haiku 該用哪個都還在猶豫，動態工作流對你可能還太早。我寫過一篇 每天用下來的 Claude 模型精準對比，先把模型選對，再來談要不要並行上千個分身。
動態工作流怎麼用？開啟條件與三步驟一次看
動態工作流不是打開 Claude Code 就有，它有明確的門檻。先確認三件事，缺一個都用不了。
❶ 升級 Claude Code 到 v2.1.154 或更新版本——這是硬條件，舊版根本看不到這功能。CLI、桌面 App、VS Code 擴充都支援。
❷ 確認你的方案：動態工作流只在 Max、Team、Enterprise 方案提供。Max 和 Team 預設就是開的；Enterprise 則預設關閉，要等管理員手動啟用。如果你是個人 Pro 方案，目前還碰不到。
❸ 直接用自然語言描述大任務，剩下交給 Claude。你不用自己寫腳本——當任務夠大、能拆解時，Claude 會判斷要不要動用動態工作流，自己生那支 JS 編排腳本、在背景跑，你的對話視窗全程保持可互動，不會卡死等它。
這裡有個我覺得最聰明的設計：腳本在背景執行時，中間那一堆子智能體產出的雜訊全都留在腳本變數裡，只有最終答案會回到你的對話。這也是為什麼它能「省 context」的根本原因，等下細談。
實際操作前，我會強烈建議你先把 Claude Code 的基本坑搞熟。並行上千個 agent 出問題時，debug 難度是平常的好幾倍。背景程序、限流、硬碟暴增這些雷，我都整理在 Codex／Claude Code 五大常見坑一篇避完，開動態工作流前先讀一遍不吃虧。
還有一個容易忽略的前置判斷：你是要在本機跑還是雲端跑？並行大量子智能體很吃資源，環境選錯體感差很多。這題我在 Claude Code 雲端 vs 本機怎麼選裡算過帳，動態工作流的使用者特別值得看。
省 token 還是燒更兇？我把兩面刃拆給你看
直接給結論：動態工作流省的是「context window」，燒的是「總 token 用量」——這是兩回事，搞混就會誤判。它讓你的主對話更清爽，但整趟任務的帳單很可能比平常高出一大截。
先講「省」的那一面。傳統做法是所有中間步驟、讀過的檔案、試錯紀錄全部堆在同一個對話裡，越堆越長，模型越來越鈍——這就是很多人感覺「Claude 怎麼越用越笨」的真正原因之一（不是被降智，是 context 被自己塞爆）。我專門寫過一篇拆解這件事：Claude 突然變慢變笨是被「降智」了嗎。動態工作流把中間雜訊全丟進腳本變數，主對話只留最終答案，等於從根本上避免了這個問題。
再講「燒」的那一面，這才是大家最該警惕的。每個子智能體都有自己獨立的 context window，各自吃自己的 token。你並行 50 個、200 個 agent，就是同時開 50、200 份用量在跑。MarkTechPost 引述官方說法很直白：這類功能「比一般 session 吃明顯更多 token」，而且「單次最多能派出 1,000 個 agent，成本飆很快」。
我把這兩面整理成一張對照表，你一眼就懂該緊張什麼、該放鬆什麼：
| 面向 | 動態工作流的影響 | 對你的實際意義 |
|---|---|---|
| 主對話 context | 大幅變省（中間結果不進主視窗） | 不會越用越慢、越鈍 |
| 總 token 用量 | 可能暴增（N 個 agent 各自吃） | 帳單／用量上限消耗很快 |
| 並行規模 | 同時 16 個、總量上限 1,000 個 | 派越多燒越快，要設天花板 |
| 速度 | 並行＝整體更快完成 | 用時間換 token 成本 |
講白話一點：動態工作流是拿「更多 token」去買「更快完成＋更乾淨的主對話」。值不值得，完全看你的任務適不適合並行，下一段我給你判斷標準。
順帶一提，如果你本來就常常用量爆表，與其指望這功能省錢，不如先把日常的 token 習慣調好。我整理過 10 個讓 token 砍半、不用升級 Max 的習慣，那才是真正省錢的地方；動態工作流是拿來「辦大事」的，不是拿來省小錢的。
動態工作流適合誰、不適合誰？我的判斷框架
一句話先擋在前面：不是任務大就該開動態工作流，而是任務「能切成一堆彼此獨立的小塊」才該開。判斷錯方向，你只是在用更貴的方式做同一件事。
我自己會用一個很簡單的問題篩：「這些子任務之間，需不需要互相知道對方在幹嘛？」不需要，就適合並行；需要頻繁共享上下文，就別硬拆。
| 情境 | 適合開動態工作流？ |
|---|---|
| 跨上百個檔案的同類型修改、大型遷移 | ✅ 適合（各檔獨立、可平行） |
| 對一份程式碼做多角度審查（安全／效能／風格分頭跑） | ✅ 適合（各視角獨立） |
| 大量資料分頭蒐集再彙整 | ✅ 適合（蒐集階段可並行） |
| 線性開發：A 做完才知道 B 怎麼做 | ❌ 不適合（強依賴，並行沒意義） |
| 小任務、單檔修改、一封信 | ❌ 不適合（殺雞用牛刀，純浪費） |
如果你符合「適合」那幾欄，我還是會勸你先小規模試水溫：第一次別一上來就放 500 個 agent，先用小批量確認它真的有把任務拆對、驗證關卡有設好，再慢慢放大。並行的可怕之處在於——錯誤也會被並行放大，1,000 個 agent 一起走錯路，那帳單你會記一輩子。
還有一種人我會直接勸退：如果你連 Claude Code 都還在猶豫要不要學，動態工作流對你太早了。先看 非工程師到底值不值得學 Claude Code，把基本盤站穩再說。動態工作流是進階使用者的放大器，不是新手的入門磚。
動態工作流跟「一般 AI agent 燒錢」差在哪？
很多人會把動態工作流跟「AI agent 帳單暴增」混為一談，其實兩者的燒錢邏輯不一樣。一般 agent 燒錢多半是單一任務反覆試錯、上下文越滾越大；動態工作流燒錢則是刻意同時開很多份用量去換速度，是「主動加碼」而非「失控暴衝」。
這個區別很重要，因為解法不同。一般 agent 燒錢的省法、帳單怎麼來的真相，我拆得很細：AI agent 一個任務燒掉好幾美元的真相＋砍半省 token 心法，那篇講的是「怎麼不浪費」。動態工作流則相反，它的成本是「你明知道會貴，但用速度和乾淨的 context 把錢賺回來」——前提是你的任務真的值得這樣花。
另一個常被問的：動態工作流會不會取代我手動串的那些 MCP、子代理流程？我的看法是互補。MCP 是讓 Claude 接到外部工具和資料，動態工作流是讓 Claude 把工作量橫向攤開，兩者解決的問題不同。想搞懂 MCP 怎麼配，可以參考 不同情境我的 MCP server 實測分工。
說點我自己的觀察。動態工作流這種「AI 自己寫腳本、自己派一群分身去幹活」的形態，其實就是這一兩年大家在吵的「AI 自我編排、自我放大」的縮影。它讓我又興奮又有點警惕——興奮是因為我腦中那些「想驗證但懶得手動拆」的點子突然都變可行了，警惕是因為自動化規模一旦失控，代價也是並行放大的。這種感受跟我讀完 Anthropic 那份報告後的心情很像，有興趣可以看 Claude 寫了 80% 程式碼、正在「瓦解人類」的真相。
👉 前往 Claude Code 官方頁面看動態工作流支援版本
說到底，動態工作流不是「越多越好」的玩具，而是一把要看任務形狀才拿出來的放大鏡。我自己的原則很簡單：能並行才開、先小規模試、把成本當主動選擇而不是意外。如果你想跟上我每天踩 AI 工具的第一手心得，訂閱我的部落格，會不定期收到新文章的通知，下次有大功能上線我也會像這篇一樣幫你把帳算清楚再決定要不要追。
FAQ 常見問題
動態工作流和一般 Claude Code 用法，我該優先用哪個？
預設用一般用法就好。動態工作流是「大任務＋能高度並行」時才開的放大器——例如跨上百檔的遷移、多視角審查。如果你的任務是線性、互相依賴的，或只是單檔小修，一般用法更省也更穩。先問自己「子任務需不需要互相知道對方在做什麼」，不需要才考慮並行。
動態工作流會讓我的帳單爆掉嗎？
有可能，要主動控管。它省的是主對話 context，但每個子智能體各自吃 token，官方明講「單次最多 1,000 個 agent，成本飆很快」。實務上先小批量試、設好並行天花板與驗證關卡，別第一次就放幾百個 agent。把它當「明知會貴但用速度換值得」的工具，不是省錢工具。
沒有 Max 或 Team 方案能用動態工作流嗎？
目前不行。動態工作流只開放 Max、Team、Enterprise 方案，Max 和 Team 預設開啟，Enterprise 要管理員手動啟用，個人 Pro 方案碰不到。另外要把 Claude Code 升到 v2.1.154 或更新版本，CLI、桌面 App、VS Code 都支援。
動態工作流真的能「省 token」嗎？這說法對嗎？
要看你指的是哪種 token。它省的是「主對話的 context 佔用」——中間結果留在腳本變數、不回主視窗，所以對話不會越用越鈍。但「整趟任務的總 token 用量」通常是增加的，因為並行多個 agent 等於同時開多份用量。說「省 token」只對了一半，完整講法是「省 context、可能燒總量」。
參考資料
- Anthropic — Introducing Claude Opus 4.8（官方公告）
- TechCrunch — Anthropic releases Opus 4.8 with new 'dynamic workflow' tool
- MarkTechPost — Workflows Capped at 1,000 Subagents（規格與成本警告）
- 關於夜羽凌：每天用 AI 超過 10 小時的跨兩岸創作者
