TL;DR
Claude Opus 4.8 的重點不只在模型能力更新，而在 Claude Code 新增的 Dynamic Workflows。
這個功能讓 Claude Code 依任務生成 JavaScript orchestration script，並以多個 subagents 並行處理大型工作。
影片示範的核心策略是用較便宜的 Haiku 類模型展開廣度，再用 Opus 4.8 做收斂與驗證。
適用範圍是大型程式碼庫遷移、批次審查、跨來源研究與多路驗證；一般小任務仍不需要啟動這種編排。
過去需要人手設計 harness、手動拆任務、安排多個 subagents 的流程，現在可以交給 Claude Code 依自然語言任務生成工作流腳本。
這個說法與 Anthropic 官方發布相符。Anthropic 在 2026 年 5 月 28 日介紹 Opus 4.8 時，同步提到 Claude Code 新增 Dynamic Workflows，可讓 Claude 規劃工作，並在單一 session 中運行大量並行 subagents，最後再驗證輸出。
影片的實作示範有三個重點。第一，最新版 Claude Code 可以透過設定啟用 Dynamic Workflows。第二，任務中可指定「便宜模型做廣度、旗艦模型做收口」的策略。第三，工作流執行時可觀察多階段進度與各 subagent 的輸出狀態。
Dynamic Workflows 的本質：把任務計畫變成腳本
傳統 prompt chaining 依賴主對話上下文維持計畫。任務一長，中間結果、審查意見與分支推理會逐步塞滿 context window。Dynamic Workflows 的設計差異在於，它把計畫轉成可執行腳本，讓迴圈、分支與中間結果留在工作流 runtime，而不是全部回灌到主對話。
這不是單純把 Claude Code 的 subagent 數量拉高。影片反覆強調，subagents、skills 與 workflows 是三個不同層級：
| 類型 | 本質 | 適合任務 | 主要限制 |
|---|---|---|---|
| Subagent | 主 session 派生的 focused worker | 單一審查、研究、局部修復 | 回傳摘要仍會進入主上下文 |
| Skill | 可重複載入的指令與資源包 | 固定領域流程、格式、工具使用 | 仍由主模型決定何時與如何使用 |
| Dynamic Workflow | 由模型生成並執行的 orchestration script | 大型遷移、多路驗證、批次研究 | 需要清楚驗收條件與成本控制 |
這個分層很重要。若任務只是修改一個檔案或整理一份短文，workflow 可能增加不必要的 overhead。若任務涉及數百個檔案、跨模組驗證或多輪對抗審查，workflow 才有明顯價值。
模型配置：Haiku 做廣度，Opus 做收斂
影片中最實用的部分，是把模型成本納入工作流設計。講者示範讓較低成本的 Haiku 類模型負責探索、分類與初步檢查，再讓 Claude Opus 4.8 做彙整、判斷與最終驗證。
這種配置背後的邏輯很直接。大型任務通常有大量可並行的低風險工作，例如掃描檔案、整理 issue、初步分類、尋找可疑點。這些工作不一定需要最強模型。真正需要 Opus 的位置，是跨結果整合、衝突判斷、架構選擇與交付前驗證。
| 階段 | 建議模型角色 | 任務範例 | 驗收方式 |
|---|---|---|---|
| 探索 | Haiku / 低成本模型 | 掃描檔案、列出候選 bug、分群 issue | 覆蓋率與可追溯清單 |
| 對抗驗證 | 多個低成本模型 | 對同一候選問題做交叉檢查 | 一致性、反例、重現步驟 |
| 收斂 | Opus 4.8 | 彙整結論、做風險排序、制定修復策略 | 測試、build、審查紀錄 |
這也解釋了為什麼 Dynamic Workflows 比「開很多 subagents」更接近 harness engineering。它不只是在增加 agent 數量，而是在定義模型分工、成本邊界、驗證節點與輸出格式。
什麼任務適合啟用 Dynamic Workflows
影片提出的典型場景包括大型 bug bash、整個程式碼庫分析、大規模遷移、框架替換、跨來源研究與多角度壓測。這些場景有共同特徵：可以拆成獨立工作流，且每個分支的結果需要最後被統一驗證。
Anthropic 官方也給出相近定位。官方描述 Dynamic Workflows 可用於 codebase-scale migrations，並以既有測試套件作為驗收標準。這點對工程團隊尤其關鍵，因為大型 agent 工作若缺少可執行驗收條件，容易變成漂亮但不可合併的報告。
比較穩健的啟動條件如下：
| 問題訊號 | 是否適合 workflow | 原因 |
|---|---|---|
| 任務可拆成 10 個以上獨立工作流 | 適合 | 可發揮並行化價值 |
| 需要跨多個資料來源互相驗證 | 適合 | 可用多分支降低單一路徑偏誤 |
| 需要修改數百個檔案 | 適合，但需測試護欄 | 風險高，必須有 build/test gate |
| 單一 bug、單一檔案修改 | 通常不適合 | orchestration overhead 大於收益 |
| 沒有明確驗收標準 | 不建議 | agent 可能產生不可驗證的進度感 |
風險：workflow 不是自動成功保證
Dynamic Workflows 的價值在於擴大可管理的任務規模，但它不會自動解決需求不清、測試不足或資料來源錯誤。影片中提到 token budget 與模型分工，這是正確方向，但仍需要額外補上三個護欄。
第一，任務要有可執行驗收條件。例如測試命令、build command、lint、截圖比對或資料校驗。第二，要限制每個階段的輸入與輸出格式，避免 subagents 產生不可合併的自由文字。第三，要保留人工檢查點，尤其在 workflow 要寫入大量檔案或影響生產流程時。
Anthropic 在 Opus 4.8 發布中也強調模型更會標註不確定性，而不是直接宣稱完成。這種「承認不確定」的能力，對長任務反而比單次 benchmark 更重要。大型 workflow 最怕的不是慢，而是錯得很自信。
對團隊的實際含義
如果你已經在使用 Codex 或 Claude Code 做日常工程，Dynamic Workflows 可以被視為下一層抽象：從「模型幫我改一段程式」走向「模型幫我管理一個可驗證的工程批次」。
短期內，它最適合用在內部工具、migration spike、測試補強、程式碼審查與研究型任務。更高風險的場景，例如自動修改核心服務、資安修補或大規模資料處理，仍需要人類 reviewer、CI gate 與 rollback plan。
作者觀點是，Dynamic Workflows 真正值得關注的地方，不是一次能開多少 subagents，而是它讓 agent orchestration 從 prompt 技巧變成可保存、可重跑、可審查的 workflow artifact。這會讓未來的 AI coding 工作更接近「工程系統」，而不是單次聊天。
權威引用來源
- Anthropic: Introducing Claude Opus 4.8
- Anthropic Resources: Claude Code Advanced Patterns: Subagents, MCP, and Scaling to Real Codebases
- Claude: Claude Code
作者觀點：Dynamic Workflows 的關鍵不是「更多 agent」，而是「可驗證的任務編排」。團隊若要導入，應先從有明確測試與低風險 rollback 的工作開始，把 workflow 當成工程流程的一部分，而不是把它當作全自動替代工程判斷的捷徑。
