計畫住在程式碼，不住在記憶：Opus 4.8 的 Dynamic Workflows 讓 Claude Code 協調 1,000 個子代理人

重點一：Anthropic 在 2026 年 5 月 28 日發布 Claude Opus 4.8，距上一代 Opus 4.7 僅 41 天，SWE-Bench Pro 得分 69.2%，比 GPT-5.5 高 10.6 個百分點，定價不變（$5/$25 每百萬 token）。

重點二：Dynamic Workflows（研究預覽）讓 Claude Code 用一個 JavaScript 腳本協調最多 1,000 個子代理人，計畫和中間結果存在腳本變數而非 Claude 的 context window——任務可以跨小時、跨天執行，你的 session 同時保持可用。

重點三：開 Dynamic Workflows 前需要判斷：規模、可拆分性、跨檔案驗證需求、可中斷恢復、明確完成標準，這五個條件若不符合，一般對話模式反而更快。

11 天，750,000 行，測試通過率 99.8%。這是 Anthropic 公布的官方案例：一個 75 萬行的 Python 2 程式碼庫，由 Claude Code 在 11 天內完成全量遷移到 Python 3。數字是 Anthropic 自己給的，不是第三方驗證——但它標出的任務量級，過去確實沒有任何 AI 代理人工具敢承接。

這件事過去靠一個 Claude Code session 做不到——不是因為模型能力不夠，而是任何 AI 代理人工具的 context window 都有物理上限，超過一定規模就必須靠人工切割任務、分批送進去，由工程師在中間扮演協調者。

2026 年 5 月 28 日，Anthropic 發布 Claude Opus 4.8，同時推出 Dynamic Workflows 研究預覽版。從這天起，上述那種任務的執行方式改變了：一個指令，一個 JavaScript 腳本，最多 1,000 個子代理人在背景同時工作，中間結果不進入 Claude 的記憶，你的 session 持續可用。

距 Opus 4.7 發布：41 天。定價變化：零。子代理人上限：1,000。這三個數字背後，是 Claude Code 的執行架構靜悄悄地換了一層。

---

Opus 4.8 同場升了什麼：benchmark 小步走，主菜是執行架構

先快速交代模型本身。Anthropic 自己把 Opus 4.8 定位為「謙遜但有感提升」（modest but tangible improvement）：在 SWE-Bench Pro（任務難度更高的評測集）上得分 69.2%，比 Opus 4.7 的 64.3% 高 4.9 個百分點，領先 GPT-5.5 的 58.6% 與 Gemini 3.1 Pro 的 54.2%；在原版 SWE-Bench Verified（500 題）上是 88.6%，比前代的 87.6% 提升有限。

官方同時提到一項與長任務直接相關的改善：Opus 4.8 比 Opus 4.7 少四倍出現「讓程式碼缺陷未被標記就通過」的情況，不確定時會主動標注而不是宣稱完成。對一個要在背景無人監看跑幾小時的工具來說，這是 Dynamic Workflows 能實際可用的前提之一。

但如果只看 benchmark 差距，會錯過這次發布真正改變開發者日常的部分。分數說明模型寫得多好；同場推出的 Dynamic Workflows，改變的是 Claude Code 能承接什麼「規模」的任務——這才是接下來四節要拆的東西。

---

計畫搬進腳本：中間結果存進變數，session 保持可用

傳統的 Claude Code 多步驟任務有一個結構性限制：每個子代理人執行完，結果都會進入 Claude 的 context window。任務夠大的時候，context 被中間結果填滿，後續代理人的「記憶」就會開始失去前面的資訊。

Dynamic Workflows 改掉的是這個底層結構：

Claude 根據你描述的任務，撰寫一個 JavaScript 腳本。這個腳本由獨立的 runtime 在背景執行，腳本裡的變數負責儲存中間結果——不是 Claude 的 context。你的 session 在任務跑的過程中完全保持活躍，可以繼續對話、問問題，最後只有最終結果回到你面前。

當計畫住在程式碼裡，不住在 Claude 的記憶裡，Claude Code 從一個聰明的對話工具變成了一個可以在背景跑幾天的任務引擎。

這個架構帶來的另一個能力是對抗性審閱（adversarial review）：workflow 腳本可以設計讓獨立的子代理人互相核查彼此的結論，只有通過交叉驗證的結果才會被納入最終輸出，而不是靠單一 pass 完成。

觸發方式很直接：在 Claude Code 的提示裡加上「workflow」這個詞，Claude 就會為這個任務撰寫腳本。也可以輸入 /effort ultracode 進入最高設定，讓 Claude 自行判斷每個任務是否值得啟動 workflow。

---

16 個並行、1,000 個上限：這兩個數字劃出的能力邊界

官方文件明確了兩個硬性邊界：

限制	數值	原因
最大同時並行子代理人	16 個	受本機 CPU / 記憶體資源限制
每次 workflow 子代理人總量	1,000 個	防止迴圈失控

750,000 行的遷移案例說明了這個設計的邊界在哪：假設每個子代理人負責大約 750 行程式碼，完成整個遷移正好需要約 1,000 個子代理人。Anthropic 把上限設在 1,000，是把這個規模的任務當作設計目標，這個數字不是偶然的。

兩個關鍵的現實條件開發者需要知道：

可恢復性（resumable）：workflow 在同一個 Claude Code session 內被中斷後，可以從完成點繼續——已完成的子代理人不重跑，只有剩餘的繼續執行。但如果你退出 Claude Code，下次重開 session 時 workflow 會從頭開始，不會延續上次的進度。

