# How to master Dynamic Workflows in Claude Code: 6 patterns and 14 steps Anthropic engineers actually
**作者**: Codez
**日期**: 2026-05-28T17:42:45.000Z
**来源**: [https://x.com/0xCodez/status/2062127385923776831](https://x.com/0xCodez/status/2062127385923776831)
---
Most Claude Code users still write their workflows by hand. They chain prompts, copy outputs, paste them into the next prompt, fix what went wrong, repeat.
9 out of 10 builders haven’t tried Dynamic Workflows even once, even though they shipped two weeks ago.
They write 50 prompts when one workflow would do. This is the 14-step roadmap and the 6 patterns Anthropic’s own engineers actually use - for migrations, research, sorting, root-cause, triage, and evals.
> Follow my Substack to get fresh AI alpha: movez.substack.com
Dynamic Workflows shipped in Claude Code on May 28, 2026. The default Claude Code harness is built for coding - and that works well for most coding tasks. But there are classes of work where one context window starts to break down: long-running, massively parallel, highly structured, or adversarial.
For those, Anthropic used to build custom harnesses themselves (Research, Code Review, agent teams). With Dynamic Workflows, Claude writes that harness for you on the fly, custom-built for your task, in JavaScript.
14 steps. 6 patterns. One workflow instead of fifty prompts.
Part 1 · The Mental Model
## 01. A workflow is a harness Claude writes.
The default Claude Code harness has Claude plan and execute in the same context window. For most coding work, this is great. For long-running, parallel, or adversarial work, it breaks down.
A Dynamic Workflow is Claude writing its own custom harness for the task - a JavaScript file with a few special functions that spawn and coordinate subagents, plus standard JavaScript (Math, JSON, Array) to process the data flowing between them.
> **cat@_catwu**: [原文链接](https://x.com/_catwu/status/2060054180379689074)
>
> Excited to share our most powerful new Claude Code feature: dynamic workflows!
> Mention "workflow" in a prompt and Claude will dynamically create an orchestration plan that it strictly follows, allowing you to confidently trust that every stage happens in the right order even
>
> 
Three things this gives you that the default harness cannot:
- Per-agent isolation. Each subagent gets its own context window with one focused goal. No cross-contamination.
- Per-agent model choice. The workflow picks which model each subagent uses - Opus for hard reasoning, Haiku for cheap exploration, Sonnet for the middle.
- Per-agent isolation level. Worktree (isolated git checkout) or remote (no checkout). The workflow decides what each agent needs.
Start one by either asking Claude directly (“make a workflow that…”) or with the trigger word ultracode. If a workflow is interrupted - user action, terminal quit - resuming the session picks up where it left off.
## 02. The 3 failure modes workflows solve.
To know when a workflow is the right tool, you have to know what it fixes. The longer Claude works on a complex task in a single context window, the more it becomes susceptible to three specific failure modes - named directly in the Anthropic launch writing:
- Agentic laziness - Claude stops before finishing a complex, multi-part task and declares done after partial progress. Addresses 20 of the 50 items in a security review and calls the rest “handled.”
- Self-preferential bias - Claude prefers its own results when asked to verify or judge them against a rubric. A verifier with skin in the game can’t be a fair verifier.
- Goal drift - the gradual loss of fidelity to the original objective across many turns, especially after compaction. Each summarization step is lossy. “Don’t do X” constraints quietly disappear at turn 47.
A workflow solves all three structurally: separate Claudes with their own contexts, focused goals, and isolated state. If your task suffers from any of these patterns - that’s the signal to reach for a workflow.
## 03. Static vs Dynamic workflows.
You may have already built static workflows using the Claude Agent SDK or claude -p - coordinating multiple Claude Code instances together.
- Static workflows are generic: written once to handle every edge case. They work, but they have to be conservative.
- Dynamic Workflows are different: Claude writes this workflow for this task. The harness is tailor-made. Below is the same question handled both ways:
The reason the dynamic version wins isn’t the search step - both can search.
It’s that the workflow gets to shape itself around your context: read your billing code, check each feature against the actual new provider docs, price at your transaction volume, and run an adversarial “why not to migrate” pass against its own emerging answer.
A static harness can’t do this because it doesn’t know your code exists.
## 04. The core API. agent(), parallel(), pipeline().
Three functions do most of the work in a workflow. Knowing them is enough to read any workflow Claude writes for you and to nudge Claude when you want a specific shape.
parallel() is a barrier: it fans out, then waits for everything before returning. pipeline() is streaming: each item flows through every stage independently.
Pick by the question: do I need all results before I can do anything next? Yes → parallel. No → pipeline (cheaper, faster overall).
## 05. Classify-and-act. Route the work before doing it.
A classifier agent decides on the type of task, then the workflow routes to different agents or behaviors based on the answer. Or a classifier runs at the end, sorting raw outputs into buckets for whatever comes next.
When this pattern earns its keep:
- The task is heterogeneous - different sub-types need different treatment.
- You want to spend the expensive model only where complexity demands it (classifier on cheap, then route to Opus only when needed).
- The decomposition of work is itself non-trivial and benefits from a model deciding the shape.
Example: “Explain how the auth module works.” A classifier subagent reads the codebase first, estimates complexity, then routes the actual explanation task to Sonnet for a 10-file module or Opus for a 100-file one. The right model for the job, decided after the work is understood.
## 06. Fan-out-and-synthesize. Many small steps, one merged result.
Split a task into many smaller steps. Run an agent on each step in parallel. Synthesize the results into one answer.
The synthesize step is a barrier - it waits for every fan-out agent, then merges their structured outputs.
Why this pattern dominates in practice: it solves the “too many things at once” failure of single-context work. Each subagent sees only its piece. The orchestrator never gets distracted by 50 unrelated details.
Each step benefits from its own clean window so they don’t cross-contaminate.
Use this when:
- You have a clearly enumerable list of work items (50 files, 200 endpoints, 100 reviews).
- Each item is independent - no item needs another’s output to begin.
- You want a single consolidated answer at the end, not a pile of partial reports.
```
// Fan out: one agent per file. Barrier: wait for all.
const reviews = await parallel(
files.map(file => () => agent(
`Review ${file} for security issues`,
{ model: "haiku", schema: IssueList }
))
)
// Synthesize: one Opus agent merges everything.
const report = await agent(
`Merge these reviews into one prioritized report:\n${JSON.stringify(reviews)}`,
{ model: "opus" }
)
```
## 07. Adversarial verification
This is the structural fix for self-preferential bias. For each spawned agent, run a separate spawned agent that adversarially verifies its output against a rubric. The verifier has never seen the original work; it can’t favor it.
The pattern matters most for:
- Claim-checking - every factual statement in a report gets its own verifier subagent, checking against the original source.
- Code review - the author agent writes the fix, the reviewer agent (separate context) reviews it. Never the same Claude judging itself.
- Quality gates - before any artifact ships, an adversary tries to find the weakest case against it. If the adversary can’t, you ship.
The pairing rule: the verifier should know only the rubric and the artifact, not who produced it. Otherwise self-preference creeps back in through hints in the prompt.
## 08. Generate-and-filter.
Generate a number of ideas on a topic, then filter them by a rubric or by verification. Dedupe duplicates. Return only the highest quality, tested ideas.
Where this pattern shines:
- Brainstorming - 30 product names, then a verifier kills clichés, trademark conflicts, and weak phonetics. You see 3.
- Hypothesis gene - 5 different approaches to a problem, then each gets scored against your constraints. The winner has earned it.
- Solution design - 5 different approaches to a problem, then each gets scored against your constraints. The winner has earned it.
The opposite of asking Claude for “the best answer.” Asking for the best answer makes Claude commit early. Generate-and-filter makes Claude commit late, after every option has been challenged.
## 09. Tournament. Pairwise comparison beats absolute scoring.
Instead of dividing the work, have agents compete on it. Spawn N agents that each attempt the same task using different approaches, then judge the results in pairwise fashion until one wins.
Comparative judgment is more reliable than absolute scoring - especially for taste-based work.
Why this beats sort-by-score: trying to sort 1,000 items in one prompt fails on two fronts - quality degrades, and it won’t fit in context. A tournament splits the bracket across fresh agents, each comparing just two items.
The bracket itself lives in deterministic loop code, not in context. Each comparison is fast, fair, and isolated. Same idea works for taste-based ranking: design choices, candidate selection, content prioritization.
## 10. Loop until done.
For tasks with an unknown amount of work, loop spawning agents until a stop condition is met - no new findings, no more errors in the logs, theory verified - instead of running a fixed number of passes.
This pattern is the answer to “keep going until it’s actually done”:
- Flaky test debugging - reproduce, form theories, test them, until one theory holds.
- Bug hunting - keep finding bugs until a full pass returns zero.
- Mining for patterns - cluster, identify rules, until no new clusters appear.
Pair this pattern with /goal to set a hard completion requirement (“don’t stop until one theory works”) and with /loop if you want the entire workflow itself to run on a recurring schedule.
The bracket and the stop condition live in code; only the active iteration stays in context.
## 11. Compose patterns for real use cases. One workflow, several patterns.
The 6 patterns rarely appear alone. A real workflow composes 2-4 of them. The matrix below pairs each use case from the Anthropic launch writing with the patterns it tends to use:
- Migrations and refactors. Fan-out (one agent per callsite/failing test in a worktree) → adversarial verification (a separate agent reviews each fix) → loop until done. This is the pattern Anthropic used to rewrite Bun from Zig to Rust.
- Deep research (the /deep-research skill). Fan-out (parallel web searches) → adversarial verification (each claim verified independently) → synthesize (one cited report).
- Deep verification of a draft. Identify all factual claims (one agent) → fan-out (one verifier per claim, each agent checks against source) → meta-verifier (checks the verifier’s sources are high quality).
- Sorting 1,000+ items. Tournament (steps 5-9) - pairwise comparison, bucket-rank, or bracket. Comparative judgment, never absolute scoring.
- Memory and rule adherence. Verifier per rule (fan-out) → skeptic persona reviews the rules themselves to avoid false positives.
- Root-cause investigation. Generate theories from disjoint evidence (different agents read logs, files, data) → panel of verifiers and refuters for each theory → loop until one survives.
- Triage at scale. Classify-and-act → dedupe against existing tickets → either attempt the fix or escalate. Pair with /loop for continuous triage.
- Exploration and taste (design, naming, UI choices). Generate-and-filter (5-20 options) → tournament with a rubric → rank or pick.
- Lightweight evals. Run the candidate in a worktree → comparison agents grade against rubric → refine and re-grade. Same shape as a tournament but for grading, not ranking.
The right way to internalize these: identify which failure mode your current task is failing under, then pick the pattern that structurally prevents it.
Drift → fan-out. Self-preference → adversarial verification. Open-ended → loop until done. Hard-to-score → tournament.
## 12. Pair with /goal, /loop, and token budgets.
Workflows can be expensive. Three controls turn them from “cool but costly” into “a tool I run unattended.”
- /goal sets a hard completion requirement. Pair it with the loop pattern: “don’t stop until one theory works.” Without /goal, a workflow stops at a soft completion point. With /goal, it iterates until the actual end condition is met.
- /loop runs the entire workflow on a recurring schedule. Use it for workflows you want running continuously - triage, weekly research updates, recurring verification.
- Explicit token budgets. Tell Claude in the prompt: “use 10k tokens.” This sets a cap on the workflow run. Without a cap, an ambitious workflow can balloon to 5–10× the tokens you expected.
```
> 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.
```
Quoting the Claude Code team directly: “Best practices are still developing. Dynamic workflows often use more tokens, so think carefully about when and how to use them.” Most traditional coding tasks do not need a panel of 5 reviewers.
Ask yourself: does this task really need more compute? If a regular Claude Code session would finish it in five minutes, you don’t need a workflow.
## 13. Use the quarantine pattern for untrusted input.
Any workflow that reads untrusted public content - support tickets, bug reports, user feedback, scraped data - needs to assume that content might contain prompt injection.
The fix: quarantine. Bar the agents that read the untrusted content from taking any high-privilege actions. Separate agents, with no exposure to the raw content, do the acting.
Any workflow that processes user-submitted content (support tickets, bug reports, customer feedback, social media), scrapes public web pages, or runs against output from a third-party API.
If the input wasn’t written by you or a trusted teammate, quarantine it. A 30-line read-only reader agent costs almost nothing and removes an entire class of prompt injection risk.
## 14. Save workflows. Ship them as Skills.
Once a workflow works, save it: press s in the workflow menu. Saved workflows go to ~/.claude/workflows. From there you have two paths:
- Keep it local - reuse it across your own projects.
- Ship it as a Skill - bundle the JavaScript file inside a Skill folder, reference it in SKILL.md, and anyone who installs the Skill runs the same workflow.
One practical nuance worth knowing: when you package a workflow into a Skill, prompt Claude to treat the workflow as a template, not a script to run verbatim.
That leaves room for Claude to adapt the workflow shape to the specific task at hand while keeping the overall structure intact. Especially useful for workflows like “deep verification” or “triage” that need to flex per use case.
## The mistakes that waste tokens on workflows
- Reaching for a workflow when a regular Claude Code session would do. Most traditional coding tasks don’t need a panel of 5 reviewers.
- No token budget. Ambitious workflows balloon to 5–10× what you expected without an explicit cap.
- One agent doing both the work and the verification. Self-preferential bias makes the verifier favor the worker. They must be separate.
- Treating parallel() and pipeline() as interchangeable. The barrier matters - parallel waits for all, pipeline streams.
- Skipping /goal on loop patterns. The workflow stops early at the first soft completion point. /goal forces hard completion.
- Letting untrusted content reach the actor. Quarantine isn’t optional once you process anything user-submitted.
- Sorting with absolute scores. Comparative judgment is more reliable. Use a tournament.
- Never saving working workflows. Re-prompting the same shape every week. Save with s, ship as a Skill.
## Conclusion:
## 相关链接
- [Codez](https://x.com/0xCodez)
- [@0xCodez](https://x.com/0xCodez)
- [478K](https://x.com/0xCodez/status/2062127385923776831/analytics)
- [movez.substack.com](https://movez.substack.com/)
- [May 29](https://x.com/_catwu/status/2060054180379689074)
- [1.6M](https://x.com/_catwu/status/2060054180379689074/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [7:00 PM · Jun 3, 2026](https://x.com/0xCodez/status/2062127385923776831)
- [478.8K Views](https://x.com/0xCodez/status/2062127385923776831/analytics)
- [View quotes](https://x.com/0xCodez/status/2062127385923776831/quotes)
---
*导出时间: 2026/6/4 09:43:27*
---
## 中文翻译
# 如何掌握 Claude Code 中的动态工作流：Anthropic 工程师实际使用的 6 种模式和 14 个步骤
**作者**: Codez
**日期**: 2026-05-28T17:42:45.000Z
**来源**: [https://x.com/0xCodez/status/2062127385923776831](https://x.com/0xCodez/status/2062127385923776831)
---
大多数 Claude Code 用户仍然手动编写他们的工作流。他们链接提示词，复制输出，将其粘贴到下一个提示词中，修复出错的地方，然后重复。
十分之九的开发者甚至从未尝试过动态工作流，尽管它在两周前就已经发布了。
他们编写 50 个提示词，而其实一个工作流就能搞定。这就是 Anthropic 自家工程师实际使用的路线图（14 个步骤）和 6 种模式——用于迁移、研究、分类、根因分析、分诊和评估。
> 关注我的 Substack 获取最新的 AI 深度信息：movez.substack.com
动态工作流功能于 2026 年 5 月 28 日在 Claude Code 中推出。默认的 Claude Code 驱动程序是为编码构建的——这对大多数编码任务都很有效。但在某些类别的任务中，单一上下文窗口开始显得力不从心：长时间运行、大规模并行、高度结构化或对抗性的任务。
对于这些任务，Anthropic 以前会自己构建定制驱动程序（研究、代码审查、智能体团队）。有了动态工作流，Claude 会为你即时编写该驱动程序，专为你量身定制，使用 JavaScript 实现。
14 个步骤。6 种模式。一个工作流胜过五十个提示词。
第一部分 · 心智模型
## 01. 工作流是 Claude 编写的一种驱动程序。
默认的 Claude Code 驱动程序让 Claude 在同一个上下文窗口中进行规划和执行。对于大多数编码工作，这很棒。但对于长时间运行、并行或对抗性的工作，它会崩溃。
动态工作流是 Claude 为该任务编写自己的定制驱动程序——一个 JavaScript 文件，其中包含一些特殊的函数，用于生成和协调子智能体，外加用于处理在它们之间流动的数据的标准 JavaScript（Math、JSON、Array）。
> **cat@_catwu**: [原文链接](https://x.com/_catwu/status/2060054180379689074)
>
> 很高兴分享我们最强大的新 Claude Code 功能：动态工作流！
> 在提示词中提及“workflow”，Claude 将动态创建一个严格遵守的编排计划，让你有信心确信每个阶段都按正确的顺序发生。
>
> 
这为你提供了三件默认驱动程序无法做到的事情：
- 智能体隔离。每个子智能体都有自己的上下文窗口，并专注于单一目标。没有交叉污染。
- 智能体模型选择。工作流决定每个子智能体使用哪种模型——Opus 用于复杂推理，Haiku 用于低成本探索，Sonnet 介于两者之间。
- 智能体隔离级别。工作树（隔离的 git checkout）或远程（无 checkout）。工作流决定每个智能体需要什么。
直接向 Claude 提出请求（“做一个工作流来……”）或使用触发词 `ultracode` 即可启动一个工作流。如果工作流被中断——用户操作、终端退出——恢复会话将从中断的地方继续。
## 02. 工作流解决的三种失败模式。
要知道工作流是否是正确的工具，你必须知道它能修复什么。Claude 在单一上下文窗口中处理复杂任务的时间越长，它就越容易受到三种特定失败模式的影响——这些模式在 Anthropic 的发布文章中被直接点名：
- 智能体懒惰——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. 分类与行动。在做之前路由工作。
一个分类器智能体决定任务的类型，然后工作流根据答案将任务路由到不同的智能体或行为。或者分类器在最后运行，将原始输出分类到不同的桶中，以便进行后续处理。
当这种模式发挥作用的场景：
- 任务是异构的——不同的子类型需要不同的处理。
- 你只想在复杂性需要的地方使用昂贵的模型（分类器用便宜的，然后仅在需要时路由到 Opus）。
- 工作的分解本身并非易事，并且由模型来决定结构会更有益。
示例：“解释 auth 模块是如何工作的。”一个分类器子智能体首先阅读代码库，估算复杂性，然后将实际的解释任务路由到 Sonnet（针对 10 个文件的模块）或 Opus（针对 100 个文件的模块）。先理解工作，再决定使用合适的模型。
## 06. 分发与综合。许多小步骤，一个合并结果。
将一个任务拆分为许多更小的步骤。并行运行一个智能体处理每个步骤。将结果综合为一个答案。
综合步骤是一个屏障——它等待所有的分发智能体，然后合并它们的结构化输出。
为什么这种模式在实践中占据主导地位：它解决了单一上下文工作中“一次处理太多事情”的失败。每个子智能体只看到它自己的那一部分。协调器永远不会被 50 个不相关的细节分散注意力。
每个步骤都从自己干净的上下文窗口中受益，因此它们不会交叉污染。
在以下情况使用：
- 你有一个清晰可枚举的工作项列表（50 个文件，200 个端点，100 个审查）。
- 每个项目都是独立的——没有任何项目需要另一个项目的输出才能开始。
- 你希望在最后得到一个单一的整合答案，而不是一堆零散的报告。
```
// 分发：每个文件一个智能体。屏障：等待所有。
const reviews = await parallel(
files.map(file => () => agent(
`Review ${file} for security issues`,
{ model: "haiku", schema: IssueList }
))
)
// 综合：一个 Opus 智能体合并所有内容。
const report = await agent(
`Merge these reviews into one prioritized report:\n${JSON.stringify(reviews)}`,
{ model: "opus" }
)
```
## 07. 对抗性验证
这是针对自身偏好偏差的结构性修复。对于每个生成的智能体，运行一个单独的生成智能体，根据标准对抗性地验证其输出。验证者从未看过原始工作；它无法偏袒它。
该模式最重要的场景：
- 声明核查——报告中的每个事实声明都有自己的验证子智能体，根据原始来源进行检查。
- 代码审查——作者智能体编写修复，审查者智能体（独立上下文）进行审查。绝不能是同一个 Claude 自己评判自己。
- 质量关卡——在任何制品发布之前，一个对抗者试图找到反对它的最弱论据。如果对抗者找不到，你就发布。
配对规则：验证者应该只知道标准和制品，而不是谁生产了它。否则，自身偏好会通过提示词中的暗示悄悄溜回来。
## 08. 生成与过滤。
就某个主题生成许多想法，然后通过标准或验证进行过滤。去重。只返回最高质量的、经过测试的想法。
这种模式大放异彩的场景：
- 头脑风暴——30 个产品名称，然后验证者剔除陈词滥调、商标冲突和发音不佳的名称。你能看到 3 个。
- 假设生成——5 种解决问题的不同方法，然后根据你的约束对每种方法进行评分。胜之无愧。
- 解决方案设计——5 种解决问题的不同方法，然后根据你的约束对每种方法进行评分。胜之无愧。
这与要求 Claude 给出“最佳答案”相反。要求最佳答案会让 Claude 过早做出承诺。生成与过滤让 Claude 延迟做出承诺，直到每个选项都受到挑战。
## 09. 锦标赛。成对比较胜过绝对评分。
不要分配工作，而是让智能体相互竞争。生成 N 个智能体，每个智能体使用不同的方法尝试同一任务，然后以成对的方式评判结果，直到产生一个获胜者。
比较性判断比绝对评分更可靠——特别是对于基于品味的工作。
为什么这比按分数排序更好：试图在一个提示词中排序 1,000 个项目会在两个方面失败——质量下降，并且无法放入上下文中。锦标赛将分组拆分到新的智能体中，每个智能体只比较两个项目。
分组本身存在于确定性循环代码中，而不是在上下文中。每次比较都是快速、公平和隔离的。同样的想法也适用于基于品味的排名：设计选择、候选人选择、内容优先级排序。
## 10. 循环直到完成。
对于工作量未知的任务，循环生成智能体，直到满足停止条件——没有新发现，日志中不再有错误，理论得到验证——而不是运行固定次数的遍历。
这种模式是“持续进行直到真正完成”的答案：
- 不稳定的测试调试——重现，形成理论，测试它们，直到一个理论成立。
- 错误搜寻——不断发现错误，直到完整遍历返回零个错误。
- 模式挖掘——聚类，识别规则，直到不再出现新聚类。
将此模式与 `/goal` 配对以设置硬性完成要求（“在一个理论奏效之前不要停止”），并与 `/loop` 配对，如果你希望整个工作流本身按循环计划运行。
分组和停止条件存在于代码中；只有活动的迭代保留在上下文中。
## 11. 为真实用例组合模式。一个工作流，多种模式。
这 6 种模式很少单独出现。一个真实的工作流组合了其中的 2-4 种。下面的矩阵将 Anthropic 发布文章中的每个用例与其倾向于使用的模式配对：
- 迁移和重构。分发（工作树中每个调用点/失败测试一个智能体）→ 对抗性验证（一个独立的智能体审查每个修复）→ 循环直到完成。这是 Anthropic 用于将 Bun 从 Zig 重写为 Rust 的模式。
- 深度研究（`/deep-research` 技能）。分发（并行网络搜索）→ 对抗性验证（每个声明独立验证）→ 综合（一份引用的报告）。
- 对草稿的深度验证。识别所有事实声明（一个智能体）→ 分发（每个声明一个验证者，每个智能体根据来源检查）→ 元验证者（检查验证者的来源是否高质量）。
- 排序 1,000+ 个项目。锦标赛（步骤 5-9）——成对比较、桶排序或分组。比较性判断，绝不使用绝对评分。
- 记忆和规则遵守。每个规则一个验证者（分发）→ 持怀疑态度的人设审查规则本身以避免误报。
- 根因调查。从不相干的证据生成理论（不同的智能体读取日志、文件、数据）→ 针对每个理论的验证者和反驳者小组→ 循环直到有一个理论幸存。
- 大规模分诊。分类与行动 → 针对现有工单进行去重 → 尝试修复或升级。与 `/loop` 配合进行持续分诊。
- 探索与品味（设计、命名、UI 选择）。生成与过滤（5-20 个选项）→ 带标准的锦标赛 → 排名或挑选。
- 轻量级评估。在工作树中运行候选 → 比较智能体根据标准打分 → 优化并重新打分。形状与锦标赛相同，但用于打分，而不是排名。
内化这些模式的正确方法：识别你当前任务正在遭受哪种失败模式，然后选择在结构上能防止它的模式。
偏移 → 分发。自身偏好 → 对抗性验证。开放式 → 循环直到完成。难以评分 → 锦标赛。
## 12. 与 /goal、/loop 和 token 预算配合使用。
工作流可能很昂贵。三个控制手段能将它们从“很酷但成本高”转变为“我可以无人值守运行的工具”。
- `/goal` 设置硬性完成要求。将其与循环模式配对：“在一个理论奏效之前不要停止”。没有 `/goal`，工作流会在软完成点停止。有了 `/goal`，它会迭代直到满足实际的结束条件。
- `/loop` 按循环计划运行整个工作流。将其用于你希望持续运行的工作流——分诊、每周研究更新、循环验证。
- 显式 token 预算。在提示词中告诉 Claude：“使用 10k token”。这为工作流运行设置了上限。没有上限，一个雄心勃勃的工作流可能会膨胀到你预期的 token 数量的 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 团队的话：“最佳实践仍在发展中。动态工作流通常使用更多 token，因此请仔细考虑何时以及如何使用它们。”大多数传统的编码任务并不需要一个由 5 位审查员组成的委员会。
问问你自己：这项任务真的需要更多算力吗？如果常规的 Claude Code 会话可以在五分钟内完成它，你就不需要工作流。
## 13. 使用隔离模式处理不受信任的输入。
任何读取不受信任的公共内容——支持工单、错误报告、用户反馈、抓取的数据——的工作流都需要假设该内容可能包含提示注入。
解决方案：隔离。禁止读取不受信任内容的智能体采取任何高权限操作。独立的、没有接触过原始内容的智能体来执行操作。
任何处理用户提交的内容（支持工单、错误报告、客户反馈、社交媒体）、抓取公共网页或针对第三方 API 输出运行的工作流。
如果输入不是你或受信任的队友编写的，请将其隔离。一个 30 行的只读智能体读取器几乎没有任何成本，并消除了一整类提示注入风险。
## 14. 保存工作流。将它们作为技能发布。
一旦工作流运行良好，就保存它：在工作流菜单中按 `s`。保存的工作流会进入 `~/.claude/workflows`。从那里你有两条路径：
- 保留在本地——在你自己的项目中重复使用。
- 作为技能发布——将 JavaScript 文件打包在技能文件夹中，在 SKILL.md 中引用它，并……