為每項任務量身打造的工具：Claude Code 中的動態工作流程

原文作者：@trq212

編譯：Peggy

編者按：Claude Code 正從一個程式碼助手，轉變為一個可編排的 Agent 工作台。

本文介紹的 workflows（工作流），核心價值在於讓 Claude 不再只是在同一個上下文視窗裡「想完再做」，而是可以根據任務動態生成一套執行框架：拆分任務、派發子 Agent、並行處理、交叉驗證、循環迭代，甚至讓不同 Agent 彼此競爭，最後再綜合結果。

這意味著 Claude Code 的使用場景正在明顯外溢。它不僅適用於代碼遷移、重構、測試復現和代碼審查，也可用於深度研究、事實核查、簡歷篩選、事故復盤、規則沉澱、商業計劃評審、命名 brainstorm 等非技術任務。許多複雜工作本質上都與編程相似：需要拆解問題、隔離上下文、驗證假設、處理大量細節，並在多個候選路徑中做選擇。

動態工作流程試圖解決大模型在長任務中常見的幾個問題：中途宣告完成的「智能體惰性」、傾向認可自身結論的「自我偏好偏差」，以及多輪執行後逐漸偏離原始目標的「目標漂移」。透過將任務交給多個擁有獨立上下文的 Claude，它將複雜任務從「單智能體長跑」轉化為「多智能體協同」。

當然，workflows 也不是萬能答案。它通常會消耗更多 token，也未必適合每一個普通編碼任務。但它提供了一個很重要的方向：未來 AI 工具的競爭，可能不只在於單個模型有多聰明，而在於它能否圍繞複雜目標，組織出一套可靠、可複用、可審查的執行流程。

以下為原文：

雖然預設的 Claude Code 執行框架是為編程構建的，但它也適用於許多其他類型的任務。事實證明，很多任務在結構上都很像編程任務。不過，有些特定任務類型要想達到最佳表現，我們仍然需要在 Claude Code 之上構建定制化執行框架，例如研究、安全分析、智能體團隊協作，或代碼審查。

Workflows（工作流）允許你動態建立執行框架，讓 Claude 能更原生地在 Claude Code 內部解決上述問題，以及更多類型的問題。你也可以與他人共享、重用這些工作流。

在本文中，我會分享自己最初使用 workflows 的經驗和心得，幫助你更充分地發揮它的能力。

不過需要說明的是，相關最佳實踐仍在形成中。動態工作流通常會消耗更多 token，因此你需要認真考慮何時使用、如何使用。

註：本文亦發布於 Claude Blog 上。

示例 Prompt

在進入技術細節之前，我想先給出一些示例 prompt，幫助你理解 workflows 的可能性：

This test fails approximately once every 50 runs. Set up a workflow to reproduce it, formulate hypotheses, and conduct adversarial testing across different worktrees. /goal Do not stop until a hypothesis is verified.

使用 workflow，回顧我最近 50 次會話，從中挖掘我反覆做出的糾正，並把這些重複出現的問題轉化為 CLAUDE.md 規則。

使用 workflow，翻查過去六個月 Slack 的 #incidents 頻道，找出那些反覆出現、但沒人提交 ticket 的根本原因。

Run my business plan through a workflow, and have different agents analyze it from the perspectives of investors, customers, and competitors.

有一個包含 80 份履歷的資料夾。請使用 workflow，根據後端職位的要求對它們進行排序，並複核前十名。請透過 AskUserQuestion 工具向我提問，以協助建立評價標準。

我需要為這個 CLI 工具取名。使用 workflow 進行腦力激盪，產生一批選項，再透過錦標賽機制選出前三名。

使用 workflow，把我們的 User 模型在所有地方都重命名為 Account。

閱讀我的部落格草稿，並使用 workflow 對照程式碼庫驗證其中每一個技術判斷。我不想發布任何錯誤內容。

動態工作流如何運作

動態工作流會執行一個 JavaScript 檔案，其中包含若干特殊函數，用來生成和協調子智能體。

動態工作流也包含標準 JavaScript 函數，例如 JSON、Math 和 Array，用於處理數據。

尤其值得注意的是，動態工作流可以決定某個 agent 使用哪一種模型，也可以決定子 agent 是否在自己的 worktree 中運行。這使得 Claude 可以根據任務需要，自主選擇所需的智能水平和隔離程度。

如果一個 workflow 被中斷，例如用戶手動操作，或終端退出，恢復會話後，該 workflow 可以從中斷處繼續執行。

當你讓預設的 Claude Code 執行框架處理一個任務時，它需要在同一個上下文視窗內同時完成規劃和執行。對於許多程式設計任務來說，這種方式非常有效，但在長時間運行、大規模並行或高度結構化的對抗性任務中，它有時會失效。

原因在於，當 Claude 在單一上下文視窗中處理複雜任務的時間越長，它就越容易出現幾類特定的失敗模式：

Agentic laziness（智能體惰性）指的是 Claude 在處理特別複雜、由多個部分組成的任務時，尚未真正完成就提前停止，並在僅取得部分進展後宣稱任務已完成。例如，在安全審查中只處理了 50 個項目中的 20 個，就宣布工作結束。

