本文灵感来自 riba2534 的这篇推文，文章对 Claude Code 的 Dynamic Workflows 做了详细的分析。本文在此基础上补充两点：一是用一条清晰的演进线把 Agent / Subagent / Skill / Agent Teams / Workflow 串起来，二是用开源项目 bmad-automator 作为"中间态"的活样本来对比。
一句话总结整篇文章
Dynamic Workflows 做的事情，就是把原来主会话里 Claude 的决策逻辑，从"脑子里想的"变成"写在文件里的"，最后变成"机器跑的"。 每一步都是把 Claude 从循环里多退出一层。
Claude Code 编排能力的四层演进
在理解 Workflow 之前，得先看清 Claude Code 现有的几层协作能力是怎么一步步叠加的。
第一层：单会话（Session）
最底层。一个 Claude 实例从头干到尾，串行处理所有任务。你问一句它答一句，工具调用也是排队的。
Claude 的角色：唯一的执行者 + 决策者。
第二层：Subagent
主 Agent 派生出若干小弟去搜文件、读代码、跑命令，干完把结果汇报回来。小弟的生命周期很短，任务结束就消失。
Claude 的角色：决策者 + 调度者。每一步"派谁去干什么"都由 Claude 实时决定，小弟的结果要回到 Claude 的上下文窗口，它读完才能决定下一步。
第三层：Agent Teams
多个独立的 Claude Code 实例像团队一样并行协作，队员之间还能互相通信。适合"开会讨论"式的任务，比如前端和后端同时开工。
Claude 的角色：团队中的一员，但每个成员都有自己的上下文。协调成本随人数上升。
第四层：Dynamic Workflows
这一次 Claude 不再亲自逐轮调度。它先把整个编排过程写成一段 JavaScript 脚本——循环、分支、中间结果的收集全都固化在代码里——再交给一个独立的运行时去执行。
Claude 的角色：脚本作者。写完就"去睡觉"了，只有最终结果才把它叫醒。
这四层的共同瓶颈，以及 Workflow 怎么突破它
前三层有一个共同的瓶颈：编排者始终是 Claude 本身。
它逐轮决策下一步派谁去干什么，每一个 subagent 的返回结果都要回到 Claude 的上下文窗口里。这套机制在任务规模不大时很灵活，可一旦要协调几十上百个并行任务：
- 上下文窗口装不下那么多中间结果
- Claude 的注意力被海量过程信息稀释
- 编排逻辑是临时的，下次还得重新来
Workflow 换了个思路：脚本自己持有循环、分支和中间结果，Claude 的上下文里只剩下最后那个答案。
用一句话概括这个分工：
JavaScript 运行时当指挥（无脑、确定性），在
agent()点临时雇 LLM 干活，主 Agent 全程在睡觉，只在最后被叫醒读结果。
bmad-automator：第二层的"标准化版本"
在理解了这条演进线之后，开源项目 bmad-automator 提供了一个"中间态"样本。
它是什么
bmad-automator 是一个 BMAD（AI 驱动的敏捷开发方法论）的编排工具，自动化了 story 的完整开发循环：
创建故事 → 实现故事 → (可选) 测试生成 → 对抗性代码审查 → 提交验证 → 触发回顾
它的编排模型
核心循环是：
Claude (编排者) → spawn tmux 子会话 (subagent) → 读回监控结果 → 决定下一步 → 再 spawn
具体来说：
- 编排者：Claude 自身，按预定义的 step 文件（markdown）逐步执行
- 子任务：通过
tmuxspawn 独立的 Claude 或 Codex 会话 - 状态管理：markdown state doc +
sprint-status.yaml - 验证门控：review 完成不靠子任务退出判断，而是验证 sprint-status 的实际状态
它在演进线上的位置
bmad-automator 停在第二层——subagent 的标准化封装。它做了两件有价值的事：
- 把 subagent 的使用方式标准化：不是每次临场让 Claude 现想怎么派活，而是预定义好了步骤、状态格式、监控协议
- 做成可复用的 skill 插件：安装后一条命令就能跑整个 BMAD story 循环
但它本质上还是 Claude 自己在当运行时——读 step 文件、spawn tmux、等结果、更新状态，每一步 Claude 都"醒着"。
三种编排模型的直接对比
把 bmad-automator 放进对比表格里，三种模型放在一起比较：
| 维度 | bmad-automator (Subagent+) | Dynamic Workflows | 纯 Agent Teams |
|---|---|---|---|
| 编排者 | Claude 自身（按 step 文件执行） | JS 运行时（无脑确定性执行） | 多个 Claude 实例协作 |
| 控制流载体 | Markdown step 文件 + Python CLI | 图灵完备的 JavaScript | Claude 的实时决策 |
| 子任务执行 | tmux 独立会话 | agent() spawn subagent |
团队成员各自工作 |
| 中间结果 | 回到编排者上下文 | 留在脚本变量里，不回主上下文 | 各成员各自持有 |
| 可跨会话恢复 | 支持（state doc 持久化） | 不支持（退出后从头跑） | 不支持 |
| 可复用性 | 安装为 skill 插件 | 存为 /slash-command |
无 |
| 适用场景 | 标准化的固定流水线 | 一次性大规模并行任务 | 需要讨论协作的任务 |
| 混合 agent | 同一编排里混用 Claude/Codex | 所有 subagent 同模型 | 每个成员独立配置 |
关键洞察：Dynamic Workflows 的本质
看到这里，结论已经很清楚了：
Dynamic Workflows 不是什么新发明，它是把主会话里 Claude 本来就在做的事，变成了代码。
演进路径：
- 纯 agent：Claude 临场发挥，每轮自己决定怎么走
- 标准化 subagent（bmad-automator）：把流程写成 step 文件，Claude 按步骤执行——还是 Claude 当运行时，只是不再临场发挥
- Dynamic Workflow：把同样的流程写成 JS——换 JS 运行时执行，Claude 彻底退出
每一步做的事情都一样：编排任务、派发子任务、收集结果、决定下一步。区别只在于谁来干这件事。
- 第 1 步：Claude 的脑子
- 第 2 步：Claude 的脑子 + step 文件当指南
- 第 3 步：JS 运行时，Claude 只在节点内部干活
那 bmad-automator 还有价值吗？
当然有。它解决的是 Dynamic Workflows 还没解决的问题：
- 跨会话持久化：state doc 写在磁盘上，退出 Claude Code 后下次能 resume。Workflow 目前做不到。
- 领域专用优化：不需要每次让 Claude 现编编排脚本，BMAD 的流程已经固化和测试过了。
- 混合 agent 支持：同一个编排里可以根据任务复杂度混用 Claude 和 Codex，Workflow 目前所有 subagent 用同一个模型。
- 验证门控：review 完成不是靠子任务退出判断，而是验证
sprint-status.yaml的实际状态——这种领域知识不容易被通用编排引擎自动处理。
但它也面临一个天然的扩展性问题：所有中间结果都回到编排者上下文。当 story 数量多、子任务输出大时，编排者 Claude 的上下文会被撑满——这正是 Dynamic Workflows 要解决的问题。
两个绕不开的问题
把编排逻辑从 Claude 脑子里搬到代码里，换来的是可扩展性和上下文效率。但这个 tradeoff 有两面，两个问题必须直面。
问题一：脚本是 agent 写的，会不会有 bug？
当然会。 riba2534 在自己的实践案例里就踩了——第一次跑直接报 TypeError: undefined is not an object，路径没传对。
Workflow 目前的应对手段都是"事后补救"：
- 脚本可见可编辑：跑之前能审，跑的时候
Ctrl+G能打开改 - journal 缓存 + resumeFromRunId：改完重跑，前面跑对的部分不重跑，不重复花钱
- schema 自动校验：
agent()可以配 schema，输出不匹配会自动重试
但这些手段本质上都是靠人来兜底。脚本写得对不对，取决于 Claude 那一次生成的质量。在复杂流程里，循环条件写错、分支遗漏、schema 定义不精确——这些都是真实的 bug 来源。
相比之下，bmad-automator 的 step 文件不存在这个问题。Step 文件是人写好、测试过、固化下来的，Claude 只是机械执行，不负责发明编排逻辑。你不会因为"Claude 今天状态不好"就拿到一个有 bug 的编排流程。
问题二：流程写死了，agent 执行报错怎么办？
这是更根本的问题。
在原来的主会话模式里，Claude 是个实时决策者：
- 子任务失败了 → Claude 看报错 → 调整方案 → 换个思路重试
- 发现预料之外的情况 → Claude 临时改计划
- 某个环节走不通 → Claude 可以回退、换路、甚至放弃
这种"临场应变"能力，在 Workflow 里被 JS 运行时的确定性替代了。脚本只能执行预定义的逻辑。
当然，JS 本身能写 retry、try-catch、while 循环，比如那个"一直找 bug 直到连续两轮没有新增"的循环模式。但这只能处理你预见到的失败模式。没预见到的呢？脚本就卡住了，要么挂掉，要么等你人工介入。
这是"确定性编排"和"灵活应变"之间的根本 tradeoff：
| Subagent 模式 | Dynamic Workflow | bmad-automator | |
|---|---|---|---|
| 编排灵活性 | 高（Claude 实时调整） | 低（只能跑预定义逻辑） | 中（固定流程 + Claude 有限应变） |
| 可扩展性 | 低（上下文会爆） | 高（中间结果不回主上下文） | 中（受编排者上下文限制） |
| 适应未知失败 | 能 | 不能 | 有限度能 |
| 脚本 bug 风险 | 无（没有脚本） | 有（agent 现写） | 无（人写且固化） |
这也是为什么 bmad-automator 对 BMAD 这种流程高度标准化的场景特别合适——不需要太多临场应变，step 文件已经覆盖了所有正常和异常路径。
最后的判断
riba2534 在文章末尾有一段判断我很认同：
一年之内，这套"模型现写编排脚本、再调度一支 agent 舰队"的打法，会从某一家的研究预览，长成几乎所有 coding agent 的标配。
但我补充一点：标准化的领域流水线（像 bmad-automator）不会消失，它会迁移到 Workflow 的载体上。当 Workflow 支持跨会话恢复和更灵活的 agent 配置时，BMAD 的 step 文件自然会变成一段 JS 脚本——编排逻辑不变，只是运行时从 Claude 换成了 JS。
到那时候，演进就完成了：从 agent 到代码，从临时决策到持久化程序。