# AIOps 告警验收用例

## 1. 目标

验证旧版 `/api/ai_ops` 入口可以作为可追踪的告警触发诊断入口，并且 payload 模式下报告聚焦输入告警。

## 2. 输入

- Session id：`mvp-demo-aiops-payment-cpu-001`
- Endpoint：`POST /api/ai_ops`
- Profile：`mvp-demo`
- 告警 payload：

```json
{
  "sessionId": "mvp-demo-aiops-payment-cpu-001",
  "alertName": "HighCPUUsage",
  "service": "payment-service",
  "severity": "P1",
  "description": "服务 payment-service 的 CPU 使用率持续超过 80%，当前值为 92%。实例: pod-payment-service-7d8f9c6b5-x2k4m。",
  "timeRange": "last_15m",
  "userRequest": "请结合 Prometheus 活动告警、system-metrics 日志和知识库生成告警分析报告。"
}
```

## 3. 验收标准

1. SSE 流输出 `session` 消息，且包含请求中的 session id。
2. AIOps 执行创建或更新 `diagnosis_session`，并写入 `agent_flow = AI_OPS`。
3. 持久化的 session query 包含告警名、服务名、等级、时间范围和描述。
4. 如果生成最终报告，`diagnosis_session.answer` 包含该报告。
5. `GET /api/diagnosis/{sessionId}/trace` 返回 AIOps session、按顺序排列的 agent steps 和 tool invocations。
6. payload 模式下，报告主线聚焦 `HighCPUUsage/payment-service`。
7. 其他活跃告警最多作为相关风险或上下文出现，不应展开成完整独立根因章节。
8. `self_evaluation.aiops_rule_evaluation` 存在，并能反映报告完整性、payload 聚焦和证据工具覆盖情况。

## 4. 已知边界

- 当前 AIOps 使用轻量规则评估器，不是完整 LLM Verifier。
- 完整运行仍依赖有效的 DB、Redis、Milvus/Zilliz、模型和 embedding 配置。
- `mvp-demo` profile 使用 mock Prometheus 和 mock CLS，主要用于稳定演示。