Claude Code 本次發佈的 Workflow 是什麼？有哪些場景值得用？

最近Claude Opus 4.8推出，同時Claude Code都一齊更新咗，推出咗新功能Dynamic Workflows，佢唔係一個簡單嘅功能，而係一種處理大型任務嘅方法。

當然，如果只係一個好細嘅需求，用簡單對話就完全夠用，但一旦換成大型任務，例如：對代碼庫做安全審計、將代碼庫例如由iOS翻譯成Android，類似嘅任務只靠主對話上下文好快就會變得擁擠、上下文爆炸。

今次更新嘅workflows嘅處理方式比較直接：首先會叫Claude先寫一段JavaScript workflow腳本，再由腳本喺後台調度一批Agent，喺主對話唔使反覆接收中間過程，而係只等整理過嘅結果。

表面睇係多開Agent進行編排，更大嘅變化喺任務計劃嘅位置：編排由聊天窗口搬咗去腳本入面控制。

一句話講清楚底層邏輯

我會將workflows理解為一種可以儲存嘅任務腳本。

我只需要將任務同約束講清楚，Claude會先生成一段JavaScript腳本，再由腳本去拆任務、叫subagent、彙總結果。中間執行過程唔會一直刷入主對話，主線程淨係保留最後整理好嘅輸出。

呢個同臨時prompt最大嘅分別係：workflow可以放到項目嘅 .claude/workflows/ 裏面。下次做類似嘅代碼審計、技術調研、方案評審時，我唔使重新組織一大段prompt，只要改一改腳本就可以繼續跑，團隊入面其他人亦都可以重用同一套流程。

所以我對佢嘅理解好簡單：腳本負責流程，Agent負責執行。

裝修屋嘅比喻

我用裝修嚟理解呢幾種能力。

普通多輪對話好似睇實一個師傅做嘢，改函數、補測試、追報錯，直接講清楚就夠。

Skill好似施工手冊，將規則、步驟、驗收標準寫好，叫師傅同類任務每次按同一套方式執行。

Subagents好似臨時叫多幾個師傅一齊做嘢，佢解決嘅係「多幾雙手」，但流程同結果合併始終要我嚟判斷同指定。

Agent Teams好似帶住班嘅施工隊，適合多角色一齊校準，例如前端、後端、測試、架構、安全一齊睇一個方案。

Workflow更加似施工流程圖：順序、返工、驗收都寫入腳本入面，Agent負責執行，流程本身可以保存同重用。

點樣區分使用都比較簡單：細需求直接傾；穩定工作沉澱成Skill；並行任務用subagents；多角色討論用Agent Teams；要分階段、覆核、重用大型任務，就要用Dynamic Workflows。

幾時應該用workflow

日常細改動，根本用唔着workflow。

佢有啟動成本，亦都更耗token，適合處理流程本身已經好重要嘅任務。

喺workflow之前，我通常會先睇嚇能唔能夠用Skill解決。例如PR review睇邊啲位、發版前跑邊啲檢查、效能問題先查邊啲log、數據庫變更要補邊啲field，呢啲都更加適合寫入 SKILL.md

Skill解決嘅係「唔好漏步驟」。Claude仲係喺主對話入面做嘢，只係會按團隊約定執行。如果任務一個人順住做就可以完成，只係希望過程更加穩定，用Skill就夠。

但如果任務變咗做枚舉、分組、並行檢查、二次覆核、去重匯總，咁就更適合workflow。

研究類任務都類似，Claude Code嘅 /deep-research 本身就係一個workflow：多方向收集資料，交叉檢查關鍵斷言，最後輸出有引用嘅報告。技術選型、競品分析、方案調研，都可以借呢個思路。

需要多階段、多視角、可覆核，而且下次可能仲要跑，就考慮workflow，只做一次嘅細任務，唔好將工具用得太重手。

點樣啟動

官方文件要求Claude Code v2.1.154 或者更高版本。Pro用戶仲需要喺 /config 裏打開 Dynamic workflows。如果要用 /deep-research，仲要確認WebSearch可以用。

