# 策展 · X (Twitter) 🔥 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 作者：Codez (@0xCodez) · 平台：X (Twitter) · 日期：2026-06-04 > 原始來源：https://x.com/0xCodez/status/2062127385923776831 ## 中文摘要 # 如何精通 Claude Code 中的 Dynamic Workflows：Anthropic 工程師實際使用的 6 種模式與 14 個步驟 大多數 Claude Code 的使用者仍然習慣手動編寫工作流程。他們串接 Prompt、複製輸出、貼上到下一個 Prompt、修正錯誤，然後重複這些步驟。 儘管 Dynamic Workflows（動態工作流程）早在兩週前就已推出，但 10 位開發者中仍有 9 位從未嘗試過。 他們為了本該一次完成的工作流程，寫了 50 個 Prompt。以下是 Anthropic 工程師在進行遷移、研究、分類、根因分析、分流（triage）及評估（evals）時，實際使用的 14 個步驟指南與 6 種模式。 > 追蹤我的 Substack 以獲取最新的 AI 資訊：movez.substack.com Dynamic Workflows 於 2026 年 5 月 28 日在 Claude Code 中推出。預設的 Claude Code harness 是為程式撰寫而設計的，對於大多數程式開發任務來說效果很好。但有些類型的任務在單一 context window 中會開始崩潰：例如長期執行、大規模平行處理、高度結構化或對抗性的任務。 對於這些情況，Anthropic 過去會自行建置自訂的 harness（如研究、程式碼審查、Agent 團隊）。現在有了 Dynamic Workflows，Claude 可以即時為你編寫該 harness，並以 JavaScript 語言為你的任務量身打造。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780560079957-iaHJ4diCcXIAAJ71vpng.png) 14 個步驟。6 種模式。用一個工作流程取代五十個 Prompt。 --- Part 1 · 心智模型 ## 01. 工作流程就是 Claude 編寫的 harness。 預設的 Claude Code harness 讓 Claude 在同一個 context window 中進行規劃與執行。對於大多數程式開發工作，這很棒。但對於長期執行、平行處理或對抗性工作，它就會失效。 Dynamic Workflow 是 Claude 為該任務編寫的自訂 harness——這是一個包含幾個特殊函式的 JavaScript 檔案，用來生成並協調子 Agent，並使用標準 JavaScript（Math、JSON、Array）來處理它們之間流動的資料。 它提供了預設 harness 無法做到的三件事： - **Agent 隔離**：每個子 Agent 都有自己的 context window，目標明確，不會發生交叉污染。 - **模型選擇**：工作流程會為每個子 Agent 選擇適合的模型——用 Opus 處理困難的推理，用 Haiku 進行低成本的探索，用 Sonnet 處理中間任務。 - **隔離層級**：Worktree（隔離的 git checkout）或遠端（無 checkout）。工作流程會決定每個 Agent 需要什麼。 你可以直接要求 Claude（「建立一個能……的工作流程」）或使用觸發詞 `ultracode` 來啟動它。如果工作流程被中斷（使用者操作、終端機關閉），恢復工作階段時會從中斷處繼續。 --- ## 02. 工作流程解決的 3 種失敗模式。 要判斷何時該使用工作流程，你必須知道它解決了什麼問題。當 Claude 在單一 context window 中處理複雜任務的時間越長，就越容易出現以下三種特定的失敗模式（Anthropic 發布文章中直接指出的）： - **Agent 懶惰**：Claude 在完成複雜、多部分的任務前就停止，並在取得部分進度後宣稱完成。例如在安全性審查中只處理了 50 個項目中的 20 個，就說剩下的「已處理」。 - **自我偏好偏差**：當要求 Claude 根據準則驗證或評判自己的結果時，它會偏好自己的產出。身為利益相關者的驗證者，無法做到公平。 - **目標漂移**：在多次對話後，對原始目標的忠實度逐漸喪失，特別是在壓縮（compaction）之後。每次摘要步驟都會造成資訊流失。第 47 次對話時，「不要做 X」的限制條件可能已悄悄消失。 工作流程從結構上解決了這三點：透過各自擁有 context、目標明確且狀態隔離的獨立 Claude 來執行。如果你的任務出現這些模式，那就是該使用工作流程的訊號。 --- ## 03. 靜態與動態工作流程。 你可能已經使用 Claude Agent SDK 或 `claude -p` 建置過靜態工作流程，將多個 Claude Code 執行個體串接在一起。 - **靜態工作流程**是通用的：編寫一次以處理所有邊緣情況。它們有效，但必須採取保守策略。 - **Dynamic Workflows** 則不同：Claude 是針對當前任務編寫工作流程。harness 是量身打造的。以下是同一問題以兩種方式處理的對比： ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780560080142-iaHJ4esVVXwAEc9i9png.png) 動態版本勝出的原因不在於搜尋步驟——兩者都能搜尋。 而在於工作流程能根據你的 context 進行調整：讀取你的帳單程式碼、根據實際的新供應商文件檢查每個功能、根據你的交易量定價，並針對其產出的答案進行對抗性的「為什麼不該遷移」檢查。 靜態 harness 做不到這一點，因為它不知道你的程式碼存在。 --- ## 04. 核心 API：agent()、parallel()、pipeline()。 這三個函式在工作流程中承擔了大部分工作。了解它們足以讓你讀懂 Claude 為你編寫的任何工作流程，並在你需要特定結構時引導 Claude。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780560080731-diaHJ4ernW0AASiu6png.png) `parallel()` 是一個屏障：它會展開任務，並在返回前等待所有任務完成。`pipeline()` 則是串流：每個項目獨立流經每個階段。 選擇標準：我是否需要所有結果才能進行下一步？是 → `parallel`。否 → `pipeline`（更便宜、整體速度更快）。 --- ## 05. 分類與執行（Classify-and-act）。在執行前進行路由。 分類器 Agent 先決定任務類型，然後工作流程根據答案將任務路由到不同的 Agent 或行為。或者在最後執行分類器，將原始輸出分類到後續處理所需的儲存桶中。 此模式的價值在於： - 任務是異質的——不同子類型需要不同處理方式。 - 你只想在複雜度要求高的地方使用昂貴的模型（分類器使用便宜模型，僅在必要時路由給 Opus）。 - 工作分解本身並不簡單，透過模型來決定結構會更有幫助。 範例：「解釋驗證模組如何運作。」分類子 Agent 先讀取程式庫，評估複雜度，然後將實際解釋任務路由給 Sonnet（針對 10 個檔案的模組）或 Opus（針對 100 個檔案的模組）。在理解任務後，決定最適合的模型。 --- ## 06. 展開與合成（Fan-out-and-synthesize）。多個小步驟，一個合併結果。 將任務拆分為許多小步驟。平行執行每個步驟的 Agent。將結果合成一個答案。 合成步驟是一個屏障——它會等待所有展開的 Agent 完成，然後合併它們的結構化輸出。 為什麼此模式在實務中佔主導地位：它解決了單一 context 工作中「同時處理太多事情」的失敗模式。每個子 Agent 只看到自己的部分。協調者不會被 50 個不相關的細節分散注意力。 每個步驟都受益於乾淨的 context window，因此不會交叉污染。 適用於： - 你有明確可列舉的工作項目清單（50 個檔案、200 個端點、100 份審查）。 - 每個項目都是獨立的——不需要其他項目的輸出即可開始。 - 你最後需要一個合併後的答案，而不是一堆零散的報告。 ```python // 展開：每個檔案一個 Agent。屏障：等待全部完成。 const reviews = await parallel( files.map(file => () => agent( `Review ${file} for security issues`, { model: "haiku", schema: IssueList } )) ) // 合成：一個 Opus Agent 合併所有內容。 const report = await agent( `Merge these reviews into one prioritized report:\n${JSON.stringify(reviews)}`, { model: "opus" } ) ``` --- ## 07. 對抗性驗證（Adversarial verification）。 這是解決自我偏好偏差的結構性修正。對於每個生成的 Agent，執行一個獨立的 Agent，根據準則對其輸出進行對抗性驗證。驗證者從未見過原始工作，因此不會偏袒它。 此模式對以下情況最重要： - **聲明檢查**：報告中的每個事實陳述都有自己的驗證子 Agent，根據原始來源進行檢查。 - **程式碼審查**：作者 Agent 編寫修正，審查者 Agent（獨立 context）進行審查。絕不讓同一個 Claude 評判自己。 - **品質閘門**：在任何產出發布前，對抗者會嘗試找出最弱的案例。如果對抗者找不到，你就可以發布。 配對規則：驗證者應該只知道準則和產出，而不知道是誰產出的。否則，自我偏好會透過 Prompt 中的暗示悄悄溜回來。 --- ## 08. 生成與過濾（Generate-and-filter）。 針對某個主題生成多個想法，然後根據準則或驗證進行過濾。刪除重複項目。只返回最高品質、經過測試的想法。 此模式的亮點： - **腦力激盪**：30 個產品名稱，然後驗證者剔除陳腔濫調、商標衝突和發音較弱的名稱。你最後只看到 3 個。 - **假設生成**：針對問題提出 5 種不同方法，然後根據你的限制條件對每種方法進行評分。勝出者實至名歸。 - **解決方案設計**：針對問題提出 5 種不同方法，然後根據你的限制條件對每種方法進行評分。勝出者實至名歸。 這與要求 Claude 給出「最佳答案」相反。要求最佳答案會讓 Claude 過早做出承諾。生成與過濾讓 Claude 在所有選項都受到挑戰後，才做出最終決定。 --- ## 09. 錦標賽（Tournament）。成對比較勝過絕對評分。 與其劃分工作，不如讓 Agent 進行競爭。生成 N 個 Agent，每個 Agent 使用不同方法嘗試同一任務，然後以成對方式判斷結果，直到選出贏家。 比較判斷比絕對評分更可靠——特別是對於基於品味的任務。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780560081110-iaHJ4gDbnW4AAP3eBpng.png) 為什麼這比按分數排序更好：試圖在一個 Prompt 中對 1,000 個項目進行排序會失敗——品質會下降，且無法放入 context。錦標賽將括號賽程分散到新的 Agent 中，每個 Agent 只比較兩個項目。 賽程本身存在於確定性的迴圈程式碼中，而不是 context 裡。每次比較都快速、公平且隔離。同樣的想法也適用於基於品味的排名：設計選擇、候選人篩選、內容優先順序。 --- ## 10. 迴圈直到完成（Loop until done）。 對於工作量未知的任務，循環生成 Agent 直到滿足停止條件——例如沒有新發現、日誌中沒有更多錯誤、理論已驗證——而不是執行固定次數。 此模式是「持續進行直到真正完成」問題的答案： - **不穩定測試除錯**：重現、形成理論、測試，直到其中一個理論成立。 - **漏洞搜尋**：持續尋找漏洞，直到完整掃描返回零錯誤。 - **模式挖掘**：分群、識別規則，直到不再出現新群集。 將此模式與 `/goal` 搭配使用以設定嚴格的完成要求（「直到一個理論有效前不要停止」），並與 `/loop` 搭配使用（如果你希望整個工作流程按排程重複執行）。 賽程和停止條件存在於程式碼中；只有當前的迭代會留在 context 裡。 --- ## 11. 組合模式以應對實際案例。一個工作流程，多種模式。 這 6 種模式很少單獨出現。一個實際的工作流程會組合 2-4 種模式。下表將 Anthropic 發布文章中的每個案例與其傾向使用的模式進行配對： - **遷移與重構**：展開（每個呼叫點/失敗測試一個 Agent）→ 對抗性驗證（獨立 Agent 審查每個修正）→ 迴圈直到完成。這是 Anthropic 用來將 Bun 從 Zig 重寫為 Rust 的模式。 - **深度研究（`/deep-research` skill）**：展開（平行網頁搜尋）→ 對抗性驗證（每個聲明獨立驗證）→ 合成（一份引用報告）。 - **草稿的深度驗證**：識別所有事實聲明（一個 Agent）→ 展開（每個聲明一個驗證者，每個 Agent 對照來源檢查）→ 元驗證者（檢查驗證者的來源是否高品質）。 - **排序 1,000+ 個項目**：錦標賽（步驟 5-9）——成對比較、儲存桶排名或括號賽程。比較判斷，絕不使用絕對評分。 - **記憶與規則遵循**：每個規則一個驗證者（展開）→ 懷疑論者角色審查規則本身，以避免誤報。 - **根因調查**：從不相連的證據生成理論（不同 Agent 讀取日誌、檔案、資料）→ 每個理論都有驗證者與反駁者小組 → 迴圈直到一個理論存活。 - **大規模分流**：分類與執行 → 對照現有工單進行去重 → 嘗試修正或升級。搭配 `/loop` 進行持續分流。 - **探索與品味（設計、命名、UI 選擇）**：生成與過濾（5-20 個選項）→ 帶準則的錦標賽 → 排名或挑選。 - **輕量級評估**：在 worktree 中執行候選方案 → 比較 Agent 根據準則評分 → 修正並重新評分。形狀與錦標賽相同，但用於評分而非排名。 內化這些模式的正確方法：識別你當前任務失敗的模式，然後選擇能從結構上防止該失敗的模式。 漂移 → 展開。自我偏好 → 對抗性驗證。開放式 → 迴圈直到完成。難以評分 → 錦標賽。 --- ## 12. 搭配 `/goal`、`/loop` 與 token 預算。 工作流程可能很昂貴。這三個控制項能將它們從「很酷但昂貴」轉變為「我可以無人值守執行的工具」。 - `/goal` 設定嚴格的完成要求。將它與迴圈模式搭配使用：「直到一個理論有效前不要停止」。沒有 `/goal`，工作流程會在軟性完成點停止。有了 `/goal`，它會持續迭代直到達到實際結束條件。 - `/loop` 按排程重複執行整個工作流程。將其用於你希望持續執行的工作流程——分流、每週研究更新、定期驗證。 - **明確的 token 預算**。在 Prompt 中告訴 Claude：「使用 10k token」。這會為工作流程執行設定上限。沒有上限，一個雄心勃勃的工作流程可能會膨脹到你預期 token 量的 5-10 倍。 ```python > ultracode quick adversarial review of this assumption: "moving to Postgres eliminates our shard rebalancing." Use 5k tokens. /goal don’t stop until you have either a counterexample or three independent confirmations. ``` 直接引用 Claude Code 團隊的話：「最佳實踐仍在發展中。Dynamic Workflows 通常會使用更多 token，因此請仔細考慮何時以及如何使用它們。」大多數傳統程式開發任務不需要 5 位審查者的小組。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780560080773-diaHJ4hGnuW8AAuDUjpg.jpg) 問問自己：這個任務真的需要更多運算嗎？如果一般的 Claude Code 工作階段能在五分鐘內完成，你就不需要工作流程。 --- ## 13. 對未經信任的輸入使用隔離（Quarantine）模式。 任何讀取未經信任的公開內容（支援工單、錯誤報告、使用者回饋、爬取資料）的工作流程，都需要假設該內容可能包含 Prompt 注入。 解決方案：隔離。禁止讀取未經信任內容的 Agent 採取任何高權限操作。由不接觸原始內容的獨立 Agent 執行操作。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780560080155-iaHJ4hVdjWMAAlmaTpng.png) 任何處理使用者提交內容（支援工單、錯誤報告、客戶回饋、社群媒體）、爬取公開網頁或針對第三方 API 輸出執行的工作流程皆適用。 如果輸入不是由你或信任的隊友編寫的，請隔離它。一個 30 行的唯讀 Agent 幾乎不花費什麼，卻能消除一整類 Prompt 注入風險。 --- ## 14. 儲存工作流程。將其發布為 Skill。 一旦工作流程運作正常，請儲存它：在工作流程選單中按 `s`。儲存的工作流程會進入 `~/.claude/workflows`。從那裡你有兩條路： - **保持本地**：在你的專案中重複使用。 - **發布為 Skill**：將 JavaScript 檔案打包在 Skill 資料夾中，在 `SKILL.md` 中引用它，任何安裝該 Skill 的人都能執行相同的工作流程。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780560081147-iaHJ4hmqnXwAAxuX6png.png) 一個值得知道的實務細節：當你將工作流程打包成 Skill 時，請提示 Claude 將工作流程視為模板，而不是逐字執行的腳本。 這留給了 Claude 根據手頭特定任務調整工作流程形狀的空間，同時保持整體結構完整。這對於「深度驗證」或「分流」等需要根據使用案例靈活調整的工作流程特別有用。 --- ## 在工作流程中浪費 token 的錯誤 - 當一般的 Claude Code 工作階段就能完成時，卻硬要使用工作流程。大多數傳統程式開發任務不需要 5 位審查者的小組。 - 沒有 token 預算。沒有明確上限，雄心勃勃的工作流程會膨脹到你預期的 5-10 倍。 - 同一個 Agent 同時負責工作與驗證。自我偏好偏差會讓驗證者偏袒執行者。它們必須分開。 - 將 `parallel()` 和 `pipeline()` 視為可互換的。屏障很重要——`parallel` 等待全部完成，`pipeline` 則是串流。 - 在迴圈模式中忽略 `/goal`。工作流程會在第一個軟性完成點過早停止。`/goal` 強制要求硬性完成。 - 讓未經信任的內容接觸執行者。一旦處理任何使用者提交的內容，隔離就不是選項，而是必須。 - 使用絕對分數進行排序。比較判斷更可靠。請使用錦標賽。 - 從不儲存運作良好的工作流程。每週重複提示相同的形狀。請用 `s` 儲存，並發布為 Skill。 --- ## 結論： ## 標籤 Claude Code, CLI, 教學資源, 功能更新, Anthropic, Claude