那篇文章里我留了个没回答的问题——为什么它跑得比人手工还慢 我当时说还没仔细分析它的实现原理。现在 BMAD 6.10 把这套东西重写了一遍改名 BMAD Loop也顺手把那个问题接上了。答案只有一句话但它是理解整个设计的钥匙控制环里不应该放 LLM。cover先纠正一个最容易踩的误解很多人第一次接触 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 orchestrator for the BMAD-METHOD implementation phase.翻译过来一个确定性的循环编排器。“确定性”deterministic这三个字是全文最重要的一组词。它把整个开发循环切成两种完全不同的工作工作 谁来做 为什么控制逻辑选哪个 story、重试几次、什么算完成、能不能提交 纯 Python 代码 要确定、可调试、可复现、不花钱创意工作写代码、写测试、做对抗式 review LLM在一次性会话里 这才是 LLM 擅长、且只有 LLM 能做的事回过头看 Story Automator 为什么慢——它的控制环里塞满了用提示词去问 LLM 现在该干嘛的环节。每问一次都要花 token、等推理还可能跑偏跑偏了就再问一次。把调度交给 LLM等于让一个容易走神、按字计费的新人在流水线上当调度员。BMAD Loop 的做法是调度员换成一段不会走神、不收钱的 Python 代码LLM 只在每个工位上干它该干的创意活干完就走。control-loop这样做换来四个好处是后续所有机制的出发点确定性同样的 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 里的完整生命周期是这样的lifecycle整条链路的控制流是 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 用全新上下文叠加双重消除偏置。这已经不是调一个模型了是模型编排。