自我偏好偏差（Self-preferential bias），指的是 Claude 傾向於偏好自己的結果或發現，尤其是在被要求根據某套評價標準驗證或評判自己產出的內容時。

目標漂移（Goal drift）指的是在多輪執行過程中，Claude 對最初目標的忠誠度逐漸下降，尤其是在上下文被壓縮之後。每一次總結都會造成資訊損失，一些細節要求，例如邊緣情況，或「不要做 X」之類的限制條件，都可能被遺失。

建立 workflow 有助於緩解這些問題，因為它可以協調多個獨立的 Claude，讓它們擁有各自的上下文視窗，並專注於相互隔離、目標明確的任務。

你之前可能已經透過 Claude Agent SDK 或 claude -p 建立過靜態工作流程，用來協調多個 Claude Code 實例。

但由於靜態工作流需要覆蓋各種邊緣情況，它們通常更通用。隨著 Claude Opus 4.8 和動態工作流的出現，Claude 現在已經足夠智能，可以為你的具體使用場景編寫一個量身定制的執行框架。

使用動態工作流時的實用模式

你可以直接讓 Claude 建立一個動態工作流，也可以使用觸發詞「ultracode」，確保 Claude Code 建立 workflow。

不過，如果你能建立起關於動態工作流如何運作的心智模型，就更容易判斷什麼時候應該使用它，也更容易通過 prompt 對 Claude 進行引導。

Claude 在建構 workflows 時，常見會使用並組合以下幾種模式：

分類並執行：使用一個分類 agent 判斷任務類型，然後根據任務類型路由到不同的 agent 或行為。也可以在流程末尾使用分類器來判斷輸出結果。

扇出並綜合：將一個任務拆分成多個更小的步驟，讓每一步都由一個 agent 處理，最後再綜合這些結果。這種方式尤其適合任務中包含大量小步驟的情況，或每個步驟都需要一個乾淨的上下文窗口，避免相互干擾或交叉污染的情況。綜合步驟相當於一個「屏障」：它會等待所有扇出的 agent 完成，然後把它們的結構化輸出合併成一個結果。

對抗式驗證：對於每一個生成的 agent，再運行一個獨立的 agent，根據某套評價標準或準則對其輸出進行對抗式驗證。

生成並篩選：圍繞一個主題生成大量想法，然後根據評價標準或驗證流程進行篩選，去除重複項，只返回經過測試、質量最高的想法。

錦標賽：不是將工作拆分，而是讓 agent 彼此競爭。生成 N 個 agent，讓它們分別用不同方法嘗試完成同一個任務。隨後由 prompt 或模型通過評審 agent 對結果進行兩兩比較，直到選出勝者。

循環直到完成：對於工作量未知的任務，不要設定固定輪次，而是循環生成 agent，直到滿足停止條件，例如不再出現新的發現，或日誌中不再出現錯誤。

使用場景

你可以更有創造性地思考何時、如何讓 Claude Code 建立動態工作流。我發現 workflows 在非技術工作中有時甚至更有用。

Bun 曾使用 workflows 從 Zig 重寫為 Rust。你可以閱讀 Jarred 在 X 上的帖子，了解具體過程。

關鍵在於，將任務拆解為一系列需要處理的步驟，例如呼叫點、失敗測試、模組等。為每個修復任務在 worktree 中啟動一個子 agent，讓它完成修復；隨後再讓另一個 agent 進行對抗式審查，最後合併結果。你可以考慮明確告訴 agent，不要使用資源消耗過高的命令，這樣就可以最大化並行程度，而不會耗盡本地機器資源。

我們在 Claude Code 中發布了一項 deep research skill（/deep-research），它採用的就是動態工作流。具體來說，它會並行執行網頁搜索、抓取來源、對相關主張進行對抗式驗證，並綜合生成一份附有引用的報告。

但這類研究並不只適用於網頁搜尋。例如，你也可以讓 Claude 從 Slack 上下文中整理一份狀態報告，或通過深入探索程式碼庫來研究某個功能是如何運作的。

另一方面，如果你有一份報告，並希望核查其中引用的每一個事實性主張和來源，就可以生成一個 workflow：先由一個 agent 識別所有事實性主張，然後為每一個主張啟動一個子 agent 進行細緻核查。你還可以讓一個驗證 agent 檢查負責溯源的子 agent，確保其來源質量足夠高。

你可能有一組項目，希望按照某種定性指標進行排序，而你相信 Claude Code 擅長評估這種指標。例如，按照 bug 嚴重程度給支援工單排序。

但如果你試圖在一個 prompt 中排序 1000 多行內容，品質就會下降，而且上下文視窗也容納不下。更好的做法是運行錦標賽機制，建立一條由兩兩比較 agent 組成的流水線，因為比較式判斷通常比絕對打分更可靠；或者先並行分桶排序，再合併結果。每一次比較都是由一個獨立 agent 完成的，因此確定性迴圈可以維持整個賽程結構，只有當前運行順序需要保留在上下文中。

