我们使用AI作为受控探针来测试警报文档

我们运营着一小批裸金属服务器，用于验证Glassmkr在真实硬件多样性下的表现。七台机器来自四个供应商、三种操作系统家族，时间跨度从2017到2024年。随着时间的推移，这些机器积累了大量警报。上周，仪表盘上活跃警报多达35个，大多是常规的漂移问题：内核更新待处理、安全补丁可用、自动更新未配置。仪表盘已告知我们数周该做什么，而我们一直未行动。

我们决定利用这个积压做点有用的事。与其亲自修复警报，不如进行一个实验：让一个编码代理尝试修复所有警报，但附加一个关键约束。

约束条件

代理只能使用：每个警报规则在/docs/alerts页面中的部分；警报证据JSON中的fix_commands字段；我们自己的文档中链接的任何文本；警报指向的日志输出。它不能使用：来自训练数据的一般Linux管理知识；我们未链接的外部供应商文档的网页搜索；未经我们建议的常识性运维操作。

这个约束的目的是测试我们的文档，而不是模型的能力。没有约束，代理会依赖训练数据解决问题，我们无法了解文档的不足。有了约束，我们指南中的每一个缺口都会显现出来。

我们对九台机器上的35个活跃警报进行了测试。去重后，共有10种不同的规则类型，涵盖内核更新、防火墙配置、SSH加固、安全补丁、自动更新、systemd服务故障、IPMI SEL事件、接口错误、SMART故障和内核漏洞。

我们的发现

大多数规则没问题。代理尝试解决了三种风险最高的类型（应用修复有实际后果），并审查了其他类型的指南质量。十种规则类型中有四种没有可操作的缺口。三种可以通过Forge记录的简单命令解决。剩下的三种在证据格式或文档中存在特定的、可修复的缺口。

这三种值得详细描述，因为每种代表不同的失败模式。

模式1：警报与证据不一致

在一台机器上，smart_failing触发严重级别警报。代理读取证据发现health: "PASSED"。从客户角度看，警报说驱动器故障，而证据说健康检查通过。没有第三个字段解释矛盾。该规则实际上基于多个独立的SMART阈值触发：重分配扇区数超过厂商阈值、待定扇区数增长、离线不可修复计数。任何一个都可能触发规则。证据形状根本没有指明哪个条件触发了。

修复是一行的求值器改动：发射一个triggering_signals数组，显式命名每个触发条件。修复后，同一台机器上警报清晰显示："triggering_signals": [{ "attribute": "reallocated_sectors", "observed": 1, "expected": 0 }]。一个扇区在Crucial MX300上重映射。真实信号，低严重性，立即清晰。

模式2：警报基于历史记录触发

在我们的生产services-1主机上，ipmi_sel_critical因2024年11月的电源供应AC事件触发。这些事件是成对的Asserted/Deasserted条目，意味着BMC观察到供电跌落和恢复。到2026年5月，电源已平稳运行15个月。而警报一直在触发。该规则没有时间窗口机制。一旦关键事件进入系统事件日志，规则永久触发，即使是一年前的瞬时事件。证据未暴露事件时间戳，因此仪表盘上的客户无法知道事件是当前还是历史，除非通过shell查看。

修复是双重的：将时间戳添加到critical_events[]证据数组中的每个事件；为规则本身添加可配置的时间窗口，默认30天，并可针对噪声主机进行覆盖。修复发布后，services-1警报在下一次采集周期自动解决：一年前的事件落在新窗口外。无需客户操作。

模式3：警报指向问题但未指向修复

在第三台机器上，systemd_service_failed因fail2ban触发。代理按照我们的四步指南：检查状态、读取日志、尝试重启、再次检查状态。前三步有效。日志显示实际问题：Have not found any log file for sshd jail。第四步（重启）失败，因为底层配置问题未改变。我们的文档在此处结束，建议“检查配置和依赖项”。这恰恰是客户自助服务中断的地方。日志说了实话。我们需要从日志输出到修复之间搭建桥梁。

修复是操作性的，而非文档性的：我们更改了Crucible，将失败单元的最后几行日志直接包含在警报证据中。客户无需SSH即可看到失败原因。该机器上的警报证据现在直接显示Have not found any log file for sshd jail错误。到修复的路径更短了。

交叉发现

这三个缺口看似不同，但共享一个形状：每种情况下，规则已经可以访问的证据比客户看到的证据更丰富。所有三个修复都是暴露我们已经掌握的信息。这是持续存在的缺口模式。我们的/docs/alerts页面以一般性术语告诉客户警报的含义，而证据JSON具体告诉客户规则观察到了什么。两者正在偏离。查看我们仪表盘中警报证据的客户比阅读我们文档页面的客户获得了更好的指导。

我们在代理成功解决警报的规则中也注意到相同的更温和版本。对于interface_errors，我们的fix_commands字段包括防火墙与网卡的歧义检查，而我们的/docs/alerts页面未提及。对于ssh_root_password，我们的fix_commands字段包括密钥访问验证探测，而文档页面未提及。更丰富的指导隐藏在警报本身中。

我们交付了什么

同一周内我们交付了三个求值器更改和一次文档审计。证据形状改进首先落地，因为杠杆更高：每个阅读任何警报的客户立即受益。文档审计随后落地，以缩小/docs/alerts与fix_commands之间的差距。我们没有为每个规则添加“可操作步骤”部分，因为fix_commands已服务于该目的。错误在于/docs/alerts没有反映它。

方法论，单独说明

使实验成功的约束值得提取出来。没有它，实验将衡量LLM的一般Linux能力，这并不有趣，因为答案是“对大多数事情足够高”。有了它，实验衡量了我们自己的指南对于自助服务是否足够完整，这正是对客户重要的关键问题。

任何在自己的基础设施上执行类似练习的人都应采用相同的约束。禁止代理使用其在领域上的训练数据。强制它仅使用你产品记录的指南。每个失败点都是真实客户也会遇到的缺口。通过AI运行的优势在于速度：实验大约需要一小时时钟时间。使用自己产品的优势在于诚实：每个暴露的缺口都是真实的。

关于工具的一个说明：我们为此实验使用了外部编码代理（Claude Code），因为禁止训练数据使用对于外部代理比对我们自己的生产部署更易执行。实验运行在我们的验证集群上，而不是任何客户基础设施。来自Glassmkr账户的客户遥测继续由我们专用L4 GPU上的Gemma 4 26B分析，从未离开Glassmkr栈。

我们一个月后还会再做一次。剩余工作列表尚未清空。