Claude Dynamic Workflows
Claude Code Dynamic Workflows 的机制、市场信号、风评、真实项目证据与采用边界
结论先行：Claude Dynamic Workflows 是 Claude Code 把多 Agent 编排从对话里的临场决策，移到可运行、可审阅、可复用的 JavaScript 脚本中。它最适合大范围审计、机械性迁移和多来源交叉研究。它没有证明自己能通用地提升复杂 feature 的正确性，也不能替代人类对目标、架构和验收的把关。公开讨论和产品案例显示开发者已在尝试这些工作流，但尚无独立的大样本 benchmark 能量化通用的速度、质量或成本收益。
一个大任务，两个不同的做法
设想团队要给一个十年历史的服务做安全清查。单个 Claude Code session 的自然路径是：读一批路由，发现一个可疑鉴权分支，继续向下追，最后把自己的调查过程、日志和修复思路全部塞进同一段对话。这个过程并非不能完成，但它把三件不同的工作捆在一起了：枚举候选点、验证每个候选点、合并结论。
更传统的多 Agent 做法，是让 Claude 在每个 turn 临时派几个 subagent。Dynamic Workflows 则再往前一步：Claude 先写一段 JavaScript 编排脚本，脚本用循环、分支和变量控制后续 agent 的启动、汇总与复核。真正读文件、运行测试、修改代码的仍是 subagent，脚本本身没有直接的 filesystem 或 shell 权限。官方工作流文档把它称为一个与会话隔离的 runtime。
这不是让一个 Agent 突然更会写代码，而是把工作计划从自然语言和主会话 context 中拿出来，变成一个可执行的控制平面。对于可以拆成许多同构单元的任务，收益来自并发、隔离的 context window 和系统性的验证。对于一个边界不清的新 feature，它也可能只是更快地产生更多需要人工审阅的猜测。
1. 它是什么，不是什么
1.1 工作模型
一个 workflow 是带 top-level await 的 JavaScript。Claude 可为一次任务生成它，用户可在运行前看 raw script，也可在成功后保存为项目内 .claude/workflows/ 或个人 ~/.claude/workflows/ 下的 slash command。保存后，流程本身而不只是 prompt 可被复跑；调用时还可通过全局 args 传入路径、issue 列表或研究问题。官方保存与参数说明
运行时的核心边界如下：
| 层 | 负责什么 | 不负责什么 |
|---|---|---|
| Claude Code 主会话 | 理解请求，生成或启动脚本，最终呈现结论 | 保存所有中间搜索和每个 agent 的完整 context |
| Workflow script | fan-out、循环、分支、聚合、重试策略和阶段结果 | 直接读写文件、运行 shell、替用户做 mid-run 决策 |
| Subagent | 实际检索、编辑、执行命令、返回结构化或文本结果 | 以自己的判断越过工具 allowlist |
| 人类 | 批准 run，审阅计划与代码，决定是否 merge | 不会被 workflow 自动替代 |
官方 runtime 上限是单次最多 16 个并发 agent，总量最多 1,000 个 agent。这是上限，不是推荐规模。一个 workflow 的 subagent 总是以 acceptEdits 运行，并继承 session 的 tool allowlist，因此文件改动会自动批准，而 shell、web fetch 和未允许的 MCP 仍可能中途要求同意。官方权限与限制 这意味着大型 edit workflow 的关键安全控制不是每个写入时点确认，而是启动前的 script 审阅、窄路径范围和最小 allowlist。
1.2 与 Subagent、Agent Teams 和 Skills 的差别
| 机制 | 下一步由谁决定 | 中间结果在哪里 | 适合规模 | 可复用的东西 | 最典型的风险 |
|---|---|---|---|---|---|
| 单一 session | Claude，逐 turn | 主 context | 顺序、小范围任务 | Prompt 与对话 | Context 被日志和探索淹没 |
| Subagent | Claude，逐 turn | 主 context | 少量明确委派 | Worker 定义 | 主会话成为协调瓶颈 |
| Skill | Claude 按 instructions | 主 context | 标准化方法 | 指令集 | 不是运行时编排器 |
| Agent Teams | Lead session，逐 turn | shared task list 和 peer messages | 少数长期协作 peer | Team 结构 | 通讯和文件所有权协调 |
| Dynamic Workflow | JavaScript script | Script variables | 数十到数百个细粒度单元 | Orchestration script | Token、权限与错误扩散 |
这张比较直接来自官方文档的控制权划分。官方比较表 最重要的区别不是“agent 数量更多”，而是计划是否由代码持有。Agent Teams 保留一个 lead 来持续协调 peer；workflow 将固定的循环、依赖和验证模式交给 runtime，主会话只接收最终结果。
1.3 它不是
- 不是无限制的 agent swarm。并发 16、总量 1,000 的 runtime cap 是硬约束，机器 CPU 核数低时并发会进一步下降。
- 不是无人值守的部署系统。没有 mid-run 用户输入。要在阶段间 sign-off，官方建议拆成多个 workflow。
- 不是跨 session 的 durable job queue。暂停后，已完成 agent 的缓存结果只可在同一 Claude Code session恢复使用；退出 Claude Code 后，下一 session 会重新开始该 workflow。官方恢复语义
- 不是质量证明。它可以组织独立 reviewer 反驳发现，但不能保证测试有效、需求完整或架构正确。
2. 背景：从多 Agent 协作到“把编排写成代码”
Anthropic 在 2025 年公开过 Claude Research 的 multi-agent 系统。其核心观察是，宽度优先的研究可以通过 orchestrator 与多条独立检索路径获益，但 token 使用和协调会快速上升，且许多 coding task 并没有足够的可并行部分。Anthropic 的研究系统工程文章
Claude Code 的 Agent Teams 将 shared tasks 与 peer messaging 带入本地 coding harness。Dynamic Workflows 的方向不同：它将协调从 lead 的持续语言决策，转成 runtime 执行的脚本。产品公告发布于 2026-05-28，官方文档要求 Claude Code v2.1.154+。公告最初为 beta，页面现在明确标注为 generally available；当前文档显示其面向所有 paid plans、Anthropic API、Bedrock、Google Cloud Agent Platform 和 Microsoft Foundry。产品公告 当前可用性
这里要区分两个相近但不相同的承诺。公告说任务进度会保存，遇到中断可继续；当前操作文档更精确地限定为“同一 session 内 resume”。因此，本文按操作文档处理：不能把它当作可在任意机器或任意后续会话接管的长期编排平台。
3. 它实际解决什么问题
3.1 大范围、同构而可验证的清查
路由鉴权、过时 API、危险调用、死代码和 flaky test 都有共同形状：对象很多，单个对象的检查规则相似，结果需要去重和复核。workflow 可以先发现目标集合，再按文件或 endpoint fan-out，最后让独立 agent 验证候选结果并统一排序。官方内置 /deep-research 也是相同结构：并行搜索、抓取、交叉核验和投票，只将保留的带引用报告交还主会话。内置 workflow 说明
这种形状中，正确的单位不是“让一百个 agent 随便找 bug”，而是“每个 agent 用同一判断规则检查一个可定位对象”。验证 agent 必须拿到原始证据和明确的判定标准，否则 fan-out 只会放大 false positive。
3.2 大型机械迁移
把数百个文件从一种框架或 API 迁到另一种框架，存在实在的并行度，但前提是每项变更拥有隔离的文件或临时副本。官方示例明确要求每个 component 在独立 copy 中迁移，避免 edit 冲突。迁移示例
这比 Agent Teams 更适合机械迁移，因为步骤可以被固定为：发现、映射、逐项转换、构建、失败回路。它并不适合共享核心 schema、跨文件状态机或一组必须共同设计的接口，那些情况的 merge 和因果推理仍是主要成本。
3.3 把“第二个意见”变成流程的一部分
最有价值的质量模式不是多数投票，而是证据可追溯的反驳：一个 agent 提出发现，另一个在独立 context 中检查它是否真的违背规则，第三个只负责合并重复项。对 security audit、性能瓶颈归因和架构方案选择，这比主会话先相信第一个合理答案更稳。
官方文档把这种模式称为 adversarial verification，但它仍受制于共模错误。所有 agent 若误解同一条 spec，或测试 harness 本身失效，彼此检查不产生独立真相。因此，应将外部可观察的验证，例如类型检查、测试、benchmark、浏览器验收，放在 workflow 的最终门槛。
3.4 什么时候不要用
| 任务特征 | 为什么不适合 | 更稳的选择 |
|---|---|---|
| 单文件的小改动 | 生成脚本、审批和启动成本高于委派收益 | 单一 session |
| 需求仍在探索 | Workflow 会把错误的假设高效扩散 | 先 plan，再小范围 prototype |
| 多人必须在阶段间裁决 | Runtime 没有 mid-run user input | 多个短 workflow 或 Agent Teams |
| 同一高耦合模块的并行 edit | 文件冲突和局部正确、整体错误都会增加 | 单 session，或先设计后顺序实现 |
| 不存在可信验收器 | 验证 agent 只能复述意见 | 先建立 tests、invariants 或 review checklist |
4. Google Trends、热度与口碑：能确认发布注意力，不能证明采用
图：Google Trends 查询截图。条件为 Worldwide、2026-05-01 至 2026-07-16、All categories、Web Search；数据采集于 2026-07-15。
4.1 Google Trends：发布峰值清晰，随后快速进入低位长尾
可复现查询是 Claude Dynamic Workflows，条件为 Worldwide、2026-05-01 至 2026-07-16、All categories、Web Search。以下数据与截图均采集于 2026-07-15，只说明该查询呈现的相对兴趣，不推断绝对搜索量。
时间序列呈典型的 feature-launch 曲线：5 月下旬前指数为 0，随后在发布窗口冲到该时间范围峰值 100；紧接着回落至约 55 至 63，并在 6 月大多处于约 10 至 35 的相对兴趣区间；7 月进入个位数，7 月 15 日为 3。最可靠的结论不是“持续爆发”，而是：发布带来短而陡的注意力峰值，随后保留了低位、递减的技术长尾。
Google Trends 的 100 只表示这个 query、时间范围、地区和搜索类型中的最高相对兴趣。它不是搜索次数、活跃用户数、市场份额或企业采用率，不能同其他独立查询的 100 直接比较。
地域信号也集中在东亚和技术密度较高的市场。在未包含 low search volume regions 的条件下，该查询显示 18 个地区，前五名如下：
| 排名 | 地区 | 相对兴趣指数 | 应如何解读 |
|---|---|---|---|
| 1 | China | 100 | 当前筛选结果中的最高相对兴趣，不等于绝对搜索量或用户数最多 |
| 2 | Singapore | 48 | 相对兴趣约为最高地区的一半 |
| 3 | South Korea | 41 | 有显著但低于 China 的相对兴趣 |
| 4 | Taiwan | 25 | 有可见的技术社区信号 |
| 5 | Netherlands | 23 | 有可见但较弱的相对兴趣 |
Rising related queries 前五项均为 Breakout：opus 4.8、claude workflow、claude dynamic workflow、claude code dynamic workflow、codex workflows。这说明搜索意图不仅指向产品名称，也同时指向模型版本、通用 workflow 概念和同类工具比较。Rising topics 中的 Documentation、Application programming interface 与 Cost 也符合早期用户正在学习接口、配置与使用成本的解释；June、Summer 等宽泛 topic 不应附会为产品信号。
4.2 数据边界
Google Trends 的相对指数只能观察特定 query 在给定时间、地区和搜索类型下的变化。它不能证明留存、付费使用、企业采用或代码质量，也不能与其他独立查询的 100 横向比较。
4.3 早期使用反馈：价值与瓶颈并存
公开讨论和 issue 只能证明可追溯的尝试与具体使用痛点，不能量化采用率、平均成本或代码质量。
4.4 被认可的价值
- 脚本把 fan-out、汇总、反证和复核固化为可审阅、可复跑的阶段，不必由 lead 在每轮临场协调。
- 分阶段并行、独立 agent context 和验证阶段能降低大范围、同构任务对主会话 context 的挤占。
早期访问者 afro88 在 HN 报告，这些机制改善了较大任务的可见性与结果；Bun 作者 Jarred Sumner 将它形容为针对任务与项目定制的 build system。这些都是个人体验或产品方表态，不是对照实验。HN 原帖
4.5 必须先接受的缺点
| 缺点 | 会造成什么后果 | 何时不应使用 |
|---|---|---|
Subagent 默认以 acceptEdits 运行 |
文件编辑不逐次请求确认，错误的范围或脚本会更快落到工作区 | 改动范围无法限定，或不能先审阅 script 和 plan |
| 运行中不能要求人工裁决 | 需求变化、发现歧义或需要业务判断时，run 不能自然停在正确边界 | 多人必须在每个阶段 sign-off 的任务 |
| 恢复只在同一 session 有效 | 退出 Claude Code 后不能把 run 当成可接管的 durable job | 长运行、跨机器或跨班次任务 |
| 错误 spec 会被批量放大 | 多个 agent 共享同一误解，投票无法变成独立真相 | 没有可信 tests、规则或人工验收器 |
| 成本警告不是熔断器 | Large workflow 只提示规模与 token 风险，不会自动暂停 run |
没有预先批准的 agent、token 和停止阈值 |
| 最终产物仍需人工审阅 | 通过单个检查不代表迁移正确、测试有效或架构合理 | 团队没有足够 review 和 QA 带宽 |
官方文档也没有回避这些约束：超过 25 个 agent 或预测 token 超过 150 万 时会显示 Large workflow 警告，但警告不暂停任务。/config 可将生成脚本的默认规模约束为 small 少于 5、medium 少于 15 或 large 少于 50 个 agent。官方成本与规模设置
4.6 GitHub issue 记录：默认策略、模型路由与 fan-out 是同一问题
截至 2026-07-16，以下是 open 的单一用户报告或 feature request。它们不是平均成本、常态行为或官方承诺；选择它们是因为它们讨论的是 workflow 在何时升级、以什么模型 fan-out、以及如何限制执行规模的系统策略。
| Issue | 报告环境与症状 | 对采用决策的含义 | 证据边界 |
|---|---|---|---|
| #64938 | macOS、2.1.160/161 下，报告者称简单 research 请求会在未明确要求 deep research 的情况下被扩展为多阶段、多 agent 路径，并达到 1.5M+ token | 工作流升级应有明确用户意图、任务复杂度阈值和 token budget；“能编排”不应等同于默认编排 | 单一用户报告，未证明分类器对所有请求都会过度升级 |
| #68695 | macOS 上的报告称内置 deep-research 模板没有按角色设置 model，约 97 个 search、fetch 与 verify agent 继承主会话的 Opus 模型 |
成本控制不能只设 agent 数；还必须审查每个 phase 的模型、并发度和输入大小，避免把高价模型用于可降级的机械工作 | 对内置模板及该报告的检查结果，标为 enhancement、stale；不是官方性能或价格基准 |
| #69206 | Linux、Anthropic API、2.1.179 下，一次本应约 10 个 worker 的 run 因参数处理错误启动 218 个 subagent；报告者称人工终止前约消耗 700k token | 每次 fan-out 前先检查切片数；把小规模、可验证输入跑通后再放大，并安排人观察实际启动数与停止条件 | 单次报告；参数字符串化是该次触发器，不能外推为所有 workflow 都会 runaway |
三项放在一起，揭示的不是某一个 subagent “质量不好”，而是控制平面缺少三层预算：何时升级为 workflow、每个阶段用什么模型、以及最多能创建多少执行单元。 官方 Large workflow 警告并不能替代这些预算。更保守的实践是把升级条件、phase 级模型选择、最大切片数、预批准 token 阈值和实际启动数检查写进 workflow contract；这是一套从 issue 报告归纳出的护栏，不是 Anthropic 已确认的设计结论。
4.7 风评结论
它的风评不应是“自动完成大型 feature”，而是“把可验证的重复工序变成高吞吐的批处理”。当对象可枚举、规则同构且验收器可信时，它能减少编排摩擦。缺少这些前提时，它会放大权限风险、token 开销和后续审阅债务。
5. 真实项目中的效果，到底有多好
现有证据必须分层，而不是把“Bun rewrite”当成所有团队都会复现的速度提升。
| 证据层级 | 已观察到的结果 | 可得出的结论 | 不应外推 |
|---|---|---|---|
| Anthropic 官方技术公告 | Jarred Sumner 使用 workflow 将 Bun 从 Zig port 到 Rust，公告称约 750,000 行 Rust、11 天从首个 commit 到 merge、99.8% 既有测试通过，每个文件有两个 reviewer；公告同时说当时尚未生产上线 | 大规模、可分片、已有强测试套件的 language port 是它的强场景 | 没有独立复现、baseline、完整成本、缺陷率或生产稳定性数据，不能推导一般 feature 的效果 |
| Klarna 与 CyberAgent 引述 | 官方公告引述 Klarna 的 dead-code discovery 和 CyberAgent 的长程可见性体验 | 大型代码库 discovery、review 和 plan-to-implementation 是早期设计伙伴的目标场景 | 没有任务数、对照组、token、返工或生产缺陷指标 |
| HN Early Access 自述 | 有用户报告更好的 large-task context management，亦有用户报告很快触顶 usage limit | 收益和成本会同时出现，TUI 与 context 隔离是可感知价值 | 样本自选、无任务定义、无独立质量测量 |
Bun 是最强的公开案例，也最需要克制。它的任务天然适合并行：源文件数量庞大、行为等价是明确目标、已有测试 suite、每个文件可有 reviewer。即使公告指标全部成立，它仍然主要证明“在这种任务形状中，workflow 可以参与一次非常大的工程交付”。它没有回答一个业务 feature 的模糊需求如何澄清，或一个看似通过的测试是否真正保护关键 invariants。
6. 一个保守、可量化的采用方式
不要把首个试验设为“用 ultracode 做完下个大 feature”。先选择三个能够独立验收、且失败影响可控的任务：
- 以固定规则审计一组 API route 的 authentication 和 input validation。
- 逐文件替换已废弃 API，并要求 typecheck、test 与 diff review 都通过。
- 让多个证据流调查一个 incident，由独立 verifier 反驳每项候选根因。
为每次 run 固定 contract：
- 输入边界：目标目录、允许修改的文件、禁止触碰的接口。
- 阶段边界：discovery 产物是什么，何时进入 edit，何时只能 report。
- 验收器：具体 command、expected output、browser 或 benchmark 观察点。
- 停止规则：发现无可信验收器、连续两轮无进展、超过预先批准的 agent 或 token 阈值时停止。
- 人工门：在任何迁移或生产改动前，人工审阅 script、plan、diff 和验证结果。
可从一段明确的请求开始：
Use a small dynamic workflow to audit every route under src/routes/ for missing
authentication. First discover candidate routes. Then assign one agent per route
for evidence collection. Have an independent verifier reject each finding unless
it cites the route, the required policy, and an observed missing check. Do not edit
files. Return a ranked report with duplicates removed. Stop if more than 12 routes
need inspection and report the remainder instead.连续比较 5 到 10 个同类任务，记录以下结果：
| 指标 | 正向信号 | 停止或缩小的信号 |
|---|---|---|
| Lead time | 从开始到可验收报告或 PR 的时间下降 | 等待编排、重跑和合并超过节省的时间 |
| Precision | verifier 后被人类接受的 finding 比例高 | false positive 仍大量进入 review |
| Rework | 测试和 review 打回次数下降 | agent 制造的返工抵消并行收益 |
| Token per accepted outcome | 增量成本与少掉的人类工作相称 | agent 数和 token 上升，交付未改善 |
| Operational control | pause、inspect、stop 和恢复足够可预测 | 需要跨 session 或跨进程救援的 run 成为常态 |
先证明一个窄流程有效，再保存它为团队 command。对于动态 workflow，最有价值的复用物不该是“再开更多 agent”的 prompt，而是已经被验证过的输入范围、验证闭环和停止阈值。
7. 最终判断
Claude Dynamic Workflows 把多 Agent 开发中最容易失控的一层显式化了：编排。独立 context、脚本变量、后台运行和 adversarial verification 使它能承载单个会话难以协调的广度任务。它尤其适合审计、迁移、研究和任何可以被拆成大量独立、可验收单元的工程工作。
它的风险同样明确：自动批准的编辑权限、可线性放大的 token 消耗、同一 session 才能恢复的运行状态，以及多 agent 共享的 spec 误解。真正的门槛并不是能否让 Claude 一次调度 100 个 worker，而是团队是否拥有可让 worker 收敛的 spec、测试、review 和成本边界。
如果只能记住一句话：把 Dynamic Workflows 当作可复用的验证流水线，而不是更快的无人值守开发团队。
来源与研究说明
研究截至 2026-07-16。官方文档与产品公告用于机制、限制和产品方案例。Hacker News 和 GitHub issue 仅作为早期口碑与运维痛点信号，不构成性能统计或采用率证据。
- Anthropic, Orchestrate subagents at scale with dynamic workflows. 运行模型、可用性、权限、上限、保存、恢复、成本与官方示例。
- Anthropic, Introducing dynamic workflows in Claude Code, 2026-05-28. 发布背景、Klarna/CyberAgent 引述与 Bun 案例。文中 case study 是供应商一方叙述。
- Anthropic, How we built our multi-agent research system, 2025-06-13. 多 Agent 的并行收益、成本与任务适配背景。它不是 Dynamic Workflows 的 coding benchmark。
- Hacker News, Dynamic Workflows in Claude Code, 2026-05-28. Early Access 的体验与成本、质量、可控性讨论。
- anthropics/claude-code, Issue #64938. 简单 research 请求被自动扩展为多 agent 路径并消耗大量 token 的公开报告；截至研究日仍 open。
- anthropics/claude-code, Issue #68695. 内置 workflow 按主会话模型继承、缺少 phase 级模型路由的公开请求；标为 enhancement、stale。
- anthropics/claude-code, Issue #69206. 意外 fan-out 至 218 个 subagent 的公开报告；截至研究日仍 open。
- anthropics/claude-code, Issue #74334. 跨进程运行控制与恢复的公开需求，不作为采用率统计。
- Google Trends, Claude Dynamic Workflows query. 条件为 Worldwide、2026-05-01 至 2026-07-16、All categories、Web Search。本文图表与数值采集于 2026-07-15。