Aegis Watchdog — 可靠性工程

一个跑在「AI 运维 AI」场景上的系统，最大的风险恰恰是那个懂行的守护者自己引入故障。Watchdog 的一切设计都围绕这一条：怎么才能让它安静地守着，而不是出错。

· 故障建模 App\fault-policy.json（SchemaVersion 2）定义 12 类：GatewayDown / LivenessFailure / Crash / PlannedStop / 连通性退化 / DuplicateGateway / HermesTaskAbnormal / WindowsShutdownWatchdogCompatibility / UnknownPersistentErrors / StatusCommandTimeout 等
· 自动修复边界仅 4 类 AllowGatewayRestart=true（Down / Crash / Liveness / Duplicate）→ hermes gateway restart；6 类 AdvisoryOnly（不建 incident / 不告警）；2 类仅诊断（PlannedStop / HermesTaskAbnormal）
· 消噪 MaxRepairAttempts=2 · CooldownMinutes=60 + debounce，不做无意义重试
· 升级开关 EnableCodexEscalation、EnableClaudeEscalation 均 = false；唯一例外是 Gateway 本体故障时受控 Hermes 事件分析（冷却 360 分钟，每 incident 限 1 次）
· 健康路径 0 LLM Token。state.json / incident 自检 llm=0，日常运行不给模型麻烦

代码量 · E1（唯一权威来自 App\）

3 818 行 PowerShell（watchdog.ps1 1 700 / gui.ps1 845 / gui-bridge.ps1 426 / incident-diagnostics.ps1 338 …）
2 306 行 C# / XAML（WPF GUI，net8.0-windows）
1 719 行 测试 + 341 行 脚本；11 个迭代版本目录（第一版 → 第十版）
合计 7 843 行（3 818 + 2 306 + 1 719），与审计报告正文的「5 843」不一致——该数字系审计自身的加总笔误，此处按分项相加

EVIDENCE 01

08:56:31.050CHECK_STARTED健康检查开始（Automatic 触发）

08:56:48.427FAULT_DETECTEDGatewayCrash · PLANNED_STOP → DOWN · error_count=5

08:56:48.456INCIDENT_CREATED建立 incident 目录 20261016-085648-dc78f9ff

08:56:48.479REPAIR_STARTEDhermes gateway restart · attempt 1

08:57:39.411REPAIR_SUCCEEDEDDOWN → HEALTHY · 68 372 ms

08:59:34.732DIAGNOSTICS_COMPLETED确认性自检：gateway.running=True · telegram=True · llm=0

08:59:43.469INCIDENT_CLOSEDrecovered=True · alert=SENT · 全程 192 429 ms

来源 incidents/20261016-085648-dc78f9ff/timeline.jsonl（11 条事件，此处取 7 个关键节点）；未使用任何人工润色时间。

真实 incident · E1（不是宣传数字）

42 份 incident.json（63 个 incident 目录），故障类型集中在 GatewayLivenessFailure / GatewayDown / GatewayCrash
2026-10-16 08:56 GatewayCrash → restart SUCCEEDED → DOWN → HEALTHY（成功自愈）
2026-10-13 19:57 LivenessFailure → restart FAILED → 受控 Hermes 分析（31 321 token）→ 升级人工（失败有编号、有解释）

工程判断

危机意识不是把所有失败都自动修复——而是精确地划出「能自动的 4 类」并把其余交给流程。这个边界刻意窄。