Claude Code Dynamic Workflows 实战：让 AI 自己写脚本调度 1000 个 subagent

Claude Code Dynamic Workflows 实战：让 AI 自己写脚本调度 1000 个 subagent（含 /deep-research 用法 + 踩坑）

原文首发于公众号「开发者效率局」，欢迎关注获取更多 Claude Code 实战。
5 月 28 日 Anthropic 跟 Opus 4.8 一起放出来的新功能。一句话：Claude 自己写一段 JavaScript 编排脚本，跑几百到上千个 subagent，整个调度逻辑不占主 context。这意味着你能让一个会话扫完整个仓库找 bug、跑端到端的大迁移、做带对抗式校验的代码审查。这篇讲清楚怎么调起、怎么用、怎么不被 token 烧穿。

痛点：Subagents 跑不动真正的大任务

你之前应该用过 Claude Code 的 Subagents（一个会话内派几个专家并行）和 Agent Teams（多会话直接通信）。它们能解决很多问题，但有一个共同的天花板------调度逻辑活在主 Claude 的 context 里。

实际后果：

你想扫完一个百万行仓库找 bug？派 50 个 subagent，每个查一个目录？主 context 装不下这么多 task 描述 + 结果摘要。
你想做一个跨 200 个文件的大迁移？Agent Teams 的协调消息会把主 context 顶爆。
你想让多个 agent 对同一个发现互相挑刺、迭代到共识？目前没有"对抗式校验"这层基础设施。

简单说：Subagents 是"一个老板带几个工人"，Agent Teams 是"几个团队互相打配合"，但你想要一个工厂------上百个工位同时干、生产管理跟干活的事分开。

5/28 发布的 Dynamic Workflows 就是这个工厂。

它到底是什么：不是新加一个命令，是让 Claude 写代码来调度

很多人第一反应是"哦又一个 /workflow 斜杠命令"。这个理解错了。

Dynamic Workflows 的本质是：Claude 根据你的需求，动态写一段 JavaScript 编排脚本，然后一个 runtime 在后台跑这个脚本，脚本里调度几百到上千个 subagent。

这跟以往所有"AI 并行"的最大区别在于：

维度	Subagents	Agent Teams	Dynamic Workflows
调度逻辑活在哪	主 Claude 的 context	主 Lead 的 context	JavaScript 变量里
并行规模	个位数	3-5 个甜区	同时 16 个 / 总数最多 1000
Context 占用	高（每个 subagent 描述/结果都吃 context）	高（协调消息累积）	几乎为 0（只有最终答案回主会话）
任务来源	你手动派	Lead 派	Claude 自己写脚本拆分
适合做什么	一次性派 3-5 个专家	协作型重构	大规模扫描 / 校验 / 迁移

关键点是那一列"几乎为 0"------以前你派 50 个 subagent，主 context 会被 50 个 task 描述加 50 段结果摘要塞满。Dynamic Workflows 把这些全搬到脚本变量里，主会话只看到最后汇总。

这就是为什么它能跑到 1000 agent 而你不会立即超 context------它本质是把 AI 协调当成 JavaScript 程序来运行，而不是一段提示词。

怎么调起：3 种方式

要求先到位：Claude Code v2.1.154+ 、Opus 4.8 模型、Max / Team / Enterprise plan（Enterprise 需 admin 启用，目前 research preview 状态）。

bash 复制代码

claude --version    # 低于 2.1.154 先 claude update

方式 1：直接说 "create a workflow"

最简单，prompt 里包含 "workflow" 这个词：

text 复制代码

Find all places in this monorepo where we leak request bodies into
error logs. Use a workflow because this needs to scan all 40 services.

Claude 看到 "workflow" 关键词 + 任务规模，会回："This looks like a job for a dynamic workflow, want me to create one?" 你确认，它就开始写脚本。

方式 2：`/deep-research` 内置 workflow

Claude Code 自带了一个开箱即用的 workflow 叫 /deep-research------专门做需要"上网+读代码+交叉验证"的深度调研：

text 复制代码

/deep-research What's the canonical way to migrate from Express to Hono in 2026?

它会自己拆成几十个 subagent：一批查文档、一批读你仓库实际代码、一批跑对照验证，最后汇总成一份带引用的报告。/deep-research 是看懂 Dynamic Workflows 的最快入口------你不需要懂 JS，直接体验完整流程。

方式 3：开 `ultracode` 让它自己决定何时用

text 复制代码

/effort ultracode

这会把 effort 拉到 xhigh，之后 Claude 自己判断什么时候上 workflow。适合"我不想每次提醒它"的场景，但 token 会烧得更猛。

一个真实的实战例子

我自己跑的第一个 workflow：在一个 50 个服务的 monorepo 里找"日志里漏 PII"。

text 复制代码

