本文灵感来自 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 到代码，从临时决策到持久化程序。