大部分 Claude Code 使用者仍然手動編寫他們的工作流程。他們串聯提示詞、複製輸出、貼到下一個提示詞、修正錯誤、然後重複。
十個開發者中有九個從未嘗試過動態工作流程，即使它們已經在兩週前推出。
他們寫了 50 個提示詞，而一個工作流程就能搞定。以下是 14 步驟的路線圖，以及 Anthropic 自家工程師實際使用的 6 種模式——適用於遷移、研究、分類、根本原因分析、分類處理和評估。
追蹤我的 Substack 以獲取最新的 AI 資訊：
動態工作流程已於 2026 年 5 月 28 日在 Claude Code 中推出。預設的 Claude Code 框架是為編碼而設計的——這對大多數編碼任務來說效果很好。但有些類型的工作，單一上下文視窗會開始失效：長時間運行、大規模並行、高度結構化或對抗性的任務。
對於這些情況，Anthropic 過去會自行建構自訂框架（研究、程式碼審查、Agent 團隊）。有了動態工作流程，Claude 會即時為你撰寫那個框架，根據你的任務量身打造，使用 JavaScript。
14 個步驟。6 種模式。一個工作流程勝過五十個提示詞。
第一部分 · 心智模型
01. 工作流程是 Claude 撰寫的框架。
預設的 Claude Code 框架讓 Claude 在同一個上下文視窗中規劃和執行。對大多數編碼工作來說，這很棒。但對於長時間運行、並行或對抗性的工作，它就會失效。
動態工作流程是 Claude 為任務撰寫自己的自訂框架——一個包含幾個特殊函數的 JavaScript 檔案，用於產生和協調子 Agent，以及標準的 JavaScript（Math、JSON、Array）來處理它們之間流動的資料。
這為你提供了預設框架無法提供的三項能力：
- 每個 Agent 的隔離性。 每個子 Agent 都有自己的上下文視窗和一個專注的目標。沒有交叉污染。
- 每個 Agent 的模型選擇。 工作流程為每個子 Agent 選擇要使用的模型——Opus 處理困難推理、Haiku 進行低成本探索、Sonnet 處理中間任務。
- 每個 Agent 的隔離層級。 Worktree（隔離的 git 檢出）或 remote（無檢出）。工作流程決定每個 Agent 需要什麼。
你可以直接要求 Claude（「製作一個工作流程來…」）或使用觸發詞 ultracode 來啟動一個。如果工作流程被中斷——使用者操作、終端機退出——恢復工作階段會從中斷處繼續。
02. 工作流程解決的 3 種失敗模式。
要知道何時該使用工作流程，你必須了解它能解決什麼問題。Claude 在單一上下文視窗中處理複雜任務的時間越長，就越容易出現三種特定的失敗模式——這些在 Anthropic 的發布文章中直接提及：
- Agent 的懶惰 - Claude 在完成複雜的多部分任務之前就停止，並在取得部分進展後就宣稱完成。例如，在安全審查中處理了 50 個項目中的 20 個，就稱其餘的「已處理」。
- 自我偏好偏誤 - 當被要求根據評分標準驗證或評判自己的結果時，Claude 會偏好自己的結果。一個有利害關係的驗證者無法成為公正的驗證者。
- 目標漂移 - 在多次互動後，特別是在壓縮後，逐漸偏離原始目標。每次摘要步驟都會造成資訊損失。「不要做 X」的限制在互動到第 47 次時會悄悄消失。
一個工作流程能從結構上解決這三個問題：使用各自擁有獨立上下文、專注目標和隔離狀態的多個 Claude 實例。如果你的任務出現任何這些模式——那就是該使用工作流程的信號。
03. 靜態 vs 動態工作流程。
你可能已經使用 Claude Agent SDK 或 claude -p 建立過靜態工作流程——協調多個 Claude Code 實例。
- 靜態工作流程是通用的：一次寫好以處理所有邊緣情況。它們有效，但必須保守。
- 動態工作流程則不同：Claude 為這個任務撰寫這個工作流程。框架是量身打造的。以下是同一個問題以兩種方式處理的比較：
動態版本勝出的原因不在於搜尋步驟——兩者都能搜尋。
在於工作流程能夠根據你的上下文來塑造自己：讀取你的計費程式碼、根據實際的新供應商文件檢查每個功能、根據你的交易量定價，並針對自己正在形成的答案進行一次「為何不遷移」的對抗性檢查。
靜態框架無法做到這點，因為它不知道你的程式碼存在。
04. 核心 API。agent()、parallel()、pipeline()。
三個函數完成了工作流程中的大部分工作。了解它們就足以讀懂 Claude 為你撰寫的任何工作流程，並在你想要特定形狀時引導 Claude。
parallel() 是一個屏障：它分散出去，然後等待所有任務完成才返回。pipeline() 是串流式的：每個項目獨立地流經每個階段。
根據問題來選擇：我需要所有結果才能進行下一步嗎？ 是 → 使用 parallel。否 → 使用 pipeline（更便宜，整體更快）。
05. 分類並執行。在執行工作前先進行路由。
一個分類 Agent 決定任務的類型，然後工作流程根據答案將任務路由到不同的 Agent 或行為。或者，一個分類器在最後運行，將原始輸出分類到不同的桶中，供後續步驟使用。
這個模式在以下情況最能發揮作用：
- 任務是異質的——不同的子類型需要不同的處理方式。
- 你只想在複雜度需要時才使用昂貴的模型（使用便宜的模型進行分類，然後只在需要時才路由到 Opus）。
- 工作的分解本身並非微不足道，且受益於由模型來決定其形狀。
範例：「解釋 auth 模組如何運作。」一個分類子 Agent 首先讀取程式碼庫，評估複雜度，然後將實際的解釋任務路由到 Sonnet（用於 10 個檔案的模組）或 Opus（用於 100 個檔案的模組）。在理解工作內容後，為任務選擇正確的模型。
06. 分散並綜合。許多小步驟，一個合併結果。
將一個任務拆分成許多小步驟。對每個步驟並行運行一個 Agent。將結果綜合成一個答案。
綜合步驟是一個屏障——它等待所有分散出去的 Agent，然後合併它們的結構化輸出。
為什麼這個模式在實踐中占主導地位：它解決了單一上下文工作中「一次處理太多事情」的失敗。每個子 Agent 只看到它自己的部分。協調者永遠不會被 50 個不相關的細節分心。
每個步驟都受益於自己乾淨的視窗，這樣它們就不會互相污染。
在以下情況使用此模式：
- 你有一個可以清楚列舉的工作項目清單（50 個檔案、200 個端點、100 個審查）。
- 每個項目都是獨立的——沒有項目需要另一個項目的輸出才能開始。
- 你最終想要一個統一的綜合答案，而不是一堆部分報告。
1// 分散：每個檔案一個 Agent。屏障：等待所有完成。2const reviews = await parallel(3 files.map(file => () => agent(4 `審查 ${file} 的安全性問題`,5 { model: "haiku", schema: IssueList }6 ))7)89// 綜合：一個 Opus Agent 合併所有內容。10const report = await agent(11 `將這些審查合併成一份優先級報告：\n${JSON.stringify(reviews)}`,12 { model: "opus" }13)
07. 對抗性驗證
這是對自我偏好偏誤的結構性修正。對於每個產生的 Agent，運行一個單獨產生的 Agent，根據評分標準對其輸出進行對抗性驗證。驗證者從未見過原始工作；它無法偏袒它。
這個模式在以下情況最為重要：
- 聲明檢查 - 報告中的每個事實陳述都有自己專屬的驗證子 Agent，對照原始來源進行檢查。
- 程式碼審查 - 作者 Agent 撰寫修正，審查者 Agent（獨立上下文）審查它。絕不讓同一個 Claude 評判自己。
- 品質關卡 - 在任何產出物發布前，一個對手試圖找出對其最不利的案例。如果對手找不到，你就發布。
配對規則： 驗證者應該只知道評分標準和產出物，而不是誰產生了它。否則，自我偏好會透過提示詞中的線索悄悄回來。
08. 產生並過濾。
針對一個主題產生一些想法，然後根據評分標準或驗證來過濾它們。去除重複項。只回傳最高品質、經過測試的想法。
這個模式在以下情況表現出色：
- 腦力激盪 - 30 個產品名稱，然後一個驗證者剔除陳腔濫調、商標衝突和發音不佳的選項。你只看到 3 個。
- 假設生成 - 針對一個問題的 5 種不同方法，然後每種方法根據你的限制條件進行評分。勝出者是實至名歸的。
- 解決方案設計 - 針對一個問題的 5 種不同方法，然後每種方法根據你的限制條件進行評分。勝出者是實至名歸的。
與其要求 Claude 給出「最佳答案」相反。要求最佳答案會讓 Claude 過早做出承諾。產生並過濾讓 Claude 延遲承諾，直到每個選項都經過挑戰。
09. 錦標賽。兩兩比較勝過絕對評分。
與其分配工作，不如讓 Agent 在任務上競爭。產生 N 個 Agent，每個 Agent 使用不同的方法嘗試相同的任務，然後以兩兩比較的方式評判結果，直到產生一個贏家。
比較性判斷比絕對評分更可靠——特別是對於基於品味的任務。
為什麼這比按分數排序更好： 嘗試在一個提示詞中對 1,000 個項目進行排序會在兩個方面失敗——品質下降，而且無法容納在上下文中。錦標賽將對戰組合分散到全新的 Agent 中，每個 Agent 只比較兩個項目。
對戰組合本身存在於確定性的迴圈程式碼中，而不是在上下文中。每次比較都是快速、公平且隔離的。同樣的想法也適用於基於品味的排名：設計選擇、候選人篩選、內容優先級排序。
10. 循環直到完成。
對於工作量未知的任務，循環產生 Agent，直到滿足停止條件——沒有新發現、日誌中沒有更多錯誤、理論得到驗證——而不是運行固定次數。
這個模式是「持續進行直到真正完成」的答案：
- 不穩定測試除錯 - 重現、形成理論、測試它們，直到一個理論成立。
- 錯誤獵殺 - 持續尋找錯誤，直到完整運行一輪後回傳零錯誤。
- 模式挖掘 - 分群、識別規則，直到沒有新的群集出現。
將此模式與 /goal 配對以設定硬性完成要求（「在一個理論成立之前不要停止」），並與 /loop 配對，如果你希望整個工作流程本身按定期排程運行。
對戰組合和停止條件存在於程式碼中；只有活躍的迭代保留在上下文中。
11. 為實際用例組合模式。一個工作流程，多種模式。
這 6 種模式很少單獨出現。一個真實的工作流程會組合 2 到 4 種模式。下表將 Anthropic 發布文章中的每個用例與其傾向使用的模式配對：
- 遷移和重構。 分散（在 worktree 中，每個呼叫點/失敗測試一個 Agent）→ 對抗性驗證（一個獨立的 Agent 審查每個修正）→ 循環直到完成。這是 Anthropic 用來將 Bun 從 Zig 重寫為 Rust 的模式。
- 深度研究（/deep-research 技能）。分散（並行網路搜尋）→ 對抗性驗證（每個聲明獨立驗證）→ 綜合（一份有引用的報告）。
- 草稿的深度驗證。 識別所有事實陳述（一個 Agent）→ 分散（每個聲明一個驗證者，每個 Agent 對照來源檢查）→ 元驗證者（檢查驗證者的來源是否高品質）。
- 對 1,000+ 個項目進行排序。 錦標賽（步驟 5-9）——兩兩比較、分桶排名或對戰組合。使用比較性判斷，絕不使用絕對評分。
- 記憶和規則遵守。 每個規則一個驗證者（分散）→ 懷疑論者角色審查規則本身以避免誤報。
- 根本原因調查。 從不相關的證據中產生理論（不同的 Agent 讀取日誌、檔案、資料）→ 為每個理論設立驗證者和反駁者小組 → 循環直到一個理論存活下來。
- 大規模分類處理。 分類並執行 → 與現有工單去重 → 嘗試修正或升級處理。與 /loop 配對以進行持續分類處理。
- 探索和品味（設計、命名、UI 選擇）。產生並過濾（5-20 個選項）→ 使用評分標準進行錦標賽 → 排名或選擇。
- 輕量級評估。 在 worktree 中運行候選方案 → 比較 Agent 根據評分標準評分 → 優化並重新評分。形狀與錦標賽相同，但用於評分而非排名。
內化這些模式的正確方法：識別你當前任務在哪種失敗模式下失敗，然後選擇能從結構上防止該失敗的模式。
目標漂移 → 分散。自我偏好 → 對抗性驗證。開放式結尾 → 循環直到完成。難以評分 → 錦標賽。
12. 與 /goal、/loop 和 Token 預算搭配使用。
工作流程可能很昂貴。三個控制項將它們從「很酷但成本高」轉變為「我可以無人值守運行的工具」。
- /goal 設定一個硬性完成要求。將其與循環模式配對：「在一個理論成立之前不要停止。」 沒有 /goal，工作流程會在一個軟性完成點停止。有了 /goal，它會迭代直到滿足實際的結束條件。
- /loop 按定期排程運行整個工作流程。用於你想要持續運行的工作流程——分類處理、每週研究更新、定期驗證。
- 明確的 Token 預算。 在提示詞中告訴 Claude：「使用 10k tokens。」 這為工作流程運行設定了一個上限。沒有限制，一個雄心勃勃的工作流程可能會膨脹到你預期的 5–10 倍 Token 用量。
1> ultracode 快速對抗性審查這個假設：2 "遷移到 Postgres 消除了我們的資料分片重新平衡。"3 使用 5k tokens。/goal 在你找到一個反例或4 三個獨立確認之前不要停止。
直接引用 Claude Code 團隊的話：「最佳實踐仍在發展中。動態工作流程通常會使用更多 Token，因此請仔細考慮何時以及如何使用它們。」 大多數傳統的編碼任務不需要一個由 5 位審查者組成的小組。
問問自己：這個任務真的需要更多運算資源嗎？如果一個普通的 Claude Code 工作階段能在五分鐘內完成它，你就不需要一個工作流程。
13. 對不受信任的輸入使用隔離模式。
任何讀取不受信任的公開內容的工作流程——支援工單、錯誤報告、使用者回饋、抓取的資料——都需要假設該內容可能包含提示注入。
解決方案：隔離。禁止讀取不受信任內容的 Agent 執行任何高權限操作。由沒有接觸過原始內容的獨立 Agent 來執行操作。
任何處理使用者提交內容（支援工單、錯誤報告、客戶回饋、社交媒體）、抓取公開網頁或針對第三方 API 輸出運行的工作流程。
如果輸入不是你或你信任的團隊成員撰寫的，請將其隔離。 一個 30 行的唯讀讀取 Agent 幾乎不花費任何成本，並消除了整個類別的提示注入風險。
14. 儲存工作流程。將它們作為技能發布。
一旦工作流程運作正常，將其儲存：在工作流程選單中按 s。儲存的工作流程會放到 ~/.claude/workflows。從那裡你有兩個選擇：
- 保留在本地 - 在你自己的專案中重複使用它。
- 作為技能發布 - 將 JavaScript 檔案打包到一個技能資料夾中，在 SKILL.md 中引用它，任何安裝該技能的人都可以運行相同的工作流程。
一個值得了解的實用細節：當你將工作流程打包成技能時，提示 Claude 將工作流程視為模板，而不是要逐字運行的腳本。
這為 Claude 保留了根據當前特定任務調整工作流程形狀的空間，同時保持整體結構完整。對於像「深度驗證」或「分類處理」這樣需要根據用例靈活調整的工作流程尤其有用。
在工作流程上浪費 Token 的常見錯誤
- 在普通的 Claude Code 工作階段就能完成時，卻使用工作流程。 大多數傳統編碼任務不需要一個由 5 位審查者組成的小組。
- 沒有 Token 預算。 沒有明確的上限，雄心勃勃的工作流程會膨脹到你預期的 5–10 倍。
- 同一個 Agent 同時執行工作和驗證。 自我偏好偏誤會使驗證者偏袒工作者。它們必須分開。
- 將 parallel() 和 pipeline() 視為可互換。 屏障很重要——parallel 等待所有任務，pipeline 是串流的。
- 在循環模式中跳過 /goal。 工作流程會在第一個軟性完成點過早停止。/goal 強制硬性完成。
- 讓不受信任的內容到達執行者。 一旦你處理任何使用者提交的內容，隔離就不是可選項。
- 使用絕對分數進行排序。 比較性判斷更可靠。使用錦標賽。
- 從不儲存有效的工作流程。 每週重新提示相同的形狀。用 s 儲存，作為技能發布。
