把單一長上下文,拆成多個乾淨上下文
每個 subagent 可以有獨立目標、模型選擇與 worktree,避免長任務在同一個 context 中逐漸失焦、偷懶或自我偏袒。
Thariq 這篇文章的重點,不是「多開幾個 agents」,而是把複雜任務從單一對話,升級成可分工、可驗證、可恢復、可分享的任務執行系統。
核心判斷:dynamic workflows 是 Claude Code 從 coding assistant 走向 general-purpose agent runtime 的重要一步;但它會吃更多 token,所以應該用在長任務、平行任務、驗證任務與高結構任務,而不是每個日常修改都套用。
過去 Claude Code 的預設 harness 很適合 coding,但 research、security review、agent teams、code review、sorting、triage 等任務,常需要更明確的分工與驗證。Dynamic workflows 讓 Claude 依任務即時生成 JavaScript workflow,並用特殊函式協調 subagents。
每個 subagent 可以有獨立目標、模型選擇與 worktree,避免長任務在同一個 context 中逐漸失焦、偷懶或自我偏袒。
Workflow 可以分類任務、fan-out、等待 barrier、合成結果、產生 verifier、跑 tournament,甚至在中斷後 resume。
文章提醒 best practices 還在形成中。一般 coding 任務未必需要 workflow;真正適合的是大規模、未知工作量、需要對抗驗證或平行探索的任務。
複雜任務做到一半就宣稱完成,例如 security review 只處理 50 項中的 20 項。Workflow 可以用 /goal、stop condition 與 verifier 強化「做到真的完成」。
模型傾向相信自己的發現,尤其在被要求驗證自己的結果時。Workflow 可以讓產出 agent 與審查 agent 分離,降低自評偏誤。
長對話與 compaction 會讓原始細節流失,像是 edge cases 或「不要做 X」的限制。Workflow 讓每個 agent 有更聚焦的任務與上下文。
這些模式可以單獨使用,也可以組合成更完整的任務系統。
把大型改名、語言遷移或模組重構拆成 callsites、測試、模組等單位;每個修復在獨立 worktree 中完成,再由 reviewer agent adversarially review 後合併。
Claude Code 的 /deep-research skill 會 fan-out web searches、fetch sources、驗證 claims,再合成引用報告。這種模式也能用在 Slack 狀態報告或 codebase 研究。
對報告中的每個 factual claim 派 agent 查證,再由另一個 verifier 檢查來源品質;適合不想發布錯誤技術內容的場景。
大量履歷、support tickets、bugs 很難塞進單一 prompt。Workflow 可用 tournament、pairwise comparison 或 bucket-rank 平行處理,再合併排序。
一邊可以用 verifier agents 檢查 CLAUDE.md 規則,一邊也可以反向分析歷史 sessions / code review corrections,把反覆出現的修正萃取成新規則。
對 incident、bug backlog、sales 下滑、pipeline failure 等問題,讓不同 agents 從 logs、files、data 產生獨立假設,再互相 refute / verify。
這些不是逐字模板,而是用來理解何時該要求 Claude 建 workflow 的任務形狀。
Dynamic workflows 的價值在於把 agent 從「會聊天的執行者」變成「能先設計執行系統的協調者」。但它不是萬用加速鍵:如果任務很短、風險低、上下文單純,直接讓 Claude Code 做就好。
長時間、多分支、需要驗證、需要排序、需要大量資料處理、需要跨來源研究、需要避免單一 agent 偏誤的任務。
小型 bug fix、明確單檔修改、普通 CRUD、已經有清楚方案且不需要平行探索的任務。
給清楚 goal、rubric、stop condition、token budget;必要時要求 quick workflow,而不是無限制地召喚大型 agent swarm。
來源連結:X post。本頁由 DMBot 依原文重新整理、翻譯與結構化。