如果你看过我之前那篇 Story Automator 上手实录应该还记得我最后的结论白天手工跑目前还是自己手工跑会更快。但睡前把一批 Story 交给它过夜跑这个场景它真的挺合适。那篇文章里我留了个没回答的问题——**为什么它跑得比人手工还慢**我当时说还没仔细分析它的实现原理。现在 BMAD 6.10 把这套东西重写了一遍改名BMAD Loop也顺手把那个问题接上了。答案只有一句话但它是理解整个设计的钥匙控制环里不应该放 LLM。先纠正一个最容易踩的误解很多人第一次接触 BMAD Loop会以为它是几个新 skillbmad-loop-setup、bmad-loop-sweep、bmad-loop-resolve、bmad-dev-auto。不是。这几个 skill 本身什么也不做。真正驱动循环的是一个用uv从 Git 装进来的Python 工具——bmad-loop包仓库在bmad-code-org/bmad-loop。那几个 skill 只是编排器在循环的不同阶段会去调用的基本操作官方文档里叫 primitive说白了就是最基础的、可以单独派活的小单元bmad-dev-auto开发——把意图变成经得起 review 的产物bmad-loop-sweep巡检——清理延后工作台账bmad-loop-resolve交互——和人一起消除歧义换句话说**skill 是肌肉Python 编排器才是中枢神经。**这一点想通了后面所有设计都顺理成章。灵魂信条No LLM in the control loop官方 README 的副标题一句话就给它定了性A deterministic ralph-loop orchestratorfor the BMAD-METHOD implementation phase.翻译过来一个确定性的循环编排器。“确定性”deterministic这三个字是全文最重要的一组词。它把整个开发循环切成两种完全不同的工作工作谁来做为什么控制逻辑选哪个 story、重试几次、什么算完成、能不能提交纯 Python 代码要确定、可调试、可复现、不花钱创意工作写代码、写测试、做对抗式 reviewLLM在一次性会话里这才是 LLM 擅长、且只有 LLM 能做的事回过头看 Story Automator 为什么慢——它的控制环里塞满了用提示词去问 LLM 现在该干嘛的环节。每问一次都要花 token、等推理还可能跑偏跑偏了就再问一次。把调度交给 LLM等于让一个容易走神、按字计费的新人在流水线上当调度员。BMAD Loop 的做法是调度员换成一段不会走神、不收钱的 Python 代码LLM 只在每个工位上干它该干的创意活干完就走。这样做换来四个好处是后续所有机制的出发点确定性同样的 sprint 跑两次调度路径一致可调试流程是代码出问题能打断点、看日志而不是猜提示词哪里没说清可复现每次运行的决策都有磁盘上的状态机记录省钱控制逻辑零 token 消耗四个让它敢放手的关键机制控制环不放 LLM说起来轻松但它带来一个尖锐的问题**编排器怎么知道一个 LLM 会话干完了、干对了**旧做法是让编排器自己也是个 LLM去看会话的输出——这正是 Story Automator 的包袱。BMAD Loop 用四个机制绕开了这个包袱。机制一每个步骤都是全新上下文的一次性会话Dev 和 review 是两个独立会话review 会话绝不继承dev 会话的上下文。这一点反直觉但极其关键。如果 review 会话带着 dev 写代码时的记忆它天然会护短——人对自己刚写的代码容易先入为主、下不去狠手心理学叫锚定效应anchoring biasLLM 也一样。把 review 放进一个对 dev 一无所知的全新会话里它才会真的去挑刺而不是附和。类比你不能让写代码的人和 code review 的人是同一个脑子。上下文隔离就是给 review 配一双没见过这份代码的眼睛。机制二靠 hook 事件文件通信绝不抓屏编排器怎么知道会话结束了答案是给 coding CLIClaude Code / Codex / Gemini注册 hook——Stop、SessionStart、SessionEnd、PreCompact。这些 hook 在关键节点往磁盘写结构化事件文件编排器只管 watch 这些文件。而每个 skill 在自动化模式下跑完会写一个机器可读的result.json声明自己这一轮的产物和状态。旧做法Story Automator BMAD Loop 的做法 ┌─────────────┐ ┌─────────────┐ │ 编排器(LLM)│ │ 编排器(Python)│ │ 去看屏幕 │ ←脆弱、贵、易错 │ watch 文件 │ ←稳、免费、结构化 └─────────────┘ └─────────────┘ ↑ ↑ 抓 pane / 读对话 读 Stop hook 写的事件 读 skill 写的 result.json抓屏pane-scraping是上一个时代的痛终端输出格式一变、模型多说了一句废话编排器就懵了。换成hook 写文件、编排器读文件接口就从自然语言降维成了结构化数据鲁棒性立刻上一个台阶。机制三Trust nothing, verify everything这是整个系统最硬核的地方。每个 LLM 会话结束后编排器不信任会话自己说的我搞定了而是去磁盘上独立校验spec frontmatter文件开头的元信息状态story 的规格文件状态字段是否真的变成了 donebaseline-commit 匹配会话声称改了哪些文件和 git 里实际的 diff 对不对得上——这是一个便宜的LLM 撒谎检测器非空 diff到底有没有真的改东西sprint-status 同步状态文件是否和实际进度一致你的测试 / lint 命令最后提交前跑一遍你自己定义的测试和 lint校验全过才允许 commit。任何一项不过要么重试要么升级。这条哲学值得单独记住**LLM 会幻觉但 git 不会。**把是否真的完成这个判断从问 LLM挪到看磁盘证据整个系统就稳了。机制四deferred-work 台账 sweep终于有人读它了循环里总会遇到现在干不了的活——某个 edge case 要等另一个 story 先落地、某个决策该人来拍板。这些不能硬干也不能丢于是写进一份台账deferred-work.md。有意思的是这份台账的身世。在更早的 BMAD 版本里这是个有名的半成品——bmad-code-review会往deferred-work.md里写延后项但没有任何 skill 会回头读它社区甚至专门提了 issue 报这个 bug。写进去的债永远没人还。BMAD Loop 的bmad-loop-sweep终于补上了这一环。它做的事是只读巡检把台账里每条 open 的项对着真实代码库逐条验证grep 症状、查 git log、读相关文件然后分成五类分区含义编排器怎么办already_resolved后来的工作顺手解决了但没标记拿证据file:line / commit自动关掉bundles现在就能一起干的按相同文件/子系统打包成一个 dev 会话执行blocked得等某个未来的 story/epic 落地标记阻塞方挂着skip已过时、无关、或项目明确排除跳过decisions必须人来拍板改冻结 spec、改 API 形状等升级给人“写进去的债有人还了”——而且是带着证据还不是凭台账里的旧状态拍脑袋。这条机制让循环可以长时间无人值守地跑下去而不至于债台高筑。一张图看清整个循环把上面四个机制拼起来一个 story 在 BMAD Loop 里的完整生命周期是这样的整条链路的控制流是 Python只有②③④这几个创意工位是 LLM 在一次性会话里干活。这就是确定性编排器的完整含义。多模型编排三个 CLI按角色混搭BMAD Loop 通过一个通用的 tmux 适配器驱动三种 coding CLIclaude默认、codex、gemini。而且可以按阶段混搭——配置在项目的.bmad-loop/policy.toml里[adapter] name claude # 默认所有阶段都用 claude [adapter.review] name codex # 但 review 阶段换成 codex为什么要混搭因为不同模型擅长的事不一样。一个很实用的组合是让一个模型写代码、让另一个模型做对抗式 review——两个不同家族的模型互相挑刺比同一个模型自审要狠得多。这正好和机制一review 用全新上下文叠加双重消除偏置。这已经不是调一个模型了是模型编排。什么时候它会停下来叫你CRITICAL 升级无人值守不等于无人干预。有一种情况编排器会主动暂停整个 run等人——CRITICAL 升级。触发条件通常是dev 或 review 会话发现冻结的 specfrozen-after-approval块自相矛盾或者对某个关键场景保持沉默没法安全地继续。这时候它不猜、不硬干而是把 run 挂起等你用bmad-loop resolve --story story-key起一个交互式会话。这个会话里有人你所以它会问你问题、给出 2-4 个具体选项和推荐。你拍板之后它去改 spec 本身——不是改代码——把歧义消掉然后编排器重新驱动这个 story对着一份修正过的、没有矛盾的 spec 重跑。这个设计很克制有几条硬规矩值得点赞resolve 会话只改 spec 内容不写一行功能代码、不跑测试、不提交它不动 sprint-status.yaml也不设 spec 的 status 字段——这些由编排器在恢复时确定性地产出如果信息不够、或者正确的修复超出了 spec 编辑的范围比如需要改 PRD/架构它会直接说我解决不了不写完成标记run 继续挂着——这是安全的默认行为一句话**遇到拿不准的宁可停下来等你也不编一个答案往下冲。**这是对无人值守最负责的理解。怎么用上手三步前置条件就一条你得有一个BMAD v6 项目而且bmad-sprint-planning已经跑过、生成了sprint-status.yaml。换句话说PRD / 架构 / epicsstories / sprint planning 这条链得先走完Loop 才有故事可转。装好之后通过bmad-loop-setup这个 skill它会从 Git 装 Python 工具 跑bmad-loop init注册 hook、铺 skill、写 policy.toml核心命令其实很少bmad-loop init # 装 bmad-loop-*skillhookpolicy.tomlgitignore bmad-loop validate # 预检config/sprint-status/git/tmux/CLI/hook bmad-loop run--dry-run # 先打印计划不真的拉起会话 bmad-loop run # 开跑 bmad-loop tui # 或者干脆全在可视化面板里操作完整命令清单覆盖了run / sweep / resume / resolve / decisions / status / attach / stop / clean等但日常 90% 的场景就是上面这几条。bmad-loop tui那个仪表盘挺漂亮——run 选择器、sprint 树、deferred-work 台账、每个 story 的实时任务表、带颜色的日志流一屏打尽。一个必须知道的一次性设置坑如果目标项目里 coding CLI 从来没跑过比如 claude 没在这个目录启动过你要先手动启动一次接受 workspace-trust 和 hooks 审批对话框。编排器拉起的子会话没法替你点这些首次运行对话框而一个挂着的对话框会被编排器误判成会话超时。血统从 Story Automator 到 BMAD Loop把 BMAD Loop 放回时间线里它的位置就很清楚了StoryAutomatorbmad-automator/bmad-autoBMADLoop(2026初,我那篇(中间的过渡形态,(6.10,重写为 实测的版本)工具名 bmad-auto)确定性Python编排器)│ │ │ └──── 控制环里有LLM─────┴───── 重写 ────────► 控制环里没有LLM──┘(慢、贵、易跑偏)(确定、可调试、省钱)README 里写得很坦诚“Inspired by the original bmad-automator (a separate, legacy project)”——它明确把上一代当成 legacy自己是从头来的重写。而它给自己定位是**“a deterministic ralph-loop orchestrator”。如果你关注过 autonomous dev 这个圈子应该听说过Ralph——那个让 Claude Code 自己跑开发循环的工具。BMAD Loop 借用了ralph-loop这个模式无人值守、反复迭代的小循环但把它确定性地**实现在了 BMAD 的 story 体系上。所以它是Ralph 的精神 BMAD 的骨架 Python 的中枢。适合谁不适合谁延续我测评 Story Automator 时的坦诚基调给你一个不吹的判断。适合用的场景你已经完整走完 BMAD 的规划链PRD → 架构 → epics → sprint planning手头有一串清晰、可独立实现的 story你接受睡前梭一把这种异步交付模式——第二天起来看结果而不是盯着它实时干你的项目有可靠的测试和 lint机制三最后那道闸靠它们否则 verify 形同虚设你想做多模型互相 review又不想自己手动切来切去不适合 / 要谨慎的场景story 还很模糊、依赖关系没理清——这种跑进循环里大概率触发一堆 CRITICAL 升级反而更累没有测试的项目——编排器再聪明最后那道 verify 闸门空转等于裸奔期待它又快又好又自动——确定性编排让它更稳、更省但单 story 的绝对速度未必比一个熟手手工盯更快。它的价值在批量、异步、可恢复不在单点提速和上一代最大的区别也是我现在最看好它的一点因为控制环是确定性代码它可调试、可复现、可信任。Story Automator 时代那个为什么这么慢的黑盒这一次终于打开了——流程是 Python你看得到每一步在干嘛、为什么这么决策。光这一点就值得把它从试验品升级成可以认真用起来的工具。写在最后从 v6.8 的锁定意图让 AI 先搞懂你要什么到 6.10 的 BMAD Loop让确定性的代码当调度员、LLM 只管写代码BMAD 这两年的演进方向其实非常一致把不该让 LLM 干的活一件一件从 LLM 手里拿回来。意图理解该锁定的用 SPEC 锁定调度该确定的用 Python 确定该人拍板的挂起 run 等人。LLM 越来越被收敛到它真正擅长的那块创意工作上。这不是对 LLM 不信任恰恰是对它的尊重——别让它干它不擅长、又会幻觉、还按字收费的活。如果你也在用 BMAD 做项目强烈建议拿一个 sprint 来认真试一次 BMAD Loop。哪怕只是为了让deferred-work.md那本永远没人还的债账终于有人管也值。参考来源bmad-loop 官方仓库bmad-code-org/bmad-loopBMAD Method 文档docs.bmad-method.org