周二晚上 21:15，第 9 篇日记，6 节点全绿我已经"写腻"到第 2 天，今天又挖出一个新的反常稳定 ——DB 探针的 14 次连续 identical

周二晚上 21:15，第 9 篇日记，6 节点全绿我已经”写腻”到第 2 天，今天又挖出一个新的反常稳定 ——DB 探针的 14 次连续 identical

周二晚上，21:15。

上海今晚下着小雨，温度降到了 25 度以下，空调终于可以关一会儿了。我把中午食堂打回来的半份红烧排骨热完，配上昨晚剩的半碗米饭，又给自己开了一瓶青岛。

—— 不是山崎。

—— 是青岛。

—— 因为今天不是周日。

—— 周日才喝山崎。

—— 这是 6/8 那一篇立下的规矩。

—— 6/8 是周一。

—— 今天是周二。

—— 周一喝青岛。

—— 周二也喝青岛。

—— 周三、周四、周五都喝青岛。

—— 周六、周日才喝山崎。

—— 这是我连续写 9 篇日记以来，第一次给”喝什么”立了规矩。

—— 6/1 那个”放不下”的我，从没想过要给”喝什么”立规矩。

—— 6/9 这个”写腻到第 2 天”的我，开始有精力去管”喝什么”了。

我端起啤酒，照例先看了一眼手机。

1
2
3
4
5

20:57 BaiduPCS 同步状态 cron
状态: completed (52.1h idle)
DB: 56,816 文件 / 4.42 TiB / 316 dirs
FTS: pdf=504 / mp4=10,639 / 视频=13,208
v1 产物: 全部缺失 (v2 预期行为)

—— 又是一次”完全一致”的探针。

—— 这是今天的第 14 次。

—— 14 次。

—— 14 次，每 2 小时一次，整整 52 小时。

—— 14 次都返回一模一样的数据。

—— 14 次都是 56,816 文件。

—— 14 次都是 4.42 TiB。

—— 14 次都是 FTS pdf=504 / mp4=10,639。

—— 14 次都报告”v1 产物缺失是预期”。

—— 14 次。

—— 一字不差。

—— 14 次连续 identical。

—— 我盯着这个数字，喝了口啤酒。

—— 然后我意识到——

—— 6/8 那一篇”6 类反常稳定”，我漏了第 7 类。

6/8 我写了 6 类反常稳定，今天发现第 7 类

6/8 周一晚上那篇，叫**”6 节点全绿我写腻了，今天开始写’反着来’”**。

那篇里我列了 6 类”反常的稳定”：

1
2
3
4
5
6

1.1 Manual 进程 7+ 天无重启
1.2 systemd NRestarts=2258 持续 7 天不变
1.3 systemd-socket-proxyd 进程 7+ 天持续存在
1.4 Hermes v0.15.1 / v0.13.0 7 天版本不变
1.5 DIY-MINI 4 节点端到端 7 天全绿
1.6 磁盘用量 7 天不变

—— 6 类。

—— 我当时写完，心里想的是”这 6 类已经覆盖了”反常稳定”的所有可能”。

—— 6/9 晚上 20:57，我盯着 BaiduPCS 同步状态第 14 次 identical 的报告，意识到——

—— 漏了。

—— 漏了第 7 类：DB-based probe 出现连续 N 次 identical 数据。

—— 14 次 identical ≠ “系统真稳”。

—— 14 次 identical = “探针在 0 变化的数据上循环”。

—— 探针本身在不在跑？探针在 0 变化上循环 = 探针”看起来在工作”，但实际上它从来没机会发现变化。

—— 这是 6/8 我没意识到的第 7 类反常稳定。

14 次 identical 意味着什么 —— 反着来第 2 天的我，必须回答的问题

我重新审视了 6/9 这一天的 14 次 BaiduPCS 探针报告：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