想率先感受嚇，可以先跑官方內置嘅deep research：

/deep-research Java 8 到 Java 20 之間有哪些主要變化？按版本歸納，並補充來源。

自己觸發workflow都唔複雜。最直接嘅辦法，係喺prompt入面講明今次要跑workflow：

請運行一個 workflow，審計 src/routes/ 下所有 API endpoint 是否缺少鑑權檢查。
返回文件路徑、endpoint 名稱、代碼證據、嚴重級別和建議修復方式。
沒有代碼證據的結論不要報告。

呢句話嘅作用就係將執行方式講死：今次唔好喺主對話入面逐啲查，直接生成workflow嚟跑。

另一種辦法係將effort校高：

/effort ultracode

Ultracode會叫Claude自己判斷使唔使用workflow。複雜請求可能會拆出唔止一個workflow，例如先理解代碼，再執行修改，最後驗證結果。佢慳心機，但亦更貴。細改做完之後，記得轉返去 /effort high。

點樣睇進度，點樣保存

workflow啟動之後，用 /workflows 睇進度。

呢個界面會列出當前會話入面正在跑同已經跑完嘅workflows。㩒入去仲可以睇某個phase、某個agent嘅prompt、工具調用同結果。

實際用起上嚟，先記住幾個掣就夠：p 暫停或者恢復，x 停止，r 重啟正在運行嘅agent，s 保存workflow腳本。

例如一個安全審計workflow，第一階段可能只係掃描，下面掛幾個子Agent；第二階段先做驗證，要等掃描結束之後再分配。禁 p 暫停之後，只要仲喺同一個Claude Code會話入面，就可以繼續跑，已經完成嘅Agent結果會被快取落嚟。

不過退出Claude Code之後，運行狀態唔會原樣保留。想長期重用，就要保存腳本。保存到 .claude/workflows/，佢屬於當前項目，可以跟住倉庫走；保存到 ~/.claude/workflows/，佢就係你個人嘅常用命令。保存之後，workflow會好似slash command咁出現。

一次好prompt只係今次傾得順。可以保存、可以重新跑、可以叫團隊一齊用，先算真正沉澱落嚟。

Prompt要寫得似任務合約

workflow prompt唔好寫成「幫我全面審計一下」。呢種講法太闊，Claude會自己補好多細節，最後結果都容易發散。

我通常會將目標、範圍、階段同證據要求提前寫清楚，例如：

請為下面的研發任務運行一個 workflow：

目標：審計訂單服務裏的接口鑑權是否完整，輸出可進入修復排期的問題清單。

範圍：
- 只檢查 services/order/src/routes、services/order/src/controllers、services/order/src/middleware。
- 排除 tests、mock、generated 目錄。

階段：
1. 枚舉所有 HTTP endpoint，記錄路由、handler 和調用鏈入口。
2. 按業務模塊分組，檢查是否經過 auth、permission、tenant 校驗。
3. 對可疑發現做二次複核，必須回到代碼證據。
4. 合併重複問題，按影響面和可利用性分級。

輸出：
- 使用 Markdown 表格。
- 字段包含：模塊、endpoint、文件路徑、handler、證據行、風險說明、嚴重級別、建議修復方式。

規則：
- 沒有代碼證據不要報告。
- 不要修改代碼，只做審計報告。
- 不確定的結論放入「需要人工確認」。

呢個模板嘅重點唔係格式，而係先將邊界釘實。

目標 決定方向，範圍 限制掃描邊界，階段 固定執行順序，規則 用嚟擋住冇證據嘅結論。

我唔使自己寫JavaScript，只需要將任務講細啲。任務越清楚，Claude生成workflow腳本時自由發揮就越少。

邊界同成本

Dynamic Workflows唔係無限並行機器。

官方限制係：單次run最多16個並行Agents，總Agent數量最多1000個。

佢可以喺一次任務入面調度幾十到上百個Agent，但唔會同一瞬間無限並行。workflow腳本都唔係直接操作層，唔讀寫檔案，唔跑shell，只負責協調；真正做嘢嘅係被調度出去嘅Agent。

