先把它讲明白
如果说过去的 Claude Code 是"一个能力很强的开发者，按顺序一件一件做事"，那么动态工作流就是让它摇身一变成项目经理：先把一个大到一次做不完的任务拆解成计划，再亲手写一段调度脚本，雇佣几十到几百名"临时工"（子代理）同时开工，并安排另一批人专门挑刺、复核，最后把一份经过交叉验证的成品交到你手上。
动态工作流是一段 Claude 现场为你的任务编写的 JavaScript 编排脚本。脚本本身持有循环、分支与中间结果，由一个独立运行时在后台执行；而你的会话保持流畅响应，Claude 的上下文里最终只留下那个结论。
它到底是什么
2026 年 5 月 28 日，Anthropic 随 Claude Opus 4.8 一同推出了 Dynamic Workflows（动态工作流），目前为研究预览（research preview）状态。它要解决的是一类特定问题——大到单个智能体一遍跑不完的任务：横跨整个服务的 bug 排查、触及成百上千个文件的迁移、需要从多个角度反复压力测试才敢动手的方案。
官方对它的定义非常精确：一段编排子代理的 JavaScript 脚本。你用自然语言描述任务，Claude 为这个任务现场写出脚本，再由一个专门的运行时在后台执行。脚本负责"决定启动什么、按什么顺序、用什么条件和循环逻辑"，并把中间状态保存在脚本变量里——这些变量活在对话之外。
它解决的三类"太大"的问题
- 全代码库级排查与审计——bug 扫描、性能剖析优化、安全审计。并行搜索整个仓库，然后对每一条发现独立复核，让报告里只剩下真实问题。
- 大规模迁移与现代化——框架替换、API 弃用处理、跨越数千文件的语言移植，端到端完成。
- 需要"复核两遍"的关键工作——当一个错误答案代价高昂时，工作流让 Claude 对同一问题做多次独立尝试，并派出"对抗性代理"在你看到结果之前先想办法推翻它。
需要 Claude Code v2.1.154 或更高版本。覆盖 CLI、桌面端、VS Code / JetBrains 扩展、claude -p 无头模式与 Agent SDK。可用于 Anthropic API，以及 Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry。Max / Team 默认开启；Pro 需在 /config 里打开；Enterprise 发布时默认关闭，由管理员开启。
关键只有一句话："谁掌握计划"
理解动态工作流，绕不开它和已有的两个老朋友——子代理（Subagents）和技能（Skills）——的根本区别。三者都能跑多步任务，真正的分水岭是：计划掌握在谁手里。
用 subagents 或 skills 时，Claude 本人是编排者：它一回合一回合地决定接下来派谁去做，而每一个中间结果都会落回 Claude 的上下文窗口。任务一大，上下文很快被中间产物塞满，既烧 token 又容易"跑偏"。
工作流则把计划搬进了代码。脚本自己持有循环、分支和中间结果，所以 Claude 的上下文里只留下最终答案。更妙的是——把计划写成代码之后，它还能施加一种"可复用的质量模式"：让独立代理之间互相对抗性评审、或者从几个角度分别起草方案再相互权衡，从而得到比"单遍跑完"更可信的结果。
| Subagents 子代理 | Skills 技能 | Workflows 工作流 | |
|---|---|---|---|
| 它是什么 | Claude 派生的一个"工人" | Claude 遵循的一套指令 | 运行时执行的一段脚本 |
| 谁决定下一步 | Claude，一回合一回合 | Claude，按提示词走 | 脚本本身 |
| 中间结果存在哪 | Claude 的上下文窗口 | Claude 的上下文窗口 | 脚本变量（对话之外） |
| 可复用的是 | 工人的定义 | 那套指令 | 编排逻辑本身 |
| 规模 | 每回合几个委派任务 | 同子代理 | 每次运行数十到数百个代理 |
| 被打断时 | 重启该回合 | 重启该回合 | 同一会话内可断点续跑 |
把编排写进脚本，带来的不只是"能跑更多代理"。它把上下文卸载（intermediate results 不再挤占 Claude 的注意力）、可复现的质量纪律（对抗评审、多角度投票）和可断点续跑的状态机三件事一次性解决了。这是从"更聪明的助手"到"可靠的工程编排系统"的跨越。
一次运行内部发生了什么
当一个工作流被触发，它不是简单地"多开几个窗口"，而是走完一条完整的生命周期。运行时在一个与对话隔离的环境里执行脚本，正是这种隔离让运行可以被追踪、被续跑。
动态规划 · Plan
Claude 根据你的提示词当场制定计划，把大任务拆解成一系列子任务与阶段（phases）。
并行扇出 · Fan-out
把工作分发给同时运行的子代理。每个代理拥有独立视角，从不同角度逼近同一个问题。
对抗证伪 · Refute
另一批代理专门尝试推翻前者的发现——这是"复核两遍"的核心，把站不住脚的结论提前剔除。
迭代收敛 · Converge
运行持续迭代，直到各路答案彼此吻合。这是单遍推理永远到不了的质量层级。
校验合并 · Verify & Fold
结果在被并入之前先经过校验，中间产物留在脚本变量里，不污染 Claude 的上下文。
单一答案 · Deliver
你回到的不是一长串逐回合的对话流水，而是一份协调一致、已过滤的最终报告。
三个让它"靠谱"的设计
- 后台执行，会话不卡。编排发生在对话之外，所以任务再大，会话依然保持响应，计划也不会"跑偏"。运行可以延续数小时乃至数天。
- 进度随时落盘。运行过程中进度持续保存。被中断的任务会从断点接着跑，而不是从头来过。
- 首跑必须确认。工作流第一次触发时，Claude Code 会展示"即将运行什么"并请你确认。组织管理员也可以通过托管设置统一禁用。
怎么用：四种进入方式
官方建议先打开 auto 模式，再用工作流体验最佳。启动一个工作流，你有四条路。
① 在提示词里直接喊出 workflow
想把单个任务当作工作流跑、又不改变整个会话的 effort 等级，只要在提示词里任意位置带上 workflow 这个词即可。Claude Code 会高亮这个词，并为任务写出脚本，而不是逐回合慢慢做。
# 审计 src/routes/ 下每个 API 端点是否漏掉鉴权
Run a workflow to audit every API endpoint
under src/routes/ for missing auth checks如果误触发了，按 alt+w 可以让本次提示词忽略这个关键词。
② 用 ultracode 让 Claude 自己决定
Ultracode 是 Claude Code 的一个设置，把 xhigh 推理强度与自动工作流编排组合在一起。开启后，Claude 会为会话中每一个实质性任务主动规划工作流，不必你开口。
/effort ultracode开启后，一个请求可能连环触发几个工作流：一个用来理解代码，一个用来改动，一个用来验证。它只对当前会话生效，新会话自动重置。回到日常琐碎工作时，用 /effort high 退回即可。注意：仅在支持 xhigh 的模型上可用。
③ 跑内置工作流 /deep-research
体验工作流最快的方式，是 Claude Code 自带的 /deep-research。它围绕一个问题从多个角度扇出网络搜索、抓取并交叉核对来源、对每条主张投票，最后返回一份带引用的报告——没通过交叉验证的主张会被直接过滤掉（需要 WebSearch 工具可用）。
/deep-research What changed in the Node.js
permission model between v20 and v22?④ 把好用的运行存成命令复用
当 Claude 为某个你会重复做的任务写出了工作流，可以把那次运行的脚本存成命令。运行 /workflows，选中那次运行，按 s 保存。下次它就以 /<名字> 出现在自动补全里，每次跑同一套编排。
.claude/workflows/—— 存在项目里，克隆仓库的人都能用~/.claude/workflows/—— 存在主目录，所有项目可用，仅自己可见
同名时，项目级工作流优先于个人级。
运行中的管理与审批
运行 /workflows 打开进度视图，可以看到每个阶段的代理数、token 总量与耗时，并钻取到单个代理查看它的提示词、最近的工具调用和结果。常用按键：
| 按键 | 作用 |
|---|---|
↑ / ↓ | 选择阶段或代理 |
Enter / → | 钻入阶段，再钻入某个代理读取细节 |
p | 暂停 / 恢复运行 |
x | 停止选中代理；焦点在整个运行上时停止整个工作流 |
r | 重启选中的运行中代理 |
s | 把该次运行的脚本存成命令 |
你的权限模式只控制"启动提示"。无论会话处于什么模式，工作流派生的子代理一律以 acceptEdits 模式运行，文件编辑自动批准，并继承你的工具白名单。不在白名单里的 shell 命令、网络抓取和 MCP 工具仍可能在运行中弹窗。长任务前，先把代理需要的命令加进白名单，能避免中途被打断。
关掉它
三种方式任选其一：在 /config 里关闭 Dynamic workflows；在 ~/.claude/settings.json 设 "disableWorkflows": true；或设环境变量 CLAUDE_CODE_DISABLE_WORKFLOWS=1。组织级禁用走托管设置。
它做不到 / 不允许的事
运行时施加了一组明确约束。理解它们，能帮你避免对工作流抱有不切实际的期待。
| 约束 | 为什么 |
|---|---|
| 运行中无法插入用户输入 | 只有代理的权限弹窗能暂停运行。若需要在阶段之间签字确认，就把每个阶段拆成独立的工作流。 |
| 脚本本身不能直接读写文件 / 跑 shell | 读写文件、执行命令是代理的活；脚本只负责协调代理。 |
| 最多 16 个并发代理（核少更少） | 限制本地资源占用。 |
| 单次运行最多 1,000 个代理 | 防止失控的无限循环。 |
| 续跑仅限同一会话 | 退出 Claude Code 后，下次会话会从头重跑该工作流，而非接着跑。 |
"数十到数百并行"指的是逻辑上调度的代理总量（上限 1000），而"16 并发"是本地同一时刻真正在跑的数量。两者不是一回事——前者决定任务规模，后者决定你机器的吞吐与发热。
已经有人用它做成了什么
研究预览阶段，Anthropic 内部团队和早期用户已经把它用在了相当硬核的场景上。
把 Bun 从 Zig 移植到 Rust
Jarred Sumner 用动态工作流完成了 Bun 的语言移植。一个工作流为 Zig 代码里每个结构体字段映射出正确的 Rust 生命周期；下一个工作流把每个 .zig 逐一改写成行为等价的 .rs——数百个代理并行，每个文件配两名评审；再用一个修复循环驱动构建与测试，直到全部跑通。移植落地后，一个通宵工作流又处理了多余的数据拷贝，并为每处改动各开一个 PR 待最终评审。
发现传统静态分析漏掉的死代码
据 Klarna 高级工程经理 Alessio Vallero 介绍，动态工作流在大型代码库的"发现与评审"类任务上尤其有价值——团队用它识别死代码、挖出传统静态分析没能发现的清理机会，让工程师在维护与重构上推进得更快。
填补"单个子代理"与"完整代理团队"之间的空白
据 CyberAgent 首席系统工程师 Ken Takao 的说法，动态工作流恰好补上了"发射单个子代理"和"搭建一整个代理团队"之间的那段空白：从规划到实现一气呵成，让他们能在不损失可见性的前提下信任更长的运行。
优势与劣势：一份诚实的清单
任何强力工具都有它的代价。下面把"亮点"和"要当心的地方"摊开来讲。
- 上下文卸载。中间结果留在脚本变量里，Claude 上下文只装最终答案——任务再大也不会被中间产物"撑爆"。
- 真正的规模。单次运行可调度数十到数百个代理（上限 1000），把原本要"按季度规划"的工作压缩到几天。
- 可复用的质量纪律。对抗性评审、多角度起草再投票——这是"质量模式"被写进了代码，而不只是"跑得更多"。
- 可断点续跑。进度随时落盘，被中断的运行从断点接着跑（同一会话内）。
- 后台运行不阻塞。编排在对话之外，会话保持响应，运行可延续数小时到数天。
- 编排即代码、可读可改可存。脚本是可读的资产，跑通后能存成命令反复复用。
- Token 消耗显著更高。每个代理都自带上下文开销，单次运行可能比同样的对话式任务"贵得多"。这是最需要警惕的一点。
- 研究预览成熟度。仍在 research preview，行为与边界可能演进，不宜直接押注生产关键路径（Bun 案例本身也尚未进入生产）。
- 运行中无法人工介入。除权限弹窗外不能中途插话；需要阶段签字就得手动拆成多个工作流。
- 本地资源受限。最多 16 个并发，CPU 核心少的机器更低，吞吐受本机制约。
- 续跑跨会话失效。退出 Claude Code 后下次会从头重跑，长任务期间不能随意关闭。
- 需要谨慎圈定范围。官方反复强调：先从一个范围明确的小任务起步，校准消耗，再上"全库审计 / 数千文件迁移"。
和原来的几种模式比，强在哪
Claude Code 的并行 / 委派能力是一条逐步演进的谱系。动态工作流不是"取代"前面几种，而是补上了规模与可靠性的最后一段。
四种编排模式的定位
- 单个会话（Single agent）——一次一件事，顺序推进。可靠但慢，受单一上下文窗口约束。
- 子代理（Subagents）——Claude 逐回合派生"工人"做研究或验证，结果回到它的上下文。适合不需要相互协调的轻量委派。
- 技能（Skills）——Claude 遵循一份 Markdown 指令序列，但它仍是流程的编排者。
- 代理团队（Agent teams）——多个会话通过共享任务列表 / 点对点消息互相协调，各自拥有隔离的上下文，适合需要彼此沟通的跨层协作。
- 动态工作流（Workflows）——把编排写成脚本，由运行时执行；规模、可复现质量、断点续跑三者兼得。
| 维度 | 子代理 | 代理团队 | 动态工作流 |
|---|---|---|---|
| 编排者 | Claude 逐回合 | 各会话点对点协调 | 脚本（运行时） |
| 典型规模 | 每回合几个 | 少量并行会话 | 数十到数百（上限 1000） |
| 中间结果 | 回到 Claude 上下文 | 各会话隔离上下文 | 脚本变量，不占上下文 |
| 可复现质量模式 | 需手动设计 | 需手动设计 | 内建（对抗评审 / 投票） |
| 被打断 | 重启回合 | 各自重启 | 同会话断点续跑 |
| 最适合 | 轻量委派、单次研究/验证 | 需相互沟通的跨层协作 | 一次对话协调不过来的超大任务 |
一句话决策法
- 任务一回合的对话就能协调过来 → 用子代理 / 技能。
- 需要几个会话互相通信、彼此挑战 → 用代理团队。
- 任务大到一次对话协调不过来，或你想把编排固化成可读、可重跑的脚本 → 用动态工作流。
它"填补了发射单个子代理与搭建完整代理团队之间的空白"。当你觉得子代理不够用、又还没必要上一整套代理团队时，工作流往往就是那个刚刚好的中间档位。
什么时候值得开
工作流会派生大量代理，单次运行用掉的 token 可能比对话式做同样的事多出一个量级。运行计入你套餐的用量与速率限制，和普通会话一样。所以"开不开"本质是一道性价比题。
三条省钱 / 控本的做法
- 先小范围试跑。官方头号建议：用一个范围明确的小任务校准消耗，再扩到全库审计或数千文件迁移。
- 大跑之前先看
/model。每个代理默认用你会话的当前模型。如果平时用小模型处理琐事，临开一个 500 代理的审计前忘了切，账单可能差出一个数量级。 - 给不吃重推理的阶段指定小模型。在描述任务时就告诉 Claude：哪些阶段用更小的模型即可。脚本可以把某个阶段路由到不同模型。
当错误的代价远高于 token 的代价时——一次会让你损失数周的迁移、一份必须可靠的安全审计、一个想从各角度压测后再动手的关键方案——工作流的"独立多次尝试 + 对抗证伪"才真正物有所值。反之，日常小修小补、一两个文件的改动，用子代理甚至单会话更划算。
给你的几条实操建议
动态工作流威力很大，但也容易踩坑。下面这套"由轻到重"的上手路径，能帮你既体会到它的价值，又不至于第一次就被 token 账单吓退。
一条循序渐进的上手路径
- 先跑
/deep-research找手感。拿一个真实问题试一次，看着代理在后台分阶段工作、最后拿到一份带引用、已过滤的报告——你会立刻明白工作流和普通对话的区别。 - 再用
workflow关键词跑一个小任务。在提示词里带上这个词，把一个范围明确的小任务交给它，借此校准 token 消耗，再决定要不要扩到全库级别。 - 最后才考虑
ultracode全自动。当你信任它的判断后，再用/effort ultracode让 Claude 自动决定何时动用工作流。记得它只对当前会话生效。
对你的工程工作
- 全代码库审计。做安全审计、鉴权与输入校验检查、不安全模式扫描时，工作流的"并行扫描 + 逐条独立复核"正好对口——让报告里只剩真实问题，而非一堆误报。
- 大规模迁移 / 重构。框架替换、API 弃用处理、跨数千文件的语言移植——Bun 那套"逐文件等价改写 + 修复循环跑到测试全绿"的模式值得直接借鉴。
- 把高频流程存成命令。比如"每个分支合并前的安全审计"，跑通一次后按
s存成项目级命令，团队克隆即用。 - 大跑前先看
/model。每个代理默认用会话当前模型，忘了切模型，账单可能差出一个数量级；不吃重推理的阶段就指定用小模型。
对你的内容生产
- 选题与事实核查。
/deep-research能围绕一个技术话题多角度扇出、交叉验证、过滤掉站不住脚的主张并附引用——这正是做严肃技术内容时最稀缺的"可信底稿"。 - 注意预览期定位。它仍是研究预览，行为可能变；做成"内容选题"很合适，但别把它当成已盖棺定论的生产级特性来背书。
从"一个很强的开发者"到"一个会自己写调度脚本、雇佣并管理一支临时舰队、还安排人互相挑刺的项目经理"——这就是动态工作流真正改变的东西。