2026年5月底，Anthropic宣布了一件挺有意思的事：Claude Code开始支持Dynamic Workflows（动态工作流）。紧接着6月初，工程博客又把这套玩法的原理和模式拆了个底朝天。现在，这个能力已经是正式可用（GA）状态了。
如果你刚读完上一篇《Claude Code Skills 九分类》，可以这样来理解这两者之间的关系：
- Skills = 一块块可以反复使用的能力积木，稳定、方便分发。
- Dynamic Workflows = 针对手头的具体任务，当场给你写出来的编排脚本，灵活是真灵活，但费Token也是真费。
官方给了句很精辟的总结：
Claude can now write and orchestrate its own multi-agent harness on the fly.
翻译成大白话就是：你不用再亲手去搭一套固定的流水线了。Claude会根据任务，动态生成一个调度引擎（Harness），然后指挥几十甚至上百个子Agent，并行地给你干活。
接下来，我们就从「到底解决了什么问题」开始，一路聊到「啥时候千万别用它」，帮你快速判断这套Dynamic Workflows是不是你现阶段需要的。
一、为什么需要Dynamic Workflows？
默认的Claude Code Harness，应付日常编码绰绰有余：一个上下文里，规划、执行，一气呵成。
但是，碰上下面这些类型的任务，它就有点力不从心了：
- 在整个仓库里排查Bug
- 横跨数百个文件的大型迁移
- 需要多角度、对抗性验证的高风险决策
- 间歇性失败（比如跑50次才挂1次）的竞态条件复现
- 上千条记录的分拣、排序和根因分析
官方总结出了单上下文长任务最容易翻车的三类失败模式：
| 失败模式 | 具体表现 |
|---|---|
| Agent偷懒 | 复杂的任务做了一部分，就宣布结束了。比如安全审计，50项检查只完成了35项。 |
| 自偏好偏差 | 自己生成的结果，自己来验证，结果怎么看怎么顺眼，偏向性很强。 |
| 目标漂移 | 多轮上下文压缩（compaction）下来，最开始设定的约束和边界条件，慢慢就丢了。 |
Dynamic Workflows的解法很简单：把一个大任务拆成多个拥有独立上下文的子Agent，每个Agent专注自己的小目标，最后再合到一起，通过对抗验证、反复迭代，直到结果收敛。
这个思路，和Anthropic在《Agentic Coding Report》里提到的「从单打独斗的Agent走向协同团队」的趋势，是一脉相承的。
二、动态vs静态：差别在哪？
你可能已经用Claude Agent SDK或者claude -p写过静态workflow——一套脚本走天下，无论什么场景都用这一套。
问题在于，这套静态脚本要为所有可能出现的边界情况兜底，结果往往是“大而不精”，偏泛化。
现在，有了Claude Opus 4.8和Dynamic Workflows，Claude足够聪明，能够针对你当下的这一个任务，量身定制一套Harness。
| 维度 | 静态Workflow | Dynamic Workflow |
|---|---|---|
| 谁写编排 | 人提前写好 | Claude运行时生成 |
| 适配性 | 通用模板 | 任务定制 |
| 子Agent数 | 通常较少 | 可达几十到上百并行 |
| Token消耗 | 相对可控 | 显著更高 |
| 适合任务 | 重复性流程 | 复杂、长时、对抗性任务 |
三、怎么触发？两种入口
官方目前提供了两种触发方式（建议把auto mode打开）：
方式1：直接要求创建Workflow
在Claude Code里直接说：
Create a workflow to …
然后把你想要的目标、范围和验收标准交代清楚就行。
方式2：打开ultracode
在Claude Code的effort菜单里，把ultracode开关打开：
- 把effort设为xhigh
- Claude会自动判断什么时候应该启用Workflow来处理任务
可用范围（以官方公告为准）：Claude Code CLI、Desktop、VS Code扩展；Max / Team / Enterprise（Enterprise需要管理员开启）；以及Claude API、Bedrock、Vertex、Foundry等。
有个小提醒：第一次触发Workflow时，Claude Code会把即将运行的计划展示给你看，并要求你确认。Token消耗会明显比普通会话高，所以建议先用小范围的任务试试水。
四、底层怎么跑？（技术直觉）
Workflow启动之后，Claude会走这么几步：
- 动态规划——根据prompt，把任务拆成子任务
- Fan-out（扇出）——并行拉起一堆子Agent（可以选择使用独立的worktree）
- 检查——结果合并之前，先验证一遍
- 合成——回到单一的协调者，汇总最终答案
编排逻辑是在对话上下文之外执行的，所以任务规模再大，计划也不会轻易跑偏。
几个关键能力值得留意：
- 可恢复：中断后resume会话，能从断点继续，不用从头再来
- 可选模型路由：分类Agent来决定哪个子任务用Sonnet，哪个用Opus
- 可设Token预算：比如在prompt里写一句「use 10k tokens」，就能设个上限
本质上，Workflow就是执行一段Ja vaScript，调用特殊的函数来协调subagent（具体细节可以去看官方docs）。
五、官方6种编排模式（值得背下来）
Anthropic工程博客总结出了Claude构建Workflow时最常用的模式——你可以把这六种模式当成提示词的“词汇表”来用。
1. Classify-and-act（分类路由）
先用一个分类Agent判断任务类型，然后再把它路由到不同的子Agent或行为上。
2. Fan-out-and-synthesize（扇出合成）
把一个任务拆成大量小步骤，每个步骤都在独立的上下文里并行执行，最后做一次屏障式合成（得等所有步骤都完成了再合并）。
这个模式特别适合处理大批量的同质步骤，能有效避免相互干扰。
3. Adversarial verification（对抗验证）
给每个产出的Agent配一个专门挑刺的Agent，按rubric来批判，直到挑不出什么原则性问题才放过。
适合：安全审计、架构方案、高代价的决策场景。
4. Generate-and-filter（生成过滤）
大量生成候选方案 → 按rubric过滤 → 去重 → 留下质量最高的。
5. Tournament（锦标赛）
多个Agent用不同的方法做同一道题，然后由一个评判Agent两两比较，直到选出最后的胜者。
适合：命名、设计、排序、方案选型。
6. Loop until done（循环直到停）
在不确定工作量的情况下，循环地拉起Agent，直到发现不了新东西 / 找不到新错误，才停下来。
适合：日志扫描、告警归因、根因排查。
这些模式可以自由组合。你在prompt里明确指出要用的模式，往往比笼统地说一句「帮我认真做」要有效得多。
六、官方给的Prompt灵感（可以直接拿来改）
工程博客上列了一批高质量的示例，摘几条给大家感受一下：
竞态复现
This test fails maybe 1 in 50 runs. Set up a workflow to reproduce it. Form competing theories about the race, and don't stop until one theory survives the evidence.
从会话里挖掘CLAUDE.md规则
Using a workflow, go through my last 50 sessions and mine them for corrections I keep making and turn the recurring ones into CLAUDE.md rules.
Slack事故根因分析
Use a workflow to dig through #incidents in Slack for the past six months and find recurring root causes where nobody has filed a ticket.
商业计划对抗验证
Take my business plan and run a workflow where different agents tear it apart from an investor's, a customer's, and a competitor's perspective.
技术博文事实核查
Go through my blog post draft and verify every technical claim against the codebase using a workflow.
看到规律了吧？——范围要清晰，停止条件要明确，模式要指定（对抗/扇出/循环）。
七、典型场景：什么时候值得开Workflow？
代码与工程
- 全仓库的Bug猎杀/安全审计/性能剖析
- 大迁移：框架替换、API废弃、语言移植（跨上千个文件的那种）
- 重构：比如User改名为Account，全仓库都要跟着改
- 间歇性Bug：需要并行验证多个假设
非代码场景同样适用
- 深度调研：先扇出搜索，再对抗核实，最后输出引用报告（
/deep-research这个Skill就是用Workflow实现的） - 分拣排序：处理上千个ticket或简历，用锦标赛模式或桶排序
- on-call分诊：先分类，再去重，然后尝试修复或升级处理
- 探索审美方案：命名、UI方向，用锦标赛模式选出Top 3
企业用户的反馈
- Klarna：在大代码库里做发现和review，能识别出静态分析漏掉的死代码
- CyberAgent：填补了「单子Agent」和「完整Agent Team」之间的鸿沟，长时运行还能保持可见性
八、案例：Bun从Zig迁移到Rust（Workflow的极限压测）
官方用Jarred Sumner的Bun迁移项目，展示了一次规模上的极限测试（Jarred后续会有更完整的文章）：
| 指标 | 数据 |
|---|---|
| 产出规模 | 约75万行Rust代码 |
| 测试通过率 | 约99.8%的既有测试套件 |
| 周期 | 从首次提交到合并，用了约11天 |
| 并行度 | 几百个Agent并行写.rs文件，每个文件还配了2个reviewer |
Workflow的几个阶段（简要描述）：
- 映射Zig里每个struct field对应的Rust lifetime
- 并行地把每个
.zig文件端口成.rs - Fix loop反复跑，直到build和test全部通过
- 通宵跑Workflow，找不必要的内存拷贝，每个优化单独开一个PR
必须强调的是：这是一个极端的压力测试案例，不代表日常需求都应该Workflow化。但它确实证明了编排层有能力把「季度级别的迁移」压缩到「天级」——前提是你已经拥有成熟的验证和review机制。
九、什么时候不要用Dynamic Workflows？
官方态度很明确：
Workflows are not needed for every task and may end up using significantly more tokens.
尽量别用Workflow的场景：
- 普通函数实现、修个小Bug、改单个文件
- 连明确停止条件都没有的模糊需求
- Token预算紧张，而且任务可以被Skills和单Agent覆盖
- 不需要对抗验证的低风险改动
一个简单的经验法则：先问自己一句「这事儿真的需要更多算力吗？」——大部分日常编码工作，并不需要一个5人审查团。
如果拿不准，可以先退一步，让Claude跑一个quick workflow（比如只做一次对抗性的单假设审查）。
十、和Skills、/loop、/goal怎么配合？
Skills × Workflows
- 把成熟的Workflow保存到
~/.claude/workflows（在Workflow菜单里按s即可） - 或者通过Skill引用Workflow JS作为模板——它不是死板的脚本，允许Claude按任务改写
上一篇Skills里提到的验证类、审查类、Runbook类，正是Workflow里子Agent的质量底座。
搭配/loop和/goal
- /loop：适合周期性triage、调研、验证（比如每小时扫一遍告警）
- /goal：给Workflow设一个硬性的完成条件，防止它无限循环下去
和merge责任的关系
Workflow会产出更多代码、更多PR——但merge的按钮，终究还在人的手里。
在扇出并行时，建议这样做：
- 每个子任务独立worktree + 小PR
- 合并之前，先跑一遍Verification Skill
- 对于高风险路径，保留人工签核（human sign-off）
十一、上手清单（今天就能试）
- 选一个“小而硬”的任务（比如：验证一篇技术文章里的所有代码声明）
- 开启auto mode，或者直接说
Create a workflow - 在prompt里写清楚：模式（比如adversarial verification）和停止条件
- 第一次确认计划时，看看子Agent的拆分是否合理
- 设一个Token预算（比如
use 10k tokens），防止失控 - 如果满意，就保存Workflow，供团队复用
- 把稳定下来的部分沉淀为Skill（验证脚本、踩坑经验）
十二、和系列文章的衔接
| 你已读过的 | 本文补充了什么 |
|---|---|
| Skills九分类 | Workflow = 运行时编排层；Skills = 模块 |
| Agentic Coding Report的多Agent | 具体产品形态与6种模式 |
| 3天→1天工作流实录 | 长时并行编排的官方方法论 |
| Generated Code / merge责任 | 高产出场景下的验收与拆PR |
下一篇的自然续篇是：C03 Bun迁移实录深度拆解（或者D01 DeepSeek V4国产技术栈）。
十三、结论
Dynamic Workflows的出现，标志着Claude Code正在从「一个聪明的编码Agent」，进化成「一个能自己编写编排器的Agent系统」。
记住这四句话就好：
1. 只有在复杂、长时、对抗性的任务上，才值得开Workflow
2. 六种模式（扇出、对抗、锦标赛、循环……）就是提示词里最大的杠杆
3. Token很贵，先拿小任务试水，设好预算，能保存就保存复用
4. Skills沉淀质量，Workflow放大算力——两者配合，不是二选一
静态流水线并没有死，但2026年的上限，属于那些能够驾驭动态Harness的指挥官。
资料来源
- Anthropic《A harness for every task: dynamic workflows in Claude Code》：https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code
- Anthropic《Introducing dynamic workflows in Claude Code》：https://claude.com/blog/introducing-dynamic-workflows-in-claude-code
- Claude Code Workflows文档：https://code.claude.com/docs/en/workflows
- Bun迁移讨论（Jarred Sumner）：https://x.com/jarredsumner/status/2060050578026189172
- 上一篇：《Claude Code Skills九分类》
Bun迁移等案例来自Anthropic官方披露，实际效果与团队工程成熟度高度相关；Workflow的Token消耗因任务差异很大，请以控制台实际用量为准。
