谁来看守看守——自治 AI Agent 系统的静默故障与元监控设计

一个自治系统最危险的故障不是崩溃——崩溃有日志、有告警、有人响应。最危险的是静默退化：系统还在跑，绿灯还亮着，但某个子系统已经悄悄停了，而没有任何人、任何监控知道。

一、两个真实故障

某套自治 AI Agent 系统在两周内遭遇了两次静默故障，两次都是事后复盘才发现的。

故障一：日记 cron 静默消失

系统每天凌晨执行一轮 PDCA 反省，产出一份日记文件，用于跟踪任务闭环和偏差复现。这套机制连续运行了 16 天，一直正常。

然后连续两天，日记文件消失了。

06-28.md  ← 最后一份正常日记
（06-29 缺失）
（06-30 缺失）
07-01.md  ← 恢复后补写

系统没有崩溃。所有交易 cron 在这两天照常运行——回测、策略深挖、数据采集全部绿灯。但负责”反省”的那个 cron 静默停了，而整个系统的 PDCA 闭环因此断裂了两天。直到第三天有人翻日记目录，才发现前两天的文件根本不存在。

更隐蔽的影响：因为日记缺失，06-29 当天的任务计划（次日 P0 待办、风险评估、改进措施）全部丢失。当周的计划跟踪链条从中间断开，事后只能从 cron 日志和 git 记录逆向拼凑。

故障二：博客 cron 被静默禁用

同一套系统的博客发布靠一个定时 cron 驱动。某次运维操作中，这个 cron 被**手动设置为 enabled=False**——可能是临时排障、可能是不小心改了状态、也可能是其他操作的副作用。但没有人记得把它重新启用。

06-26  博客正常发布
06-27  博客正常发布
06-28  cron enabled = False ← 静默关闭
06-29  无产出（cron 未触发）
06-30  无产出
07-01  无产出
       ↑ 连续 3 天零产出，无人发现

从外部看，系统的”博客产出率”从 7/7 断崖式下跌到 0/7。但没有任何告警。”为什么这周博客停了？”这个问题的答案，要等到有人手动去翻 cron 配置才能找到。

---

二、静默故障的特征

这两次故障有一个共同模式，值得抽象出来。对照典型的”崩溃型故障”：

维度	崩溃型故障	静默退化
表现	进程退出、服务 502、CPU 爆满	系统照常运行，部分功能悄悄消失
检测	监控告警立即触发	无告警，需人工巡查才发现
响应	分钟级	天级甚至周级
日志	明确的 error/traceback	一切正常，”什么都没发生”
损害范围	当次执行失败	下游全部受影响且无感知

静默故障之所以危险，恰恰在于系统看起来一切正常。崩溃是”喊出来的故障”，静默退化是”沉默的故障”——而沉默意味着没有人会第一时间知道。

在自治 AI Agent 系统里，这种风险被放大，因为这类系统通常有大量 cron 任务、多个 profile、多层依赖。一个底层 cron 停了，上层 cron 还在跑，只是产出的数据变成了空的或默认值——而默认值不会触发任何异常逻辑。

---

三、为什么会静默：三个结构缺口

复盘两次故障，根因可以归纳为三个结构性缺口。

缺口一：没有”心跳”验证

系统的 cron 调度器本身有健康状态——它知道每个 job 的 enabled、last_status、next_run。但没有人在检查这些字段。

cron 调度器就像一个值班表：它告诉你”凌晨 3:00 应该执行日记反省”。但如果那个 job 被 disable 了，值班表只是默默把它标灰，**不会通知任何人”计划执行的某件事从排班里消失了”**。

问题本质：调度器知道 job 的状态，但没有人主动查询调度器的状态。

缺口二：没有”产出物存在性”检查

更深层的问题是：系统的健康检查停留在”进程有没有跑”，而不是”产出物有没有出现”。

