上一篇写 Hooks 的时候,Claude 还是个”听话的对话窗口”——你给指令,它一步步干,跑完报告。5/28 跟 Opus 4.8 一起放出来的 Dynamic Workflows 改了一件事:Claude 不亲自指挥了,它写一段 JavaScript 脚本,把整个调度流程写进代码里。
我第一次看到这个功能的时候,第一反应是”这不就是 Subagent 加了自动拆分?“。跑了一个真实的任务才意识到不一样。Subagent 是主 Claude 在脑子里调度,每派一个都要写一段 prompt 喂给子 Agent,prompt 本身也要吃 context。Dynamic Workflows 把这件事搬出主 Claude 的脑子——Claude 只负责写一个调度脚本,脚本跑的时候主对话窗口在睡觉。
它的本质
Dynamic Workflows 不是新加一个命令。它是让 Claude 根据你的需求,动态生成一段 JavaScript 编排脚本,然后一个 runtime 在后台跑这个脚本。脚本里调 agent()、pipeline()、parallel() 这些控制流,中间结果存在脚本变量里,不进主对话的 context。
举一个我跑过的例子:50 个服务的 monorepo,找”日志里漏的 PII”。Claude 写了个大概这样结构的脚本:
const services = await agent("list-services", "列出所有服务名");
const findings = await parallel(
services.map(svc =>
() => agent("find-pii", `在 ${svc}/src/** 找可能漏的 email/body/token`)
)
);
// 对抗式校验:每条发现派第二个 agent 来反驳
const verified = await parallel(
findings.flat().map(f =>
() => agent("refute", `这是真的 PII 泄漏还是测试代码?${f.snippet}`)
)
);
return verified.filter(v => v.verdict === "real");
这种脚本是我以前自己手写 Harness 才干的事。现在 Claude 帮我写,我负责审。
三种触发方式
不是每次都要写脚本。Claude Code 提供三种开 Dynamic Workflows 的方式:
-
在 prompt 里带 “workflow” 关键词。比如”用一个 workflow 把 src/routes 里的接口扫一遍”。Claude Code 会把”workflow”高亮,自动为这个任务写脚本。误触可以按
Alt+W取消。 -
/effort ultracode。把 effort 拉到 xhigh,再让 Claude 自己判断什么时候该开 workflow。一个请求可能连开三个——一个读代码,一个改,一个验证。日常 high effort 就够了,ultracode 适合那种”这活很大你自己看着办”的场景。 -
内置
/deep-research。这是个开箱即用的 workflow,专门做”上网 + 读代码 + 交叉验证”的深度调研。给它一个问题,它自己拆成几十个 subagent,查文档、查仓库代码、跑对照验证,最后汇总成带引用的报告。没通过验证的结论直接筛掉。第一次用 workflow 我建议从这个入手。
1000 Agent 听起来吓人
官方上限是单次 1000 Agent,16 个并发。但实际不会跑到 1000——我那个 PII 扫描跑了 50 个左右已经烧掉几美元。第一次 /deep-research 跑了大概 $8。Anthropic 在文档里反复提醒”先拿小任务试试水”,不是客气话。
我学到的成本控制:
- 用 model 路由。脚本里可以指定哪个 stage 用哪个模型。信息搜集用 Haiku,深度推理用 Opus 4.8,能砍掉一半账单。
- 先小后大。第一次先 “scan services/auth”,看 5-10 个 agent 的产出形态,再扩到全量。
- 关掉 auto mode 的话 workflow 跑得很慢。每个 subagent 都要弹权限确认,16 个并发变 1 个串行,token 反而烧更多。
跟 Subagent / Agent Teams 不是替代
容易踩的认知错误是”workflow 比 Subagent 强所以只用 workflow”。不对。这三个是分层的:
- Subagent:你手动派,3-5 个专家活,结果回主对话
- Agent Teams:3-5 个 Claude 实例像团队协作,队友之间能直接发消息、共享任务列表
- Dynamic Workflows:几十到几百个独立任务,主 context 一定爆,需要对抗式校验
判断标准:超过 10 个文件,或者超过 3 个独立子任务,再考虑 workflow。否则直接做更快。
第一次跑的工作流
我自己跑过最有价值的一次是给一个老项目做安全审计。代码是别人写的,五年前的结构,我接手不到一周。正常做法是一个个文件读,找可疑的鉴权缺失、硬编码密钥、不安全依赖。
我用 workflow 干这件事。Claude 写的脚本分三阶段:
- 第一阶段:20 个 subagent 并行扫不同的目录,每个负责找特定类型的漏洞
- 第二阶段:5 个 verifier 专门挑刺——“这个真的是漏洞还是误报?”
- 第三阶段:3 个 agent 整合报告,按严重程度排序
我盯着 /workflows 视图看进度条跑完,最后拿到一份 47 个发现的报告。我自己手动审计大概需要两天。这套工作流跑了 40 分钟,花了 $12 左右。
不一定每次都这么值。但遇到那种”必须扫整个代码库”的活,workflow 是目前唯一靠谱的方案。
还在研究预览
Dynamic Workflows 现在是 research preview 状态,几个限制要记着:
- 需要 Claude Code v2.1.154+ 和 Opus 4.8
- Pro plan 用不了,至少 Max
- 同一个 session 内可以断点续传,但退出 Claude Code 之后下次新 session 不会自动恢复
- 脚本本身不能直接读文件或执行命令——所有”动手干”的活必须通过
agent()派出去
最后一个限制我一开始没理解。脚本是沙箱里跑的,它不能 fs.readFileSync,必须派一个 agent 去读。这是故意的设计:脚本只负责调度,干活的是 agent。
下一步
Dynamic Workflows 把”AI 并行”从十几个推到了上千。关键不是数字大,是把调度逻辑搬出主 context 这件事——意味着以前一次对话装不下的活,现在能跑完了。
下一篇按计划写 Skills——把项目规则做成可复用模块。Dynamic Workflows 解决”大”,Skills 解决”散”,两件事正好是 Claude Code 日常最常面对的两个维度。
系列文章和进度在 Vibe Coding 工作流。