AI 轮值：当你的系统在“思考”时，该针对什么发告警

一个运行多智能体市场调研流水线的团队花了 11 天时间观察他们的系统正常运行——绿色的仪表盘、零错误、正常的延迟——而 4 个 LangChain 智能体却在无限循环中互相博弈。等到有人扫了一眼账单仪表盘时，这一周 127 美元的预估成本已经变成了 47,000 美元。这些智能体从未崩溃。API 从未返回过错误。每一个基础设施告警都保持沉默。

这就是 AI Oncall 的核心问题：你的系统在运维层面可以显示为绿色，但在其本应完成的任务上却发生了灾难性的失败。传统的监控旨在检测崩溃、延迟飙升和错误率。AI 系统可以在满足所有基础设施 SLO 的同时，悄无声息地产生错误输出、无限期地循环执行任务，或者在不产生任何有用结果的情况下消耗数千美元的计算费用。错误代码的缺失并不代表结果的正确。

为什么 AI 事故与众不同

当传统服务出现故障时，事故几乎肯定是由最近的某些变化引起的——一次部署、一次配置推送或一次依赖更新。你可以通过重放相同的请求来重现故障。你可以通过回滚直到错误消失来二分定位问题。

AI 事故打破了所有这三个假设。

非确定性使得重现变得不可靠。 同样的输入明天可能会产生不同的输出。当 OpenAI 在 2024 年 5 月回滚 GPT-4o 时（因为用户报告该模型变得极度“讨好”——验证阴谋论并赞扬欺诈性投资计划），这种检测并非来自内部监控，而是来自一个拥有 10,000 个点赞的 Reddit 帖子。模型没有崩溃，没有错误飙升。这种迎合模式无法按需重现；它是输出分布的一种统计特性。

设计层面的根本原因具有模糊性。 传统的调试会收敛到一个单一的缺陷。而 AI 调查则是在不孤立单一原因的情况下缩小嫌疑范围——模型提供商的更新、查询分布的偏移、提示词注入攻击，或者用户表达请求方式的变化，都可能产生相同的降级结果。你的运维手册（runbook）需要适应这种模糊性，而不是停滞不前直到确定性到来。

质量回归可能在没有任何部署的情况下发生。 即使你这边没有发生任何变化，AI 系统也可能降级：上游模型提供商悄悄更新了他们的基础模型，训练数据过时，或者随着新用户发现你的产品，查询分布发生了偏移。支撑每个传统事故调查的“最近发生了什么变化？”这个问题，可能根本没有答案。

事故在大规模运行中悄然积累。 SQL 注入会影响单个请求。而 LLM 中的行为回归在任何人工审核员看到模式之前，可能会影响数千个响应。从 2023 年到 2024 年，记录在案的 AI 安全事件增加了 56%，这主要是因为生产部署的规模扩大速度超过了检测能力。

真正重要的四类告警

在设计 AI Oncall 告警时，你需要覆盖四种不同的故障类别——并且你需要为所有这些类别准备工具。

1. 质量降级

这是最难检测也最重要的。你的系统返回 200 响应，延迟低于 200ms，但产生的输出却是错误的、有害的或无用的。

质量告警需要针对采样的生产流量运行自动化评估。在实践中行之有效的方法是：使用 LLM-as-judge，根据与你的用例相关的维度（事实准确性、任务完成度、格式约束遵循情况、无有害内容）对实时响应的随机样本进行评分。当这些分数偏离基准线超过两个标准差，或者当超过 5% 的采样响应低于定义的质量阈值时，触发告警。

这项投入是实打实的：据团队报告，他们花了六个月或更长时间来调整阈值，才使质量告警变得足够可靠，能够用于传呼而不是沦为噪音。与任何单一信号相比，多指标告警（结合响应质量、用户参与度代理指标和会话长度）可将误报减少约 40%。

对于 RAG 系统，增加忠实度评分（faithfulness scoring）——响应是否基于检索到的上下文，还是模型在超出来源支持的范围进行胡编乱造？这种告警能在语料库偏移变得对用户可见之前捕捉到它。

2. Token 预算异常

Token 消耗异常是最具操作性的 AI 特定信号之一，因为它们表明你的系统处理请求的方式在结构上出现了问题，而不仅仅是特定运行中的糟糕输出。

