如何在 Claude Code 中管理好 Dynamic Workflows：Anthropic 工程师实操的 6 种模式和 14 个核心步骤
Claude Code 用户仍在手动编写工作流。他们把 prompts 链接起来，复制输出，粘贴到下一个 prompt，修复错误，然后重复这个过程。
十个开发者中有九个从未尝试过 Dynamic Workflows，尽管这个功能两周前就已经发布了。他们写出 50 个 prompts，而实际上一个工作流就能完成所有工作。
这就是 Anthropic 工程师实际使用的 14 步路线图和 6 种模式——用于代码迁移、研究分析、批量排序、根因调查、分诊处理和质量评估。
什么是 Dynamic Workflows？
Dynamic Workflows 于 2026 年 5 月 28 日在 Claude Code 中正式发布。默认的 Claude Code 运行环境是为编码而构建的——对于大多数编码任务来说，这已经运作良好。但有一类工作会让单个上下文窗口开始崩溃：长时间运行、大规模并行、高度结构化或对抗性任务。
对于这些场景，Anthropic 以前会为 Research、Code Review 和 agent 团队构建自定义运行环境。有了 Dynamic Workflows，Claude 可以动态为你编写这个运行环境——针对你的任务量身定制，用 JavaScript 实现。
Dynamic Workflows 能做到的三件事
- 每个 agent 隔离：每个子 agent 都有自己独立的上下文窗口，带着一个专注的目标。没有交叉污染。
- 每个 agent 可选模型：工作流决定每个 agent 使用哪个模型——Opus 用于困难推理，Haiku 用于便宜的探索，Sonnet 用于中间地带。
- 每个 agent 隔离级别：Worktree（隔离的 git checkout）或 remote（无 checkout）。工作流决定每个 agent 需要什么。
只需向 Claude 直接提出请求（“创建一个工作流来……”）或使用触发词 ultracode 即可启动。如果工作流被中断——用户操作或终端退出——恢复会话会从中断处继续。
Part 1：思维模型
01 | 工作流是 Claude 写的运行环境
默认的 Claude Code 运行环境是让 Claude 在同一个上下文窗口中规划和执行。对于大多数编码工作来说，这很棒。但对于长时间运行、并行或对抗性工作，它就会崩溃。
Dynamic Workflow 是 Claude 为当前任务编写的自定义运行环境——一个 JavaScript 文件，包含几个特殊的函数来生成和协调子 agent，以及标准 JavaScript（Math、JSON、Array）来处理它们之间流动的数据。
02 | 工作流解决的 3 种失败模式
要了解何时使用工作流，你必须知道它能解决什么问题。Claude 在单个上下文窗口中处理复杂任务的时间越长，就越容易受到三种特定失败模式的影响——这些名称直接来自 Anthropic 的发布文档：
- Agentic laziness（代理惰性）：Claude 在完成复杂的、多部分任务之前就停下来，在部分进展后就宣布完成。处理了安全审查中的 20 个项目中的 20 个，然后宣称其余的已经“处理好了”。
- Self-preferential bias（自我偏好偏见）：当被要求根据评分标准验证或评判自己的结果时，Claude 倾向于偏好自己的结果。一个有利害关系的验证者不可能是公正的验证者。
- Goal drift（目标漂移）：在多轮对话中，尤其是压缩之后，对原始目标的保真度逐渐丧失。每次总结步骤都是有损的。“不要做 X”的约束在第 47 轮时悄然消失。
工作流通过结构化方式解决所有这三个问题：独立的 Claude，各自有自己的上下文、专注的目标和隔离的状态。如果你的任务存在任何这些模式——这就是使用工作流的信号。
03 | 静态 vs 动态工作流
你可能已经使用 Claude Agent SDK 或 claude -p 构建过静态工作流——协调多个 Claude Code 实例。
- 静态工作流是通用型的：编写一次来处理所有边缘情况。它们能工作，但必须保守。
- 动态工作流则不同：Claude 为这个任务编写这个工作流。运行环境是量身定制的。
动态版本获胜的原因不是搜索步骤——两者都可以搜索。关键在于工作流能够围绕你的上下文来塑造自己：读取你的计费代码，根据实际的新的提供商文档检查每个功能，按照你的交易量定价，并对自己的初步答案运行一个“为什么不要迁移”的对抗性检验。
静态运行环境做不到这一点，因为它不知道你的代码存在。
04 | 核心 API：agent()、parallel()、pipeline()
工作流中三个函数做了大部分工作。了解它们就足够阅读 Claude 为你写的任何工作流，并在你想要特定形状时引导 Claude。
parallel()是一个屏障：它向外扩散，然后等待所有结果后再返回。pipeline()是流式的：每个项目独立地流经每个阶段。
根据问题选择：需要所有结果后才能做下一件事吗？是的 → parallel。否 → pipeline（更便宜，整体更快）。
6 种核心模式
05 | 分类-执行（Classify-and-act）
分类 agent 决定任务类型，然后工作流根据答案路由到不同的 agent 或行为。或者分类器在最后运行，将原始输出分拣到 buckets 中，供下一步使用。
这个模式适用的场景：
- 任务异构——不同的子类型需要不同的处理方式
- 你只想在复杂度需要的地方花费昂贵模型的资源（分类用便宜的模型，然后只在需要时才路由到 Opus）
- 工作分解本身不简单，需要模型来决定形状
例如：“解释 auth 模块是如何工作的。”一个分类子 agent 先读取代码库，评估复杂度，然后将实际解释任务路由到 Sonnet（10 个文件的模块）或 Opus（100 个文件的模块）。合适规模的模型，在工作被理解后决定。
06 | 扇出-综合（Fan-out-and-synthesize）
将任务分割成许多更小的步骤。并行运行一个 agent 在每个步骤上。将结果综合成一个答案。
综合步骤是一个屏障——它等待每个扇出 agent，然后将它们的结构化输出合并。
为什么这个模式在实践中占主导地位：它解决了单上下文工作“同时处理太多事情”的失败。每个子 agent 只看到它的部分。编排者从不会被 50 个不相关的细节分散注意力。每个步骤受益于自己干净的窗口，所以它们不会交叉污染。
使用这个模式的场景：
- 你有一个明确可枚举的工作项列表（50 个文件、200 个端点、100 个审查）
- 每个项目是独立的——没有项目需要另一个的输出来开始
- 你想要一个最终的综合答案，而不是一堆部分报告
// 扇出：每个文件一个 agent。屏障：等待所有。
const reviews = await parallel(
files.map(file => () => agent(
`Review ${file} for security issues`,
{ model: "haiku", schema: IssueList }
))
)
// 综合：一个 Opus agent 合并所有内容。
const report = await agent(
`Merge these reviews into one prioritized report:\n${JSON.stringify(reviews)}`,
{ model: "opus" }
)
07 | 对抗验证（Adversarial verification）
这是自我偏好偏见的结构性修复。对于每个生成的 agent，运行一个单独的 agent 来对抗性地验证其输出是否符合评分标准。验证者从未见过原始工作；它无法偏好它。
这个模式最重要的场景：
- 声明检查：报告中每个事实陈述都有自己的验证子 agent，根据原始来源进行检查。
- 代码审查：作者 agent 编写修复，审查者 agent（独立的上下文）审查它。同一个 Claude 永远不要评判自己的工作。
- 质量门控：在任何产物发布之前，一个对手试图找到最弱的反对案例。如果对手找不到，你就发布。
配对规则：验证者应该只知道评分标准和产物，而不知道是谁产生的。否则自我偏好会通过提示悄悄爬回来。
08 | 生成-过滤（Generate-and-filter）
围绕一个主题生成大量想法，然后通过评分标准或验证来过滤它们。去重重复项。只返回经过验证的最高质量的想法。
这个模式擅长的场景：
- 头脑风暴：30 个产品名称，然后验证者杀死陈词滥调、商标冲突和弱发音。你看到 3 个。
- 假设生成：5 种不同的解决问题的方法，然后每个根据你的约束条件评分。胜者当之无愧。
- 解决方案设计：同上，胜者经过了充分验证。
这与要求 Claude “给出最佳答案”相反。要求最佳答案会让 Claude 过早承诺。生成-过滤让 Claude 晚承诺——在每个选项都受到挑战之后。
09 | 淘汰赛（Tournament）
不是分割工作，而是让 agent 竞争。生成 N 个 agent，每个用不同的方法尝试相同的任务，然后在成对比较中评判结果，直到一个获胜。
比较判断比绝对评分更可靠——尤其是对于基于品味的工作。
为什么这比按分数排序更好：试图在一个 prompt 中对 1000 个项目排序会在两个方面失败——质量下降，而且它不会塞进上下文。淘汰赛将 bracket 分割到各个新鲜的 agent，每个只比较两个项目。
bracket 本身存在于确定性循环代码中，而不是在上下文中。每次比较都是快速、公平和隔离的。同样的想法也适用于基于品味的排名：设计选择、候选人选择、内容优先级排序。
10 | 循环直到完成（Loop until done）
对于工作量未知的任务，循环生成 agent 直到满足停止条件——没有新发现、日志中没有更多错误、理论得到验证——而不是运行固定数量的轮次。
这个模式是“继续直到实际完成”的答案：
- ** flaky 测试调试**：复现、形成理论、测试它们，直到一个理论成立。
- ** bug 搜索**：继续找 bug，直到一次完整扫描返回零。
- 模式挖掘：聚类、识别规则，直到没有新的聚类出现。
将此模式与 /goal 配对以设置硬性完成要求（“直到一个理论有效才停止”），如果你想让整个工作流按循环计划运行，则与 /loop 配对。
Bracket 和停止条件存在于代码中；只有活跃的迭代留在上下文中。
11 | 组合模式用于真实用例
这 6 种模式很少单独出现。一个真实的工作流组合了 2-4 种。以下矩阵将 Anthropic 发布文档中的每个用例与它通常使用的模式配对：
| 用例 | 使用的模式 |
|---|---|
| 代码迁移和重构 | 扇出（每个 callsite/失败测试一个 agent，在 worktree 中）→ 对抗验证（独立的 agent 审查每个修复）→ 循环直到完成。Anthropic 用这个模式将 Bun 从 Zig 重写到 Rust。 |
| 深度研究（/deep-research skill） | 扇出（并行网页搜索）→ 对抗验证（每个声明独立验证）→ 综合（一份带引用的报告） |
| 草案的深度验证 | 识别所有事实声明（一个 agent）→ 扇出（每个声明一个验证者，每个 agent 根据来源检查）→ 元验证者（检查验证者的来源质量） |
| 1000+ 项目排序 | 淘汰赛——成对比较、桶排名或 bracket。比较判断，绝不是绝对评分 |
| 记忆和规则遵守 | 每条规则一个验证者（扇出）→ 怀疑者角色审查规则本身以避免误报 |
| 根因调查 | 从不相交的证据生成理论（不同的 agent 读取日志、文件、数据）→ 每个理论的验证者和反驳者小组 → 循环直到一个存活 |
| 大规模分诊 | 分类-执行 → 与现有工单去重 → 要么尝试修复，要么升级。与 /loop 配对用于持续分诊 |
| 探索和品味（设计、命名、UI 选择） | 生成-过滤（5-20 个选项）→ 带评分标准的淘汰赛 → 排名或选择 |
| 轻量级评估 | 在 worktree 中运行候选者 → 比较 agent 根据评分标准评分 → 完善和重新评分。与淘汰赛相同的形状，但用于评分，而不是排名 |
记住这些的正确方式：识别你的当前任务正在哪种失败模式下失败，然后选择结构性地防止它的模式。
- 漂移 → 扇出
- 自我偏好 → 对抗验证
- 开放式 → 循环直到完成
- 难以评分 → 淘汰赛
12 | 配合 /goal、/loop 和 token 预算
工作流可能很昂贵。三个控制将它们从“酷但昂贵”变成“我可以无人值守运行的工具”。
- /goal 设置硬性完成要求。与循环模式配对：“直到一个理论有效才停止。”没有 /goal，工作流会在软性完成点停止。有了 /goal，它会迭代直到实际的结束条件满足。
- /loop 按循环计划运行整个工作流。用于你希望持续运行的工作流——分诊、每周研究更新、重复验证。
- 明确的 token 预算：在 prompt 中告诉 Claude：“使用 10k tokens。”这为工作流运行设置上限。没有上限，一个有雄心的工作流可能膨胀到你预期的 5-10 倍。
> ultracode quick adversarial review of this assumption:
"moving to Postgres eliminates our shard rebalancing."
Use 5k tokens. /goal don't stop until you have either
a counterexample or three independent confirmations.
引用 Claude Code 团队的原话：“最佳实践仍在发展中。Dynamic Workflows 通常使用更多 tokens，所以要仔细考虑何时以及如何使用它们。”大多数传统编码任务不需要 5 个审查者组成的小组。
问问自己：这项任务真的需要更多计算吗？如果常规的 Claude Code 会话能在五分钟内完成它，你就不需要工作流。
13 | 隔离模式处理不可信输入
任何读取不可信公开内容的工作流——支持工单、bug 报告、用户反馈、抓取的数据——需要假设该内容可能包含 prompt 注入。
解决方案：隔离。禁止读取不可信内容的 agent 执行任何高权限操作。单独的 agent，与原始内容没有接触，执行操作。
任何处理用户提交内容（支持工单、bug 报告、客户反馈、社交媒体）、抓取公共网页、或针对第三方 API 输出运行的工作流。
如果输入不是由你或可信赖的队友写的，就隔离它。一个 30 行的只读读取者 agent 几乎不花什么钱，却能消除一整类 prompt 注入风险。
14 | 保存工作流为 Skills
一旦工作流运行成功，就保存它：在工作流菜单中按 s。保存的工作流会到 ~/.claude/workflows。从那里你有两条路径：
- 保持本地：在你的各个项目之间重用。
- 发布为 Skill：将 JavaScript 文件打包到 Skill 文件夹中，在 SKILL.md 中引用它，任何安装该 Skill 的人都可以运行相同的工作流。
一个值得知道的实用细节：当你将工作流打包成 Skill 时，提示 Claude 将工作流视为模板，而不是逐字运行的脚本。
这为 Claude 留下了调整工作流形状以适应特定任务的空间，同时保持整体结构完整。对于“深度验证”或“分诊”等需要每个用例灵活调整的工作流特别有用。
常见错误：这些操作会浪费 tokens
- 在常规 Claude Code 会话可以完成时使用工作流。大多数传统编码任务不需要 5 个审查者组成的小组。
- 没有 token 预算。没有明确上限，一个有雄心的工作流会膨胀到预期的 5-10 倍。
- 一个 agent 同时做工作和验证。自我偏好偏见使验证者偏向工作者。它们必须是分开的。
- 将 parallel() 和 pipeline() 视为可互换。屏障很重要——parallel 等待所有，pipeline 流式处理。
- 在循环模式上跳过 /goal。工作流会在第一个软性完成点停止。/goal 强制硬性完成。
- 让不可信内容接触执行者。一旦你处理任何用户提交的内容，隔离就不是可选项。
- 用绝对分数排序。比较判断更可靠。使用淘汰赛。
- 从不保存运行良好的工作流。每周重复相同形状的 prompt。将它保存为 Skill。
写在最后
Dynamic Workflows 的出现，本质上是在解决一个核心矛盾：当 AI 需要处理超出单个上下文窗口限制的复杂任务时，默认的“规划-执行一体化”模式会遇到瓶颈。
Anthropic 工程师分享的这 6 种模式——分类-执行、扇出-综合、对抗验证、生成-过滤、淘汰赛、循环直到完成——并不是要取代你对任务的思考，而是要给你的思考提供一个结构化的执行框架。
关键在于识别你当前任务正在经历的失败模式：是漂移？是自我偏好？是开放式工作难以判断完成？找到对应的模式，然后让工作流来保证执行的一致性。
最后，记住 Claude Code 团队的那句话：Best practices are still developing。Dynamic Workflows 仍在快速迭代中，最好的使用方法可能就在你的下一次实践中被发现。
