Dynamic Workflow：把编排逻辑从脑子里搬出来
2026 年 5 月 28 日，Anthropic 给 Claude Code 加了一个叫 Dynamic Workflows 的功能（research preview）。Bun 团队用它 11 天把 75 万行 Zig 代码迁移到 Rust，99.8% 测试通过。
但最值得关注的不是”75 万行”或”11 天”这些数字。而是一个安静的架构变化：编排计划从模型的 context window 里搬了出来，变成了一段可以阅读、可以 diff、可以重跑的脚本。
一个类比
想象一个项目经理。以前他所有任务都记在脑子里：谁在做什么、哪个做完了、哪个卡住了。每一步他都亲自决策。结果就是——他脑子里的”工作记忆”塞满了调度细节，真正用来思考问题解决方案的空间反而被挤压了。
Dynamic Workflow 做的事情相当于：经理把调度逻辑写成了一份操作手册，交给一个执行系统去跑。他的脑子终于可以专注在问题上。
在 Claude Code 的语境里：
- 以前：Claude 在对话中逐 turn 决定下一步干什么，每个 subagent 的结果都回到它的 context window。context 被中间过程填满，注意力花在管理上而不是解题上。
- Dynamic Workflow：Claude 先写一段 JavaScript 脚本，脚本负责编排 subagent。脚本在后台跑，session 不被阻塞。中间结果存在脚本变量里，Claude 的 context 只接收最终答案。
四种编排模式
Claude Code 官方文档把 agent 编排分成四种模式：
| Subagents | Skills | Agent Teams | Workflows | |
|---|---|---|---|---|
| 是什么 | Claude 派出的工作者 | Claude 遵循的指令 | Lead agent 监督多个 peer session | 运行时执行的脚本 |
| 谁决定下一步 | Claude，逐 turn | Claude，按 prompt | Lead agent，逐 turn | 脚本 |
| 中间结果在哪 | Claude 的 context | Claude 的 context | 共享任务列表 | 脚本变量 |
| 可复现的是什么 | worker 定义 | 指令内容 | 团队定义 | 编排逻辑本身 |
| 规模 | 每 turn 几个 | 每 turn 几个 | 少数长期 peer | 数十到数百个 agent |
| 中断后 | 重启 turn | 重启 turn | peers 继续跑 | 可在同一 session 恢复 |
前三种模式有一个共同点：计划活在模型的 context window 里。 Claude 一边推理一边决策，每个中间结果都挤进 context。这在任务简单时不是问题，但一旦规模上来——比如审计几百个文件、迁移整个代码库——context 就会被 bookkeeping 占满，模型开始管理混乱而不是解决问题。
Workflow 打破了这个限制。计划变成了代码。
什么时候用什么
一个好的判断框架：
目标清楚，步骤不多 → 直接让 Claude 做。最简单的情况，不需要任何编排。你问它答。
目标清楚但步骤多 → Subagents 或 Skills。Claude 在 context 里逐步编排，派 worker 做子任务。适合写一个功能、修一个 bug、做一次研究。规模在几个到十几个子任务。
任务能拆成并行的独立子任务 → Agent Teams。一个 lead agent 监督几个 peer session 并行跑。适合”同时研究三个方向然后汇总”。
需要大规模并行，或者需要交叉验证确保质量 → Dynamic Workflows。Claude 写脚本编排几十到几百个 agent。适合代码库迁移、全量审计、多角度研究。
关键区分点不是”任务大小”，而是计划的确定性和质量要求：
- 如果你能预先列出所有步骤 → Subagents 够用
- 如果任务需要”多角度探索 + 收敛验证”才敢信 → Dynamic Workflow
- 如果不确定会找到什么、需要根据中间结果动态分支 → Dynamic Workflow
Dynamic Workflow 的杀手锏：质量模式
并行只是表面优势。更深层的是：因为计划是代码，它可以强制执行质量模式。
Anthropic 的描述很精确：“agents 从不同角度解决问题，其他 agents 尝试反驳已有发现，run 持续迭代直到答案收敛。”
内置的 /deep-research 就是这个模式的实现：
多个 agent 从不同角度搜索
↓
fetch 并交叉检查来源
↓
对每个声明投票
↓
过滤掉没通过交叉验证的声明
↓
输出带引用的报告
这不是简单的”人多力量大”。这是一个写在代码里的认知流程：探索 → 质疑 → 收敛。每一步都可审计。
传统 agent 做不到这一点，因为所有中间判断都在 Claude 的 context 里，Claude 既当运动员又当裁判。Workflow 把这些角色拆开，分配给不同的 agent，由脚本强制执行流程。
限制
Dynamic Workflow 不是万能的。几个硬约束：
运行中不能接收用户输入。 脚本一旦启动，只有 agent 的权限提示能暂停它。如果需要阶段之间的人工 sign-off，得把每个阶段拆成单独的 workflow 跑。
workflow 本身不能直接读写文件系统或跑 shell。 它只负责协调 agent。所有实际操作由 agent 执行，脚本做的是调度。
并发上限 16 个 agent。 单次 run 总量上限 1000 个。超过这个规模需要拆分。
成本可能很高。 数百个 agent 跑几十轮，token 消耗是传统 agent 的几十倍。Bun 迁移 75 万行的成本没有公开，但不会便宜。
与 Advisor Strategy 的关系
Advisor Strategy 和 Dynamic Workflow 解决的是不同层面的问题：
- Advisor 是推理层的模型协作：executor 做事，advisor 在决策点介入。关心的是单个 agent 内部的质量提升和成本控制。
- Dynamic Workflow 是编排层的架构选择：计划外化为脚本，多 agent 并行 + 交叉验证。关心的是任务级别的规模化和质量保证。
两者可以组合：workflow 里的每个 subagent 都可以用 advisor pattern，在大规模并行的同时控制单个 agent 的成本。
更大的趋势
Dynamic Workflow 代表的方向不只是”更多并行”。它是一个更深的转变：AI agent 的核心逻辑正在从”对话中的即兴发挥”变成”可工程化的流程代码”。
以前你跟 Claude 说”帮我审计所有 API 端点”，它在 context 里逐步做，做完了就完了。下次做同样的事，又是从零开始。
现在 Claude 会写一个脚本。这个脚本可以保存（/workflows → s），可以 diff 看看它打算怎么做，可以重跑，可以分享给团队，可以基于它迭代改进。
编排逻辑从消耗品变成了资产。这可能比并行本身更重要。
相关阅读：Advisor-Strategy-小模型干活大模型把关 | harness-engineering | agent-architecture