Claude Code 的 Dynamic Workflows，到底新在哪？
整理版優先睇
Claude Code Dynamic Workflows：將多 Agent 調度變成可執行腳本，唔係單純疊加運算力
呢篇文章係解析 Anthropic 嘅 Claude Code 新功能「Dynamic Workflows」，作者本身有豐富 AI 工具實戰經驗，想幫讀者釐清呢項功能嘅本質，而唔係被「並行幾百個 Agent」呢類數字帶偏。作者指出，Dynamic Workflows 唔係預先畫好嘅固定流程，亦唔係多個 Agent 隨機傾偈，而係 Claude 根據任務描述動態生成一段 JavaScript 編排腳本，由後台運行時執行，中間結果放喺腳本變數，唔塞返入對話。呢個設計令到循環、分支、併發、驗證同彙總都變成可觀察、可保存、可複用嘅工程化對象。
為咗突出差異，作者用一個簡單問題劃分 Subagent、Skill 同 Workflow：計劃放喺邊？Subagent 嘅計劃由 Claude 每一輪判斷，結果放返入對話，適合少量探索；Skill 係可複用嘅說明書，由 Claude 按說明執行，適合固定流程；Workflow 嘅計劃係動態生成嘅腳本，由腳本驅動執行，結果放喺變數，適合大規模審計、遷移同交叉驗證。呢個能力之所以重要，係因為單一 Agent 喺複雜代碼庫嘅瓶頸越來越明顯：上下文塞唔落、執行時間長、中間結果多、驗證鏈條長。
Anthropic 嘅官方案例（Jarred Sumner 將 Bun 從 Zig 移植到 Rust）好吸睛，但作者特別提醒呢項工作未入生產環境，只能當能力展示。Dynamic Workflows 值得關…
- Dynamic Workflows 係 Claude 根據任務動態生成嘅 JS 編排腳本，唔係固定 DAG 亦唔係多 Agent 隨機對話，本質係將調度邏輯從對話搬到可執行腳本。
- Subagent 適合少量探索，Skill 適合固定流程，Workflow 適合大規模可並行可驗證任務，三者關鍵分別係「計劃放喺邊」同「結果放喺邊」。
- 多 Agent 對抗性驗證（例如 deep-research）提升結果可信度，但唔係絕對正確，如果所有 Agent 依賴同一份錯誤資料仍然會一齊錯。
- 使用前一定要先做只讀任務、睇清楚生成嘅 workflow 腳本、放獨立分支跑，唔好一嚟就喺核心倉庫做生產級變更。
- 呢項能力提醒我哋 AI 編程工具正從一次對話走向可觀察可複用嘅任務編排，但人的責任冇得消失，最終合併仍然要團隊把關。
佢到底係咩嘢？
Dynamic Workflows 呢個名有啲繞口，好多人第一眼就盯住「幾十到幾百個並行 Agent」呢個數字，但好易睇錯重點。更準確嘅理解係：Claude Code 唔係淨係多派幾個 Subagent，而係將「邊個做先、邊個做後、點樣檢查、點樣收科」呢套編排邏輯，從對話上下文搬到一段可執行腳本入面。
跟 Claude Code 文檔嘅講法，Dynamic Workflow 係 Claude 根據你嘅任務描述動態寫出嚟嘅一段 JavaScript 編排腳本，由後台運行時執行，用嚟調度大量 Subagent。中間結果保存喺腳本變數，唔會塞返入 Claude 當前對話窗口。
Workflow 唔係你預先畫好嘅固定 DAG
腳本生成之後，執行路徑、循環、分支同結果彙總都有咗相對明確嘅結構
編排嘅產生方式似 Agent，編排嘅執行方式似 Workflow
Subagent、Skill、Workflow 有咩分別？
可以用一個好簡單嘅問題區分：計劃放喺邊？
- Subagent：臨時派出去嘅工作者，Claude 每一輪判斷下一步，結果放返入 Claude 上下文，適合少量探索、代碼搜索、輔助分析。
- Skill：可複用嘅說明書，Claude 按說明執行，結果放返入上下文，適合固定流程、檢查清單、團隊規範。
- Dynamic Workflow：動態生成嘅編排腳本，腳本驅動執行，結果放喺腳本變數同運行時狀態，適合大規模審計、遷移、交叉驗證。
Subagent 嘅價值係「將一部分髒活累活掉出去做」，但規模大咗之後，Claude 仍然要喺對話接收、理解、繼續調度。Skill 嘅價值係「將重複提示詞產品化」，但執行主體仍然係 Claude。
呢個亦係佢同普通 Agent、Subagent、Skill 最關鍵嘅區別
點解 Anthropic 要推呢個能力？
原因唔難理解：單個 Agent 嘅瓶頸越來越明顯。複雜代碼庫入面嘅問題，成日唔係「寫一段函數」就搞得掂。好似全倉庫鑑權漏洞檢查、幾百個文件嘅 API 遷移、一次語言級別嘅移植，都會遇到現實約束：上下文塞唔落、執行時間好長、中間結果好多、驗證鏈條亦好長。
Anthropic 官方案例提到 Jarred Sumner 用 Dynamic Workflows 將 Bun 從 Zig 移植到 Rust，約 75 萬行 Rust，現有測試套件 99.8% 通過，由首次提交到合併約 11 日。但正文必須加一個限定：官方博客同時說明呢項工作當時未入生產環境。
大型遷移真正難嘅地方唔止生成代碼，仲包括後續維護、性能回歸、邊界行為、生態兼容
Dynamic Workflows 值得關注嘅係佢將以前好難組織嘅多 Agent 協作，變成一個可以觀察、暫停、恢復、保存嘅工程化對象
官方文檔亦強調 Workflow 可以讓多個 Agent 從不同角度獨立完成任務，再讓其他 Agent 質疑、反駁同驗證結果。內置嘅 /deep-research 就屬於呢種思路：多角度檢索信息，交叉核對來源，過濾冇通過驗證嘅結論。
點樣用先唔會用偏？
目前官方文檔畀咗幾種入口：你可以喺 Claude Code 直接要求「創建一個 workflow」，或者喺 prompt 包含 workflow 呢個詞觸發。亦可以用 /effort ultracode 等 Claude 對實質性任務自動判斷是否需要 workflow。Claude Code 仲內置咗 /deep-research 用於多來源交叉驗證式研究。
唔建議一嚟就將佢用喺核心倉庫大改。更穩妥嘅起步方式係：
- 1 先做只讀任務，例如全倉庫死代碼掃描、鑑權檢查、依賴升級影響面分析。
- 2 明確驗收標準，例如「必須列出文件路徑、證據、置信度、誤報風險」。
- 3 先睇生成嘅 workflow 腳本同階段計劃，先至允許執行。
- 4 對會改文件嘅任務，放喺獨立分支或隔離工作區入面跑。
- 5 只將跑通兼且可以解釋嘅 workflow 保存為項目命令。
對普通開發者嚟講，最值得嘗試嘅唔係「等佢重寫整個項目」，而係當佢係一個高成本嘅工程審計工具，用喺人肉做太慢、但又必須可複核嘅任務上。
先做只讀任務，明確驗收標準，先睇腳本再執行，放獨立分支跑
只將跑通兼且可以解釋嘅 workflow 保存為項目命令
佢嘅邊界同我哋應該點做？
Dynamic Workflows 有幾個明顯邊界。首先，佢仲喺 research preview 階段，功能、入口、限制同可用計劃都可能調整。第二，成本會明顯上升，一次運行消耗嘅 token 同速率額度遠高於普通 Claude Code 會話，ultracode 更唔適合長期掛住做日常小改動。
第三，權限要格外小心。官方文檔提到 Workflow 入面嘅 Subagent 會繼承 tool allowlist，文件編輯可能自動批准；shell、Web fetch 同 MCP 工具則可能喺運行中繼續觸發權限確認。對企業代碼庫嚟講，呢個係審計邊界。第四，佢唔適合所有任務，單文件修改、簡單問答、線性排查用普通對話、Subagent 或 Skill 就夠。
- 1 重新劃分任務類型，唔係所有任務都值得 Agent 化。
- 2 將驗收條件寫清楚，提示詞越似任務單，結果越易複核。
- 3 先放喺審計同遷移嘅外圍，等佢揾問題、列清單、寫候選 PR、做交叉驗證，而唔係一開始就將生產級變成交畀佢合併。
Workflow 可以擴大執行半徑，但唔可以代替工程判斷
最終合併咩，仍然要由團隊嘅測試、審查同責任鏈話事
Dynamic Workflows 呢個名有啲繞口。好多討論會先盯住「幾十到幾百個並行 Agent」呢個數字，但咁樣好容易帶錯方向。
更準確嘅理解係：Claude Code 唔單止係派多幾個 Subagent，而係將「邊個做先、邊個做後、點樣檢查、點樣收斂」呢套編排邏輯，由對話上下文搬咗去一段可以執行嘅腳本入面。
呢個亦都係佢同普通 Agent、Subagent、Skill 最關鍵嘅分別。
先講清楚：佢究竟係乜
根據 Claude Code 文檔嘅講法，Dynamic Workflow 係 Claude 根據你嘅任務描述動態寫出嚟嘅一段 JavaScript 編排腳本。呢個腳本由後台運行時執行，用嚟調度大量 Subagent；中間結果保存喺腳本變量入面，而唔係全部塞返入 Claude 當前對話窗口。
呢句話裏面有三個重點。
第一，Workflow 唔係你預先畫好嘅固定 DAG。佢唔係 Airflow、Temporal 嗰類「先定義流程，再反覆執行」嘅傳統工作流引擎。
第二，佢亦都唔係多個 Agent 隨機傾偈。腳本生成之後，執行路徑、循環、分支同結果彙總都有咗相對明確嘅結構。
第三，佢仍然依賴 Claude 嘅判斷。Workflow 腳本可以讀、可以保存、可以複用，但腳本點樣生成、各個 Agent 點樣完成任務，仍然係模型能力嘅一部分。
所以我更加願意將佢睇成一個中間形態：編排嘅產生方式似 Agent，編排嘅執行方式更似 Workflow。
Subagent、Skill、Workflow 到底爭啲乜
可以用一個好簡單嘅問題嚟區分：計劃放喺邊度？
Subagent 嘅價值係「將一部分污糟嘢丟出去做」。例如俾一個唯讀 Agent 去搜代碼，俾另一個 Agent 睇日誌。佢可以減輕主對話嘅負擔，但規模大咗之後，Claude 仍然要喺對話裏面接收、理解、繼續調度。
Skill 嘅價值係「將重複提示詞產品化」。例如代碼審查規範、發佈檢查流程、某個項目嘅構建步驟。佢令 Claude 唔使每次由頭理解你嘅要求，但執行主體仍然係 Claude。
Dynamic Workflow 則更加激進：佢將調度本身寫成代碼。循環、分支、並發、驗證、彙總，都可以入腳本。呢個亦都係佢點解更加適合長任務同大任務。
Anthropic 點解要推呢個能力
原因唔難理解：單一個 Agent 嘅瓶頸越來越明顯。
複雜代碼庫裏面嘅問題，好多時唔係「寫一段函數」就可以解決。例如全倉庫鑑權漏洞檢查、幾百個檔案嘅 API 遷移、一次語言級別嘅移植，都會遇到幾個現實限制：上下文塞唔落，執行時間好長，中間結果好多，驗證鏈條亦都好長。
Anthropic 喺官方案例入面提到，Jarred Sumner 用 Dynamic Workflows 將 Bun 由 Zig 移植到 Rust，大約 75 萬行 Rust，現有測試套件 99.8% 通過，由首次提交到合併大約 11 日。呢個案例好吸引眼球，但正文入面一定要加一個限制：官方博客同時話，當時呢項工作仲未進入生產環境。
即係話佢可以作為「能力展示」，但唔可以直接寫成「AI 已經穩定接管大型工程遷移」。大型遷移真正難嘅地方，唔淨止係生成代碼，仲包括後續維護、性能回歸、邊界行為、生態兼容同長期缺陷暴露。
Dynamic Workflows 值得留意嘅地方，唔係佢將人完全取代咗，而係佢將以前好難組織嘅多 Agent 協作，變成一個可以觀察、暫停、恢復、保存嘅工程化對象。
對抗性驗證，可能比並發數量更加重要
如果淨係睇「並行幾百個 Agent」，好容易得出一個粗糙結論：呢個就係暴力堆 token。
但官方文檔強調嘅另一點更加值得留意：Workflow 可以俾多個 Agent 由唔同角度獨立完成任務，再俾其他 Agent 質疑、反駁同驗證呢啲結果。內置嘅 /deep-research 就屬於呢種思路：多角度檢索資訊，交叉核對來源，過濾冇通過驗證嘅結論。
呢樣嘢對研究同審計類任務尤其重要。因為呢類任務真正怕嘅唔係「慢」，而係「錯得好自信」。
當然，對抗性驗證唔係魔法。多個 Agent 如果依賴同一組錯誤資料、同一個測試盲區，仍然有可能一齊錯。佢提升嘅係發現問題嘅概率同結果嘅可解釋性，唔係俾結果蓋一個絕對正確嘅印。
點樣用，先唔會用錯
目前官方文檔俾咗幾種入口。
你可以喺 Claude Code 裏面直接要求「創建一個 workflow」，或者喺 prompt 入麪包含 workflow 呢個詞嚟觸發。亦可以用 /effort ultracode，等 Claude 對實質性任務自動判斷係咪需要 workflow。Claude Code 仲內置咗 /deep-research，用嚟做多來源交叉驗證式研究。
但唔建議一開波就用喺核心倉庫大改。更加穩妥嘅起步方式係：
1. 先做唯讀任務，例如全倉庫死代碼掃描、鑑權檢查、依賴升級影響面分析； 2. 明確驗收標準，例如「必須列出檔案路徑、證據、置信度、誤報風險」； 3. 先睇生成嘅 workflow 腳本同階段計劃，先至準許執行； 4. 對會改檔案嘅任務，放喺獨立分支或者隔離工作區度行； 5. 淨係將行得通而且可以解釋嘅 workflow 保存為項目指令。
對普通開發者嚟講，最值得試嘅唔係「叫佢重寫成個項目」，而係當佢係一個高成本嘅工程審計工具。用喺嗰啲人肉做太慢、但係又要可以重複核實嘅任務上面。
佢都有幾個明顯嘅限制
第一，佢仲處於 research preview 階段。呢個狀態本身就意味着功能、入口、限制同可用計劃都可能調整。
第二，成本會明顯上升。Workflow 會拉起好多 Agent，一次運行消耗嘅 token 同速率額度可能遠高於普通 Claude Code 會話。ultracode 更加唔適合長期掛住做日常小改動。
第三，權限要格外小心。官方文檔提到，Workflow 裏面嘅 Subagent 會繼承工具 allowlist，檔案編輯可能會自動批准；shell、Web fetch 同 MCP 工具就可能喺運行中繼續觸發權限確認。對企業代碼庫嚟講，呢個唔係一個小細節，而係審計邊界。
第四，佢唔適合所有任務。單檔案修改、簡單問答、線性排查，用普通對話、Subagent 或 Skill 就夠。將所有任務都塞入 Workflow，只會將簡單問題變成昂貴流程。
我哋應該做啲乜
如果你負責團隊工程效率，建議先由三個方向建立自己嘅判斷。
第一，重新劃分任務類型。唔係所有任務都值得 Agent 化，只有「可以拆分、可以並行、可以驗證、結果可以彙總」嘅任務，先適合 Dynamic Workflows。
第二，將驗收條件寫清楚。Workflow 真正需要嘅係結構化目標：掃描範圍係乜、誤報點樣處理、證據點樣呈現、測試點樣行、邊啲檔案唔可以掂。提示詞越似任務單，結果越容易複核。
第三，先將佢放喺審計同遷移嘅外圍。叫佢揾問題、列清單、寫候選 PR、做交叉驗證，而唔係一開始就將生產級變更交俾佢合併。
呢項能力真正提醒我哋嘅，可能唔係「Agent 變強咗」咁簡單。更加現實嘅變化係：AI 編程工具正由一次對話、一次補全，走向可觀察、可保存、可複用嘅任務編排。
但越係咁，人嘅責任越唔可以消失。Workflow 可以擴大執行半徑，但唔可以替代工程判斷。至少喺而家，比較穩陣嘅姿勢仍然係：等佢並行探索，等佢俾證據，等佢先喺邊界內行；最終合併啲乜，仍然要由團隊嘅測試、審查同責任鏈話事。
參考來源
• Anthropic：Introducing dynamic workflows in Claude Code，2026-05-28，https://claude.com/blog/introducing-dynamic-workflows-in-claude-code • Claude Code Docs：Orchestrate subagents at scale with dynamic workflows，https://code.claude.com/docs/en/workflows • Claude Code Docs：Model configuration / effort / ultracode，https://code.claude.com/docs/en/model-config • Claude Code Docs：Extend Claude with skills，https://code.claude.com/docs/en/skills • Claude Code Docs：Create custom subagents，https://code.claude.com/docs/en/sub-agents • Claude Code Docs：Run agents in parallel，https://code.claude.com/docs/en/agents
——完——
按個關注，一齊學下嘢~
Dynamic Workflows 這個名字有點繞。很多討論會先盯着“幾十到幾百個並行 Agent”這個數字看，但這容易把問題帶偏。
更準確的理解是：Claude Code 不只是多派幾個 Subagent，而是把“誰先做、誰後做、怎麼檢查、怎麼收斂”這套編排邏輯，從對話上下文裏搬到一段可執行腳本里。
這也是它和普通 Agent、Subagent、Skill 最關鍵的區別。
先講清楚：它到底是什麼
按照 Claude Code 文檔的說法，Dynamic Workflow 是 Claude 根據你的任務描述動態寫出的一段 JavaScript 編排腳本。這個腳本由後台運行時執行，用來調度大量 Subagent；中間結果保存在腳本變量裏，而不是一股腦塞回 Claude 當前對話窗口。
這句話裏有三個重點。
第一，Workflow 不是你預先畫好的固定 DAG。它不是 Airflow、Temporal 那類“先定義流程，再反覆執行”的傳統工作流引擎。
第二，它也不是多個 Agent 隨機聊天。腳本生成之後，執行路徑、循環、分支和結果彙總都有了相對明確的結構。
第三，它仍然依賴 Claude 的判斷。Workflow 腳本可以讀、可以保存、可以複用，但腳本如何生成、各個 Agent 如何完成任務，仍然是模型能力的一部分。
所以我更願意把它看成一箇中間形態：編排的產生方式像 Agent，編排的執行方式更像 Workflow。
Subagent、Skill、Workflow 到底差在哪
可以用一個很樸素的問題來區分：計劃放在哪裏？
Subagent 的價值是“把一部分髒活累活丟出去做”。比如讓一個只讀 Agent 去搜代碼，讓另一個 Agent 看日誌。它能減輕主對話的負擔，但規模大了以後，Claude 仍然要在對話裏接收、理解、繼續調度。
Skill 的價值是“把重複提示詞產品化”。例如代碼審查規範、發佈檢查流程、某個項目的構建步驟。它讓 Claude 不必每次從零理解你的要求，但執行主體仍然是 Claude。
Dynamic Workflow 則更激進一點：它把調度本身寫成代碼。循環、分支、併發、驗證、彙總，都可以進入腳本。這也是它為什麼更適合長任務和大任務。
Anthropic 為什麼要推這個能力
原因不難理解：單個 Agent 的瓶頸越來越明顯。
複雜代碼庫裏的問題，經常不是“寫一段函數”就能解決。比如全倉庫鑑權漏洞檢查、幾百個文件的 API 遷移、一次語言級別的移植，都會遇到幾個現實約束：上下文塞不下，執行時間很長，中間結果很多，驗證鏈條也很長。
Anthropic 在官方案例裏提到，Jarred Sumner 使用 Dynamic Workflows 將 Bun 從 Zig 移植到 Rust，約 75 萬行 Rust，現有測試套件 99.8% 通過，從首次提交到合併約 11 天。這個案例很吸引眼球，但正文裏必須加一個限定：官方博客同時說明，當時這項工作還沒有進入生產環境。
這意味着它可以作為“能力展示”，但不能直接寫成“AI 已經穩定接管大型工程遷移”。大型遷移真正難的地方，不只是生成代碼，還包括後續維護、性能迴歸、邊界行為、生態兼容和長期缺陷暴露。
Dynamic Workflows 值得關注的地方，不是它把人完全替代了，而是它把以前很難組織的多 Agent 協作，變成了一個可以觀察、暫停、恢復、保存的工程化對象。
對抗性驗證，可能比並發數量更重要
如果只看“並行幾百個 Agent”，很容易得出一個粗糙結論：這就是暴力堆 token。
但官方文檔強調的另一點更值得注意：Workflow 可以讓多個 Agent 從不同角度獨立完成任務，再讓其他 Agent 質疑、反駁和驗證這些結果。內置的 /deep-research 就屬於這種思路：多角度檢索信息，交叉核對來源，過濾沒有通過驗證的結論。
這對研究和審計類任務尤其重要。因為這類任務真正怕的不是“慢”，而是“錯得很自信”。
當然，對抗性驗證不是魔法。多個 Agent 如果依賴同一組錯誤資料、同一個測試盲區，仍然可能一起錯。它提升的是發現問題的概率和結果的可解釋性，不是給結果蓋一個絕對正確的章。
怎麼用，才不容易用偏
目前官方文檔給了幾種入口。
你可以在 Claude Code 裏直接要求“創建一個 workflow”，或者在 prompt 裏包含 workflow 這個詞來觸發。也可以使用 /effort ultracode，讓 Claude 對實質性任務自動判斷是否需要 workflow。Claude Code 還內置了 /deep-research，用於多來源交叉驗證式研究。
但不建議一上來就把它用於核心倉庫大改。更穩妥的起步方式是：
1. 先做只讀任務，例如全倉庫死代碼掃描、鑑權檢查、依賴升級影響面分析； 2. 明確驗收標準，例如“必須列出文件路徑、證據、置信度、誤報風險”； 3. 先看生成的 workflow 腳本和階段計劃，再允許執行； 4. 對會改文件的任務，放在獨立分支或隔離工作區裏跑； 5. 只把跑通且能解釋的 workflow 保存為項目命令。
對普通開發者來說，最值得嘗試的不是“讓它重寫整個項目”，而是把它當成高成本的工程審計工具。用在那些人肉做太慢、但又必須可複核的任務上。
它也有幾個明顯邊界
第一，它仍處在 research preview 階段。這個狀態本身就意味着功能、入口、限制和可用計劃都可能調整。
第二，成本會明顯上升。Workflow 會拉起很多 Agent，一次運行消耗的 token 和速率額度可能遠高於普通 Claude Code 會話。ultracode 更不適合長期掛着做日常小改動。
第三，權限要格外小心。官方文檔提到，Workflow 裏的 Subagent 會繼承工具 allowlist，文件編輯可能自動批准；shell、Web fetch 和 MCP 工具則可能在運行中繼續觸發權限確認。對企業代碼庫來說，這不是一個小細節，而是審計邊界。
第四，它不適合所有任務。單文件修改、簡單問答、線性排查，用普通對話、Subagent 或 Skill 就夠了。把所有任務都塞進 Workflow，只會把簡單問題變成昂貴流程。
我們應該做什麼
如果你負責團隊工程效率，建議先從三個方向建立自己的判斷。
第一，重新劃分任務類型。不是所有任務都值得 Agent 化，只有“可拆分、可並行、可驗證、結果可彙總”的任務，才適合 Dynamic Workflows。
第二，把驗收條件寫清楚。Workflow 真正吃的是結構化目標：掃描範圍是什麼、誤報怎麼處理、證據怎麼呈現、測試怎麼跑、哪些文件不能碰。提示詞越像任務單，結果越容易複核。
第三，先把它放在審計和遷移的外圍。讓它找問題、列清單、寫候選 PR、做交叉驗證，而不是一開始就把生產級變更交給它合併。
這項能力真正提醒我們的，可能不是“Agent 變強了”這麼簡單。更現實的變化是：AI 編程工具正在從一次對話、一次補全，走向可觀察、可保存、可複用的任務編排。
但越是這樣，人的責任越不能消失。Workflow 可以擴大執行半徑，不能替代工程判斷。至少在現在，比較穩的姿勢仍然是：讓它並行探索，讓它給證據，讓它先在邊界內跑；最終合併什麼，仍然要由團隊的測試、審查和責任鏈說了算。
參考來源
• Anthropic：Introducing dynamic workflows in Claude Code，2026-05-28，https://claude.com/blog/introducing-dynamic-workflows-in-claude-code • Claude Code Docs：Orchestrate subagents at scale with dynamic workflows，https://code.claude.com/docs/en/workflows • Claude Code Docs：Model configuration / effort / ultracode，https://code.claude.com/docs/en/model-config • Claude Code Docs：Extend Claude with skills，https://code.claude.com/docs/en/skills • Claude Code Docs：Create custom subagents，https://code.claude.com/docs/en/sub-agents • Claude Code Docs：Run agents in parallel，https://code.claude.com/docs/en/agents
——END——
點點關注，一起學習~