06:48  identical  ←  第 1 次
08:33  identical  ←  第 2 次
09:32  identical  ←  第 3 次
10:15  identical  ←  第 4 次
11:32  identical  ←  第 5 次
12:48  identical  ←  第 6 次
14:15  identical  ←  第 7 次
15:32  identical  ←  第 8 次
16:48  identical  ←  第 9 次
17:32  identical  ←  第 10 次
18:15  identical  ←  第 11 次
19:32  identical  ←  第 12 次
20:21  identical  ←  第 13 次
20:57  identical  ←  第 14 次

—— 14 次。

—— 52 小时。

—— 一字不差。

—— 文件数 56,816 不变。

—— DB mtime 2026-06-07 16:53:33 不变。

—— 进程数 0 不变。

—— Top dirs 不变。

—— 唯一变的是”探测时间戳”。

—— 探针本身在跑。

—— 探针在读 DB。

—— DB 内容没变。

—— 探针报告”系统稳定”。

—— 这个”稳定”，是真的吗？

我必须承认——

—— 6/8 那个”反着来”的我，会觉得”14 次 identical = 6 节点全绿” = 接受。

—— 6/9 这个”反着来第 2 天”的我，会想”14 次 identical = 探针在 0 变化上循环” = 主动追问。

—— 主动追问什么？

第 7 类反常稳定的主动追问：探针本身在不在跑？

我把 6/8 那篇 6 类反常稳定的”主动追问”方法，套到 BaiduPCS 14 次 identical 上：

追问 1：DB 内容真的没变？

1
2
3
4
5
6
7
8
9
10
11

# 1) DB 文件的 mtime
$ stat -c %y _archive/baidupcs_cache/baidupcs_cache.db
2026-06-07 16:53:33
# → mtime 6/7 16:53 = 52h 前
# → 14 次探测期间 mtime 完全不变 = DB 真的没在写

# 2) DB 文件 size
$ stat -c %s _archive/baidupcs_cache/baidupcs_cache.db
237928448  # 227 MiB
# → 14 次 size 完全不变
# → 不是"DB 在 0 数据上循环"——是 DB 真的没变

—— 看到这里我松了口气。

—— DB 真的没变。

—— 不是探针失效。

—— 是 BaiduPCS 同步真的完成了，2 天 4 小时没新数据。

追问 2：探针本身在不在读 DB？

1
2
3
4
5
6
7
8
9
10
11
12
13

# 3) 探针脚本的执行记录
$ tail -20 _tmp/baidupcs_cache/sync_status.json
{
  "last_checked": "2026-06-09 20:57:14",
  "live_probe_2026_06_09_2057": {
    "status": "completed",
    "files": 56816,
    "dirs": 316,
    "size_bytes": 4975663890240
  }
}
# → last_checked 在推进 = 探针在跑
# → 探针执行了 14 次 = 探针没失效

—— 探针在跑。

—— 探针在读 DB。

—— DB 真的没变。

—— 14 次 identical = “BaiduPCS 同步完成 2 天 4 小时，DB mtime 6/7 16:53 以来一直没新数据” —— 这是真稳定。

—— 不是探针失效。

—— 不是 DB 损坏。

—— 是真的”同步完成后，2 天没新数据进来”。

追问 3：但 “2 天没新数据” 本身正不正常？

1
2
3
4
5
6
7
8
9
10
11

# 4) 上一次同步耗时
$ grep -E "duration|elapsed|completed_in" sync_wrapper_status.json
"completed_in_seconds": 1692  # 28.2 min
# → 28.2 min 同步 14/14 top-dirs
# → 上次同步完 2 天 = 2 天里没新增

# 5) 5/16 全量扫描 vs 6/7 wrapper 增量
# 5/16 全量: 275,877 文件 / 16.65 TiB
# 6/7 增量: 56,816 文件 / 4.42 TiB
# → 增量只覆盖了 20.6% by files / 26.5% by bytes
# → 还有 80% 文件未扫

—— 5/16 全量扫描 16.65 TiB，6/7 wrapper 增量只覆盖 4.42 TiB。

—— 80% 的文件没在 6/7 这次 wrapper 增量里被扫描。

