掌握 Claude Code 动态工作流：Anthropic 工程师实际使用的 6 种模式和 14 个步骤

掌握 Claude Code 动态工作流：Anthropic 工程师实际使用的 6 种模式和 14 个步骤 掌握 Claude Code 动态工作流：Anthropic 工程师实际使用的 6 种模式和 14 个步骤 Modified June 5 这是修复 self preferential bias 的结构性方案。对每个启动出来的 agent，再启动一个独立 agent，根据 rubric 对它的输出做对抗性验证。verifier 没看过原始工作，因此不会偏袒它。 这个模式最重要的场景： • Claim checking。 报告里的每个事实陈述都交给自己的 verifier subagent，对照原始来源检查。 • Code review。 author agent 写修复，reviewer agent（独立 context）审查它。永远不要让同一个 Claude 评判自己。 • Quality gates。 任何 artifact 发布前，先让一个 adversary 找出反对它的最强理由。如果 adversary 找不到，再发布。配对规则： verifier 应该只知道 rubric 和 artifact，不知道是谁产出的。否则 self preference 会通过 prompt 里的暗示重新渗进来。 08. Generate and filter 围绕一个主题生成多个想法，然后按 rubric 或验证结果进行过滤。去掉重复项。只返回质量最高、经过测试的想法。 这个模式特别适合： • Brainstorming。 先生成 30 个产品名，再让 verifier 淘汰陈词滥调、商标冲突和读音弱的选项。你最后只看到 3 个。 • Hypothesis generation。 针对一个问题提出 5 种不同方案，再按你的约束逐个打分。胜出的方案是经受过挑战的。 • Solution design。 针对一个问题提出 5 种不同方案，再按你的约束逐个打分。胜出的方案是经受过挑战的。 这和直接问 Claude “最好的答案是什么”完全相反。要求最好的答案，会让 Claude 过早下注。Generate and filter 会让 Claude 在每个选项都被挑战之后，再晚一点做承诺。 09. Tournament：成对比较优于绝对评分 不要把工作拆开，而是让 agents 在同一个任务上竞争。启动 N 个 agent，让它们用不同方法尝试同一任务，然后通过成对比较判断结果，直到决出胜者。 比较式判断比绝对评分更可靠，尤其适合偏品味的工作。 为什么它优于按分数排序： 试图在一个 prompt 里给 1,000 个 item 排序，会在两方面失败：质量下降，而且 context 装不下。tournament 会把 bracket 分摊到新的 agents 中，每个 agent 只比较两个 item。 bracket 本身存在确定性的 loop code 里，而不是 context 里。每次比较都很快、公平且隔离。同样的思路也适用于偏品味的排序：设计选择、候选人筛选、内容优先级。 10. Loop until done 对于工作量未知的任务，不要跑固定次数，而是循环启动 agents，直到满足停止条件：没有新发现、日志里没有更多错误、理论得到验证。 这是对“继续做，直到真的完成”的回答： • Flaky test debugging。 复现、形成理论、测试理论，直到某个理论成立。 • Bug hunting。 持续找 bug，直到完整一轮返回 0 个问题。 • Mining for patterns。 聚类、识别规则，直到不再出现新 cluster。 把这个模式和 /goal 配对，可以设定硬性完成要求，比如“不要停，直到有一个理论成立”。如果你希望整个 workflow 定期重复运行，可以配合 /loop。bracket 和停止条件存在代码里，只有当前活跃 iteration 留在 context 中。 11. 为真实用例组合模式：一个 workflow，多种模式 这 6 种模式很少单独出现。真实 workflow 通常会组合 2 到 4 种。下面这个矩阵，把 Anthropic 发布文章里的每个 use case 和它倾向使用的模式对应起来： • Migrations and refactors。 Fan out（每个 callsite 或失败测试一个 worktree agent）→ adversarial verification（独立 agent 审查每个修复）→ loop until done。这就是 Anthropic 用来把 Bun 从 Zig 重写到 Rust 的模式。 • Deep research（/deep research skill）。Fan out（并行 web searches）→ adversarial verification（每个 claim 独立验证）→ synthesize（一个带引用的报告）。 • Deep verification of a draft。 识别所有事实 claim（一个 agent）→ fan out（每个 claim 一个 verifier，每个 agent 对照来源检查）→ meta verifier（检查 verifier 使用的来源是否高质量）。 • Sorting 1,000+ items。 Tournament（步骤 5 9）：成对比较、bucket rank 或 bracket。用比较式判断，不用绝对评分。 • Memory and rule adherence。 每条规则一个 verifier（fan out）→ skeptic persona 审查规则本身，避免 false positives。 • Root cause investigation。 从互不重叠的证据生成理论（不同 agents 读取日志、文件、数据）→ 每个理论都有一组 verifiers 和 refuters → loop until one survives。 • Triage at scale。 Classify and act → 与现有 tickets 去重 → 尝试修复或升级处理。配合 /loop 做连续分诊。 • Exploration and taste（设计、命名、UI choices）。Generate and filter（5 20 个选项）→ 带 rubric 的 tournament → 排名或选出一个。 • Lightweight evals。 在 worktree 中运行 candidate → comparison agents 按 rubric 评分 → refine and re grade。形态类似 tournament，但用于评分而不是排名。 真正掌握这些模式的方式：先识别当前任务正在哪种失败模式下失效，再选择能从结构上避免它的模式。 Drift → fan out。Self preference → adversarial verification。Open ended → loop until done。Hard to score → tournament。 12. 配合 /goal、/loop 和 token budgets workflow 可能很贵。三个控制项能把它从“很酷但昂贵”变成“可以无人值守运行的工具”。 • /goal 设置硬性完成要求。把它和 loop 模式配合使用：“不要停，直到有一个理论成立。” 没有 /goal 时，workflow 会在软性完成点停止。有了 /goal，它会迭代到真实结束条件满足为止。 • /loop 让整个 workflow 按固定周期运行。适合你希望持续运行的 workflow，例如 triage、每周研究更新、周期性验证。 • 明确 token budgets。 在 prompt 里告诉 Claude：“use 10k tokens.” 这会给 workflow run 设置上限。没有上限时，一个雄心勃勃的 workflow 可能膨胀到你预期 token 的 5 到 10 倍。 Code block Plain Text Copy 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 团队的话：“Best practices are still developing. Dynamic workflows often use more tokens, so think carefully about when and how to use them.” 大多数传统编码任务不需要 5 个 reviewer 组成的 panel。 问问自己：这个任务真的需要更多 compute 吗？如果常规 Claude Code session 能在五分钟内完成它，那你不需要 workflow。 13. 对不可信输入使用 quarantine 模式 任何读取不可信公开内容的 workflow，例如 support tickets、bug reports、user feedback、scraped data，都需要假设这些内容可能包含 prompt injection。 解决办法是：quarantine。禁止那些读取不可信内容的 agents 执行任何高权限操作。由另一组没有接触原始内容的独立 agents 执行动作。 任何处理用户提交内容（support tickets、bug reports、customer feedback、social media）、抓取公开网页，或处理第三方 API 输出的 workflow，都适用这个原则。 如果输入不是你或可信队友写的，就把它隔离起来。 一个 30 行的只读 reader agent 几乎没有成本，却能移除一整类 prompt injection 风险。 14. 保存 workflow，把它发布成 Skill 一旦某个 workflow 能用了，就保存它：在 workflow menu 里按 s。保存后的 workflow 会放到 /.claude/workflows。从这里开始，你有两条路： • 保留在本地。 在自己的项目中复用。 • 发布成 Skill。 把 JavaScript 文件打包到 Skill 文件夹里，在 SKILL.md 中引用它。任何安装这个 Skill 的人，都能运行同一个 workflow。 有一个实用细节值得知道：当你把 workflow 打包进 Skill 时，要提示 Claude 把这个 workflow 当成模板，而不是逐字执行的脚本。 这样 Claude 就有空间根据当前具体任务调整 workflow 的形状，同时保留整体结构。对于 “deep verification” 或 “triage” 这类需要按 use case 变化的 workflow 尤其有用。 浪费 workflow token 的常见错误 • 常规 Claude Code session 足够时仍然使用 workflow。 大多数传统编码任务不需要 5 个 reviewer 组成的 panel。 • 没有 token budget。 雄心勃勃的 workflow 如果没有明确上限，可能膨胀到你预期的 5 到 10 倍。 • 同一个 agent 同时做工作和验证。 Self preferential bias 会让 verifier 偏向 worker。它们必须分开。 • 把 parallel() 和 pipeline() 当成可互换。 barrier 很重要：parallel 等全部完成，pipeline 流式处理。 • 在 loop 模式中跳过 /goal。 workflow 会在第一个软性完成点提前停止。/goal 强制硬性完成。 • 让不可信内容接触 actor。 一旦处理任何用户提交内容，quarantine 就不是可选项。 • 用绝对分数排序。 比较式判断更可靠。使用 tournament。 • 从不保存已经有效的 workflow。 每周都重新 prompt 同一种结构。按 s 保存，把它发布成 Skill。 这是修复 self preferential bias 的结构性方案。对每个启动出来的 agent，再启动一个独立 agent，根据 rubric 对它的输出做对抗性验证。verifier 没看过原始工作，因此不会偏袒它。 这个模式最重要的场景： • Claim checking。 报告里的每个事实陈述都交给自己的 verifier subagent，对照原始来源检查。 • Code review。 author agent 写修复，reviewer agent（独立 context）审查它。永远不要让同一个 Claude 评判自己。 • Quality gates。 任何 artifact 发布前，先让一个 adversary 找出反对它的最强理由。如果 adversary 找不到，再发布。配对规则： verifier 应该只知道 rubric 和 artifact，不知道是谁产出的。否则 self preference 会通过 prompt 里的暗示重新渗进来。 08. Generate and filter 围绕一个主题生成多个想法，然后按 rubric 或验证结果进行过滤。去掉重复项。只返回质量最高、经过测试的想法。 这个模式特别适合： • Brainstorming。 先生成 30 个产品名，再让 verifier 淘汰陈词滥调、商标冲突和读音弱的选项。你最后只看到 3 个。 • Hypothesis generation。 针对一个问题提出 5 种不同方案，再按你的约束逐个打分。胜出的方案是经受过挑战的。 • Solution design。 针对一个问题提出 5 种不同方案，再按你的约束逐个打分。胜出的方案是经受过挑战的。 这和直接问 Claude “最好的答案是什么”完全相反。要求最好的答案，会让 Claude 过早下注。Generate and filter 会让 Claude 在每个选项都被挑战之后，再晚一点做承诺。 09. Tournament：成对比较优于绝对评分 不要把工作拆开，而是让 agents 在同一个任务上竞争。启动 N 个 agent，让它们用不同方法尝试同一任务，然后通过成对比较判断结果，直到决出胜者。 比较式判断比绝对评分更可靠，尤其适合偏品味的工作。 为什么它优于按分数排序： 试图在一个 prompt 里给 1,000 个 item 排序，会在两方面失败：质量下降，而且 context 装不下。tournament 会把 bracket 分摊到新的 agents 中，每个 agent 只比较两个 item。 bracket 本身存在确定性的 loop code 里，而不是 context 里。每次比较都很快、公平且隔离。同样的思路也适用于偏品味的排序：设计选择、候选人筛选、内容优先级。 10. Loop until done 对于工作量未知的任务，不要跑固定次数，而是循环启动 agents，直到满足停止条件：没有新发现、日志里没有更多错误、理论得到验证。 这是对“继续做，直到真的完成”的回答： • Flaky test debugging。 复现、形成理论、测试理论，直到某个理论成立。 • Bug hunting。 持续找 bug，直到完整一轮返回 0 个问题。 • Mining for patterns。 聚类、识别规则，直到不再出现新 cluster。 把这个模式和 /goal 配对，可以设定硬性完成要求，比如“不要停，直到有一个理论成立”。如果你希望整个 workflow 定期重复运行，可以配合 /loop。bracket 和停止条件存在代码里，只有当前活跃 iteration 留在 context 中。 11. 为真实用例组合模式：一个 workflow，多种模式 这 6 种模式很少单独出现。真实 workflow 通常会组合 2 到 4 种。下面这个矩阵，把 Anthropic 发布文章里的每个 use case 和它倾向使用的模式对应起来： • Migrations and refactors。 Fan out（每个 callsite 或失败测试一个 worktree agent）→ adversarial verification（独立 agent 审查每个修复）→ loop until done。这就是 Anthropic 用来把 Bun 从 Zig 重写到 Rust 的模式。 • Deep research（/deep research skill）。Fan out（并行 web searches）→ adversarial verification（每个 claim 独立验证）→ synthesize（一个带引用的报告）。 • Deep verification of a draft。 识别所有事实 claim（一个 agent）→ fan out（每个 claim 一个 verifier，每个 agent 对照来源检查）→ meta verifier（检查 verifier 使用的来源是否高质量）。 • Sorting 1,000+ items。 Tournament（步骤 5 9）：成对比较、bucket rank 或 bracket。用比较式判断，不用绝对评分。 • Memory and rule adherence。 每条规则一个 verifier（fan out）→ skeptic persona 审查规则本身，避免 false positives。 • Root cause investigation。 从互不重叠的证据生成理论（不同 agents 读取日志、文件、数据）→ 每个理论都有一组 verifiers 和 refuters → loop until one survives。 • Triage at scale。 Classify and act → 与现有 tickets 去重 → 尝试修复或升级处理。配合 /loop 做连续分诊。 • Exploration and taste（设计、命名、UI choices）。Generate and filter（5 20 个选项）→ 带 rubric 的 tournament → 排名或选出一个。 • Lightweight evals。 在 worktree 中运行 candidate → comparison agents 按 rubric 评分 → refine and re grade。形态类似 tournament，但用于评分而不是排名。 真正掌握这些模式的方式：先识别当前任务正在哪种失败模式下失效，再选择能从结构上避免它的模式。 Drift → fan out。Self preference → adversarial verification。Open ended → loop until done。Hard to score → tournament。 12. 配合 /goal、/loop 和 token budgets workflow 可能很贵。三个控制项能把它从“很酷但昂贵”变成“可以无人值守运行的工具”。 • /goal 设置硬性完成要求。把它和 loop 模式配合使用：“不要停，直到有一个理论成立。” 没有 /goal 时，workflow 会在软性完成点停止。有了 /goal，它会迭代到真实结束条件满足为止。 • /loop 让整个 workflow 按固定周期运行。适合你希望持续运行的 workflow，例如 triage、每周研究更新、周期性验证。 • 明确 token budgets。 在 prompt 里告诉 Claude：“use 10k tokens.” 这会给 workflow run 设置上限。没有上限时，一个雄心勃勃的 workflow 可能膨胀到你预期 token 的 5 到 10 倍。 直接引用 Claude Code 团队的话：“Best practices are still developing. Dynamic workflows often use more tokens, so think carefully about when and how to use them.” 大多数传统编码任务不需要 5 个 reviewer 组成的 panel。 问问自己：这个任务真的需要更多 compute 吗？如果常规 Claude Code session 能在五分钟内完成它，那你不需要 workflow。 13. 对不可信输入使用 quarantine 模式 任何读取不可信公开内容的 workflow，例如 support tickets、bug reports、user feedback、scraped data，都需要假设这些内容可能包含 prompt injection。 解决办法是：quarantine。禁止那些读取不可信内容的 agents 执行任何高权限操作。由另一组没有接触原始内容的独立 agents 执行动作。 任何处理用户提交内容（support tickets、bug reports、customer feedback、social media）、抓取公开网页，或处理第三方 API 输出的 workflow，都适用这个原则。 如果输入不是你或可信队友写的，就把它隔离起来。 一个 30 行的只读 reader agent 几乎没有成本，却能移除一整类 prompt injection 风险。 14. 保存 workflow，把它发布成 Skill 一旦某个 workflow 能用了，就保存它：在 workflow menu 里按 s。保存后的 workflow 会放到 /.claude/workflows。从这里开始，你有两条路： • 保留在本地。 在自己的项目中复用。 • 发布成 Skill。 把 JavaScript 文件打包到 Skill 文件夹里，在 SKILL.md 中引用它。任何安装这个 Skill 的人，都能运行同一个 workflow。 有一个实用细节值得知道：当你把 workflow 打包进 Skill 时，要提示 Claude 把这个 workflow 当成模板，而不是逐字执行的脚本。 这样 Claude 就有空间根据当前具体任务调整 workflow 的形状，同时保留整体结构。对于 “deep verification” 或 “triage” 这类需要按 use case 变化的 workflow 尤其有用。 浪费 workflow token 的常见错误 • 常规 Claude Code session 足够时仍然使用 workflow。 大多数传统编码任务不需要 5 个 reviewer 组成的 panel。 • 没有 token budget。 雄心勃勃的 workflow 如果没有明确上限，可能膨胀到你预期的 5 到 10 倍。 • 同一个 agent 同时做工作和验证。 Self preferential bias 会让 verifier 偏向 worker。它们必须分开。 • 把 parallel() 和 pipeline() 当成可互换。 barrier 很重要：parallel 等全部完成，pipeline 流式处理。 • 在 loop 模式中跳过 /goal。 workflow 会在第一个软性完成点提前停止。/goal 强制硬性完成。 • 让不可信内容接触 actor。 一旦处理任何用户提交内容，quarantine 就不是可选项。 • 用绝对分数排序。 比较式判断更可靠。使用 tournament。 • 从不保存已经有效的 workflow。 每周都重新 prompt 同一种结构。按 s 保存，把它发布成 Skill。 原帖链接：https://x.com/0xCodez/status/2062127385923776831 原帖链接：https://x.com/0xCodez/status/2062127385923776831 大多数 Claude Code 用户仍然在手写自己的工作流程。他们串联 prompt，复制输出，把结果粘到下一个 prompt 里，修掉出错的地方，然后重复。10 个开发者里有 9 个甚至一次都没试过动态工作流，尽管它已经在两周前发布了。 他们写了 50 个 prompt，而一个 workflow 本来就够了。下面是 14 步路线图，以及 Anthropic 自家工程师实际使用的 6 种模式：用于迁移、研究、排序、根因分析、分诊和 evals。 关注我的 Substack，获取新的 AI alpha：movez.substack.com movez.substack.com 动态工作流在 2026 年 5 月 28 日随 Claude Code 发布。默认的 Claude Code harness 是为编码而构建的，对大多数编码任务来说效果很好。但有些工作类型会让单个 context window 开始失效：长时间运行、大规模并行、高度结构化，或者带有对抗性。 过去，Anthropic 会为这些场景自己构建自定义 harness，比如 Research、Code Review、agent teams。有了动态工作流，Claude 会在运行时为你编写这个 harness，用 JavaScript 为你的任务量身定制。 14 个步骤。6 种模式。用一个 workflow 代替 50 个 prompt。 第一部分：心智模型 01. workflow 是 Claude 自己写的 harness 默认的 Claude Code harness 会让 Claude 在同一个 context window 里规划并执行。对大多数编码工作来说，这很好。对长时间运行、并行或对抗性工作来说，它会失效。 动态工作流就是 Claude 为任务编写自己的自定义 harness：一个 JavaScript 文件，包含几个特殊函数，用来启动和协调 subagents，同时使用标准 JavaScript（Math、JSON、Array）处理它们之间流动的数据。 它带来三件默认 harness 做不到的事： • 每个 agent 独立隔离。 每个 subagent 都有自己的 context window 和一个聚焦目标。不会互相污染。 • 每个 agent 可选择模型。 workflow 会决定每个 subagent 使用哪个模型：Opus 负责困难推理，Haiku 负责低成本探索，Sonnet 负责中间地带。 • 每个 agent 可选择隔离级别。 worktree（隔离的 git checkout）或 remote（不 checkout）。workflow 决定每个 agent 需要什么。启动方式有两种：直接让 Claude “make a workflow that...”，或者使用触发词 ultracode。如果 workflow 被中断，例如用户操作或终端退出，恢复 session 后会从中断处继续。 02. workflow 解决的 3 种失败模式 要知道什么时候该用 workflow，就必须先知道它修复了什么。Claude 在单个 context window 里处理复杂任务的时间越长，就越容易受到三种特定失败模式影响。这些名字直接来自 Anthropic 的发布文章： • Agentic laziness。 Claude 在复杂、多部分任务完成前停下，只做了部分进展就宣布完成。比如安全评审里有 50 项，它处理了 20 项，然后把剩下的也说成“已处理”。 • Self preferential bias。 当 Claude 被要求按 rubric 验证或评判自己的结果时，它会偏向自己的输出。一个“利益相关”的 verifier 不可能是公平的 verifier。 • Goal drift。 原始目标在多轮对话中逐渐失真，尤其是在 compaction 之后。每一次 summarization 都是有损的。“