仲有一個限制容易俾人忽略：workflow唔適閤中途成日問你意見。官方文件說明，run過程中冇普通嘅用戶輸入節點，只有權限提示可能會暫停。如果你希望「第一階段結束後我先確認，再進入第二階段」，最好拆成兩個workflow。

成本都要提前計。一個workflow會啟動好多Agent，每個Agent都會消耗當前session嘅模型token。除非腳本將簡單階段路由到更平嘅模型，否則賬單會好快變厚。

跑大任務前，先睇一睇 /model，再確認shell、WebFetch、MCP呢啲工具權限有冇開放。長任務跑到一半先卡喺allowlist度，會好影響節奏。

呢個功能應該點睇

Dynamic Workflows更加適合大型任務，尤其係嗰啲一放進主對話就會有上下文壓力嘅任務。

佢睇落似Skill + subagent嘅組合，但本質唔同。Skill叫Claude按固定規則做嘢，subagent負責將局部任務拆出去執行，而workflow係將整套執行計劃寫入腳本入面：點樣拆、點樣並行、點樣覆核、點樣匯總，都由腳本控制。

呢個都係佢同普通多Agent最大嘅分別。普通對話入面，Claude仲喺主線程入面一邊判斷、一邊調度，中間結果會不斷塞入上下文；workflow就將中間狀態留喺運行時入面，主對話只係接最後整理好嘅結果。

所以workflow主要解決嘅唔係多Agent編排，而係叫複雜任務有一套可以保存、可以檢查、可以重新跑嘅執行流程。

我嘅理解係：細任務用prompt，穩定規則用Skill，局部並行用subagent；當任務大到需要分階段、控制上下文、交叉覆核，而且下次仲可能再跑時，先係workflow嘅主場。

參考資料

1. Anthropic: Introducing Claude Opus 4.8
   https://www.anthropic.com/news/claude-opus-4-8
2. Claude Code Docs: Orchestrate subagents at scale with dynamic workflows
   https://code.claude.com/docs/en/workflows
3. Claude Code Docs: Run agents in parallel
   https://code.claude.com/docs/en/agents
4. Claude Code Docs: Orchestrate teams of Claude Code sessions
   https://code.claude.com/docs/en/agent-teams

最近Claude Opus 4.8 發佈，同時Claude Code 也一起更新了，發佈了新特性 Dynamic Workflows，它不是一個簡單的功能，而是一種處理大任務的方式

當然，如果只是一個很小需求使用簡單對話就完全夠用了，但一旦換成大型任務，比如：代碼庫進行安全審計、代碼庫比如ios翻譯成安卓，類似的任務只主對話上下文很快就會變得擁擠、上下文爆炸

本次更新的 workflows 的處理方式比較直接：首先會讓 Claude 先寫一段 JavaScript workflow 腳本，再由腳本在後台調度一批 Agent，在主對話不用反覆接收中間過程，而是隻等整理過的結果。

表面看是多開 Agent進行編排，更大的變化在任務計劃的位置：編排從聊天窗口，搬到了腳本里來控制

一句話說清楚底層邏輯

我會把 workflows 理解成一種可落盤的任務腳本

我只需要把任務和約束說清楚，Claude 會先生成一段 JavaScript 腳本，再由腳本去拆任務、調 subagent、彙總結果。中間執行過程不會一直刷進主對話，主線程只保留最後整理好的輸出。

這和臨時 prompt 最大的區別是：workflow 可以放到項目的 .claude/workflows/ 裏。下次做類似的代碼審計、技術調研、方案評審時，我不用重新組織一大段 prompt，只要改一改腳本就能繼續跑，團隊裏其他人也能複用同一套流程

所以我對它的理解很簡單：腳本負責流程，Agent 負責執行

裝修房子的比喻

我用裝修來理解這幾種能力。

普通多輪對話像盯着一個師傅幹活，改函數、補測試、追報錯，直接說清楚就夠了

Skill 像施工手冊，把規則、步驟、驗收標準寫好，讓師傅同類任務每次按同一套方式執行

