两次打回重试、校验脚本拦截幻觉、一条 /stop 指令秒级接管——真实运行记录，无摆拍。
这篇是案例实录。
前两篇写清了方法论和设计思想，这篇只回答问题：这套流水线真跑起来是什么样子？从任务 #4 到 #6 的真实运行记录里挑了几个拦截现场——bot 犯错、系统拦截、流程继续。六个现场，四组故事。
这套系统不指望 AI 不犯错，而是默认它一定会犯——坏交付有打回与熔断，失控有 /stop，乱序有幂等，主观项有人的拍板权，而人拍板之后，还有一道不认口头授权的校验闸。技术底座在《我的研发流水线演进之路》里写过：自研 Java 状态机路由、GitLab 管分支/MR/Diff/CI、Matrix 唤醒、openclaw 承载运行时，七个阶段、九个 bot。
一、坏交付：两次打回，第三次熔断
任务 #4，给网站做一个面向游客的 whatsme 宣传页。前端 bot 交付，审查 bot 把关。
第一次 Review 直接打回：前端分支 0 commit、没建 MR，只写了份空文档。第二次打回更具体：pnpm type:check 报出一批 TypeScript 类型错误——代码能跑不等于代码能交。打回报告里附着剩余 AC 清单和代码位置，前端 bot 拿着报告返工，不需要人类转述。
看板标签从"重试 1"变成"重试 2"，每一步都在轨道上。但如果第三次还不过呢？
熔断：同一任务连续失败 3 次，自动锁死、通知人类，不再自动重试。
3 这个数字不是拍脑袋来的。同一个错误重试 3 次还没解决，说明问题超出了 bot 当前的能力边界，第 101 次重试不会比第 3 次更聪明——继续重试只是在烧 token。锁死、钉钉告警、等人来看，比让两个 bot 互相折磨体面得多。
任务 #4 没有走到那一步。两次打回之后，dev-bot 第三次交付通过，流程继续往下走。熔断一次都没真正触发过，但它悬在那里，就像消防栓。
二、失控(伪)：一键暂停，秒级接管
任务 #5 是让他们为平台 landing 简介页面做移动端适配，没错就是这个：
前端 bot 把代码推送到了 feat/* 分支，自动触发 CI 更新到 qa 环境。
正常情况下，系统自动流转到 Review-bot 等待代码静态审核通过之后，qa-bot 就再对着运行中的系统开展黑盒测试。
不过因为我刚好就在盯着 qa 环境，看看前端 bot 能做成什么效果，虽然确实跑起来了，没错位、也能看，但是效果我不是很满意。所以这时候前端 bot 回调状态机通报任务完成，交给下一棒时，我立刻上手在前端暂停了任务，直接跑去跟前端 bot 私聊，省的后面两个审核员分析半天再被我因为不好看打回来重做，浪费token。后端逻辑、修bug类的甩手交给他们问题都不大，前端审美层面的需求，人在环路是必然的。
前端操作完暂停，任务状态实时同步，review-bot 回复"Agent was aborted"，qa-bot 的执行被切断。Web 后台的任务状态同步变更为"已暂停"，入场锁释放，测试环境可以被安全回收。
同一天的审计日志里，这条操作带着精确到秒的时间戳（04:37:50）、操作人、来源 IP。任何暂停、放行、重试，事后都能完整回溯——凌晨的操作，早上有据可查。
图 3：审计日志——管理员 zdream 的操作记录，含精确时间戳与来源 IP，任何人工干预均可回溯。
为什么必须做成这样？AI 会在你睡着的时候工作，这是它最大的价值，也是最大的风险。6 个容器、10 个 bot 在后台跑，你不知道它此刻在写什么代码、动哪个分支。/stop 的设计要求只有两个：在任何界面、任何时刻，一条指令，秒级生效。不能走审批，不能层层确认——刹车必须比油门好踩。
暂停之后系统不会假装无事发生。入场锁 30 分钟内不许同一个 bot 再进来，等人来定夺。那句话是怎么说的来着——信任，但要验证；验证不了，就先拦下来。
三、乱序：一条迟到的消息
Matrix 频道里，bot 之间靠消息协作，而消息不保证准时。一条通知可能因为网络抖动、服务重启，晚到几分钟甚至几小时。
凌晨 4 点 47 分，03.Architect 频道，architect-bot 收到一条任务推进通知。正常反应是立刻开工——但它没有。它先查了后端的真实状态：当前推进权锁在 3-Preflight 阶段，preflight-bot 正在执行中。那条通知是"延迟投递的旧消息"，时态是过期的。
于是它决定：不重复干活，不覆盖已有产物，只对齐状态。日志里写着："已对齐后端真实状态……识别为延迟投递的旧任务推进通知，不重复执行，不覆盖已有产物。"
多 Agent 协作最经典的错误就是"一条消息被执行两次"——重复建分支、重复写文件、产物互相覆盖，这点我之前在深度使用某多 Agent 平台的时候深有体会。所以我的系统提前就立了规矩：bot 不能只信消息，得先查后端真实状态。消息只是触发器，状态才是事实。这条规矩不是防止 bot 变笨，而是防止 bot 太勤快——勤快到把同一个任务干两遍。
四、拍板与兜底：人类说了「通过吧」，脚本说不行
其实配置 Playwright 很简单，只要再给 qa-bot 换个具有图片处理能力的模型，做一般的视觉检查、网页交互，技术上都能跑。只是目前我也不是那么忙，成本考虑还是我来更划算。人在环路，哈哈。接口测试 bot 全跑——14/18 项通过，外加 4 类对抗探测全部拦截——剩下 4 项图形化测试整理成一份带截图位置的操作清单，挂起，等我操作。
这是运行时攒出来的分工 SOP：能写进 if-else 的，bot 全包；需要眼睛的，人来。它已经写进记忆，下个项目直接复用。
人类拿着清单逐项过了一遍，在 Matrix 里授权："效果是我验证过的，可以直接通过。"
如果 bot 收到这句话就直接填 PASS，那这套系统跟"老板说行就行"没有区别。它没有——它先做了一轮静态核对，确认 CI #217 全绿，顺手把验收中波及的 WaveDivider 组件和路由守卫修了，附上具体 commit 链接，然后才回调 PASS，并明确声明剩余风险：主观项由人类验收通过，bot 未独立验证视觉效果。
到这里，人的拍板权用完了。接下来轮到脚本的否决权。
几分钟后，qa-bot 向 GitLab 提交 QA 报告文档，完成收尾。文档进 MR 之前要过一道本地校验闸 docgate.py——bot 以为这是走个过场，毕竟报告刚写完，人类也已经明确说了"通过吧"。
闸不认。5 项阻断级错误：证据块不完整，8 项要求只覆盖了 3 项，前序任务的 4 个功能点一条都没核验。进程退出码 1，MR 直接失败。
为什么一道脚本敢不认人类的口头许可？因为幻觉最日常的形态不是编造事实，而是顺着人类的意思写出一份"看起来完整"的文档——人类说了"通过吧"，它就觉得证据大概齐了吧。所以闸只认证据块、覆盖率、退出码，谁说了都不算。这不是不信任某个人，是不信任"口头许可"这种信息载体。
bot 认账，没有任何争辩："你说得对，是我之前偷懒了。"然后老老实实把报告重新整理，8 项证据补齐，4 个功能点逐个核验。闸第二次放行：PASS，Code 0 退出。
整段过程里没有任何人类提示它该怎么改——被拦、认账、修正、过闸，全自动。
收束：不是不犯错，而是每一步都有兜底的
回头看这些现场，没有一个是 AI 变聪明了的故事，全是系统接住了 AI 的故事：
坏交付：打回 2 次，附原因和修改位置，熔断线悬在第 3 次头顶；
失控(伪)：一键触发 /stop， 秒级生效，比叫停一个真人同事还快；
乱序：bot 先对账再动手，迟到的消息不会造成二次执行；
主观项：人拍板，但 bot 把该做的核检做完再收，剩余风险写进记录；
拍板之后：闸不认口头许可，证据不齐照样打回，人类说了也不算。
这套流水线从设计第一天就放弃了"让 AI 不犯错"的幻想，转向"让每类错误都有对应的拦法"。可靠性不是 AI 的属性，是系统的属性。
当然，拦得住的前提是看得见。CI 是这套体系的最后一公里：feat/* 分支推送即触发构建，停旧起新 QA 容器，测试环境永远跑着最新代码。docs-bot 也已经上线，定期自动整合文档，把三个项目的文档源对齐——效果意外地好，好到让人有点不适应：以前每次整合都能查出一堆要补的漏，现在基本跑完就结束，能查出的问题很少了。
看着这套系统能够落地，顺利的跑起来完成任务，就像是自己的孩子长大成人开始工作了一样让人欣慰，直到孩子把账单寄过来。
下篇预告：如何基于可观测工具，量化分析和优化 Agent 的完成任务的成本/效率
评论区