Anthropic 在 2026 年 5 月底给 Claude Code 加了一个新功能：Dynamic Workflows。它还处在 research preview 阶段，但设计方向很有意思。用一句话概括，就是让 Claude 现场写一份 JavaScript harness，把多 agent 编排逻辑放进代码里执行，而不是把所有协调规则继续塞进模型的上下文窗口。
这和此前在 Claude Code 里开几个 subagent 并行不太一样。Dynamic Workflows 不是简单地让多 agent 更强，而是把协调和判断拆开：模型负责判断，每个子任务由独立 subagent 处理；代码负责协调，循环、分支、合并、终止条件都由 harness 管起来。这样一来，主 session 不必把每个分支的细节都塞进上下文里，真正需要模型判断的地方才交给模型。
这篇文章按官方博客和文档梳理它的设计动机、工作方式、六种编排模式、典型使用场景，以及什么时候不该用它。
Claude Code 的默认 harness 是为编码任务设计的。模型在同一个上下文窗口里既要规划，也要执行。对绝大多数编码任务来说，这已经够用；但 Anthropic 自己指出，当任务变成长周期、大规模并行、高度结构化，或者带有明显对抗性时，默认 harness 会出现三个具体失败模式。
Agentic laziness（agent 偷懒）指的是 Claude 在多部分复杂任务里，还没有完成所有部分，就提前宣布已完成。官方举的例子是 security review：清单里有 50 项要查，Claude 处理完 35 项就停了。
Self-preferential bias（自我偏好）指的是让 Claude 验证或评判自己的产出时，它更容易给自己开绿灯。这在同一个 session 里既做又评的时候尤其明显。
Goal drift（目标漂移）指的是 session 跑久之后，原始目标会在压缩中逐步流失。每一次 context compaction 都有信息损耗，edge case 的需求，或者不要做 X 这类约束，很容易在后半程变弱。
Dynamic Workflows 的解决方式不是再写一段更长的 prompt，而是做结构性拆分：把任务交给多个独立 subagent，每个 subagent 拿到自己的上下文窗口和明确隔离的目标，再用代码协调它们。
一个 dynamic workflow 本质上是一段 JavaScript 文件。文件里有几个特殊函数，用来 spawn 和协调 subagent；同时也能使用标准 JavaScript 能力，比如 JSON、Math、Array 等，用来做数据处理、排序、循环和判断。
几个实现细节值得记住：
这套设计有一个关键差别：代码执行不消耗主上下文窗口。也就是说，主 session 不需要记住每个分支的细节，只需要让 harness 维护执行顺序和状态。这就是 workflow 能支撑比普通 subagent 并行更大规模编排的原因。
如果你之前用过 Claude Agent SDK，或者用 claude -p 串接多个 Claude Code 实例，那更接近静态 workflow。静态 workflow 能跑，但为了覆盖所有边界情况，脚本通常会写得比较通用，也比较啰嗦。
Dynamic 这个词的关键含义是：Claude Opus 4.8 已经足够聪明，可以针对眼前这个具体任务现场写一份定制 harness。它只覆盖这次需要的逻辑分支，不为通用性付出额外代码膨胀。一次迁移涉及三个模块，就写三个模块的 harness；一次博客事实校验需要逐条 claim 验证，就写逐条声明验证的 harness。
所以 dynamic 和 static 最本质的差别，不是有没有 workflow，而是harness 是否和当前任务一一对应。
按官方说法，触发 dynamic workflow 主要有两种方式。
第一种是直接让 Claude 做一个。你可以用自然语言说 use a workflow 或 make a workflow。
第二种是使用触发词 ultracode。在 prompt 里包含 ultracode 这个词，Claude Code 会把它识别为为当前任务写 dynamic workflow harness的明确信号。
第二种可以理解为第一种的简写。文档里还提到 session 级设置 /effort ultracode，它会让整个 session 内的实质性任务自动启用 workflow。不过这个开关风险更大，一句话可能展开成多个连续 workflow，建议只在明确要处理大任务时使用。
官方博客列了六个可组合的 pattern。Claude 会根据任务自己选择组合，但理解这些 pattern 能帮你写出更清楚的 prompt。
Classify-and-act（分类后行动）。先用一个 classifier agent 判断任务类型，再 route 到不同 agent 或行为。也可以把 classifier 放在末尾，让它决定输出哪个结果。
Fan-out-and-synthesize（扇出 + 综合）。把任务切成很多小步骤，每步 spawn 一个 agent，最后由 synthesize 步骤把结果合并。synthesize 是一个 barrier，它会等待所有 fan-out agent 完成，再把结构化输出合成最终结果。它适合步骤多、每一步都需要干净独立上下文的场景。
Adversarial verification（对抗性验证）。每个 spawn 出来的 agent，都配一个验证 agent，按 rubric 或标准对它的输出做对抗性校验。
Generate-and-filter（生成 + 筛选）。先生成一批候选，再用 rubric 或验证 agent 过滤、去重，最后只返回质量最高且经过验证的结果。
Tournament（锦标赛）。spawn N 个 agent，让它们各自用不同方法尝试同一个任务，再用 judging agent 做 pairwise comparison，最后跑出冠军。它比让一个 agent 直接打绝对分更稳，因为成对比较通常比绝对评分可靠。
Loop until done（循环到完成）。对于工作量未知的任务，循环 spawn agent，直到 stop condition 满足，比如没有新发现，或者 log 里没有更多错误，而不是预先写死执行轮数。
官方博客给的场景列表很有参考价值。下面按类别梳理，每个场景配一两个示例 prompt，方便你直接迁移到自己的任务里。
Bun 项目从 Zig 重写到 Rust 用的就是 workflows。做法是把任务拆成一系列要操作的步骤，比如 call site、failing test、模块等。每个 fix 起一个 subagent，在独立 worktree 里修改；再起一个 review agent 做对抗审查，最后合并结果。
示例 prompt：
User model 重命名为 Account
这里有个小技巧：让 agent 不要跑资源密集型命令，这样更容易把并行度吃满。
Anthropic 自己发布的 /deep-research skill 就是用 dynamic workflows 实现的。它会扇出 web search、抓取 source、对抗性验证 claim，最后综合出一份带引用的报告。
这个 pattern 不只适合 web search。你也可以用它从 Slack 历史里整理状态报告，或者通过并行读代码来理解某个 feature 的实际实现。
如果你有一份报告，需要核实里面每一条事实性声明，可以开一个 workflow：先让一个 agent 抽出所有 claim，再给每条 claim spawn 一个 subagent 单独深查源头。还可以额外加 verifier agent，检查引用源头本身是否可靠。
示例 prompt：
当你要按某种定性标准排序大量条目时，比如把 1000+ 条 support ticket 按 bug 严重度排序，直接让 Claude 一口气排，质量会下降，上下文也装不下。更适合的做法是 tournament、pairwise comparison 流水线，或者先 bucket-rank 再合并。
这里的关键点是，每次比较都可以成为一个独立 agent；循环逻辑维护 bracket，主上下文里只保留运行顺序。
示例 prompt：
如果有一些规则你发现 Claude 总是漏，即使写进 CLAUDE.md 也不稳定，可以在 workflow 里给每条规则配一个 verifier agent。每条规则对应一个验证器，再配一个 skeptic persona agent 审查规则本身，降低 false positive。
反方向也可以：挖最近的 session 和 code review 评论，找你反复纠正的同类问题。多个 agent 并行聚类，再对每个候选规则做对抗性验证：如果当时有这条规则，能不能阻止那次真实失误？幸存下来的规则再整理回 CLAUDE.md。
调试最有效的方式，往往是同时提出几个独立假设并测试。单个上下文窗口里，Claude 容易被最早的假设带偏；workflow 可以从结构上减少这种自我偏好。
做法是根据互不重叠的证据 spawn agent，让它们各自生成假设，比如 log 一个、文件一个、数据一个。每个假设再过一组验证者和反驳者的评审。
这不仅适用于代码，也适用于销售、数据工程和 post-mortem。比如 3 月份销量为什么掉了，这条 pipeline 为什么失败，或者某个事故根因为什么一直没有收敛。
示例 prompt：
每个团队都会遇到 support queue、bug 报告，或者其他超出人力处理上限的 backlog。分诊 workflow 可以为每个条目分类，和已有条目去重，然后决定下一步动作：尝试修复，或者升级给人工。
这里有一个有用的 pattern 叫 quarantine（隔离）：禁止读取非可信公共内容的 agent 做高权限操作，把高权限动作交给另一组只基于已整理信息行动的 agent。
如果配合 /loop，Claude 可以持续做这类分诊工作，而不是只跑一轮。
命名、设计、文案方向这类任务带有品味判断。workflow 的用法不是让一个 agent 想一个答案，而是让它探索一批方案，再用 review agent 拿 rubric 评估。如果 review agent 认为满足标准就结束；如果候选之间差异明显，也可以通过 tournament 选出最优。
示例 prompt：
Dynamic Workflows 也适合跑轻量 eval。你可以在 worktree 里 spawn 独立 agent，再 spawn 比较 agent，按 rubric 对各自输出打分。例如评估一个 skill 是否稳定达到标准，再根据评估结果迭代 skill。
有些任务并不是一开始就知道该用哪个模型。可以先调出一个 classifier agent，由它研究任务规模、文件数量、工具调用需求，再决定后续用 Sonnet、Opus 还是更轻量的模型。
比如解释 auth 模块怎么工作，该用 Sonnet 还是 Opus，取决于 auth 模块有多少文件、代码路径多复杂、是否需要跨模块推理。classifier agent 先做这点调研，再 route 到合适的模型。
官方明确说了：workflow 是新东西，在不少场景下会产生超额收益，但它不是每个任务都需要，并且可能显著增加 token 消耗。
最直接的检验问题来自官方原文：它真的需要更多计算吗？
大多数传统编码任务并不需要一个 5 人审稿团。比如：
如果每个 turn 都展开成 workflow，体验反而会变得笨重。更合理的做法，是把 workflow 用在过去 Claude Code 做不好、做不稳或者做不到的任务上，而不是把它当成普通任务的升级版。
详细 prompt。Dynamic workflow 对 prompt 细节比平常更敏感。你可以按前面的六个 pattern，把任务拆分方式、验证标准、终止条件和预算说清楚，效果会更稳定。
Quick workflow。Workflow 不一定只服务大任务。你可以 prompt use a quick workflow，比如对这个假设做一次快速对抗审查。轻量 workflow 也是合法用法，关键是它确实需要独立视角或明确循环。
配合 /goal 和 /loop。可重复执行的 workflow，比如 triage、research、verification，可以配 /loop 周期跑；配 /goal 设硬完成条件，避免流程越跑越散。
Token budget。可以为 dynamic workflow 设显式 token 预算。在 prompt 里写 use 10k tokens，会被识别为硬上限。这是控制 workflow 跑飞的直接手段。
保存和分享。在 workflow 菜单里按 s 保存。可以提交到 ~/.claude/workflows，也可以通过 skill 分发：把 JS workflow 文件放进 skill 目录，在 SKILL.md 里引用它们。Anthropic 建议把 skill 里的 workflow 当作模板，而不是逐字执行的固定脚本，这样跨项目更灵活。
下面几个是从官方原文里挑出来的 prompt 起点，覆盖不同 pattern。你可以照着改成自己的版本。
CLAUDE.md 规则User model 重命名为 Account
这些 prompt 来自 Anthropic 博客作者的实际使用经验，代表性比较强。
回到开头那句概括：Dynamic Workflows 让 Claude 现场写一份 JavaScript harness，把多 agent 编排逻辑放进代码里执行。
如果你之前用过 Claude Agent SDK 写静态 workflow，或者在一个 session 里手动开过几个 subagent，dynamic workflows 把这两种模式都重新定义了一遍：前者从提前写一套通用 harness，变成用时即写一份专用 harness；后者从在主上下文里编排，变成把编排搬到代码里。
但它不应该成为日常 default。这一点 Anthropic 自己反复强调：think creatively。把它用在以前 Claude Code 做不好、做不稳，或者做不到的事情上，而不是把它当成普通任务的升级版。判断标准依然是那句话：它真的需要更多计算吗？
相关阅读
##### FunTester 名片｜万粉千文，百无一用