Use a workflow to scan every service in services/* for places where
we accidentally log user emails, request bodies, or auth tokens.

For each finding, have a second agent verify it's a real leak (not test
code, not a comment) before reporting.

Output a markdown report grouped by service.

Claude 写了一个大概这样结构的脚本（实际更长）：

javascript 复制代码

const services = await spawn("list-services", "ls services/");

const findings = await Promise.all(
  services.map(svc =>
    spawn("scan-logs", `grep for email/body/token in ${svc}/src/**`)
  )
);

// 对抗式校验：每条发现派第二个 agent 来反驳
const verified = await Promise.all(
  findings.flat().map(async f => {
    const refute = await spawn(
      "refute",
      `Is this a real PII leak or test/comment? ${f.snippet}`
    );
    return refute.verdict === "real" ? f : null;
  })
);

return makeReport(verified.filter(Boolean));

注意几件事：

spawn 是脚本暴露的接口------你看不到这些代码，是 Claude 写的，runtime 自己跑
Promise.all 并行------runtime 会自动限速到 16 个并发，不会爆
refute 这一步是 dynamic workflow 的杀招：agents propose → others refute → iterate until converge
进度自动 checkpoint ------中途 Ctrl+C 退出再起，已经跑完的 agent 结果会从缓存读，不会重跑

结果：50 个服务、扫了约 200 个候选点、对抗校验后留下 11 条真发现。整个过程主会话的 context 几乎没动。

跟 Subagents / Agent Teams 怎么选

写下来的决策树：

3-5 个并行的专家活，结果要回到主对话：用 Subagents
任务之间有接口依赖，需要互相通信和协调：用 Agent Teams
几十到几百个独立任务，主 context 一定爆：用 Dynamic Workflows
需要对抗式校验、有"提议-反驳-收敛"模式：Dynamic Workflows 是目前唯一原生支持的

具体场景对应：

任务	推荐
重构 5 个文件，修一下 lint	普通会话即可
重构 30 个路由，类型签名要协调	Agent Teams
扫整个 monorepo 找某类 bug	Dynamic Workflows
对一个改动让 5 个不同视角的 reviewer 评	Dynamic Workflows（对抗式校验）
一份要交付的深度调研报告	`/deep-research`
把所有 console.log 换成 logger	Subagents 就够

5 个必须知道的坑

坑 1：workflow 脚本本身不能访问 fs 和 shell

这是新手最容易踩的认知错误。脚本里能 spawn 出去给 agent 做，但不能直接 fs.readFileSync------因为脚本跑在沙箱里。所有"动手干"的活必须通过 spawn 出去给 agent 做。这是故意的设计：脚本只负责调度，干活的是 agent。

坑 2：1000 agent 是上限，但 token 会让你提前停下

文档说 1000 agent / run，同时跑 16 个。但你大概率不会跑到 1000 ------一个中等任务 50-100 个 agent 就要烧掉几美元到几十美元。我的第一次 /deep-research 跑了大概 $8。

建议：先小范围测试（"scan only services/auth"）确认形态对，看到不对就 Ctrl+C------checkpoint 会保留已完成的，不浪费。

坑 3：必须 Opus 4.8

Sonnet 跑不了 Dynamic Workflows。这点文档很清楚------只有 Opus 4.8 模型能调动这个 runtime。所以 Max plan 是最低门槛，Pro plan 用不了。

坑 4：Research Preview，API 会变

5/28 才发的，还在 preview 阶段。spawn 接口、/deep-research 的输出结构都可能调整。别把 workflow 脚本写死进 CI。

坑 5：Enterprise 默认禁用

如果你在公司用 Enterprise plan，开 workflow 之前先去 admin settings 启用 ，不然 /deep-research 会直接报"not enabled for your org"。

我的实战建议

跑了一周下来的几条经验：

第一次用 /deep-research 入门------不用学 JS，直接看到完整工作流
第二次自己派一个 scan 类的 workflow------选一个明确的"全仓库扫某类问题"的任务
第三次开始用对抗式校验------这是 Dynamic Workflows 区别于其他工具的杀手锏
ultracode 慎用------账单会很难看，日常 high effort 就够
小范围验证 → 再全量跑------先 "scan services/auth"，看 5-10 个 agent 的产出形态，再扩到全量

总结

5/28 发布的 Dynamic Workflows 把"AI 并行"这件事从十几个量级推到了上千。关键不是数字大，是调度逻辑搬出主 context 这件事------意味着你能跑全仓库级别的扫描和校验。

调起方式 3 选 1：

在 prompt 里说 "use a workflow"
用内置 /deep-research
开 ultracode 让 Claude 自己判断

它跟 Subagents / Agent Teams 不是替代关系------Subagents 管小活、Agent Teams 管协作活、Dynamic Workflows 管大规模 + 对抗校验的活。三档配合用才合理。

如果觉得有帮助，欢迎点赞收藏 👍

更多 Claude Code 实战，关注公众号「开发者效率局」，每周二/四更新。

Claude Code Dynamic Workflows 实战：让 AI 自己写脚本调度 1000 个 subagent