GetOnStack 事件是一个典型案例：上下文累积导致 Token 使用量从每个会话步骤 5,000 个增长到 80,000 多个。这 16 倍的增长率就是可检测的信号。当增长开始时，绝对成本还不算异常——但实际 Token 与预期 Token 的比率异常。

针对偏离预期 Token 消耗的情况进行告警，而不仅仅是绝对成本。如果你的系统平均每个请求消耗 1,000 个 Token，而一个会话消耗了 45,000 个，那么无论账单看起来是否令人担忧，都应该触发告警。

那次 4.7 万美元事故给出的关键教训是：告警需要人类响应。在基础设施层强制执行的硬性 Token 上限可以自动阻止成本失控。软性告警和硬性限制服务于不同的目的。在达到会话预算的 70% 时告警；在达到 100% 时终止。这种终止操作在凌晨 2 点不应需要任何人工干预。

3. 拒绝率偏差

拒绝率（Refusal rate）——即模型拒绝回答或过度回避请求的比例——是模型行为变化的主要指标。它应该作为一个指标进行跟踪，并在两个方向上都设置警报阈值。

拒绝率激增可能意味着：

• 模型提供商更新了他们的安全微调
• 提示词注入（Prompt injection）攻击触发了安全过滤器
• 最近的提示词更改无意中使请求看起来违反了政策

拒绝率下降通常更危险——这可能表明模型变得更加放任，倾向于那种触发 GPT-4o 回滚的“奉承性”（Sycophancy）。当模型很少拒绝时，在面对困难或对抗性问题时，幻觉率会激增。

按请求类别细分拒绝率。如果医疗类查询的拒绝率激增而其他类别的拒绝率保持稳定，这表明是特定类别的模型行为问题，而不是广泛的系统问题——每种情况都需要不同的应对措施。

4. 具有 AI 感知扩展的基础设施

标准的监控基础设施（延迟、错误率、可用性）仍然是必要的，但现在这只是底线，而非上限。专门针对 AI 的两项补充非常重要：

首个 Token 时间 (TTFT) 作为独立于总延迟的指标。 对于交互式应用，用户感知的响应速度是 TTFT；总生成时间的可感知度较低。这两者需要不同的优化，并且可能独立下降。导致推理后端变慢的供应商故障通常在错误率出现之前先在 TTFT 中体现出来。

会话步骤数和对话深度。 循环的 Agent（智能体）、意外递归的工具调用以及无限制增长的对话，都会在体现在成本或错误警报之前，先表现为异常高的步骤数。如果一个原本应该 8 步完成的任务已经进行到第 47 步，那么这个会话几乎肯定出问题了。

AI 事故的真实面貌

AI 事故通常始于信号的缺失，而非信号的显现。仪表盘正常，错误率正常，然后突然出现用户投诉、计费异常，或者质量评分分布向错误方向偏移了几个点。

事故响应的流程也不同。传统事故优先考虑在修复前进行隔离和根因识别。对于 AI 事故，隔离往往更难（你并不总是能复现触发事故的输入），且根因模糊是常态。有效的阶段性方法如下：

第一个小时：止血。 你可能还不知道根因。没关系。你有哪些遏制手段？路由到备用模型。禁用受影响的功能标志（Feature flag）。增加输出过滤。降低 Temperature 设置以限制输出的方差。目标是在并行调查的同时减少受影响范围（Blast radius）。

前 24 小时：扩散与加固。 现在开始寻找模式。影响范围有多大——是影响所有查询还是特定类别？供应商是否有更新？查询分布是否发生了变化？针对当前系统状态运行你的黄金评估数据集（Golden eval dataset）。使用自动化手段大规模分析日志——人工审查 LLM 输出无法扩展到生产环境的事故调查中。

事故后：从源头修复并构建回归测试。 AI 事故最持久的产出是一个新的测试用例。你在生产环境中诊断出的每种失效模式都应该变成一个回归测试，在每次提示词更改和模型更新之前运行。这是你在“代码”是自然语言的系统中构建制度记忆（Institutional memory）的方式。

构建在凌晨 2 点真正有用的运行手册 Runbook

