Harness 是任务的外骨骼
文章把 harness 从固定产品能力变成动态生成能力：不是人预先写好所有流程，而是模型根据当下任务生成一个刚好够用的编排脚本。
01 / Thesis
Dynamic Workflows 的本质：让 Claude Code 从“执行任务”变成“先为任务设计执行系统”。
默认 Claude Code harness 擅长编码任务，但复杂任务往往需要并行、隔离、交叉验证、循环收敛和可恢复状态。Dynamic Workflows 让 Claude 临时写出 JavaScript workflow，用特殊函数调度 subagents，把任务拆成一套可执行的 harness。
Workflow 是可运行的协调层
Workflow 不是提示词清单，而是 JavaScript 文件。它能持有状态、启动 subagents、等待结果、合并输出，并在中断后恢复。
价值来自结构性纠偏
它主要针对单窗口长任务里的三个问题：偷懒式提前结束、自我偏好、目标漂移。解决办法不是“更努力”，而是让结构替模型兜底。
一句话读法：Dynamic Workflows 不是把 Claude Code 变成更大的聊天窗口，而是让它按任务生成一个小型组织。
02 / Why It Matters
为什么默认 harness 会失效？因为复杂任务不只是“上下文更长”，而是控制结构变了。
单窗口 Agent 的三种典型退化
Agentic laziness：复杂任务做了一部分就宣布完成。
Self-preferential bias：模型更容易相信自己刚产出的判断，验证变成背书。
Goal drift：多轮与压缩之后，原始约束、边界和“不要做什么”逐渐丢失。
Workflow 的解决方式
把任务分配给多个拥有独立上下文的子代理；把生成者和验证者分离；把判断标准写进 rubric；把循环、停止条件和合并逻辑交给脚本，而不是交给一个持续变长的对话上下文。
这就是文章标题里 “a harness for every task” 的含义：不同任务需要不同的控制结构，而不是都塞进同一条 agent 主循环。
03 / Six Patterns
六种工作流模式：这张图是文章最值得收藏的部分。
它们不是互斥模板，而是 Claude 生成 workflow 时可以组合的控制原语。真正会用 Dynamic Workflows，关键是能在提示词里点名你想要哪一种结构。
Classify
Classify-and-act
先用 classifier 判断任务类型，再路由给不同 agent 或行为。适合工单分流、候选简历分类、日志归因、不同复杂度模型路由。
Fan-out
Fan-out-and-synthesize
把任务拆成大量互不污染的小任务并行执行，然后在 synthesis barrier 汇总。适合大规模代码库探索、批量材料阅读、研究报告资料抓取。
Verify
Adversarial verification
每个生成 agent 配一个对抗验证 agent，用 rubric 检查输出。适合技术事实核验、安全审查、报告引用验证、方案风险评估。
Filter
Generate-and-filter
先生成大量候选，再按规则去重、过滤、验证，只保留高质量结果。适合命名、创意、prompt 方案、候选策略池。
Tournament
Tournament
多个 agent 用不同方法解决同一问题，再通过 pairwise judging 选胜者。适合架构方案、设计方向、复杂推理和主观品味选择。
Loop
Loop until done
当工作量未知时，不预设固定轮数，而是持续执行到停止条件成立，例如没有新发现、日志无错误、验证全部通过。
04 / Use Cases
最有价值的用例，不一定是写代码，而是“规模化判断”。
| 场景 | 适合的模式 | 为什么有效 |
|---|---|---|
| 迁移与重构 | Fan-out + Verify + Loop | 按 callsite、模块、失败测试拆分；每个修复独立 worktree；再由验证 agent 审查后合并。 |
| Deep Research | Fan-out + Adversarial verification + Synthesis | 并行搜索、抓取、核验来源，再合成带引用报告，降低单窗口遗漏和幻觉。 |
| 事实核查 | Claim extraction + per-claim verifier | 先抽取每个事实声明，再逐条找证据，必要时再验证来源质量。 |
| 大规模排序 | Tournament / bucket-rank | 1000 行数据很难一次性排序；pairwise comparison 往往比绝对打分更稳定。 |
| 记忆与规则遵守 | Rule verifier + mining workflow | 把反复犯错的修正沉淀为规则，再验证这些规则是否真的能阻止历史错误。 |
| 根因分析 | Independent hypotheses + refuters | 让不同 agent 从日志、代码、数据各自生成假设，再由反驳者测试，减少自我偏好。 |
05 / Boundaries
不要把 workflow 当成默认按钮：它用更多 token，也扩大了自动化半径。
简单任务不值得
普通编码任务、单文件小修、低风险问答，不需要五个 reviewer。更多 agent 不等于更高质量。
要给预算
文章建议可以显式设置 token budget。对高价值复杂任务值得，对日常任务则会浪费成本。
要做权限隔离
尤其是 triage 公共输入时，读取不可信内容的 agent 不应同时拥有高权限动作。先 quarantine，再 action。
判断标准很简单：如果任务需要并行、对抗、重复、隔离或可恢复状态，用 workflow；如果只是一次性执行，用默认 harness。
06 / How To Reuse
把这篇迁移到我们自己的工作方式：先学会用结构化提示词召唤 harness。
可直接复用的提示词骨架
研究型：使用 workflow 并行查找资料；每个来源由单独 verifier 核验；最后综合成带证据等级的报告。
评审型：让不同 agent 分别从用户、工程、商业、风险角度评审方案；再用 tournament 选出最稳妥版本。
排障型：为每个假设生成独立调查 agent；再由 refuter 攻击证据链；循环直到只有一个解释能站住。
精读后的个人结论
Dynamic Workflows 不是 Claude Code 的一个功能更新，而是一个信号：下一阶段 Agent 产品的竞争重点，会从“模型能不能做”转向“系统能不能组织模型做”。
真正稀缺的能力不是无限上下文，而是任务结构设计：什么时候分流，什么时候并行，什么时候验证，什么时候循环，什么时候停止。
07 / Sources
来源与延伸阅读
- Claude Blog: A harness for every task: dynamic workflows in Claude Code
- Claude Code Docs: Dynamic workflows documentation
- Claude Code Docs: Subagents
- Claude Code Docs: Skills
本文件为中文精读整理与视觉重构，不复刻原文全文；重点保留文章论证结构、关键模式、适用边界和迁移启发。