如果你有一組特定規則，而 Claude 即使在 CLAUDE.md 中看到這些規則，仍然經常遺漏或執行不好，那麼可以建立一個 workflow，把這些規則列出來，並讓驗證 agent 逐條檢查——每條規則對應一個驗證 agent。建立一個「懷疑者」人格的子 agent 來審查這些規則是否合理，也有助於避免過多誤報。

反之亦然：挖掘你最近的會話和程式碼審查評論，找出你反覆做出的修正；讓平行 agent 對這些問題進行聚類；再對每個候選規則進行對抗式驗證，判斷它是否真的能防止某個真實錯誤；最後把通過篩選的規則提煉回 CLAUDE.md 中。

最有效的調試方式，是提出幾個相互獨立的假設，並逐一測試。但如果你只使用一個上下文視窗，Claude 可能會陷入自我偏好偏差。

workflow 可以從結構上防止這種情況：它可以啟動多個 agent，讓它們基於互不重疊的證據分別生成假設。例如，讓不同 agent 分別查看日誌、文件和數據。隨後，每個假設都可以接受一組驗證者和反駁者的審查。

這並不只適用於代碼。workflows 也可以用於銷售分析，例如「為什麼三月銷售額下降了？」；用於數據工程，例如「為什麼這條 pipeline 失敗了？」；或用於任何事後復盤。

每個團隊都有支援隊列、錯誤報告，或其他無法完全由人類處理的積壓事項。一個分診 workflow 可以對每個項目進行分類，與已被追蹤的問題去重，並採取行動。這可能意味著嘗試修復，也可能意味著升級給人類用戶處理。

對於分診工作流，一個有用的模式是 quarantine（隔離）。也就是說，禁止那些讀取不可信公開內容的 agent 執行高權限操作；高權限操作應由專門負責行動的 agent 來完成。

你可以將分診 workflows 與 /loop 搭配使用，讓 Claude 持續執行這類任務。

當你需要探索解決方案的不同路徑，尤其是設計、命名這類帶有審美判斷的任務，並且可以受益於一套評價標準時，workflows 很有用。

你可以讓 Claude 探索大量方案，並給審查 agent 一套關於「好方案是什麼樣」的評價標準。當審查 agent 認為結果已經滿足標準時，任務就完成了。不同方案也可以根據這套評價標準，通過錦標賽機制進行排序或篩選。

你可以透過在 worktree 中啟動獨立 agent，再啟動比較 agent，根據評價標準比較和打分具體輸出，從而為特定任務運行輕量級 evals。例如，你可以評估並改進自己創建的某個 skill，看它是否滿足某些特定標準。

模型與智能水平路由：你可以建立一個針對自身任務進行優化的分類 agent，讓它決定使用哪一種模型。當任務涉及大量工具調用，且在執行前進行研究有助於識別最合適的模型時，這種方式會非常有用。

例如，對於「解釋 auth 模塊如何工作」這個任務來說，最合適的模型取決於 auth 模塊中有多少文件，以及程式碼庫結構是什麼樣。分類 agent 可以先完成這項研究，再根據預期複雜度，把任務路由給 Sonnet 或 Opus。

workflows 仍然是新東西。雖然在許多使用場景中，它可以帶來遠超常規方式的效果，但並不是每個任務都需要它，而且它可能顯著增加 token 消耗。

最好將 workflows 用在那些能以新方式拓展 Claude Code 能力邊界的任務上。對於常規編程任務，你可以先問自己：這個任務真的需要更多計算資源嗎？例如，大多數傳統編程任務並不需一個由 5 名審查者組成的小組。

構建動態工作流的技巧

撰寫動態工作流的 prompt 時，細節越充分，效果通常越好，尤其是使用上文提到的具體技巧。

workflows 並不只適用於大型任務。你也可以提示模型使用一個「quick workflow」。例如，你可以創建一個快速的對抗式審查流程，用來檢查某個假設。

當你使用可重複執行的 workflows，例如分診、研究或驗證工作流時，可以將它們與 /loop 搭配，讓它們按固定間隔運行；同時用 /goal 設置硬性的完成要求。

你可以為動態工作流設定明確的 token 使用預算，以限制任務消耗的 token 數量。你可以在 prompt 中寫入類似「use 10k tokens」的預算要求，它會把上限設定為 10k token。

你可以在 workflow 菜單中按下「s」來保存 workflows。你可以把它們提交到 ~/.claude/workflows，也可以通過 skill 分發。

如果想透過 skill 共享它們，可以把 JavaScript workflow 檔案放進 skill 資料夾，並在 SKILL.md 中引用。為了獲得更大的靈活性，你也可以提示 Claude：把 skill 中的 workflows 視為模板，而不是必須逐字運行的腳本。

一個全新的世界

Workflows 是擴展 Claude Code 的一種有用新方式。我鼓勵你將其視為一個起點。關於如何最佳地使用它，我們仍有許多需要探索的地方。歡迎告訴我們你的發現。

Thariq Shihipar 和 Sid Bidasaria（@sidbid）是 Anthropic 技術團隊成員，負責 Claude Code 相關工作。

[原文連結]

點擊了解律動 BlockBeats 在招崗位

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia