FunTester 一文看懂 Claude Code Dynamic Workflows

FunTester · 2026年07月19日 · 76 次阅读

Anthropic 在 2026 年 5 月底给 Claude Code 加了一个新功能：Dynamic Workflows。它还处在 research preview 阶段，但设计方向很有意思。用一句话概括，就是让 Claude 现场写一份 JavaScript harness，把多 agent 编排逻辑放进代码里执行，而不是把所有协调规则继续塞进模型的上下文窗口。

这和此前在 Claude Code 里开几个 subagent 并行不太一样。Dynamic Workflows 不是简单地让多 agent 更强，而是把协调和判断拆开：模型负责判断，每个子任务由独立 subagent 处理；代码负责协调，循环、分支、合并、终止条件都由 harness 管起来。这样一来，主 session 不必把每个分支的细节都塞进上下文里，真正需要模型判断的地方才交给模型。

这篇文章按官方博客和文档梳理它的设计动机、工作方式、六种编排模式、典型使用场景，以及什么时候不该用它。

为什么需要 Dynamic Workflows

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 等，用来做数据处理、排序、循环和判断。

几个实现细节值得记住：

可选模型：workflow 可以指定每个 subagent 用哪个模型，比如重活儿用 Opus，轻活儿用 Sonnet 或 Haiku
可选 worktree 隔离：subagent 可以跑在自己的 git worktree 里，避免互相改同一份工作区
可恢复：如果 workflow 被用户操作或终端退出中断，恢复 session 后可以从中断点继续

这套设计有一个关键差别：代码执行不消耗主上下文窗口。也就是说，主 session 不需要记住每个分支的细节，只需要让 harness 维护执行顺序和状态。这就是 workflow 能支撑比普通 subagent 并行更大规模编排的原因。

动态与静态 Workflow

如果你之前用过 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
Spring Boot 升 3.0，遍历所有 deprecation 警告并分别修复

这里有个小技巧：让 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：

80 份简历，开 workflow 按后端岗位匹配度排序，前十名再核一遍
200 条 bug report 按严重程度排序

规则遵守

如果有一些规则你发现 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：

这个测试 50 次里挂 1 次。开 workflow 复现它，提出互相竞争的几个 race 假设，直到一个假设站得住为止

规模化分诊

每个团队都会遇到 support queue、bug 报告，或者其他超出人力处理上限的 backlog。分诊 workflow 可以为每个条目分类，和已有条目去重，然后决定下一步动作：尝试修复，或者升级给人工。

这里有一个有用的 pattern 叫 quarantine（隔离）：禁止读取非可信公共内容的 agent 做高权限操作，把高权限动作交给另一组只基于已整理信息行动的 agent。

如果配合 /loop，Claude 可以持续做这类分诊工作，而不是只跑一轮。

探索和品味

命名、设计、文案方向这类任务带有品味判断。workflow 的用法不是让一个 agent 想一个答案，而是让它探索一批方案，再用 review agent 拿 rubric 评估。如果 review agent 认为满足标准就结束；如果候选之间差异明显，也可以通过 tournament 选出最优。

示例 prompt：

我要给这个 CLI 工具想个名字，开 workflow 头脑风暴一批选项，再跑 tournament 选出前 3
做一份落地页 hero section 的 5 种文案方向，按 rubric 评分挑最优

评估

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 人审稿团。比如：

已经定位到的单 bug 修复
写一个明确 spec 的小 feature
单文件 refactor
翻译润色一段文字
写一个 hook 脚本或一段 SQL
来回讨论方案选型

如果每个 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。你可以照着改成自己的版本。

复现 flaky test：开 workflow 复现一个偶发失败的 race，提出互相竞争的几个假设，直到一个假设站得住为止
从 session 历史里抽规则：开 workflow 翻最近 50 个 session，挖出你反复在做的纠正，把高频问题整理成 CLAUDE.md 规则
大规模重命名：开 workflow 把代码库里所有 User model 重命名为 Account
从 Slack 里挖隐藏问题：开 workflow 翻过去半年的 #incidents 频道，找出反复出现但没人开过 ticket 的根因
多视角拆解商业计划：开 workflow 让不同 agent 分别从投资人、客户、竞品视角拆解商业计划
文章事实核验：开 workflow 把博客草稿里每一条技术声明拿到代码库里验证一遍
品味类决策：开 workflow 头脑风暴一批名字，再跑 tournament 选出前 3
简历排序：开 workflow 把 80 份简历按某个岗位排序，前十名再核一遍

这些 prompt 来自 Anthropic 博客作者的实际使用经验，代表性比较强。

版本与可用范围

需要 Claude Code v2.1.154 或更新版本
Claude Code CLI、Desktop、VS Code 扩展上可用
覆盖 Max、Team、Enterprise 计划，Enterprise 需管理员开启，也覆盖 Claude API、Amazon Bedrock、Vertex AI、Microsoft Foundry
Pro 计划可能需要手动激活
仍在 research preview 阶段，行为可能调整

结语

回到开头那句概括：Dynamic Workflows 让 Claude 现场写一份 JavaScript harness，把多 agent 编排逻辑放进代码里执行。

如果你之前用过 Claude Agent SDK 写静态 workflow，或者在一个 session 里手动开过几个 subagent，dynamic workflows 把这两种模式都重新定义了一遍：前者从提前写一套通用 harness，变成用时即写一份专用 harness；后者从在主上下文里编排，变成把编排搬到代码里。

但它不应该成为日常 default。这一点 Anthropic 自己反复强调：think creatively。把它用在以前 Claude Code 做不好、做不稳，或者做不到的事情上，而不是把它当成普通任务的升级版。判断标准依然是那句话：它真的需要更多计算吗？