Subagents 像臨時多叫幾個師傅並行幹活，它解決的是“多幾雙手”，但流程和結果合併還得我來判斷與指定

Agent Teams 像帶領班的施工隊，適合多角色一起校準，比如前端、後端、測試、架構、安全一起看一個方案

Workflow 更像施工流程圖：順序、返工、驗收都寫進腳本里，Agent 負責執行，流程本身可以保存和複用

如何區分使用也比較簡單：小需求直接聊；穩定工作沉澱成 Skill；在並行任務用 subagents；多角色討論用 Agent Teams；要分階段、複核、複用 大型任務，再用 Dynamic Workflows

什麼時候該用 workflow

日常小改動，根本用不上 workflow

它有啓動成本，也更耗 token，適合處理流程本身就很重要的任務

在 workflow 之前，我一般會先看能不能用 Skill 解決。比如 PR review 看哪些點、發版前跑哪些檢查、性能問題先查哪些日誌、數據庫變更要補哪些字段，這些都更適合寫進 SKILL.md

Skill 解決的是“別忘步驟”。Claude 還是在主對話裏做事，只是會按團隊約定執行。如果任務一個人順着做就能完成，只是希望過程更穩定，用 Skill 就夠了

但如果任務變成了枚舉、分組、並行檢查、二次複核、去重彙總，那就更適合 workflow

研究類任務也類似，Claude Code 的 /deep-research 本身就是一個 workflow：多方向收集資料，交叉檢查關鍵斷言，最後輸出帶引用的報告。技術選型、競品分析、方案調研，都可以借這個思路

需要多階段、多視角、可複核，並且下次可能還要跑，就考慮 workflow，只做一次的小任務，別把工具用重了

怎麼啓動

官方文檔要求 Claude Code v2.1.154 或更高版本。Pro 用戶還需要在 /config 裏打開 Dynamic workflows。如果要用 /deep-research，還要確認 WebSearch 可用。

想先感受一下，可以先跑官方內置的 deep research：

/deep-research Java 8 到 Java 20 之間有哪些主要變化？按版本歸納，並補充來源。

自己觸發 workflow 也不復雜。最直接的辦法，是在 prompt 裏明說這次要跑 workflow：

請運行一個 workflow，審計 src/routes/ 下所有 API endpoint 是否缺少鑑權檢查。
返回文件路徑、endpoint 名稱、代碼證據、嚴重級別和建議修復方式。
沒有代碼證據的結論不要報告。

這句話的作用就是把執行方式說死：這次不要在主對話裏一點點查，直接生成 workflow 來跑。

另一種辦法是把 effort 調高：

/effort ultracode

Ultracode 會讓 Claude 自己判斷要不要用 workflow。複雜請求可能會拆出不止一個 workflow，比如先理解代碼，再執行修改，最後驗證結果。它省心，但也更貴。小改動做完後，記得切回 /effort high。

怎麼看進度，怎麼保存

workflow 啓動後，用 /workflows 看進度。

這個界面會列出當前會話里正在跑和已經跑完的 workflows。點進去還能看某個 phase、某個 agent 的 prompt、工具調用和結果。

實際用起來，先記住幾個鍵就夠了：p 暫停或恢復，x 停止，r 重啓正在運行的 agent，s 保存 workflow 腳本。

比如一個安全審計 workflow，第一階段可能只是掃描，下面掛幾個子 Agent；第二階段才做驗證，要等掃描結束後再分配。按 p 暫停以後，只要還在同一個 Claude Code 會話裏，就可以繼續跑，已經完成的 Agent 結果會被緩存下來。

不過退出 Claude Code 以後，運行狀態不會原樣保留。想長期複用，就要保存腳本。保存到 .claude/workflows/，它屬於當前項目，可以跟着倉庫走；保存到 ~/.claude/workflows/，它就是你個人的常用命令。保存之後，workflow 會像 slash command 一樣出現。

一次好 prompt 只是這次聊得順。能保存、能復跑、能讓團隊一起用，才算真正沉澱下來。

Prompt 要寫得像任務合同

