原文標題：A harness for every task: dynamic workflows in Claude Code

原文作者：@trq212

編譯：Peggy

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

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

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

動態 workflows 試圖解決的，正是大模型在長任務中常見的幾個問題：做到一半就宣布完成的「智能體惰性」、傾向認可自己結論的「自我偏好偏差」，以及多輪執行後逐漸偏離原始目標的「目標漂移」。通過把任務交給多個擁有獨立上下文的 Claude，它將複雜任務從「單 Agent 長跑」改造成「多 Agent 協同」。

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

以下為原文：

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

Workflows（工作流程）允许您动态创建执行框架，使 Claude 能够更原生地在 Claude Code 内部解决上述问题，以及更多类型的问题。您还可以与他人共享、重复使用这些工作流程。

在本文中，我将分享我最初使用 workflows 的经验和见解，帮助您更充分地发挥其能力。

但需要说明的是，相关最佳实践仍在形成中。动态工作流程通常会消耗更多令牌，因此您需要认真考虑何时以及如何使用。

注：本文也发布在 Claude Blog 上。

示例提示

在深入技术细节之前，我想先给出一些示例提示，帮助您理解工作流程的潜力：

「这个测试大概每 50 次运行会失败 1 次。搭建一个工作流程来复现它，提出假设，并在不同的工作树中进行对抗式测试。/goal 不要停止，直到有一个假设被验证成立。」

「使用工作流程，回顾我最近的 50 次会话，从中挖掘我反复做出的更正，并将这些反复出现的问题转化为 CLAUDE.md 规则。」

「使用工作流程，查阅过去六个月 Slack 的 #incidents 频道，找出那些反复出现但没有人提交工单的根本原因。」

「拿我的商业计划书跑一个工作流程，让不同的代理人分别从投资人、客户和竞争对手的角度来拆解它。」

「这里有一个包含 80 份简历的文件夹。使用工作流程，根据后端职位要求对它们进行排序，并审核前十名。通过 AskUserQuestion 工具向我提问，帮助您建立评价标准。」

「我需要给这个 CLI 工具取一个名字。使用工作流程头脑风暴一批选项，然后通过锦标赛机制选出前三名。」

「使用工作流程，将我们的用户模型在所有地方重命名为账户。」

「閱讀我的部落格草稿，並使用 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 失敗了？」；或用於任何事後複盤。

大規模分診

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

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

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

探索與品味判斷

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

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

Evals（評測）

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

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

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

什麼時候不該使用動態工作流

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

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

構建動態工作流的技巧

Prompt 設計

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

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

與 /goal 和 /loop 結合使用

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

Token 使用預算

你可以為動態工作流設定明確的 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 官方社群：

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

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

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