本文灵感来自 riba2534 的这篇推文，文章对 Claude Code 的 Dynamic Workflows 做了详细的分析。本文在此基础上补充两点：一是用一条清晰的演进线把 Agent / Subagent / Skill / Agent Teams / Workflow 串起来，二是用开源项目 bmad-automator 作为"中间态"的活样本来对比。
Dynamic Workflows 做的事情，就是把原来主会话里 Claude 的决策逻辑，从"脑子里想的"变成"写在文件里的"，最后变成"机器跑的"。 每一步都是把 Claude 从循环里多退出一层。
在理解 Workflow 之前，得先看清 Claude Code 现有的几层协作能力是怎么一步步叠加的。
最底层。一个 Claude 实例从头干到尾，串行处理所有任务。你问一句它答一句，工具调用也是排队的。
Claude 的角色：唯一的执行者 + 决策者。
主 Agent 派生出若干小弟去搜文件、读代码、跑命令，干完把结果汇报回来。小弟的生命周期很短，任务结束就消失。
Claude 的角色：决策者 + 调度者。每一步"派谁去干什么"都由 Claude 实时决定，小弟的结果要回到 Claude 的上下文窗口，它读完才能决定下一步。
多个独立的 Claude Code 实例像团队一样并行协作，队员之间还能互相通信。适合"开会讨论"式的任务，比如前端和后端同时开工。
Claude 的角色：团队中的一员，但每个成员都有自己的上下文。协调成本随人数上升。
这一次 Claude 不再亲自逐轮调度。它先把整个编排过程写成一段 JavaScript 脚本——循环、分支、中间结果的收集全都固化在代码里——再交给一个独立的运行时去执行。
Claude 的角色：脚本作者。写完就"去睡觉"了，只有最终结果才把它叫醒。
前三层有一个共同的瓶颈：编排者始终是 Claude 本身。
它逐轮决策下一步派谁去干什么，每一个 subagent 的返回结果都要回到 Claude 的上下文窗口里。这套机制在任务规模不大时很灵活，可一旦要协调几十上百个并行任务：
Workflow 换了个思路：脚本自己持有循环、分支和中间结果，Claude 的上下文里只剩下最后那个答案。
用一句话概括这个分工：
JavaScript 运行时当指挥（无脑、确定性），在
agent()点临时雇 LLM 干活，主 Agent 全程在睡觉，只在最后被叫醒读结果。
在理解了这条演进线之后，开源项目 bmad-automator 提供了一个"中间态"样本。
bmad-automator 是一个 BMAD（AI 驱动的敏捷开发方法论）的编排工具，自动化了 story 的完整开发循环：
创建故事 → 实现故事 → (可选) 测试生成 → 对抗性代码审查 → 提交验证 → 触发回顾
核心循环是：
Claude (编排者) → spawn tmux 子会话 (subagent) → 读回监控结果 → 决定下一步 → 再 spawn
具体来说：
tmux spawn 独立的 Claude 或 Codex 会话sprint-status.yamlbmad-automator 停在第二层——subagent 的标准化封装。它做了两件有价值的事：
但它本质上还是 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 不是什么新发明，它是把主会话里 Claude 本来就在做的事，变成了代码。
演进路径：
每一步做的事情都一样：编排任务、派发子任务、收集结果、决定下一步。区别只在于谁来干这件事。
当然有。它解决的是 Dynamic Workflows 还没解决的问题：
sprint-status.yaml 的实际状态——这种领域知识不容易被通用编排引擎自动处理。但它也面临一个天然的扩展性问题：所有中间结果都回到编排者上下文。当 story 数量多、子任务输出大时，编排者 Claude 的上下文会被撑满——这正是 Dynamic Workflows 要解决的问题。
把编排逻辑从 Claude 脑子里搬到代码里，换来的是可扩展性和上下文效率。但这个 tradeoff 有两面，两个问题必须直面。
当然会。 riba2534 在自己的实践案例里就踩了——第一次跑直接报 TypeError: undefined is not an object，路径没传对。
Workflow 目前的应对手段都是"事后补救"：
Ctrl+G 能打开改agent() 可以配 schema，输出不匹配会自动重试但这些手段本质上都是靠人来兜底。脚本写得对不对，取决于 Claude 那一次生成的质量。在复杂流程里，循环条件写错、分支遗漏、schema 定义不精确——这些都是真实的 bug 来源。
相比之下，bmad-automator 的 step 文件不存在这个问题。Step 文件是人写好、测试过、固化下来的，Claude 只是机械执行，不负责发明编排逻辑。你不会因为"Claude 今天状态不好"就拿到一个有 bug 的编排流程。
这是更根本的问题。
在原来的主会话模式里，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 到代码，从临时决策到持久化程序。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。