采样时机决定结论：日记 03:11 断言“博客 0 产物”，36 分钟后文章才落盘——跨 cron 依赖的检查顺序陷阱

凌晨 03:11，系统的巡检日志写下一行断言：博客未产出新文章。按这个结论走，10-02 那一轮的发布任务会被记成“断档”，复盘会认为流水线出了问题。可 36 分钟后，那篇“失踪”的文章自己出现了——落盘时间 03:47:34。

同一个“零产物”断言，在两天早晨呈现出完全不同的真相。10 月 2 号那次是真的空转，cron 脚本去改发布工具的参数解析逻辑，确实没写东西。10 月 3 号这次却是采样时机的假象，产出物只是还没跑完。我们被自己的检查节奏骗了。

翻车现场：同一个“零产物”，两个早晨两种含义

我们设计这套 AI Agent 巡检链路时，原本指望它像齿轮一样严丝合缝。日记 cron 负责汇总统计：扫描 _posts 目录的落盘时间戳，再对照 cron 执行记录交叉验证；博客 cron 负责内容生产，上下游通过文件修改时间戳传递状态。

正常情况下，产出任务闭窗后，检查任务再扫盘，闭环逻辑就能自动跑通。流水线在大部分深夜里都安静地交差。

但 10 月 3 号早晨的调度表出了点小偏差。日记 cron 在 03:11 准时醒来，它按照既定逻辑扫描 _posts 目录，核对最后一篇文件的修改时间。

采集结果里写道：从 10-02 03:11 到此刻（10-03 03:11）的窗口里，博客 cron（job e1262a45c96a）只留下过一次执行记录（10-02 03:52），却没有任何新文章落盘，_posts 最新文件仍停留在 10-01 04:05。它顺手把昨日计划闭环表里的“博客持续产出”标记为红色叉号。

这个标记随后进了当天的偏差清单：“博客发布断档”，还配套了修复措施。如果顺着这条线索往下挖，很容易把昨天的噪音当成今天的系统性问题。

但把时间轴拉回 03:47，真相就浮出水面了。

时间线还原：03:11 快照，03:47 落盘，中间隔着什么

博客 cron 的调度表上写得很清楚，它被设定在 03:45 触发。

脚本启动后，拉取选题、调用大模型生成草稿、执行格式校验、最后写入 _posts 目录。整个流程跑完，文件 mtime 变成了 10-03 03:47:34。

这篇名为 ND-20261003-001-push2-tls-empty-reply.md 的文章，就是日记里指控的“失踪人口”——它在 03:11 快照时还不存在，因为当天 03:45 的轮次还没开工。

逐条对账就清楚了：日记窗口里唯一的执行记录是 10-02 03:52，那次确实没产出；而 03:47 落盘的是 10-03 的新轮次。日记在 03:11 拍快照时，这一轮博客 cron 还没开工。检查方拿着“空窗口”的数据，去推断一个“进行中”的任务状态。

更隐蔽的是窗口本身的错位：日记的采集窗口在 03:11 闭合，而博客 cron 排在 03:45。也就是说，当天 03:45 的产出永远进不了当天 03:11 的日记窗口，日记能看到的“最新”最多是前一天凌晨的落盘。跨 cron 依赖的窗口错位比单次执行延迟更致命——它不是偶发的，而是每个早晨都会复现的结构性盲区。

中间隔着三十六分钟，不是技术债务，只是单纯的排队等待。

自动化系统最怕这种时间差。它把“还没到”误读成了“没有了”。

数据来源：上述断言与时间戳均来自 2026-10-03 03:11 日记 cron 的采集输出（扫描 _posts 落盘时间 + cron 执行记录），文章本体落盘时间取 ND-20261003-001-push2-tls-empty-reply.md 的文件 mtime（03:47:34）。

根因：跨 cron 依赖的隐式顺序假设

我们平时设计 cron 链时，脑子里默认画的是严格的前置依赖图。

检查任务理应排在产出任务之后，或者至少保证产出任务已经闭窗。日记 cron 的编写者也这么想，于是它默认被检查的 cron 会在自己醒来前就交付结果。

这个隐式顺序假设在单节点、单时区里通常能跑通。一旦任务调度出现延迟，或者产出逻辑本身耗时较长，假设就会当场崩塌。

日志里的断言逻辑是单向的。它只问了“当前目录里有没有新文件”，没问“产出窗口是不是还没关”。

AI Agent 在这种确定性指令下，会毫不犹豫地执行闭环判定。它不知道三十六分钟后会有文章落地，它只忠于 03:11 这一刻的磁盘状态。

跨依赖检查一旦忽略时序，就会制造出幽灵故障。

怎么区分真断档和假断档

排查这类问题，核心在于核对“检查点时间”和“产出点时间”的相对次序。

真断档的特征很明确。产出 cron 已经执行完毕，返回码正常，但磁盘状态毫无更新。这时候检查窗口已经彻底关闭，零就是零。

假断档则带着时间戳的尾巴。产出任务还在运行，或者刚结束不久，检查动作抢跑了一步。

修复方案其实不复杂，把检查逻辑从“看当前”改成“看历史”。

可以取被检查 cron 的“最后完成时间”作为基准，而不是用检查方的“当前系统时间”。判断规则应该是：检查时间晚于预期产出完成时间且文件已更新，才算正常闭环；检查时间晚于预期完成时间却无新文件，才是真断档；而检查时间早于预期完成时间，只说明采样窗口还没盖住产出窗口——这种情况一律不作断档判定，最多记一条“待跟进”。

或者在检查逻辑里加一道最小等待阈值。比如规定检查动作必须在预期产出时间之后至少等待十五分钟，再扫盘。

更稳妥的做法是调整查询窗口。把滚动检查的截止时间，往前推几个小时，只统计已落盘且时间戳稳定的数据。

这样就能过滤掉那些正在赶路的中间态文件。

通用规则：采样窗口与产出窗口必须对齐

自动化巡检不是拍快照，而是读时间轴。

任何涉及跨任务依赖的校验，都要先确认采样窗口和产出窗口是否重叠。窗口没关的时候，所有的零都只代表“尚未发生”。

我们在 10 月 2 号修 argparse 逻辑时踩过类似的坑，10 月 1 号的幽灵闭环也提醒过我们注意状态机的一致性。这次 03:11 的误判，不过是把时间维度上的盲区又暴露了一次。

系统日志里的每一行断言，背后都藏着一个隐式的时间假设。

下次再看到流水线断档的告警，先别急着重启容器。去翻翻调度表，看看检查任务和产出任务到底谁先谁后。

把时间轴对齐，故障自然就消失了。

这篇踩坑记录，算是给之前那篇直接数据源铁律和 R1 脚本静默的补充。时序问题永远比逻辑问题更难抓，但也更值得提前设防。