workflow prompt 不要寫成“幫我全面審計一下”。這種說法太寬，Claude 會自己補很多細節，最後結果也容易發散。

我一般會把目標、範圍、階段和證據要求提前寫清楚，比如：

請為下面的研發任務運行一個 workflow：

目標：審計訂單服務裏的接口鑑權是否完整，輸出可進入修復排期的問題清單。

範圍：
- 只檢查 services/order/src/routes、services/order/src/controllers、services/order/src/middleware。
- 排除 tests、mock、generated 目錄。

階段：
1. 枚舉所有 HTTP endpoint，記錄路由、handler 和調用鏈入口。
2. 按業務模塊分組，檢查是否經過 auth、permission、tenant 校驗。
3. 對可疑發現做二次複核，必須回到代碼證據。
4. 合併重複問題，按影響面和可利用性分級。

輸出：
- 使用 Markdown 表格。
- 字段包含：模塊、endpoint、文件路徑、handler、證據行、風險說明、嚴重級別、建議修復方式。

規則：
- 沒有代碼證據不要報告。
- 不要修改代碼，只做審計報告。
- 不確定的結論放入「需要人工確認」。

這個模板的重點不是格式，而是先把邊界釘住。

目標 決定方向，範圍 限制掃描邊界，階段 固定執行順序，規則 用來擋住沒證據的結論。

我不需要自己寫 JavaScript，只需要把任務講細一點。任務越清楚，Claude 生成 workflow 腳本時自由發揮就越少。

邊界和成本

Dynamic Workflows 不是無限併發機器。

官方限制是：單次 run 最多 16 個併發 Agents，總 Agent 數最多 1000 個。

它可以在一次任務裏調度幾十到上百個 Agent，但不會同一瞬間無限併發。workflow 腳本也不是直接操作層，不讀寫文件，不跑 shell，只負責協調；真正幹活的是被調度出去的 Agent。

還有一個限制容易被忽略：workflow 不適合中途頻繁問你意見。官方文檔說明，run 過程中沒有普通的用戶輸入節點，只有權限提示可能暫停。要是你希望“第一階段結束後我先確認，再進入第二階段”，最好拆成兩個 workflow。

成本也要提前算。一個 workflow 會啓動很多 Agent，每個 Agent 都會消耗當前 session 的模型 token。除非腳本把簡單階段路由到更便宜的模型，否則賬單會很快變厚。

跑大任務前，先看一眼 /model，再確認 shell、WebFetch、MCP 這些工具權限有沒有放開。長任務跑到一半才卡在 allowlist 上，會很影響節奏。

這個功能該怎麼看

Dynamic Workflows 更適合大型任務，尤其是那種一放進主對話就會有上下文壓力的任務。

它看起來像 Skill + subagent 的組合，但本質不一樣。Skill 讓 Claude 按固定規則做事，subagent 負責把局部任務拆出去執行，而 workflow 是把整套執行計劃寫進腳本里：怎麼拆、怎麼並行、怎麼複核、怎麼彙總，都由腳本來控制。

這也是它和普通多 Agent 最大的區別。普通對話裏，Claude 還在主線程裏一邊判斷、一邊調度，中間結果會不斷擠進上下文；workflow 則把中間狀態留在運行時裏，主對話只接最後整理過的結果。

所以 workflow 主要解決的不是多Agent編排，而是讓複雜任務有一套可保存、可檢查、可復跑的執行流程。

我的理解是：小任務用 prompt，穩定規則用 Skill，局部並行用 subagent；當任務大到需要分階段、控上下文、交叉複核，並且下次還可能再跑時，才是 workflow 的主場。

參考資料

1. Anthropic: Introducing Claude Opus 4.8
   https://www.anthropic.com/news/claude-opus-4-8
2. Claude Code Docs: Orchestrate subagents at scale with dynamic workflows
   https://code.claude.com/docs/en/workflows
3. Claude Code Docs: Run agents in parallel
   https://code.claude.com/docs/en/agents
4. Claude Code Docs: Orchestrate teams of Claude Code sessions
   https://code.claude.com/docs/en/agent-teams