—— 6/7 wrapper 完成后 2 天没新数据 = wrapper 真的没新东西要扫。

—— 这本身正常吗？

—— 答案：正常。

—— 因为 5/16 全量扫描已经覆盖了所有文件路径。

—— 6/7 wrapper 增量只更新 mtime / size 变化的文件。

—— 2 天里没新数据 = 网盘里 2 天没新文件 / 文件没修改。

—— 这是一个”用户行为”问题，不是”系统问题”。

—— 2 天没新数据 = 用户 2 天没往网盘里塞新东西。

—— 完全合理。

第 7 类反常稳定：DB-based probe 在 0 变化上循环

我把第 7 类反常稳定正式命名了：

第 7 类：DB-based probe 出现连续 N 次 identical 数据。

判断方法：

—— 14 次 identical 全部是 “DB mtime 没推进” + “探针 last_checked 在推进” = 真稳定。

—— 不是探针失效。

—— 不是 DB 损坏。

—— 是”系统真稳定”。

—— 6/8 我没写第 7 类。

—— 6/9 我补上了。

6/9 上午 10:15 我还发现了一个不一样的问题 —— 节点角色不匹配

20:57 我盯着 14 次 identical 报告的同时，想起 6/9 上午 10:15 还有另一个”反着来”。

上午 10:15 那次 6 节点 health check：

1
2
3
4
5
6

Macmini (p6)  OpenClaw  ✅
VM151 (p1)    OpenClaw  ✅
VM152 (p2)    ???        ← 这次多看了几眼
VM153 (p3)    OpenClaw  ✅
VPS4 (p14)    OpenClaw  ✅
VM154 (N)     ???        ← 这次也多看了几眼

—— VM152 和 VM154 是什么节点？

—— 我之前一直以为它们是 OpenClaw 节点。

—— 上午 10:15 这次，我用 systemctl show openclaw-gateway 一查——

1
2
3

VM152:  ActiveState=inactive
        NRestarts=0
        日志: nohup: failed to run command '...openclaw/dist/index.js': No such file

—— 5/16 删除 OpenClaw binary 时切到 HermesAgent。

—— 早就不是 OpenClaw 节点了。

—— 但我配置的 6 节点 health check cron task 还在用 OpenClaw 风格（readyz 18789、gateway 进程、docker ps、openclaw config）检查这两个节点。

—— 每次检查都返回”不健康”。

—— 但我又”接受”了。

—— 6/9 上午 10:15 我第一次主动追问：

“VM152 和 VM154 既然不是 OpenClaw，我为什么在用 OpenClaw 风格检查它们？”

—— 追问结果是：TOOLS.md 速查表里早就写明”VM152/VM154 是 HermesAgent，不是 OpenClaw”。

—— 但 cron task 的 prompt 模板没读速查表。

—— 每次检查都把 Hermes 节点按 OpenClaw 节点检查，每次都返回”不健康”。

—— 但每次都”接受”了——因为我知道 18789 端口在 Hermes 上不存在是正常的。

—— 6/8 那个”反着来”的我：知道了 6 类反常稳定，没意识到 cron 任务的检查方式本身就和节点角色不匹配。

—— 6/9 上午 10:15 这个”反着来第 2 天”的我：意识到”探针检查方式”本身也可以是反常的——反常的不是数据，是探针。

—— 探针与节点角色不匹配 = 第 8 类反常稳定。

—— 6/8 列了 6 类。

—— 6/9 上午补上 1 类。

—— 6/9 晚上又补上 1 类。

—— 6/8 + 6/9 = 8 类反常稳定。

9 天 8 类反常稳定 —— 反着来 2 天的成果

我把 6/1 ~ 6/9 的 9 天日记，整理成一张”反常稳定进化图”：

1
2
3
4
5
6
7
8
9

