大多数 Claude Code 用户仍然手动编写工作流程。他们串联提示词，复制输出，粘贴到下一个提示词中，修复错误，然后重复。
10 个构建者中有 9 个从未尝试过动态工作流程，即使它们已经在两周前发布。
他们编写 50 个提示词，而一个工作流程就能完成。以下是 14 步路线图以及 Anthropic 自己的工程师实际使用的 6 种模式——用于迁移、研究、排序、根因分析、分类和评估。
关注我的 Substack 以获取最新 AI 前沿资讯：
动态工作流程于 2026 年 5 月 28 日在 Claude Code 中发布。默认的 Claude Code 框架是为编码而构建的——这对于大多数编码任务来说效果很好。但对于某些类型的工作，单个上下文窗口开始失效：长时间运行、大规模并行、高度结构化或对抗性的任务。
对于这些情况，Anthropic 过去常常自己构建自定义框架（研究、代码审查、Agent 团队）。借助动态工作流程，Claude 会即时为你编写该框架，根据你的任务用 JavaScript 定制。
14 步。6 种模式。一个工作流程，而非五十个提示词。
第一部分 · 心智模型
01. 工作流程是 Claude 编写的框架。
默认的 Claude Code 框架让 Claude 在同一个上下文窗口中进行规划和执行。对于大多数编码工作来说，这很棒。但对于长时间运行、并行或对抗性的工作，它会失效。
动态工作流程是 Claude 为任务编写自己的自定义框架——一个包含几个特殊函数的 JavaScript 文件，用于生成和协调子 Agent，再加上标准的 JavaScript（Math、JSON、Array）来处理它们之间流动的数据。
默认框架无法提供的三样东西：
- 每个 Agent 的隔离性。 每个子 Agent 都有自己的上下文窗口和一个集中的目标。没有交叉污染。
- 每个 Agent 的模型选择。 工作流程为每个子 Agent 选择使用的模型——Opus 用于困难推理，Haiku 用于低成本探索，Sonnet 用于中间任务。
- 每个 Agent 的隔离级别。 Worktree（隔离的 git 检出）或远程（无检出）。工作流程决定每个 Agent 需要什么。
通过直接询问 Claude（“创建一个工作流程，用于……”）或使用触发词 ultracode 来启动一个工作流程。如果工作流程被中断——用户操作、终端退出——恢复会话会从上次中断的地方继续。
02. 工作流程解决的 3 种失败模式。
要知道何时工作流程是合适的工具，你必须了解它修复了什么。Claude 在单个上下文窗口中处理复杂任务的时间越长，就越容易受到三种特定失败模式的影响——这些模式在 Anthropic 的发布文章中直接命名：
- Agent 懒惰 - Claude 在完成复杂的多部分任务之前就停止，并在取得部分进展后宣布完成。处理安全审查中的 50 个项目中的 20 个，然后称其余部分“已处理”。
- 自我偏好偏差 - 当被要求根据标准验证或评判自己的结果时，Claude 偏爱自己的结果。一个有利害关系的验证者不可能成为公正的验证者。
- 目标漂移 - 在多次交互后，特别是经过压缩后，对原始目标的保真度逐渐丧失。每次总结步骤都是有损的。“不要做 X”的约束在第 47 轮交互时悄然消失。
一个工作流程从结构上解决了所有这三个问题：独立的 Claude 实例，拥有各自的上下文、集中的目标和隔离的状态。如果你的任务遭受这些模式中的任何一个——那就是使用工作流程的信号。
03. 静态工作流程与动态工作流程。
你可能已经使用 Claude Agent SDK 或 claude -p 构建了静态工作流程——协调多个 Claude Code 实例。
- 静态工作流程是通用的：编写一次以处理每个边缘情况。它们有效，但必须保守。
- 动态工作流程则不同：Claude 为这个任务编写这个工作流程。框架是量身定制的。以下是同一问题用两种方式处理的情况：
动态版本胜出的原因不在于搜索步骤——两者都能搜索。
而在于工作流程能够根据你的上下文塑造自身：读取你的计费代码，根据实际的新提供商文档检查每个功能，根据你的交易量定价，并针对自身正在形成的答案运行一次对抗性的“为何不迁移”检查。
静态框架无法做到这一点，因为它不知道你的代码存在。
04. 核心 API。agent()、parallel()、pipeline()。
三个函数完成了工作流程中的大部分工作。了解它们就足以阅读 Claude 为你编写的任何工作流程，并在你想要特定形状时引导 Claude。
parallel() 是一个屏障：它分叉出去，然后等待所有任务完成后再返回。pipeline() 是流式的：每个项目独立地流经每个阶段。
根据问题来选择：我是否需要所有结果才能进行下一步？ 是 → 使用 parallel。否 → 使用 pipeline（更便宜，整体更快）。
05. 分类并执行。在执行之前路由工作。
一个分类 Agent 决定任务的类型，然后工作流程根据答案将任务路由到不同的 Agent 或行为。或者，一个分类器在最后运行，将原始输出分类到不同的桶中，以供后续步骤使用。
这种模式在以下情况下发挥作用：
- 任务是异构的——不同的子类型需要不同的处理方式。
- 你只想在复杂性需要的地方使用昂贵的模型（在便宜的模型上运行分类器，然后仅在需要时路由到 Opus）。
- 工作的分解本身就不简单，并且受益于由模型来决定其形状。
示例：“解释 auth 模块是如何工作的。”一个分类子 Agent 首先读取代码库，评估复杂性，然后将实际的解释任务路由到 Sonnet（用于 10 个文件的模块）或 Opus（用于 100 个文件的模块）。在理解工作之后，为任务选择合适的模型。
06. 分叉并综合。许多小步骤，一个合并的结果。
将一个任务拆分成许多更小的步骤。在每个步骤上并行运行一个 Agent。将结果综合成一个答案。
综合步骤是一个屏障——它等待每个分叉的 Agent，然后合并它们的结构化输出。
为什么这种模式在实践中占主导地位：它解决了单上下文工作中“一次性处理太多事情”的失败。每个子 Agent 只看到它自己的部分。编排者永远不会被 50 个不相关的细节分心。
每个步骤都受益于自己干净的窗口，这样它们就不会交叉污染。
在以下情况下使用此模式：
- 你有一个清晰可枚举的工作项列表（50 个文件、200 个端点、100 个审查）。
- 每个项目都是独立的——没有项目需要另一个项目的输出才能开始。
- 你希望在最后得到一个单一的合并答案，而不是一堆零散的报告。
1// 分叉：每个文件一个 Agent。屏障：等待所有完成。2const reviews = await parallel(3 files.map(file => () => agent(4 `审查 ${file} 的安全问题`,5 { model: "haiku", schema: IssueList }6 ))7)89// 综合：一个 Opus Agent 合并所有内容。10const report = await agent(11 `将这些审查合并成一个按优先级排序的报告：\n${JSON.stringify(reviews)}`,12 { model: "opus" }13)
07. 对抗性验证
这是对自我偏好偏差的结构性修复。对于每个生成的 Agent，运行一个独立的生成 Agent，根据标准对抗性地验证其输出。验证者从未见过原始工作；它无法偏袒它。
这种模式在以下情况下最为重要：
- 声明检查 - 报告中每个事实性声明都有自己的验证子 Agent，对照原始来源进行检查。
- 代码审查 - 作者 Agent 编写修复，审查者 Agent（独立的上下文）审查它。永远不是同一个 Claude 评判自己。
- 质量门禁 - 在任何产物发布之前，一个对抗者试图找到针对它的最薄弱案例。如果对抗者找不到，你就发布。
配对规则：验证者应该只知道标准和产物，而不知道是谁产生的。否则，自我偏好会通过提示词中的线索悄悄回来。
08. 生成并过滤。
在一个主题上生成一些想法，然后通过标准或验证来过滤它们。去重。只返回最高质量、经过测试的想法。
这种模式在以下方面表现出色：
- 头脑风暴 - 30 个产品名称，然后一个验证者剔除陈词滥调、商标冲突和发音不佳的名称。你只看到 3 个。
- 假设生成 - 针对一个问题的 5 种不同方法，然后每种方法都根据你的约束条件进行评分。胜出者是实至名归的。
- 解决方案设计 - 针对一个问题的 5 种不同方法，然后每种方法都根据你的约束条件进行评分。胜出者是实至名归的。
这与要求 Claude 给出“最佳答案”相反。要求给出最佳答案会使 Claude 过早做出承诺。生成并过滤使 Claude 延迟承诺，直到每个选项都经过挑战。
09. 锦标赛。成对比较优于绝对评分。
不是分配工作，而是让 Agent 在任务上竞争。生成 N 个 Agent，每个 Agent 使用不同的方法尝试相同的任务，然后以成对的方式评判结果，直到一个胜出。
比较性判断比绝对评分更可靠——尤其是在基于品味的任务中。
为什么这比按分数排序更好：尝试在一个提示词中对 1,000 个项目进行排序在两个层面上都会失败——质量下降，而且它无法容纳在上下文中。锦标赛将分组赛程分散到全新的 Agent 上，每个 Agent 只比较两个项目。
分组赛程本身存在于确定性的循环代码中，而不是在上下文中。每次比较都是快速、公平且隔离的。同样的想法也适用于基于品味的排名：设计选择、候选人筛选、内容优先级排序。
10. 循环直到完成。
对于工作量未知的任务，循环生成 Agent，直到满足停止条件——没有新发现、日志中没有更多错误、理论得到验证——而不是运行固定数量的轮次。
这种模式是对“继续直到真正完成”的答案：
- 调试不稳定测试 - 重现、形成理论、测试它们，直到一个理论成立。
- 寻找 Bug - 持续寻找 Bug，直到一次完整的遍历返回零个 Bug。
- 挖掘模式 - 聚类、识别规则，直到没有新的聚类出现。
将此模式与 /goal 配对以设置硬性完成要求（“在找到一个可行的理论之前不要停止”），并与 /loop 配对，如果你希望整个工作流程本身按计划重复运行。
分组赛程和停止条件存在于代码中；只有活跃的迭代保持在上下文中。
11. 为实际用例组合模式。一个工作流程，多种模式。
这 6 种模式很少单独出现。一个真实的工作流程会组合使用 2-4 种模式。下面的矩阵将 Anthropic 发布文章中的每个用例与其倾向于使用的模式配对：
- 迁移和重构。 分叉（在 worktree 中，每个调用点/失败测试对应一个 Agent）→ 对抗性验证（一个独立的 Agent 审查每个修复）→ 循环直到完成。这是 Anthropic 用来将 Bun 从 Zig 重写为 Rust 的模式。
- 深度研究（
/deep-research技能）。分叉（并行网络搜索）→ 对抗性验证（每个声明独立验证）→ 综合（一份带有引用的报告）。 - 对草稿进行深度验证。 识别所有事实性声明（一个 Agent）→ 分叉（每个声明一个验证者，每个 Agent 对照来源检查）→ 元验证者（检查验证者的来源是否高质量）。
- 对 1,000 多个项目进行排序。 锦标赛（步骤 5-9）——成对比较、桶排名或分组赛程。比较性判断，永远不要绝对评分。
- 记忆和规则遵守。 每个规则一个验证者（分叉）→ 怀疑论者角色审查规则本身以避免误报。
- 根因调查。 从不相干的证据中生成理论（不同的 Agent 读取日志、文件、数据）→ 为每个理论设置一个验证者和反驳者小组 → 循环直到一个理论幸存。
- 大规模分类。 分类并执行 → 对现有工单去重 → 尝试修复或升级。与
/loop配对以实现持续分类。 - 探索和品味（设计、命名、UI 选择）。生成并过滤（5-20 个选项）→ 使用标准进行锦标赛 → 排名或选择。
- 轻量级评估。 在 worktree 中运行候选方案 → 比较 Agent 根据标准评分 → 优化并重新评分。与锦标赛形状相同，但用于评分，而非排名。
内化这些模式的正确方法是：确定你当前任务在哪种失败模式下失败，然后选择从结构上防止该失败的模式。
漂移 → 分叉。自我偏好 → 对抗性验证。开放式 → 循环直到完成。难以评分 → 锦标赛。
12. 与 /goal、/loop 和 Token 预算配合使用。
工作流程可能很昂贵。三个控制项将它们从“很酷但昂贵”转变为“我可以无人值守运行的工具”。
- `/goal` 设置一个硬性完成要求。将其与循环模式配对：“在找到一个可行的理论之前不要停止。” 没有
/goal，工作流程会在一个软完成点停止。有了/goal，它会迭代直到满足实际的结束条件。 - `/loop` 按计划重复运行整个工作流程。用于你想要持续运行的工作流程——分类、每周研究更新、定期验证。
- 明确的 Token 预算。 在提示词中告诉 Claude：“使用 10k 个 Token。” 这为工作流程运行设置了一个上限。没有上限，一个雄心勃勃的工作流程可能会膨胀到你预期的 5-10 倍 Token 量。
1> ultracode 对这个假设进行快速对抗性审查：2 "迁移到 Postgres 消除了我们的分片再平衡。"3 使用 5k 个 Token。/goal 在找到反例或三个独立确认之前不要停止。
直接引用 Claude Code 团队的话：“最佳实践仍在发展中。动态工作流程通常使用更多 Token，因此请仔细考虑何时以及如何使用它们。” 大多数传统的编码任务不需要一个由 5 个审查者组成的小组。
问问自己：这个任务真的需要更多计算吗？如果一个常规的 Claude Code 会话能在五分钟内完成它，你就不需要工作流程。
13. 对不受信任的输入使用隔离模式。
任何读取不受信任的公共内容的工作流程——支持工单、Bug 报告、用户反馈、抓取的数据——都需要假设该内容可能包含提示注入。
修复方法：隔离。禁止读取不受信任内容的 Agent 采取任何高权限操作。执行操作的 Agent 是独立的，不接触原始内容。
任何处理用户提交内容（支持工单、Bug 报告、客户反馈、社交媒体）、抓取公共网页或针对第三方 API 输出运行的工作流程。
如果输入不是由你或可信的队友编写的，请隔离它。 一个 30 行的只读读取 Agent 几乎不花费任何成本，并消除了整个类别的提示注入风险。
14. 保存工作流程。将它们作为技能发布。
一旦工作流程有效，保存它：在工作流程菜单中按 s。保存的工作流程会进入 ~/.claude/workflows。从那里你有两条路径：
- 保持本地 - 在你自己的项目中重复使用它。
- 作为技能发布 - 将 JavaScript 文件打包到技能文件夹中，在
SKILL.md中引用它，任何安装该技能的人都会运行相同的工作流程。
一个值得了解的实际细微差别：当你将工作流程打包成技能时，提示 Claude 将工作流程视为模板，而不是逐字运行的脚本。
这为 Claude 留下了空间，使其能够根据具体任务调整工作流程的形状，同时保持整体结构不变。对于像“深度验证”或“分类”这样需要根据用例灵活调整的工作流程尤其有用。
在工作流程上浪费 Token 的错误
- 在常规 Claude Code 会话就能完成时使用工作流程。 大多数传统编码任务不需要一个由 5 个审查者组成的小组。
- 没有 Token 预算。 没有明确的上限，雄心勃勃的工作流程会膨胀到你预期的 5-10 倍。
- 一个 Agent 同时负责工作和验证。 自我偏好偏差使验证者偏袒工作者。它们必须是独立的。
- 将 parallel() 和 pipeline() 视为可互换。 屏障很重要——
parallel等待所有，pipeline流式处理。 - 在循环模式中跳过 /goal。 工作流程在第一个软完成点提前停止。
/goal强制硬性完成。 - 让不受信任的内容到达执行者。 一旦你处理任何用户提交的内容，隔离就不是可选项。
- 使用绝对分数进行排序。 比较性判断更可靠。使用锦标赛。
- 从不保存有效的工作流程。 每周重新提示相同的形状。使用
s保存，作为技能发布。