子代理人的權限模式：workflow 內的子代理人一律以 acceptEdits 模式執行，不繼承你 session 的權限設定。如果任務中途需要執行尚未在 allowlist 裡的 shell 指令或 MCP 工具，workflow 會在那個點停下來等確認——長時間任務最好在開始前先把需要的指令加進 allowlist。

---

換句話說：Dynamic Workflows 能讓 Claude Code 承接「人工切割任務」的那類工作，但 1,000 個上限和 session 限制意味著它還不是無限制的後台服務——它是一個有邊界的大型批次作業框架。

---

Effort Control 與 Ultracode：從對話模式切換到作業排程模式

Opus 4.8 同時在 claude.ai 和 Cowork 上線了 Effort Control：模型選擇器旁邊多了一個調節控制，讓你決定 Claude 在這次回應上投入多少思考。

設定	適合場景	消耗
Low	日常問答、快速檢查	最省 token / 時間
High	複雜問題、多步驟規劃	一般增加
Ultracode	自主大型任務	顯著增加

Ultracode 是 Claude Code 專屬設定，輸入 /effort ultracode 啟用。開啟後，Claude 會自行判斷每個任務是否值得啟動 workflow：一個請求可能變成三個串接的 workflow（理解程式碼 → 執行修改 → 驗證結果）。

Ultracode 在 session 結束後自動重設，不會持續到下一個 session。回到日常工作時輸入 /effort high 即可降回來。重要提醒：Ultracode 只在支援 xhigh 推理層級的模型上可用，且每個請求的 token 消耗和時間都會顯著上升——它是作業排程模式，不是日常對話模式。

---

費用怎麼估：定價不變背後的 token 消耗邏輯

Opus 4.8 的標準定價與 Opus 4.7 完全相同：

• 標準模式：$5 / $25（每百萬 input / output token）
• Fast Mode（2.5 倍速）：$10 / $50（每百萬 input / output token）

Anthropic 同時調降了 Fast Mode 費用，是上一代 Opus Fast Mode 的三分之一，讓速度優先的任務更划算。

但有一個費用邏輯開發者容易低估：Dynamic Workflows 啟動後，每一個子代理人都有獨立的 context + 輸出，token 消耗量遠超過單次對話。一個有幾十到幾百個子代理人的 workflow，帳單可以是普通對話的數十倍。

Anthropic 的文件直接點明：「一次 workflow 執行可以消耗比單次對話多出許多的 token，計入你計畫的使用量上限。」

實際做法：開始一個大型 workflow 前，先用 /workflows 查看預估的階段規模，確認這個任務的商業價值能支撐這個費用。對預算敏感的任務，先用一般對話模式測試邏輯再用 workflow 執行。

---

五個條件：哪些任務值得開 Dynamic Workflows？

這是今天最重要的判斷框架。Dynamic Workflows 不是適合所有任務的工具。

值得用的五個條件：

1. 規模超過 500 個檔案或函式 — 單一 context 無法容納整個任務範圍
2. 需要跨檔案交叉驗證 — 一個代理人修改 A 檔案後，需要另一個代理人確認 B 檔案的相依是否仍然成立
3. 任務可以拆成獨立子任務 — 各子代理人的工作之間沒有強依賴，可以平行執行
4. 任務可以中斷後恢復 — 可以接受任務跑幾小時甚至幾天，也能接受在同一個 session 內分段執行
5. 有明確的完成標準 — 例如：測試全過、lint 無錯誤、每個檔案符合指定格式

不值得用的三種情況：

• 單次修改或對話型問答 — 開 workflow 的啟動成本（token + 時間）高於任務本身
• 預算敏感任務 — 子代理人的 token 消耗不可精確預測，不適合有嚴格費用上限的工作
• 需要即時人工判斷的任務 — workflow 執行過程中不能等你輸入，只有代理人需要授權新工具時會暫停

白話講：Dynamic Workflows 設計的對象是「過去因為太大而不敢交給 Claude Code 的任務」——讓大型任務從「人工協調」升級到「腳本協調」。日常的對話型任務用 workflow 反而多了一層啟動成本，一般模式更快。

---

Anthropic 同時內建了一個最低門檻的 workflow 讓你試試看這個機制：輸入 /deep-research 加上任何你想調查的問題，Claude Code 會在背景啟動跨來源的研究任務，讓多個代理人分別搜尋、互相核查、過濾掉沒通過交叉驗證的結論，最後輸出一份帶引用的報告。

你不需要先設計腳本，也不需要有大型任務在手。這是最快看見 workflow 如何在背景跑起來的方式，執行前先確認 Claude Code 版本在 v2.1.154 以上，Pro 計畫使用者需要在 /config 手動開啟 Dynamic workflows。

Anthropic 的 41 天節奏表明接下來仍然會繼續疊加功能。目前值得問的問題不是「Opus 4.8 比 4.7 好多少」，而是：你手上現在有哪個工程任務，因為規模太大而放棄了用 Claude Code？那個任務，現在值得重新評估一次。

---

資料來源：Anthropic 官方 blog（Introducing Claude Opus 4.8）、Claude Code 官方文件（Orchestrate subagents at scale with dynamic workflows）、Claude blog（Introducing dynamic workflows in Claude Code）、TechCrunch、The Decoder、The New Stack