副标题：静态流水线已成瓶颈——运行时自建 Harness，并行调用上百子 Agent 的 6 种编排模式与避坑实战
2026 年 5 月底，Anthropic 宣布 Claude Code 正式支持 Dynamic Workflows；6 月初官方工程博客进一步拆解了其底层原理与典型模式。目前该能力已全面开放使用。
如果你刚读完上一篇文章《Claude Code Skills 九分类》，可以这样理解两者的关系：
- Skills = 可复用的能力积木（稳定、可分发）
- Dynamic Workflows = 为当前任务即时编写的编排脚本（灵活、Token 消耗较高）
官方一句话总结：不再是手动编写一套固定流水线，而是 Claude 根据任务动态生成 Harness，调度几十甚至上百个子 Agent 并行执行。
下面从「解决什么问题」「如何工作」「6 种模式」「Bun 实战记录」「何时避免使用」等多个维度展开，帮助你判断是否应该启用 Dynamic Workflows。
一、为什么需要 Dynamic Workflows？
默认的 Claude Code Harness 在常规编码场景下确实够用：在一个上下文里规划、执行，一气呵成。
但遇到以下场景就容易遇到瓶颈：
- 全仓库 Bug 排查
- 跨数百个文件的大规模迁移
- 需要多角度对抗验证的高风险决策
- 间歇性失败（1/50）的竞态复现
- 上千条记录的分拣、排序、根因分析
官方总结了单上下文长任务的三类常见失败模式：
| 失败模式 | 表现 |
|---|---|
| Agentic laziness（Agent 偷懒） | 复杂任务完成一部分就宣称结束（例如安全审计 50 项只做了 35 项） |
| Self-preferential bias（自偏好） | 自己生成、自己验证时倾向于认可自己的结果 |
| Goal drift（目标漂移） | 多轮压缩后，原始约束和边界条件逐渐丢失 |
Dynamic Workflows 的解决思路很直接：拆分成多个独立上下文的子 Agent，各自聚焦子目标，再通过合成、对抗验证、迭代收敛的方式得出最终结果。
这与 Anthropic《Agentic Coding Report》中「单 Agent → 协同团队」的趋势完全一致。
二、动态 vs 静态：差别在哪里？
你可能已经用 Claude Agent SDK 或 claude -p 写过静态 workflow——一套脚本适配所有场景。问题在于，静态 workflow 必须为所有边界情况兜底，导致方案往往偏泛化。
有了 Claude Opus 4.8 和 Dynamic Workflows，Claude 足够聪明，能针对你当前的具体任务编写定制化的 Harness。
| 维度 | 静态 Workflow | Dynamic Workflow |
|---|---|---|
| 谁写编排 | 人提前写好 | Claude 运行时生成 |
| 适配性 | 通用模板 | 按任务定制 |
| 子 Agent 数量 | 通常较少 | 可达几十～上百并行 |
| Token 消耗 | 相对可控 | 显著更高 |
| 适用任务 | 重复性流程 | 复杂、长时、对抗性任务 |
三、如何触发？两种入口
官方目前提供两种方式，建议开启 auto 模式：
方式 1：直接要求创建 Workflow
在 Claude Code 中输入：
并清晰描述目标、范围、验收标准。
方式 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 本质上是执行一段 JavaScript，调用特殊函数协调 subagent（详见官方文档）。
五、官方 6 种编排模式（值得收藏）
Anthropic 工程博客总结了 Claude 构建 Workflow 时最常用的模式，可以当作提示 Claude 的词汇表。
1. Classify-and-act（分类路由）
先用分类 Agent 判断任务类型，再路由到不同子 Agent 或行为。
2. Fan-out-and-synthesize（扇出合成）
拆成大量小步骤，每步独立上下文并行，最后通过屏障式合成（等待全部完成再合并）。
适合：大批量同质步骤，避免交叉污染。
3. Adversarial verification（对抗验证）
每个产出 Agent 配一个挑刺 Agent，按 rubric 批判，修到只剩下 nitpick。
适合：安全审计、架构方案、高代价决策。
4. Generate-and-filter（生成过滤）
大量生成候选 → 按 rubric 过滤 → 去重 → 保留高质量结果。
5. Tournament（锦标赛）
多个 Agent 用不同方法处理同一问题，评判 Agent 进行 pairwise 比较，直到选出胜者。
适合：命名、设计、排序、方案选型。
6. Loop until done（循环直到停止）
工作量未知时，循环 spawn Agent，直到无新发现或无新错误才停止。
适合：日志扫描、告警归因、根因排查。
这些模式可以组合使用。在 prompt 中明确指定模式，往往比泛泛地说「帮我认真做」有效得多。
六、官方提供的 Prompt 灵感（可直接修改使用）
工程博客列出了一些高质量示例，摘录几条：
竞态复现、从会话中挖掘 CLAUDE.md 规则、Slack 事故根因、商业计划对抗、技术博文事实核查。
看出规律了吗？——范围清晰、停止条件明确、指定模式（对抗/扇出/循环）。
七、典型场景：什么时候值得开启 Workflow？
代码与工程
- 全仓库 Bug hunt / 安全审计 / 性能剖析
- 大迁移：框架替换、API 废弃、语言移植（跨千个文件）
- 重构：如 User → Account 全库重命名
- 间歇性 Bug：多假设并行验证
非代码场景同样适用
- 深度调研：fan-out 搜索 + 对抗核实 + 引用报告（
/deep-researchSkill 即使用了 Workflow） - 分拣排序：上千 ticket/简历，tournament 或 bucket-rank
- on-call 分诊：分类 → 去重 → 尝试修复或升级
- 探索审美方案：命名、UI 方向，tournament 选出 top 3
企业用户反馈
- Klarna：在大代码库中做发现与 review，识别静态分析遗漏的死代码
- CyberAgent：填补「单子 Agent」和「完整 Agent Team」之间的鸿沟，长时运行仍保持可见性
八、案例：Bun 从 Zig 迁移到 Rust（Workflow 极限压力测试）
官方用 Jarred Sumner 的 Bun 迁移作为规模示例（Jarred 后续会有更详细文章）：
代码语言：JavaScript
约 75 万行 RustWorkflow 阶段（概述）：
- 映射 Zig 每个 struct field 对应的 Rust lifetime
- 并行移植每个
.zig→.rs - Fix loop 直到 build + test 全部通过
- 通宵 workflow 找出不必要的数据拷贝，每个优化单独开 PR
重要免责声明：这是极端高压测试案例，不代表日常需求都应 Workflow 化。但它证明了编排层能把「季度级迁移」压缩到「天级」——前提是你有成熟的验证与 review 流程。
九、何时不要使用 Dynamic Workflows？
官方态度很明确：
不要使用 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（验证脚本、Gotchas）
十二、与系列文章的衔接
| 你已读 | 本文补充 |
|---|---|
| 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 系统」。
记住四句话：
- 复杂、长时、对抗性任务才值得开启 Workflow
- 六种模式（扇出、对抗、锦标赛、循环等）是提示词中的杠杆
- Token 成本高，先从小任务试水，设定预算，能够保存复用
- Skills 沉淀质量，Workflow 放大算力——两者配合使用，而非二选一
静态流水线并未消亡，但 2026 年的上限，属于那些能够驾驭动态 Harness 的指挥官。
资料来源
- Anthropic《A harness for every task: dynamic workflows in Claude Code》
- Anthropic《Introducing dynamic workflows in Claude Code》
- Claude Code Workflows 文档
- Bun 迁移讨论（Jarred Sumner）
- 上一篇：《Claude Code Skills 九分类》
Bun 迁移等案例来自 Anthropic 官方披露，效果与团队工程成熟度强相关；Workflow Token 消耗因任务差异很大，请以控制台实际用量为准。