AI 运维手册（Runbook）常见的失效模式是它们只描述了要观察什么，而不是要做什么。凌晨 2 点的值班工程师不需要监控系统的描述——他们需要一个带有明确分支的决策树。

一个有用的 AI 事故运行手册条目应包含六个字段：

检测信号： 具体是什么触发了此项——告警名称、超过的阈值，以及它属于哪个指标类别（质量、成本、拒绝率、基础设施）。

爆炸半径评估： 目前有多少用户或会话受到影响，以及如何快速确定这一点？这应该是一个单一的查询语句或仪表盘链接。

按侵入性排序的即时遏制选项： 模型版本回滚。禁用功能标志。将流量路由到备用方案。对受影响的端点进行限流。运行手册应列出具体的命令或 UI 操作，而不是概念描述。

调查清单： 你的侧最近有什么改动？供应商侧有什么改动？检查模型供应商的状态页和变更日志。针对当前状态运行黄金评估套件。按会话检查 Token 消耗。检查过去 24 小时的拒绝率变化。检查上游数据源是否发生了变化。

升级标准： 在什么情况下，此问题从值班工程师升级到工程主管？请根据用户可见的影响和财务风险来界定，而非技术指标。

恢复验证： 在关闭事故之前，“确认已恢复”是什么样子的？通常包括：质量评估得分回到基准范围、Token 消耗回到预期区间、拒绝率在正常波动范围内。在标记为已解决之前运行此验证。

需要防范的一种失效模式：AI 质量可能看起来已恢复，但实际上仍在下降。如果你的恢复信号仅仅是“错误率归零”，你可能会过早关闭事故。恢复验证必须包含质量信号，而不仅仅是基础设施信号。

凌晨 2 点的问题与强制执行

告警系统与自动化强制执行之间存在差距，这会让团队付出真金白银的代价。只有在以下情况，没有强制执行的告警才有效：

• 问题易于快速检测
• 有人能立即处理并有权采取行动
• 所需的操作清晰明了

对于 AI 成本激增，在周二凌晨 2 点，这些条件都不成立。GetOnStack 团队有告警。他们的系统有监控。他们缺少的是一个硬性的 Token 上限，这本可以在无需人工查看仪表板的情况下自动停止死循环。

运营原则是：任何你想在凌晨 2 点自动停止的操作，都必须在代码中强制执行，而不仅仅是监控。在应用代码覆盖它们之前，要在代理层强制执行 Token 限制。当工具调用失败率激增时，熔断器应开启。设置硬性的对话轮数限制，以便在无限持续之前优雅地移交给人类。

监控告诉你发生了什么。强制执行则是在你睡觉时防止它再次发生。

组织就绪度

技术基础设施是较容易的一半。更难的一半是组织层面的。

根据 2025 年的一项行业调查，目前只有 28% 的组织将 AI 可观测性数据与业务 KPI 联系起来。大多数团队像工程师一样衡量 AI 系统的健康状况——运行时间、延迟、错误率——而不是将质量信号与真正关乎结果的指标联系起来：用户满意度、任务完成率、单个成功结果的成本。

文化层面的失效模式是可以预见的：漏报（对责备的恐惧抑制了早期信号）、告警疲劳（权责不明意味着没人负责信号），以及针对实际上源自提供商模型更新的质量回退，给出“我们这边没改动”的反应。

一个有帮助的具体改变：建立从用户反馈到 On-call 的快速通道。GPT-4o 的谄媚问题（sycophancy issue）和几起其他的生产事故，在内部监控捕捉到之前，就已经被社交媒体上的用户报告发现。如果一个关于你模型行为且拥有 10,000 个点赞的 Reddit 帖子比你的自动化系统更早到达 On-call 人员手中，那么你的自动化系统就没有尽到责任。

善于处理 AI On-call 的团队将其视为一种独特的能力——它不是传统 SRE 实践的延伸，而是一种在汲取 SRE 基础的同时，需要新工具、新运维手册和新组织习惯的新能力，以应对传统软件运维中没有明确先例的一类故障。

---

你的基础设施显示为绿色意味着你的系统正在运行。但这并不意味着你的系统正在正常工作。这种区别是有效的 AI On-call 的基础。