题记：本文编译自 Anthropic 官方博客《A harness for every task: dynamic workflows in Claude Code》，由 Anthropic 工程师 Thariq Shihipar 和 Sid Bidasaria 撰写。
Claude Code 的默认模式是单 Agent，一个上下文窗口搞定规划和执行。大多数编程任务这就足够好用了。
但是也有很多场景你怎么优化都跑不好。单 Agent 在长时间运行、大规模并行、需要对抗性验证的任务上，有三个已知的退化模式：
第一个是偷懒。让它做一轮安全审查，50 个检查项查到 20 个就宣布完成了。这不是幻觉，是 Agent 在长上下文里的行为退化。第二个是自我偏爱。让它评判自己的产出，它天然倾向于给好评，需要严格验证的场景里这是致命的。第三个是目标漂移。上下文压缩是有损的，每压缩一次，原始需求里的边缘条件、约束细节就丢一点。时间长了之后，Agent 在优化的目标可能已经偏离了你最初给它的任务。
这三个问题不是模型能力问题，是单上下文窗口同时承担规划和执行带来的架构局限。Anthropic 显然也清楚这一点，所以之前陆续搞了 Research、安全审计、Agent Teams、Code Review 这些定制 Harness，每个都是针对特定任务类型写死的调度逻辑。
上周他们把这个能力泛化了：Claude Code 现在可以自己写调度逻辑，针对当前任务实时生成编排脚本，也就是 Dynamic Workflows。
工作原理
动态工作流的核心思路是：用独立的子 Agent 各自占一个干净的上下文窗口，每个子 Agent 只干一件事，由一个确定性的 JavaScript 脚本来调度它们的执行顺序和依赖关系。
动态 vs 静态：区别在哪
之前用 Claude Agent SDK 或者 claude -p 来编排多个 Claude Code 实例，本质上是静态工作流。你得提前写好脚本，考虑各种边界情况，写出来的东西往往比较通用。
动态工作流不一样。Claude Code 自己看任务，自己写调度脚本，针对当前这一个具体任务量身定制。Opus 4.8 的能力已经足够让它自己写出高质量的 Harness。
我自己试了一下，感受是：对于那些你本来就知道怎么拆分的任务，静态工作流更可控。但对于"我大概知道要做什么，但不确定最优的拆分方式"的场景，让 Claude Code 自己决定怎么调度确实省事。
六种调度模式
Claude Code 在构建动态工作流时会组合使用几种基本模式：
最基础的是分类路由，一个分类 Agent 判断任务类型，分发给不同的处理 Agent。也可以反过来，在最后加一个分类器决定输出格式。
用得最多的是扇出合并。把任务拆成很多小步，每个小步一个独立 Agent，最后一个合并 Agent 汇总结果。好处是每个子 Agent 有干净的上下文，互不污染。
对抗验证是直接针对自我偏爱问题的解法：每个生成 Agent 配一个独立的验证 Agent，专门挑毛病。生成过滤类似，先大量生成，再按标准筛选去重，只留通过验证的。
然后是锦标赛模式。N 个 Agent 用不同策略做同一件事，两两比较淘汰，留下赢家。最后是循环到完成，不设固定轮次，一直跑到满足停止条件为止。
这些模式可以组合。比如先扇出，每个分支内部做对抗验证，合并时再跑一轮锦标赛选最优方案。
实际能干什么
那这些模式实际能用在哪？原文列了不少场景，我挑几个觉得实用的说。
大规模迁移和重构
Bun 从 Zig 重写成 Rust 就用了工作流。核心思路是：把需要改的地方拆成独立单元（调用点、失败的测试、模块），每个单元派一个子 Agent 在独立的 worktree 里修，另一个 Agent 做对抗性 Review，通过了再合并。
这个场景我觉得价值最大。平时做大规模重构最头疼的就是改着改着上下文丢了，或者改了 A 忘了 B 也要跟着改。每个修改点一个独立 Agent，天然避免了交叉污染。
深度验证
如果你写了一篇技术文章，里面有大量事实性声明，可以用工作流让一个 Agent 先把所有事实性声明提取出来，然后每个声明派一个子 Agent 去核实。还可以再加一层，验证核实 Agent 引用的信息源本身是否可靠。
排序
对定性内容排序（比如按 Bug 严重程度排 1000 条工单），单次 Prompt 的质量会随数量急剧下降。工作流的做法是用锦标赛模式，两两比较。比较判断比绝对评分可靠得多，而且每次比较是一个独立 Agent，确定性的循环逻辑只负责维护对阵表。
规则遵守
有时候明明在 CLAUDE.md 里写了规则，但 Claude Code 跑着跑着就忘了。这时候，就可以用工作流做一个验证层：一条规则一个验证 Agent，每个验证 Agent 用怀疑论者的视角去检查是否违规。
反过来也行：扫最近的 session 日志和 Code Review 评论，找反复出现的纠正，聚类、验证（这条规则真的能防住之前的错误吗？），然后把确认有效的提炼成新的 CLAUDE.md 规则。
根因分析
调试最怕的是认定了一个假设就一路追到底。单 Agent 在一个上下文窗口里特别容易犯这个错误。工作流可以结构性地避免：分别从日志、文件变更、数据状态生成独立假设，每个假设面对一组验证者和反驳者。
这个模式不只适用于代码。销售数据下降、数据管道故障、任何需要事后复盘的场景都能用。
大规模分流
每个团队都有处理不完的支持队列。工作流可以对每条工单做分类、去重（跟已有的 ticket 对比）、尝试自动修复或升级给人。
这里有个有意思的设计模式叫隔离区：读不可信外部内容的 Agent 不允许执行高权限操作，高权限操作由另一个 Agent 负责。读和写分离，避免 prompt injection 导致的越权。
什么时候不需要工作流
动态工作流消耗的 token 显著更多，适合复杂、高价值的任务。
日常写代码，问自己一个问题：这件事真的需要 5 个 Reviewer 组成的评审团吗？大多数常规编程任务可能并不需要。
我的判断标准是：如果你能在 Prompt 里一句话描述清楚要做什么，而且做完之后你自己能快速验证结果，那就不需要工作流。需要工作流的场景通常有两个特征：任务可以被拆成独立的并行单元，或者验证成本高到你不想自己一个个检查。
用法和技巧
开启动态工作流的方法有两种：直接在 Prompt 里要求 Claude 创建工作流，或者用触发词 ultracode。
描述调度模式的时候要具体。不是”用工作流做这件事”就完了，而是告诉 Claude Code 你想要什么样的验证方式、什么样的并行策略。上面那六种模式的名字可以直接用在 Prompt 里。
对于可重复的工作流（分流、监控、验证），搭配 /loop 设置定期执行，/goal 设置硬性完成条件。工作流很容易跑飞，在 Prompt 里加一句“用 10k token”（大概一两轮对话的量）就能限制消耗。
工作流运行时按 s 可以保存脚本，存到 ~/.claude/workflows 或者通过 Skill 分发给团队。
几个实际的 Prompt 示例
原文给了一组示例 Prompt，我觉得比理论解释更直观：
- 这个测试大概 50 次跑挂一次。用工作流复现它，形成竞争性假设，不找到经得起验证的根因不许停。
- 用工作流扫我最近 50 个 session，找到我反复在纠正的模式，把重复出现的提炼成 CLAUDE.md 规则。
- 拿我的商业计划，用工作流让不同 Agent 分别从投资人、客户、竞争对手的视角撕它。
- 这个文件夹有 80 份简历，用工作流按后端岗位排名，前 10 名交叉验证一遍。先用 AskUserQuestion 问我评分标准。
- 用工作流把我们的 User 模型全局重命名成 Account。
共同点很明显：都是可以拆分成独立并行单元的任务，并且都需要某种形式的验证或对抗。
写在最后
三个月前的《为什么单 Agent 搞不定复杂应用？Anthropic 的 Harness 设计给出了答案》，当时聊的是 Anthropic 用 Generator-Evaluator 模式做长时间全栈开发。那套架构需要人手动搭建，三个 Agent 跑 6 小时花 200 美元。
动态工作流的思路是把"搭建 Harness"这件事也交给 Claude Code 自己。不再需要你预先想好怎么拆分、怎么验证、怎么合并，Claude 看了任务之后自己决定。
这是不是靠谱？说实话，我的体感是：对于你已经有经验的任务类型，自己写静态工作流更可控；对于探索性的任务，让 Claude Code 自己决定调度方式确实能发现一些你没想到的拆法。两者不矛盾，动态工作流可以保存下来变成静态的。
不过话说回来，Harness 可能也像 prompt engineering 一样，是大模型发展过程中的一个中间状态。模型不够强的时候需要人写精巧的调度逻辑，需要多个 Agent 互相制衡才能把一件事做好；模型足够强了，这些逻辑就会被内化。今天你还在想怎么编排子 Agent，也许下一代模型根本不需要外部编排，自己就能在内部完成任务分解和对抗验证。当然，这个"也许"到底要多久，没人知道。
相关资源：
- 原文链接：https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code
- 动态工作流文档：https://code.claude.com/docs/en/workflows
- 前作：Bun 重写（Jarred Sumner）：https://x.com/jarredsumner/status/2060050578026189172
欢迎长按下面的二维码关注 Feisky 公众号，了解更多云原生和 AI 知识。
