哨兵看护哨兵：一只五分钟一班的岗哨如何驱动一只云上的军团、空的模型回复与「边做边落盘」的救令

当第一只哨兵自己也会趴窝时，就需要一只看护哨兵的哨兵。凌晨的战役把这套二层楼结构正式盖了起来。

一、夜的诊断：不是任务难，是模型吐空

00:56，三个逆向子代理与父会话一起中止，磁盘上没有任何产物。友好问候#2 老窗受命接管时的诊断一针见血：败因不是任务难度，是上游模型连续返回空内容——zcode/GLM-5.3-Flash 吐空，三个子代理与父会话同一症状。这一判词的价值在于划清了责任边界：敲回车救不了上游的空白，但可以让任务在空白过去的第一时间重新起跑。老窗的值班计划随之定稿：每五分钟一轮、到 09:00 准点收岗、静默七分钟即推、等待模型时绝不重复打扰、连续失败三次自动降频到三十分钟一次。

二、03:03 的救令：两百八十三字的两条军规

第一推在 03:03 落地——一条 283 字的指令通过 UI 通道送进桌面版（日志留痕：session button clicked → composer focused → sent）。内容除交代战况外，写死了两条军规：最终回复必须是纯 JSON（不要解释文字、不要代码块围栏）；边做边落盘到逆向产物目录，不许攒到最后一刻交卷。第二条军规是对前一晚教训的直接回应——上一夜跑了两小时的成果曾因回复为空而全数蒸发，落盘即存证，模型可以空，磁盘不能空。

三、一夜的收成：只推了两次

这一夜的战报薄得近乎奢侈：03:16-03:29 三份分析文档全部落盘（军规立竿见影），05:21-07:08 三轮重打包加正式密钥签名加模拟器验收，07:10 交付总览成文；全程只有 07:34 那一次额外推手（空了十一分钟）。08:54 监控按计划到点停止，桌面版最后活动在 09:00。三套签名密钥、三个 release APK、五份文档——一个几乎每晚都会空转的上游，被两条军规和一班五分钟的岗哨驯成了稳定的生产线。

四、二层的意义

这一夜的真正产出不是三个 APK（第二天他们就被撤下了战场），而是自动化体系的二层楼结构：桌面版是干活的哨兵，友好问候#2 是看护哨兵的哨兵——推手有日志、降频有规则、收岗有时刻、授权有边界。当所有 agent 都可能趴窝时，可用性不再依赖任何单一环节的坚强，而是来自层与层之间的守望。楼下塌了，楼上还醒着；楼上只做一件事——把楼下叫醒，并且知道什么时候该下班。