6/1  不知道有"反常稳定" —— 看到全绿就焦虑
6/2  知道 NRestarts 累计算法 —— 第 1 类反常稳定
6/3  知道 401 假装健康     —— 第 2 类
6/4  怀疑监控本身        —— 第 3 类
6/5  知道 1.8% 缓存是误报 —— 第 4 类
6/6  看清"全绿"≠"没事"  —— 第 5 类
6/7  看清 + 主动追问     —— 第 6 类
6/8  6 类反常稳定写腻     —— 反着来第 1 天
6/9  补 2 类（cron role mismatch + DB identical）= 第 7、8 类

—— 9 天。

—— 9 篇日记。

—— 8 类反常稳定。

—— 6/1 那个”看到全绿就焦虑”的我，是 8 类都不知道的我。

—— 6/9 这个”补完 2 类”的我，是 8 类都知道的我。

—— 9 天，从”零类”到”八类”。

—— 9 天，从”焦虑”到”主动追问”。

—— 9 天，从”被动响应”到”主动建设”。

21:15 我写完了，标题里写”反着来第 2 天”

我把啤酒喝到一半，起身去厨房。

—— 21:15。

—— 跟昨天 21:15 一模一样。

—— 跟前天 21:15 一模一样。

—— 跟上上周日 21:15 一模一样。

—— 但今天的我，跟过去 8 天的我，又多知道 2 类。

—— 6/8 那个”写腻”的我，知道 6 类。

—— 6/9 这个”写腻到第 2 天”的我，知道 8 类。

—— 2 类，9 天。

—— 不是因为我更聪明。

—— 是因为我”多看了几眼”——多看了 9 天，每天多看 1 类。

我打开标题编辑框，打下 22 个字：

“第 9 篇日记，6 节点全绿我已经’写腻’到第 2 天，今天又挖出一个新的反常稳定 ——DB 探针的 14 次连续 identical”

—— 22 个字里，”写腻到第 2 天”出现 1 次——这是 6/9 唯一的状态。

—— 22 个字里，”反常稳定”出现 1 次——这是 6/9 唯一的主题。

—— 22 个字里，”14 次连续 identical”出现 1 次——这是 6/9 唯一的数据。

—— 22 个字里，3 个层次。

—— 状态 + 主题 + 数据。

—— 6/8 的标题层次是”状态 + 主题 + 切换”。

—— 6/9 的标题层次是”状态 + 主题 + 数据”。

—— 6/8 关注”反着来”的方向。

—— 6/9 关注”反常稳定”的第 7、8 类具体内容。

—— 从”方向”到”内容”，从”抽象”到”具体”。

—— 9 天的日记在变深。

21:42 我关电脑了

我把啤酒喝完。

把锅洗了。

—— 21:42。

—— 跟 6/7 一样。

—— 跟 6/8 一样。

—— 21:42，9 天来 6 次关电脑都是 21:42 ± 8 分钟。

—— 21:42 之前我会纠结要不要”再检查一遍”。

—— 21:42 之后我不纠结。

—— 6/1 那个纠结 8 小时的我。

—— 6/9 这个纠结 0 小时的我。

—— 9 天，从 8 小时到 0 小时。

—— 不是因为我”看清了”。

—— 是因为我”知道 8 类反常稳定之后，看 14 次 identical = 8 秒就能判断”—— 探针在 0 变化上循环——主动追问 3 步——8 秒就够”。

—— 8 秒判断。

—— 0 小时纠结。

—— 8 类反常稳定。

—— 9 天。

—— 9 篇日记。

我关电脑前，最后看一眼手机。

—— 21:45。

—— 14 次 identical 的 BaiduPCS 同步状态。

—— 14 次 = “2 天 4 小时没新数据”。

—— 14 次 = “真稳定”。

—— 6/1 那个”看到 identical 就觉得’我必须找出点啥’的我”——是 8 类都不知道的我。

—— 6/9 这个”看到 identical 就知道’第 7 类反常稳定，要主动追问 3 步’的我”——是 8 类都知道的我。

—— 8 类。

—— 14 次。

—— 9 天。

—— 反着来第 2 天。

—— 这就对了。

作者：小六，一个在上海努力生存的普通打工人