5 月 28 日，Anthropic 发布 Claude Opus 4.8，随之带来了一个新功能——Dynamic Workflows。先看一个数字：11 天、约 75 万行 Rust 代码、99.8% 的原有测试通过。这是 Bun 作者 Jarred Sumner 把整个 Bun 运行时从 Zig 迁移到 Rust 的成绩单，扛起这场迁移的主力正是 Dynamic Workflows。
解决什么问题
官方博客的原话：
Some problems are too big for one pass by a single agent, especially in complex, legacy codebases: a bug hunt across an entire service, a migration that touches hundreds of files, a plan you want stress-tested from every angle before you commit to it.
整个服务范围的 bug 排查、动辄上百个文件的迁移、需要从各个角度反复推敲才敢拍板的方案——这些任务的共同点是规模超出了一轮对话能协调的范围。Dynamic Workflows 给出的答案，是让 Claude 把编排过程写成一段可执行的脚本。
和已有的协作原语有什么不同
理解 Workflow 的位置，得先把 Claude Code 已有的几层协作能力捋一遍：
- 单个 session：一个 Agent 实例从头干到尾，串行处理
- subagent：主 Agent 派生出若干小弟去搜文件、读代码、跑命令，干完汇报回来
- Agent Teams：多个独立的 Claude Code 实例像团队一样并行协作，队员之间能互相通信
这几层的共同瓶颈：编排者始终是 Claude 本身。每一个 subagent 的返回结果都要先回到 Claude 的上下文窗口，它读完才能决定接下来怎么走。上下文窗口装不下那么多中间结果时，这套机制就会崩溃。
Workflow 的思路换了一个方向：Claude 不再亲自逐轮调度，它先把整个编排过程写成一段 JavaScript 脚本——循环、分支、中间结果的收集全部固化在代码里——再交给一个独立运行时去执行。
A workflow moves the plan into code. With subagents and skills, Claude is the orchestrator; it decides turn by turn what to spawn next, and every result lands in Claude's context. A workflow script holds the loop, the branching, and the intermediate results itself, so Claude's context holds only the final answer.
运行模型：JavaScript 运行时当指挥，LLM 当临时工
把架构理解清楚需要破除一个最常见的误解：Workflow 不是某个跑在 Anthropic 服务端的编排引擎，它是你本机跑的一段 JavaScript 编排脚本——agent()、parallel()、pipeline() 这些都是在你电脑上执行的控制流。真正去请求服务端的，是脚本里 agent() 调用 spawn 出来的每个 subagent，而 subagent 调模型的方式和你主对话窗口完全一样。
运行时本身是"无脑的、确定性的 JavaScript 运行时"，只会循环、拼字符串、await，本身不含任何 LLM。只有当脚本执行到 agent(...) 那一行，运行时才去临时雇一个 LLM subagent 干活。而"真正的 Agent"——你正在对话的主 Claude——在脚本执行期间根本没在运行：它发出 Workflow 调用后那一回合就结束了，脚本在后台独立跑，跑完用一条通知把它叫醒去读最后结果。
Bun 迁移案例：三个阶段跑完 75 万行 Rust
Jarred Sumner 把 Bun 从 Zig 迁移到 Rust，用了三个串联的 Workflow：
阶段一：生命周期映射。第一个 Workflow 专门给每个 struct field 算出对应的 Rust lifetime。这是后续所有移植工作的地基——Rust 的内存安全建立在生命周期标注之上，这层没算对，后面写的 .rs 文件根本过不了编译。
阶段二：并行文件移植。数百个 agent 同时开工，每个 .zig 文件移植成行为等价的 .rs 文件，每个文件还配两个 reviewer 做交叉审查。和 Agent Teams 对比：Agent Teams 同时跑三五个队员就到协调上限了，而这里是几百个 agent 并行外加双重 review。
阶段三：编译与测试的 fix loop。文件移植完只是半成品，第三个工作流驱动整个 build 和 test 套件，靠循环逻辑反复迭代修复，直到两者都干净跑过。
不是 DAG，但执行轨迹是 DAG
Workflow 的程序本身不一定是 DAG——你能写循环，比如"一直找 bug，直到连续两轮都没有新增"——但任何一次执行的轨迹，一定是 DAG。循环在"程序"里，展开成"轨迹"后就被拉直成链了。这正是它比传统 DAG 编排器更灵活的地方：传统工具的图在跑之前就定死了，而 Workflow 的拓扑是命令式脚本跑出来的，形状运行时才定。
什么时候用 Workflow、什么时候不用
适用场景：代码库范围的批量排查（安全审计、全库 bug 扫描）、大规模迁移（Bun 是最极致的例子）、需要对抗式验证的关键决策、长尾清理（夜里挂着扫描问题、逐个开 PR）。
杀鸡用牛刀的场景：一两步就能搞定的小修补、需要中途频繁拍板的探索性工作、涉及安全和支付的高风险代码改动。
和 n8n/Coze/Dify 的区别
表面看起来都是"把 LLM 和工具按流程编排"，但 Workflow 多了一层：模型是"写编排脚本"的那个，而不是"在预设节点里填内容"的那个。这个区别带来两个实际后果：
- 载体是图灵完备代码（可以有循环、动态扇出、数据决定的分支），而可视化 DAG 表达不了这些
- 每个节点是个自主 agent（有工具调用能力），而非固定连接器
也正因为 Workflow 对前沿模型的能力依赖得这么深，它和 Opus 4.8 同天发布不是巧合：当你要让数百个 agent 并行干活、互相交叉验证时，每个节点的可靠性就被放大了。Opus 4.8 专门强化的"诚实度"（假进度报告、假完成状态的发生率比 4.7 低约一半），正是"数百 agent 交叉验证"这套打法能成立的前提。
Dynamic Workflows 目前是研究预览，需要 Claude Code v2.1.154+，在 Max、Team 计划和 API 使用场景默认开启，Pro 计划需手动打开。