Claude Code Dynamic Workflows:讓 Claude 為每個任務自造 Harness

Thariq 這篇文章的重點,不是「多開幾個 agents」,而是把複雜任務從單一對話,升級成可分工、可驗證、可恢復、可分享的任務執行系統。

核心判斷:dynamic workflows 是 Claude Code 從 coding assistant 走向 general-purpose agent runtime 的重要一步;但它會吃更多 token,所以應該用在長任務、平行任務、驗證任務與高結構任務,而不是每個日常修改都套用。

Dynamic workflows in Claude Code article cover
來源:Thariq〈A harness for every task: dynamic workflows in Claude Code〉,X Article / 2026-06-02

一句話:Claude 不只執行任務,還能先寫一個適合任務的執行器

過去 Claude Code 的預設 harness 很適合 coding,但 research、security review、agent teams、code review、sorting、triage 等任務,常需要更明確的分工與驗證。Dynamic workflows 讓 Claude 依任務即時生成 JavaScript workflow,並用特殊函式協調 subagents。

它解決什麼

把單一長上下文,拆成多個乾淨上下文

每個 subagent 可以有獨立目標、模型選擇與 worktree,避免長任務在同一個 context 中逐漸失焦、偷懶或自我偏袒。

它怎麼做

用 JavaScript workflow 編排 agents

Workflow 可以分類任務、fan-out、等待 barrier、合成結果、產生 verifier、跑 tournament,甚至在中斷後 resume。

它的代價

更強,但也更耗 token

文章提醒 best practices 還在形成中。一般 coding 任務未必需要 workflow;真正適合的是大規模、未知工作量、需要對抗驗證或平行探索的任務。

這不是功能小更新,而是 agent 架構的改變

Failure Mode 1

Agentic laziness

複雜任務做到一半就宣稱完成,例如 security review 只處理 50 項中的 20 項。Workflow 可以用 /goal、stop condition 與 verifier 強化「做到真的完成」。

Failure Mode 2

Self-preferential bias

模型傾向相信自己的發現,尤其在被要求驗證自己的結果時。Workflow 可以讓產出 agent 與審查 agent 分離,降低自評偏誤。

Failure Mode 3

Goal drift

長對話與 compaction 會讓原始細節流失,像是 edge cases 或「不要做 X」的限制。Workflow 讓每個 agent 有更聚焦的任務與上下文。

Dynamic workflows 常見的 6 種編排模式

這些模式可以單獨使用,也可以組合成更完整的任務系統。

Classify-and-act先用 classifier agent 判斷任務類型,再把任務路由到不同 agent、模型或後續行為;也可以在最後分類輸出。
Fan-out-and-synthesize把大量小步驟拆給多個 agent 平行處理,再用 synthesize barrier 等所有結果回來後合併。
Adversarial verification每個產出都配一個 verifier,依照 rubric 對抗式檢查,避免模型只證明自己是對的。
Generate-and-filter大量產生候選解,再依 rubric 去重、過濾、驗證,只留下高品質方案。
Tournament讓多個 agent 用不同策略競爭同一任務,再用 pairwise judging 選出勝者;適合命名、設計、排序、方案比較。
Loop until done對未知工作量任務,持續 spawn agents 直到沒有新 findings、沒有錯誤或達到明確 stop condition。

文章中特別適合 workflows 的任務類型

Migrations / Refactors

把大型改名、語言遷移或模組重構拆成 callsites、測試、模組等單位;每個修復在獨立 worktree 中完成,再由 reviewer agent adversarially review 後合併。

Deep Research

Claude Code 的 /deep-research skill 會 fan-out web searches、fetch sources、驗證 claims,再合成引用報告。這種模式也能用在 Slack 狀態報告或 codebase 研究。

Deep Verification

對報告中的每個 factual claim 派 agent 查證,再由另一個 verifier 檢查來源品質;適合不想發布錯誤技術內容的場景。

Sorting / Ranking

大量履歷、support tickets、bugs 很難塞進單一 prompt。Workflow 可用 tournament、pairwise comparison 或 bucket-rank 平行處理,再合併排序。

Memory / Rule Adherence

一邊可以用 verifier agents 檢查 CLAUDE.md 規則,一邊也可以反向分析歷史 sessions / code review corrections,把反覆出現的修正萃取成新規則。

Root-cause / Triage / Evals

對 incident、bug backlog、sales 下滑、pipeline failure 等問題,讓不同 agents 從 logs、files、data 產生獨立假設,再互相 refute / verify。

可以直接借用的 prompt 形狀

這些不是逐字模板,而是用來理解何時該要求 Claude 建 workflow 的任務形狀。

什麼時候該用?用在「需要結構」的任務,不是用在所有任務

Dynamic workflows 的價值在於把 agent 從「會聊天的執行者」變成「能先設計執行系統的協調者」。但它不是萬用加速鍵:如果任務很短、風險低、上下文單純,直接讓 Claude Code 做就好。

適合

長時間、多分支、需要驗證、需要排序、需要大量資料處理、需要跨來源研究、需要避免單一 agent 偏誤的任務。

不適合

小型 bug fix、明確單檔修改、普通 CRUD、已經有清楚方案且不需要平行探索的任務。

最重要的 prompt 技巧

給清楚 goal、rubric、stop condition、token budget;必要時要求 quick workflow,而不是無限制地召喚大型 agent swarm。

來源連結:X post。本頁由 DMBot 依原文重新整理、翻譯與結構化。