Agent 到代码：Claude Code 编排模型的演进

ude 的角色决策者 调度者。每一步派谁去干什么都由 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 是一个 BMADAI 驱动的敏捷开发方法论的编排工具自动化了 story 的完整开发循环创建故事 → 实现故事 → (可选) 测试生成 → 对抗性代码审查 → 提交验证 → 触发回顾它的编排模型核心循环是Claude (编排者) → spawn tmux 子会话 (subagent) → 读回监控结果 → 决定下一步 → 再 spawn具体来说编排者Claude 自身按预定义的 step 文件markdown逐步执行子任务通过 tmux spawn 独立的 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 本来就在做的事变成了代码。演进路径纯 agentClaude 临场发挥每轮自己决定怎么走标准化 subagentbmad-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 和 CodexWorkflow 目前所有 subagent 用同一个模型。验证门控review 完成不是靠子任务退出判断而是验证 sprint-status.yaml 的实际状态——这种领域知识不容易被通用编排引擎自动处理。但它也面临一个天然的扩展性问题所有中间结果都回到编排者上下文。当 story 数量多、子任务输出大时编排者 Claude 的上下文会被撑满——这正是 Dynamic Workflows 要解决的问题。两个绕不开的问题把编排逻辑从 Claude 脑子里搬到代码里换来的是可扩展性和上下文效率。但这个 tradeoff 有两面两个问题必须直面。问题一脚本是 agent 写的会不会有 bug当然会。 riba2534 在自己的实践案例里就踩了——第一次跑直接报 TypeError: undefined is not an object路径没传对。Workflow 目前的应对手段都是事后补救脚本可见可编辑跑之前能审跑的时候 CtrlG 能打开改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 直到连续两轮没有新增的循环模式。但这只能处理你预见到的失败模式。没预见到的呢脚本就卡住了要么挂掉要么等你人工介入。这是确定性编排和灵活应变之间的根本 tradeoffSubagent 模式 Dynamic Workflow bmad-automator编排灵活性 高Claude 实时调整 低只能跑预定义逻辑 中固定流程 Claude 有限应变可扩展性 低上下文会爆 高中间结果不回主上下文 中受编排者上下文限制适应未知失败 能 不能 有限度能脚本 bug 风险 无没有脚本 有agent 现写 无人写且固化这也是为什么 bmad-automator 对 BMAD 这种流程高度标准化的场景特别合适——不需要太多临场应变step 文件已经覆盖了所有正常和异常路径。最后的判断riba2534 在文章末尾有一段判断我很认同