Claude Code
會自己搭工作台

Dynamic workflows 讓 Claude 不只執行任務，也能為任務臨時寫出一個 JavaScript harness，把工作拆給多個 subagents、隔離 context、驗證再彙整。

SCROLL
PART 1 ｜ 預設工作台不夠時

一般任務用一個 Claude 就夠，
複雜任務需要一套臨時組織

Claude Code 原本的預設 harness 是為寫程式設計的。很多任務其實也很像寫程式：有目標、有檔案、有工具、有驗證。但有些任務會長到超過一個 context 能穩定處理的範圍。

例如安全審查、深度研究、多 agent 團隊、code review、大規模 refactor。這些任務不只是「想好再做」。它們需要分工、隔離、重複驗證、合併結果，還要防止同一個模型一路做到後面開始偷懶或偏離目標。

Dynamic workflows 的核心變化是：Claude 可以為眼前任務即時寫一個專用工作台，而不是把所有事情塞進同一個對話裡硬撐。

這個工作台是一個 JavaScript 檔，裡面可以呼叫特殊函式來產生和協調 subagents。它也可以使用 JSON、Math、Array 這些標準 JavaScript 能力來處理資料。

PART 2 ｜ 它真的在做什麼

不是多叫幾個 agent 而已，
而是把任務拆成可控流程

Dynamic workflows 可以決定每個 agent 用哪個模型，也能決定 subagent 是否在自己的 worktree 裡執行。這讓 Claude 可以把高智慧模型留給困難步驟，把低風險或大量工具呼叫交給比較便宜的配置。

如果 workflow 中途被打斷，使用者關掉 terminal 或手動中止，之後 resume session 時，workflow 可以接著原本進度往下走。這對長任務很重要，因為工作不再只是聊天記錄，而是一個有狀態的執行流程。

Dynamic workflow 的基本形狀
01
寫 harness
Claude 依照任務，產生一個專用 JavaScript 工作流。
02
分派 subagents
每個 agent 有自己的 context、目標和工具邊界。
03
驗證與合併
用 verifier、judge 或 synthesizer 把結果收斂。
04
可中斷續跑
長任務被打斷後，可以回到原本 workflow 狀態。

這讓 Claude Code 從一個「會寫程式的 agent」，往「能臨時搭建 agentic 系統的 agent」再走一步。

PART 3 ｜ 為什麼需要它

長任務最怕三件事：
偷懶、偏心、忘記原始目標

預設 harness 很適合一般 coding task，因為 planning 和 execution 放在同一個 context 裡通常夠用。但任務越長、越平行、越需要對抗式驗證，單一 context 的缺點就越明顯。

文章列了三個常見 failure modes。第一是 agentic laziness，Claude 做完一部分就宣布完成。第二是 self-preferential bias，Claude 在驗證自己成果時容易偏愛自己的答案。第三是 goal drift，任務經過多輪與壓縮後，原始限制開始失真。

偷懶
Partial progress
安全審查有 50 項，做了 20 項就說完成。
偏心
Self-preference
自己產出的結果，自己驗證時比較容易放過。
漂移
Goal drift
context 壓縮後，細節要求和禁止事項被慢慢磨掉。

Workflow 的解法不是叫 Claude 更用力，而是把結構搭好。每個 subagent 有清楚目標，驗證者和執行者分開，最後由 harness 收斂。

PART 4 ｜ 幾種常見模式

Claude 不是只會分工，
它會依任務挑組織型態

Dynamic workflows 可以把幾個常見模式組合起來。不同任務需要的不是同一種 agent swarm，而是不同的分工方式。

🧭
Classify-and-act
先用 classifier 判斷任務類型，再導向不同 agent 或流程。
🪭
Fan-out-and-synthesize
把任務拆成許多小步驟平行處理，再等全部完成後合併。
🧪
Adversarial verification
每個產出都交給另一個 agent 按 rubric 對抗式檢查。
🧹
Generate-and-filter
先大量生成想法，再去重、過濾、保留最高品質結果。
🏆
Tournament
讓多個 agent 用不同方式做同一題，再由 judge 兩兩比較選出贏家。
🔁
Loop until done
工作量未知時，不預設輪數，而是一直跑到沒有新錯誤或新發現。

這些模式的共同點，是把「一個聰明模型的連續思考」改成「多個乾淨 context 的可控協作」。這一點很微妙，但威力很大。

PART 5 ｜ 用在哪些地方

它不只適合寫程式，
反而很適合那些像工程的非工程任務

文章提到的用例很多。大型 migration 和 refactor 可以把 callsites、failing tests、modules 拆出去，各自在 worktree 修，再由另一組 agent review 和 merge。Deep research 可以 fan-out 搜尋、抓來源、驗證主張，再合成帶引用的報告。

Deep verification 則反過來：先找出報告裡每個 factual claim，再派 subagent 逐一查證。Sorting 可以用 tournament 或 pairwise comparison 排序上千筆 ticket、履歷或候選項目。Root-cause investigation 可以讓不同 agent 從 logs、files、data 產生獨立假說，再由 verifier 和 refuter 交叉檢查。

場景
單一 context 的問題
Workflow 的做法
Deep research
資料量太大，來源容易混在一起。
平行搜尋、來源驗證、最後再合成報告。
Root cause
模型容易愛上第一個假說。
分開產生假說，再讓 verifier 和 refuter 互相挑戰。
Rule mining
靠記憶很難看出反覆犯的錯。
掃過去 session 和 review comment，找出能寫回規則的模式。

特別有意思的是 memory and rule adherence。你可以讓 workflow 掃最近 session 和 code review comments，找出你一直在糾正 Claude 的地方，再把有用的規則蒸餾回 CLAUDE.md。

PART 6 ｜ 不要每件事都開工作流

Workflow 是放大器，
不是每個小任務都需要五個評審

文章也提醒，dynamic workflows 不是每個任務都該用。它們通常會用更多 tokens，也會讓任務啟動成本變高。一般 coding task 不一定需要更多 compute，更不需要五個 reviewer 圍觀一個簡單 bug。

比較適合 workflow 的，是長、平行、需要對抗式驗證、需要大量分類或排序、或需要 loop 到完成條件才停的任務。你也可以提示 Claude 用 quick workflow，只做一次小型對抗式 review。

好用的判斷法是：如果任務失敗的主因是資訊太多、步驟太散、需要互相驗證，workflow 很可能值得；如果只是改三行 code，它可能只是把小事辦成部門會議。

它還能搭配 /goal 和 /loop。前者設定硬完成條件，後者讓 triage、research、verification 這類流程定期重跑。也可以設定 token budget，像「use 10k tokens」，限制這次 workflow 最多花多少。

Dynamic workflows 不是讓一個 Claude 更用力，而是讓一群小 Claude 各守一個任務，最後由 harness 收斂。

它把 agent 的能力，從單次回答推向臨時組織。

如果你要用 dynamic workflow，
第一個想拿來做什麼？

選完之後，分享你的觀點

你的觀點

想看更深入的分析？

Claude Blog 原文完整說明 dynamic workflows 的工作原理、常見模式、適用場景與 token 使用提醒。

閱讀完整文章 →