一、Dynamic Workflow 一句话解释

先让模型根据当前任务生成一份工作流脚本，再由独立 Runtime 按脚本编排大量 Subagent。

这是一种通用的智能体编排范式：计划由模型动态生成，执行由确定性的 Runtime 接管。任何智能体系统都可以采用这种方式，Claude Code 的 dynamic workflows 是其中一个参考实现。

二、核心思想：把计划从上下文移到代码里

传统多智能体编排中，由一个编排模型（orchestrator）逐轮决定下一步做什么，所有中间结果都回流到它的上下文窗口。这带来两个瓶颈：

- 不稳定：每一轮的决策都依赖模型当时的输出，同一任务跑两次路径可能不同

- 不可扩展：中间结果挤占上下文，agent 数量一多就装不下

Dynamic Workflow 的解法是把计划"物化"为一份可执行脚本：循环、分支、并行关系、中间结果都由脚本持有，模型上下文只接收最终汇总结果。流程的确定性从模型输出转移到脚本本身——这是它能扩展到几百上千个 agent、且可复现的原因。

三、Dynamic Workflow 的两个阶段

第一阶段：模型生成脚本

模型分析任务，生成一份适合该任务的工作流脚本（如 JavaScript）。一份完整的计划通常包含七个部分：

• 执行阶段划分（phases）
• SubAgent 数量
• 并行关系
• 循环和分支
• 中间结果的产出与存储（便于停止或恢复）
• 验证策略（产出时自检 / 交由独立 agent 交叉验证）
• 最终汇总方式

效果好的脚本可以保存下来复用：同一份编排逻辑可反复执行、可读、可 diff、可手工修改后重跑。这意味着可复用的不只是 prompt 或 agent 定义，而是编排本身。

第二阶段：Runtime 独立执行

脚本在与对话隔离的环境中由 Runtime 执行：

• 不再由模型每轮临时决定下一步，而是由脚本决定
• 并行调度 Subagent，主会话保持可用
• 中间结果保存在脚本变量中，不进入模型上下文
• 跟踪各阶段的运行状态
• 支持暂停和恢复：已完成的 agent 返回缓存结果，其余继续运行

一个稳健的 Runtime 通常还需要这些约束设计：

- 职责分离：脚本只负责编排，不直接访问文件系统和 shell，实际读写和执行由 agent 完成

- 资源上限：限制并发数和单次运行的 agent 总数，防止失控的循环耗尽资源

- 无中途人工介入：运行中不接收用户输入，需要分阶段确认时拆成多个 workflow

四、Dynamic Workflow 与其他编排方式的区别

维度	普通 AI 工作流	模型即编排器（如 Subagent）	Dynamic Workflow
流程是谁设计的	工程师	模型逐轮临时决定	模型一次性生成脚本
流程何时创建	开发阶段	运行期间，每轮一次	运行任务之前或运行期间
谁决定下一步	预设流程	模型	脚本
中间结果存在哪里	外部系统	模型上下文窗口	脚本变量
规模	固定	每轮几个委派任务	单次运行几十到上千个 agent
可复现性	高	低	高（同一脚本可重跑）

五、适用场景

适合"一个 agent 单次处理不完、且流程可以预先规划"的任务：

• 全代码库审计、Bug 扫荡
• 涉及成百上千个文件的批量迁移
• 多信源交叉验证的深度研究
• 从多个独立角度起草方案再相互评审

不适合的场景：流程无法预先规划、需要频繁人工介入、或单个 agent 一轮就能完成的任务——这些用普通对话或单 agent 委派即可。

六、参考实现：Claude Code

Claude Code 的 dynamic workflows 是该范式的落地示例：模型为任务生成 JavaScript 脚本，后台 Runtime 并发调度 subagent（上限 16 并发、单次 1,000 个 agent），脚本可保存为命令复用，并内置 /deep-research 等工作流。其他智能体框架实现同样范式时，可参考它的脚本持有计划、变量持有中间结果、Runtime 与会话隔离等设计。