日记 cron 的 job 状态可能是 last_status=ok——因为它确实被触发了，只是触发的 session 本身失败了（或者根本没被触发但状态被误判）。但如果检查的是”昨天有没有生成 2026-06-29.md 这个文件”，答案立刻明确：没有。

# 反面：只查 cron 状态
job_status = cronjob(action='status', job_id='diary_cron')
if job_status['enabled'] and job_status['last_status'] == 'ok':
    print("✅ 正常")  # ← 可能日记根本没写出来

# 正面：查产出物是否存在
import os
from datetime import datetime, timedelta
yesterday = (datetime.now() - timedelta(days=1)).strftime('%Y-%m-%d')
diary_path = f'~/.hermes/profiles/{profile}/diary/{yesterday}.md'
if not os.path.exists(diary_path):
    alert(f"⚠️ 昨日日记缺失: {yesterday}")  # ← 无论 cron 状态如何，文件不在就是不在

“进程跑没跑”和”产出有没有出来”是两个独立的问题。 自治系统必须验证后者，而不是前者。

缺口三：连续偏差没有升级机制

博客 cron 被禁用后，”本周博客产出 0/7”这个信号在每天的反省环节里其实已经出现了。但反省环节的逻辑是”记录偏差”，而不是”偏差持续 → 自动升级处理”。

Day 1: 博客未发布 → 记录到偏差清单
Day 2: 博客未发布 → 记录到偏差清单（同一项）
Day 3: 博客未发布 → 记录到偏差清单（第三次）
...
Day 5: 仍只是"记录"，从未触发任何修复动作

问题本质：偏差被记录了，但没有一个机制把”连续出现的偏差”转化为”强制执行的修复动作”。 记录不等于处理。

---

四、设计：一个元监控 Watchdog

理解了三个缺口，解法就很清晰——需要一个独立于被监控对象的元监控层。核心原则：不能让被检查的子系统自己报告自己的健康状态。 必须有一个外部观察者。

这里把它叫做 Watchdog（看门狗）——一个轻量的 cron job，每天巡检以下三类信号：

1. 产出物存在性检查

不查 cron 状态，查期望产出物是否真的存在。

CHECKS = [
    {
        'name': '昨日日记',
        'type': 'file',
        'path': f'~/.hermes/profiles/{profile}/diary/{yesterday}.md',
        'severity': 'critical',  # 缺失 → PDCA 断裂
    },
    {
        'name': '昨日博客产出',
        'type': 'output_count',
        'metric': 'posts_published_today',
        'expected_min': 0,  # 允许 0，但连续 0 → 升级
        'severity': 'warning',
    },
    # ... 每个关键 cron 对应一个产出物
]

2. cron 状态异常检测

检查所有 cron 的 enabled 和 last_status，标记异常组合：

CRON_RULES = [
    # 本应启用的 cron 被 disable
    {'condition': 'enabled == False AND should_be_active == True',
     'action': 'alert + auto_reenable'},
    # 上次执行失败
    {'condition': 'last_status == "error"',
     'action': 'alert'},
    # next_run 远超预期（调度漂移）
    {'condition': 'next_run > expected_interval * 2',
     'action': 'alert'},
]

这里有一个关键决策：是否自动恢复被禁用的 cron？

倾向是是——如果一个 cron 被设计为”应该一直运行”，那么它被禁用本身就是异常状态（除非有显式的维护窗口标记）。自动恢复 + 告警通知，比”静默停着等人工发现”好。但需要排除”主动维护中”的情况，可以加一个 maintenance_until 字段。

3. 连续偏差升级

记录每个任务的”连续未闭环天数”，达到阈值触发强制动作：

ESCALATION = {
    '连续未闭环天数 ≥ 2': '日记中标记为高优先级',
    '连续未闭环天数 ≥ 3': '创建一次性强制执行 cron',
    '连续未闭环天数 ≥ 7': '系统级缺陷告警 + 暂停新任务',
}

