一个任务，
配一套 harness
上一篇讲了 Dynamic Workflows 是什么。这一篇讲怎么用：长任务交给一个 Claude 从头干到尾，它会偷懒、会偏袒自己、会跑偏。把活拆成各自独立上下文的子 agent，按几种固定套路并行、对抗、淘汰——这才是 workflow 真正的用法。
前一篇讲「是什么」，
这一篇讲 「怎么用」
发布一周后，Claude Code 团队的 Thariq 和 Sid 又写了篇续篇。它不再解释 workflow 是什么，专讲哪几种套路反复好使、为什么长任务非得这么拆、哪些场景出乎意料地合适，以及——什么时候压根别用。
还没看「是什么」那篇？workflow 的本质（Claude 现写的 JS 编排脚本）、它和 Skill 的分界（谁持有 plan）、运行机制与硬限制、Bun 从 Zig 移植到 Rust 的旗舰案例——都在 《谁持有 Plan》 里。本篇默认你已经知道这些，不再重复。
开篇作者就把丑话说在前头：workflow 烧 token 多得多，只适合复杂、高价值的任务，而且最佳实践还在长。它不是万能锤——这句话，整篇都在反复强调。
“Keep in mind, best practices are still developing: dynamic workflows often use more tokens and are best suited for complex, high value tasks.”
单个 context 跑长任务，
会犯的三个错
要懂那六个 pattern，得先懂它们在治什么病。默认 harness 干活时，规划和执行挤在同一个 context window 里——对很多编程任务这很好使，但碰上长时间跑、大规模并行、高度结构化或对抗性的任务，就会以三种方式塌掉。
Agentic laziness
偷懒
没干完就宣布干完了。50 项的安全审查，做到第 35 项就说「搞定」——剩下 15 项被它自己跳过了。
Self-preferential bias
自我偏袒
偏爱自己的产出。尤其让它拿着 rubric 去验证、评判自己刚做的东西时，它会下意识护着自己——既当运动员又当裁判。
Goal drift
目标漂移
跑了很多回合后，对原目标的忠实度一点点流失。compaction（上下文压缩）之后尤其严重，「别做 X」这类约束在一次次有损摘要里被丢掉。
解法是一句话：“Creating a workflow helps combat these by orchestrating separate Claude subagents with their own context windows and focused, isolated goals.”
偷懒——因为脚本拿着完整清单，循环不到末尾不算完，不靠模型自觉；偏袒——因为验证的是另一个独立 agent，不是自己；漂移——因为目标写在脚本里，不随 compaction 流失。三个 pattern 的根，都在这。
六个 pattern：Claude 搭 workflow 时反复用的套路
这六种可以组合着用——Claude 搭一个 workflow 时往往把它们拼起来。点一下，看每种套路的编排形状长什么样。
一半的用例，根本不是写代码
作者特意说，要有创意地想 workflow 能用在哪——他发现「有时候在非技术工作上更有用」。下面这串，技术的非技术的混着来。
迁移与重构 技术
把任务拆成一串要逐个处理的东西——callsite、失败的测试、模块。每个改动开一个 agent 在自己的 worktree 里改，另一个 agent 对抗式审查，再 merge。Bun 从 Zig 到 Rust 就是这么干的（案例 nuance 见前作）。
深度研究 技术
自带的 /deep-research 就基于 workflow：铺开网搜、抓来源、对抗式验证每条 claim、合成带引用的报告。但不止网搜——也能从 Slack 上下文攒状态报告，或深挖代码库研究一个功能怎么实现的。
深度核查 技术
一份报告想把每条事实声明都查证、标出处：一个 agent 把所有声明拎出来，每条开一个子 agent 细查；甚至再加一个 agent 去检查查证者的来源够不够硬。
排序 技术
1000+ 行塞进一个 prompt 排，质量会崩也塞不下。改用淘汰赛、两两比较的流水线，或并行分桶再合并。关键经验：成对比较比绝对打分可靠。
根因调查 跨职能
让一批 agent 从不相交的证据各自生成假设——一个看日志、一个看文件、一个看数据，再过一组验证者和反驳者的面板。不只给代码用：销售（三月为什么掉单）、数据工程（pipeline 为什么挂）、任何复盘都行。
记忆与规则遵守 跨职能
有组规则 Claude 老是漏，哪怕写进 CLAUDE.md：一条规则配一个 verifier agent 去查。反过来更妙——从最近 session 挖你反复纠正的点，对抗验证后蒸馏回 CLAUDE.md。
探索与品味 跨职能
设计、起名这种「品味驱动」又能给 rubric 的活：让 Claude 探索一堆方案，给 review agent 一份「好方案长什么样」的 rubric，它觉得达标了就算完，也能用淘汰赛挑。
模型路由 技术
一个分类器 agent 决定用哪个模型。比如「解释 auth 模块怎么工作」该用哪个，取决于模块多少文件、代码库什么形状——分类器先调研，再路由到 Sonnet 还是 Opus。
规模化分诊 Quarantine 隔离
处理不完的支持队列、bug 报告：一个 triage workflow 把每项分类、跟在跟的去重、再采取行动（尝试修复或升级给人）。这里有个安全 pattern 叫 quarantine（隔离）——读不可信公开内容的 agent，不许做高权限动作；高权限动作交给另一批专门负责行动的 agent。读和做分家，正是防 prompt injection 的结构性手段。配上 /loop 就能持续不断地分诊。（Evals 轻量评测也是同一路子：agent 在各自 worktree 跑出产物，再派比较 agent 拿 rubric 打分。）
不是每件事，
都值得一个 5 人评审团
作者花了专门一节讲「别用」，态度很清楚：workflow 是新东西，很多场景能出奇效，但不是每个任务都需要，而且可能烧掉多得多的 token。
这真的需要更多算力吗？workflow 是用来把 Claude Code 推到你以前没法做的地方，不是给每件小事加码。作者举的例子很到位——
“most traditional coding tasks do not need a panel of 5 reviewers.”
除了大任务，还能这么使
小任务也能开
不止大工程。可以让它做一次快速的对抗式审查——比如对一个假设挑挑刺，一句话的事。
配着定时和硬目标
可重复的 workflow（triage、研究、验证）配 /loop 定时跑，配 /goal 设一个硬性的完成要求。
给它封个顶
直接在 prompt 里写 "use 10k tokens" 之类，给这次任务的 token 用量设上限，免得失控。
存下来、分享出去
菜单按 s 存，可 check 进 ~/.claude/workflows 或塞进 skill 分发。提示 Claude 把它当模板、而非必须逐字跑的脚本，灵活性更高。
逻辑是闭合的
前作回答「这东西是什么、为什么 plan 该交给代码」；本篇回答「拿到手怎么搭、怎么用、什么时候别用」。把两篇连起来，链条是闭合的：
→ 所以把 plan 从模型 context 搬进确定性脚本（前作核心）
→ 搬进去之后，对抗验证 / 淘汰赛 / loop-until-dry / quarantine 才第一次从「指望模型记得」变成「代码强制执行」（本篇）
这正是 workflow 区别于「单纯并行跑更多 agent」的地方——它把怎么保证质量也写进了代码。