Agent 系统的告警策略应该如何设计
1️⃣ 考察意图
面试官想看你能否设计一个 Agent 系统的告警体系，而非简单说"加监控"。刁钻点在于：Agent 系统的告警比传统软件复杂——除了基础设施指标（CPU/内存/延迟），还需要 LLM 特有的指标（幻觉率、工具调用失败率、安全事件）。而且 Agent 的"慢"不一定是 bug（复杂任务本就需要多步推理），如何区分"正常慢"和"异常慢"是告警设计的核心挑战。答好了能展示你的 SRE 思维和对 LLM 系统可观测性的深度理解。
2️⃣ 标准答
Agent 告警体系分四层，从基础设施到业务质量：
1. 基础设施层告警（Infra Alerts）
| 指标 | 告警阈值 | 优先级 | 说明 |
|---|---|---|---|
| 服务可用性 | < 99.9% | P0 | 健康检查连续 3 次失败 |
| P99 延迟 | > 30s | P1 | Agent 任务正常 5-15s，>30s 异常 |
| CPU 使用率 | > 85% | P2 | 持续 5 分钟 |
| 内存使用率 | > 90% | P1 | 可能 OOM |
| GPU 使用率 | > 95% | P1 | 自部署模型场景 |
| API 限流 | rate_limit_hit > 10% | P1 | OpenAI/Anthropic API 限流 |
2. LLM 质量层告警（Quality Alerts）
| 指标 | 告警阈值 | 优先级 | 说明 |
|---|---|---|---|
| 任务完成率 | 下降 > 10% vs 基线 | P1 | 滑动窗口 1 小时对比 |
| 幻觉率 | > 8% | P1 | NLI 检测，滑动窗口 1 小时 |
| 工具调用失败率 | > 15% | P1 | 区分工具端故障和 Agent 参数错误 |
| 安全拒绝率 | > 20% 或 < 2% | P0 | 过高=误拒影响体验，过低=可能被绕过 |
| Token 消耗异常 | > 基线 × 2 | P2 | 可能是 prompt 异常或循环调用 |
| LLM-as-Judge 评分 | < 0.7 | P1 | 滑动窗口 30 分钟 |
3. 安全层告警（Security Alerts）
| 事件 | 告警方式 | 优先级 | 说明 |
|---|---|---|---|
| 提示注入疑似 | 立即 PagerDuty + 自动阻断 | P0 | 检测到注入模式 |
| 权限越界 | 立即 PagerDuty + 熔断 | P0 | Agent 尝试调用未授权工具 |
| 敏感信息泄露 | 立即 PagerDuty | P0 | 输出包含 PII/API key |
| 批量危险操作 | 1 分钟内 > 5 次 L2+ 操作 | P0 | 熔断 + 要求 2FA |
| 沙箱逃逸疑似 | 立即 PagerDuty + 容器隔离 | P0 | eBPF 检测异常系统调用 |
4. 业务层告警（Business Alerts）
| 指标 | 告警阈值 | 优先级 | 说明 |
|---|---|---|---|
| 用户 CSAT | < 3.5/5 | P2 | 滑动窗口 4 小时 |
| 用户投诉量 | > 基线 × 3 | P1 | 客服系统对接 |
| 日活/任务量 | 下降 > 20% | P2 | 可能是质量问题导致用户流失 |
| 成本/任务 | > 基线 × 1.5 | P2 | token 价格波动或 Agent 效率下降 |
5. 告警降噪与自动化
- 告警聚合：同一 Trace ID 的多个告警聚合为一条，避免告警风暴
- 告警抑制：P0 告警触发时，抑制同级和下级告警 5 分钟，聚焦处理核心问题
- 自动 Runbook：每个告警附带 Runbook 链接（如"任务完成率下降 → 检查1.模型状态 2.工具可用性 3.prompt版本"）
- 自动降级：P0 安全告警自动触发降级——暂停 Agent 服务、切换到备用模型、启用只读模式
- 告警复盘：每次 P0/P1 告警后 24 小时内复盘，更新告警阈值和 Runbook
3️⃣ 答题模板（30 秒电梯版）
"Agent 告警四层体系。基础设施层：可用性<99.9%(P0)、P99>30s(P1)、API限流(P1)。LLM质量层：任务完成率下降>10%(P1)、幻觉率>8%(P1)、工具失败率>15%(P1)、安全拒绝率过高或过低(P0)。安全层：提示注入/权限越界/信息泄露/批量危险操作/沙箱逃逸全部P0立即PagerDuty。业务层：CSAT<3.5(P2)、投诉量3倍(P1)。降噪：同Trace聚合+P0抑制下级+自动Runbook+自动降级。核心：Agent告警不只是'服务挂了'，还需要监控'服务质量退化'。"
4️⃣ 高频追问 & 应对
追问 1：任务完成率的"基线"怎么定义？Agent 不同任务类型完成率差异很大。
分层基线：(1) 按任务类型分基线——简单查询任务基线 95%、复杂推理任务基线 75%、工具调用任务基线 85%。不同类型分别对比，避免混合统计导致误报；(2) 动态基线——用最近 7 天同时段的平均值作为基线（如本周二 14:00-15:00 vs 上周二 14:00-15:00）。消除时间周期性影响；(3) 异常检测——用时间序列异常检测（如 Prophet 或 isolation forest）替代固定阈值。如果实际完成率偏离预测值超过 2 个标准差，触发告警。适用场景：任务类型分布变化频繁时，固定阈值不适用。
追问 2：安全拒绝率"过高或过低"都是告警，具体怎么设阈值？
双向阈值：(1) 过高（>20%）——说明安全策略可能过于保守，大量正常请求被误拒。用户体验受损，需要检查是否 prompt 过于严格或安全 Agent 误判。阈值依据：正常场景下拒绝率通常 3-8%（主要是真正的危险请求被拒）。>20% 很可能是误报率过高；(2) 过低（<2%）——可能是安全策略被绕过（如模型升级后指令遵循能力变化导致安全 prompt 失效），也可能是攻击者在试探。阈值依据：即使没有攻击，总会有少量边缘案例触发安全机制。<2% 说明安全机制可能形同虚设；(3) 趋势监控比绝对值更重要——拒绝率突然从 5% 跳到 15% 或从 5% 降到 1%，即使都在阈值范围内也应该告警。用变化率（如 1 小时内变化 >5%）作为补充告警条件。
追问 3：Agent 系统的告警量比传统系统大很多（更多指标），怎么防止告警疲劳？
三个策略：(1) 告警分级与路由——P0 告警走 PagerDuty（立即通知+电话升级），P1 走 Slack 通知（5分钟内响应），P2 走日报汇总。不同级别走不同渠道，避免所有告警都打电话导致疲劳；(2) 智能聚合——用关联分析把"因果关系"的告警聚合。例如"API 限流"导致"任务完成率下降"导致"CSAT下降"——这三个告警应该聚合为一条"API 限流引发的服务降级"，而非三条独立告警。用 Trace ID 或时间窗口关联；(3) 自适应阈值——系统运行稳定后，自动学习正常波动范围，动态调整阈值。减少因为正常波动导致的误报告警。实测自适应阈值能减少 40-60% 的误报。
5️⃣ 避坑 · 常见错误答法
- ❌ "告警就是监控 CPU 和内存" → ✅ "Agent 系统除了基础设施监控，还需要 LLM 质量监控（幻觉率/工具失败率/安全拒绝率）和安全监控（注入/越界/泄露）。传统监控无法覆盖 Agent 特有的质量退化。"
- ❌ "延迟高就告警" → ✅ "Agent 的延迟与任务复杂度相关——简单查询 3s 正常，复杂推理 30s 也可能正常。需要按任务类型设不同阈值，或用异常检测替代固定阈值。"
- ❌ "所有告警都发 PagerDuty" → ✅ "告警疲劳会导致工程师忽略真正的紧急告警。需要分级路由——P0 走 PagerDuty、P1 走 Slack、P2 走日报。加上智能聚合和自适应阈值减少误报。"
6️⃣ 简历呼应
- 如果你有 Agent SRE 项目：从"告警体系建设"切入，描述你设计的四层告警体系（基础设施/LLM质量/安全/业务），给出数据（如告警准确率从 60% 提升到 85%、平均响应时间从 30 分钟降到 5 分钟）
- 如果你只做过传统 SRE：用"微服务监控"迁移，说明 Prometheus/Grafana/PagerDuty 的使用经验直接适用。Agent 特有的是"质量层告警"——幻觉率、工具失败率等 LLM 特有指标
- 如果你是校招无项目：用 Prometheus + Grafana 搭建 Agent 监控 demo，实现四层告警 + 智能聚合 + 自动 Runbook，用模拟数据演示告警流程
- "SRE for Machine Learning Systems" (Google, 2024)
- "Observability for LLM Applications" (Honeycomb, 2024)
- "Monitoring AI Systems: A Practical Guide" (Arize AI, 2024)
本章学习完毕 ← 返回 Agent 岗面试宝典 v3 · 精华版 | 📝 建议整理错题笔记 | 🎯 标记掌握程度