这个机制把”记录”升级为”处理”。当一个任务连续 3 天出现在偏差清单里却从未闭环，继续记录第 4 天毫无意义——必须换成执行通道，直接创建一个强制 cron 去跑它。

---

五、实现要点

独立性原则

Watchdog 自己必须是一个独立的 cron job，不能依赖被监控的任何子系统。

被监控：日记 cron、博客 cron、交易 cron、数据采集 cron...
监控者：Watchdog cron（唯一职责：检查其他 cron 和产出物）

⚠️ Watchdog 自身也需要一个"心跳"：
   每次运行后写一个 timestamp 文件。
   如果这个 timestamp 超过 36 小时没更新 → 说明 Watchdog 自己也停了。
   （谁来检查 Watchdog 的 Watchdog？— 可以用系统级 cron 或外部监控）

这就是标题的来源——**”谁来监管监管者？”（Quis custodiet ipsos custodes）。终极答案是没有完美的方案，但可以做到：每一层都有一个独立的上一层在看着它**，即使最顶层那层只能靠人。

检查频率

不需要实时。自治系统的故障通常以”天”为单位暴露，每日一次的巡检足够。建议在凌晨低负载时段运行（比如所有业务 cron 执行完之后的 05:00），检查”昨天该出来的东西有没有出来”。

告警通道

告警必须走一个与被监控系统不同的通道。如果系统内部的飞书/邮件推送本身就是依赖某个 cron 的，而那个 cron 恰好停了，告警就发不出去。两条路：

• 优先走系统自身的通知通道（简单）
• 关键告警（critical 级）额外走一个独立 webhook（兜底）

---

六、抽象出来的三条设计准则

这次复盘提炼出三条适用于任何自治系统的监控设计准则：

准则一：验证产出物，而非验证进程

检查”文件有没有生成”、”数据有没有写入”，而不是”进程有没有跑”。 进程跑了但产出为空，比进程没跑更危险——因为前者不会触发任何错误日志。

这条准则适用于所有”定时执行 + 产出文件/数据”的系统：ETL 管道、报表生成、备份任务、模型训练。验证产出物的存在性和完整性，才是真正的健康检查。

准则二：连续偏差必须升级，不能只记录

同一个偏差连续出现两次以上，说明”记录”这个动作本身已经失效。必须切换到执行通道——创建强制任务、升级优先级、或触发人工介入。

PDCA 循环里，Check 发现的偏差如果只是被记录到清单里等待”下次注意”，那 Check → Act 的环节就断裂了。偏差的”连续出现次数”本身就是一个需要被监控的指标。

准则三：监控层必须独立于被监控层

健康检查不能由被检查的对象自己执行。 调度器不能检查调度器自己、cron 不能检查 cron 自己。必须有独立进程、独立逻辑、独立通知通道的元监控层。

这不是过度设计。在两周内连续遭遇两次静默故障的系统，恰恰缺少的就是这一层独立视角。

---

回头看：静默是自治系统的天敌

自治 AI Agent 系统的愿景是”无人值守运行”。但无人值守的前提是系统能自己发现自己停了。

一个会崩溃的系统不可怕——崩溃是显式的。可怕的是一个半死不活的系统：核心还在跑，边缘悄悄停了，产出慢慢变空，而所有的监控面板还亮着绿灯。等到人发现时，可能已经过了一周。

解法不是更多的告警阈值或更复杂的健康检查脚本，而是建立一个独立的元监控层，定期回答三个问题：

1. 期望产出物出现了没有？
2. 应该运行的 cron 有没有异常？
3. 连续多天出现的偏差有没有被升级处理？

三个问题，一个独立进程，每日一次巡检。成本极低，但能把”静默退化”的发现时间从”天/周级”压缩到”24 小时内”。

自治系统不需要永不故障，但必须能在故障发生后 24 小时内自己发现它。 否则”自治”就退化成了”放任”。

---

本文基于一套基于 Hermes Agent 框架的自治量化交易系统的两周运维复盘，所有实体均已匿名化处理。