我那套跑 AI Agent 的自动化脚本居然在凌晨三点集体“罢工”了
我当时第一反应就是代码出 Bug 了，或者是解析器的复杂度直接从 O(n) 变成了 O(n²)，甚至怀疑是数据库碎片化的问题。我挨个排查，把这些明显的坑都踩了一遍，最后发现全都没问题。这时候我提出了一个“弱假设”：凌晨三点肯定有别的程序在跟我抢资源。
为了验证这个猜想，我没急着改代码，而是搞了两套“基建”：
一、 监控采样器 (Instrument)： 在 02:50 到 03:45 这个时间段，每 10 秒抓一次数据，包括 load average、vm_stat、磁盘活动和 CPU 占用最高的进程。
二、 证伪机制 (Falsifier)： 我在任务链里加了一个完整性检查，如果发现警告（WARN）频率上升，就立刻把检查逻辑拆分到另一个时间段跑。
按理说这套组合拳打下来，结果应该是板上钉钉的。结果第一晚的数据看起来非常完美，警告频率确实上升了 2.52 倍，看起来完美验证了我的猜想。
但结果证明，我这两个工具全是错的，而且错得极其离谱。
第一个坑：我的监控指标居然在“记录时间”
看报告时我发现一个极其诡异的现象，Swapouts（内存交换输出）这个指标在五天内呈指数级爆炸：
- 第一晚：135,932
- 第五晚：24,592,563
看着这数据，我以为是内存压力越来越大，导致任务越来越慢。但当我去翻原始采样数据时，我傻眼了：在那个特定的时间窗口内，这五天的增量居然全是 0！
原来 vm_stat 里的 Swapouts 是一个从机器开机就开始累加的计数器。我直接取了窗口内的最大值，这玩意儿只要机器不重启，它就会一直涨。它完全没反映出那个时间段发生了什么，只是在忠实地记录“机器已经运行了多久”。我居然用一个完全没有“区间增量”概念的指标，去试图论证一个“区间内资源竞争”的假设。
真正的信号其实藏在另一列：窗口内的 load1 平均值从 1.78 飙升到了 8.54，CPU 占用也从 0% 变成了 611%。这说明在 10 核机器上，确实有别的程序在那一刻吞掉了 6 个核心。
这次踩坑给我最大的教训就是：如果你想衡量一个时间段内的变化，指标必须定义为“差值”（最后一次采样减去第一次采样），绝对不能直接拿一个累积计数器的绝对值来做区间报告。否则，你的监控系统不仅没用，还会给你编造一个极其逼真的假象。
