用 AI Agent 做 Oncall 运维告警处理：告警初筛 + 日志分析 + 根因草稿

Agent 要分析，先得能看到数据。用 MCP 或脚本把监控/日志系统暴露给它：

# 示例：用 MCP 把 Prometheus + Loki 接进Agent
{
  "mcpServers": {
    "prometheus": { "command": "npx", "args": ["-y", "mcp-server-prometheus", "--url", "http://prom:9090"] },
    "loki":       { "command": "npx", "args": ["-y", "mcp-server-loki", "--url", "http://loki:3100"] }
  }
}
# 没有现成 MCP？用脚本包一层 REST 也行

这是整个系统的"安全护栏"，务必写清楚红线：

你是我们的 Oncall 分析助手，职责：
- 收到告警后，聚合相关告警、判断严重度（P0-P3）
- 拉取近 30 分钟相关服务的日志与核心指标
- 给出"最可能原因 Top3"和"建议排查步骤"
- 绝不执行任何写操作（重启/回滚/删数据/改配置）

红线：
- 任何执行类操作，只给出命令草稿，等我确认
- 不确定时明确说"需人工确认"，不许编造根因

配置告警触发后自动调用 Agent，先做个聚合去重：

# 伪流程：告警 Webhook → Agent
收到 12 条"CPU 高"告警（来自同一集群）
Agent 输出：
  严重度：P2（非 P0，非全集群）
  关联：与 5 分钟前的"发布事件 #8821"时间吻合
  建议：先观察，疑似发布引起，不必立即叫人
  → 推送到 Oncall 群，附聚合摘要

对确需关注的告警，Agent 主动拉数据并产出草稿：

Agent 自动产出（示例）：
【现象】order-service 错误率 14:02 起升至 8%
【关联指标】下游 pay-service P99 延迟同步抬升
【日志线索】14:02 出现大量 "timeout calling pay-service"
【可能根因 Top3】
  1. pay-service 扩容未完成，连接池打满（概率高）
  2. 网络策略变更导致跨区延迟（概率中）
  3. 上游限流配置误改（概率低）
【建议排查】先查 pay-service 实例数与连接池；命令草稿见下
【命令草稿】（待我确认再执行）
  kubectl get pods -n pay | grep -v Running

接上钉钉/飞书/企微机器人，让 Agent 把草稿发到 Oncall 群，并 @ 当班人：

# Agent 输出结构化卡片到群
[Oncall 分析] order-service 错误率异常
严重度：P1
根因草稿：pay-service 连接池打满（高概率）
需你确认：是否执行 kubectl 扩容？回复"执行/稍等"
# 人回复"执行" → 才触发后续自动化（且要走审批）

Orca-Bench 告诉我们：涉及多服务、模糊日志、需深度系统知识的故障，Agent 成功率会塌到 30% 以下。此时让它主动"交还控制权"：

Agent 判断：
  本次涉及 6 个服务、日志不完整、无明确时间锚点
  置信度：低（<40%）
动作：标记为"需人工深度排查"，
      附已收集的日志片段 + 初步假设，
      升级给值班 SRE，不再自行推断根因。

故障解决后，把"现象→真因→解法"写进知识库，下次同类告警 Agent 直接命中：

复盘入库模板：
  触发特征：order-service 错误率突增 + pay 延迟
  真因：pay-service 发布后连接池未调大
  解法：发布 checklist 增加连接池校验
  → 存入 RAG 知识库，Agent 下次自动引用