AIOps Agent 运维闭环系统重构设计（V4 草案）#

状态：P0 已实现（2026-07-09，pytest 426 passed，见 layers-v4/P0-IMPLEMENTATION-REPORT.md）　日期：2026-07-08 定位：这是对现有 V3（fast/deep 双模式）的一次骨架级重构提案。本文只做”落库”——先把整体设计、参考出处、迁移路径固化下来，后续每个模块（Layer）再单独开文档深挖。 原始输入：~/Downloads/aiops-agent-closed-loop-design.md（Spring/Milvus/DocMind 血统的六层闭环草案）+ 本仓库 V3 现状。

核心约束：本文每一个关键设计决策都必须挂一个真实的开源 / 成熟商业项目参考，不自创。 见 §10 参考出处汇总。

0. TL;DR#

• 分层自适应调查引擎：砍掉调用方手选的 fast/deep 双模式，换成确定性三级递进的唯一调查链路——告警经规则引擎预处理（去重、时间窗聚合、拓扑级联关联）收敛至根因候选集；Tier 1 已知故障 Runbook 匹配直接处置，Tier 2 相似故障向量检索限定 3 轮定向验证，Tier 3 未命中进入 ReAct Agentic Loop 深度调查。各级未命中自动递进并继承已有证据。
• 假设驱动式调查机制：Tier 3 采用两阶段推理——LLM 先生成 3-5 条根因假设按可能性排序，再在 ReAct Loop 中逐条调用工具定向取证，每轮输出结构化假设状态与置信度，达标即终止，避免非必要推理。
• Runbook 冷启动与自增长闭环：初期导入通用 Runbook 实现冷启动；后续 Tier 3 调查经人工确认后，LLM 自动从证据链提炼前置条件与处置步骤，生成结构化 Runbook 经审核入库，持续扩充 Tier 1 覆盖率，形成”越用越准”的知识飞轮。
• LLM 修复操作的安全治理：将修复操作按资源域建模为参数受限的结构化工具，以调用白名单工具替代生成自由 shell 命令，消除命令注入与越权风险；高风险操作通过飞书移动端一键审批，超时自动降级。对齐 OWASP LLM Top 10 / Google SRE，见 §5。
• 事务化修复与验证闭环：为修复方案创建补偿事务并预生成补偿操作；执行前 CAS 漂移检测，失败自动补偿回滚；执行后三级递进门禁（命令成功 → 服务健康 → 指标恢复）逐级验证，形成执行-验证-回滚的自校验闭环。
• 以 Incident 状态机为骨架（第一类公民），告警只是喂给 Incident 的信号，Incident 有完整生命周期。保留”六层闭环”分层思想，全部翻译成本项目 Python 技术栈（FastAPI / LangGraph / pgvector / Redis Streams / MCP / DeepSeek-V4）。
• 核心理念不变：“进来的是症状，出去的是根因 + 修复验证结果 + 沉淀的知识”。

1. 为什么要重构：现有 fast/deep 的问题#

2. 骨架：Incident 生命周期状态机#

Incident 是第一类公民。告警经预处理后归并进 Incident，Incident 在一张持久化状态机上流转：

DETECTED
   │  预处理产出 IncidentContext
   ▼
TRIAGING ──────────────► 分诊：定 impact，进入唯一调查链路（便宜优先、命中即止）
   │
   ▼
INVESTIGATING ◄───────── 任意后续态可被"新告警并入"拉回此态（增量再调查）
   │  产出 Investigation（假设树 + 根因 + 证据链）
   ▼
RCA_READY
   │  决策层判自治等级
   ├── AUTO ──────────► REMEDIATING
   ├── AWAIT_APPROVAL ─► （飞书一键审批 / 超时降级）► REMEDIATING or ESCALATED
   └── HANDOFF ───────► ESCALATED（推 RCA 给人工，Agent 不执行）
   │
REMEDIATING
   │  事务化工具：快照→CAS→执行
   ▼
VERIFYING
   │  verify_metric / metric_recovery 门禁；resolved ≠ 根治
   ├── 通过 ─► RESOLVED ─► （回流学习层）
   └── 失败 ─► 自动回滚 ─► ESCALATED

状态迁移表、并发规则（同 Incident 串行、跨 Incident 并行）、增量再调查的合并语义 留到 Layer 文档细化。

参考：incident.io / Rootly / FireHydrant 的事件生命周期与时间线模型；Netflix Dispatch（开源事件管理）；状态持久化用 LangGraph checkpointer（现有）或 Temporal（§7）。

3. 核心改动：分层自适应调查引擎（取代 fast/deep）#

3.1 设计立场：确定性三级递进，而非调用方选模式#

fast/deep 的问题不在于”只有两个模式”，而在于存在需要调用方选择的模式。把两个模式换成三级阶梯但仍让调用方选，只是把 2 个模式变成 3 个模式，复杂度不降反升——这是一次被否掉的中间设计，记录在此以示教训。

正解是调用方只提交告警，系统内部一条确定性三级递进链路自动决定调查深度：Tier 1 → Tier 2 → Tier 3，每级未命中自动递进至下一级并继承已有证据。调查”走多深”是系统的输出结果而非输入参数，对调用方完全透明。

3.2 唯一链路：规则预处理 → 确定性三级递进#

提交告警（调用方只做这一步，不选任何东西）
   │
   ▼
规则引擎预处理（去重、时间窗聚合、拓扑级联关联）──► 收敛至根因候选集（IncidentContext）
   │
   ▼
Tier 1：已知故障 Runbook 匹配 + 前置条件校验 ──命中──► 确定性处置（不进 LLM）──► 结束
   │未命中（继承已有证据）
   ▼
Tier 2：相似故障向量检索 + 限定 3 轮定向验证历史根因 ──命中──► 复用历史 RCA ──► 结束
   │未命中（继承已有证据）
   ▼
Tier 3：假设驱动 ReAct Agentic Loop 深度调查 ──► 输出根因 + 证据链 ──► 结束

• Tier 1/2/3 是同一条链路上的三个确定性递进阶段，不是三个模式，也没有入口分流开关。各级未命中自动递进至下一级，并继承已有证据。
• “省算力”是**“命中即止”的自然结果**，不需要任何人预先选择投入等级。
• 影响面（impact_score）只影响各级的置信门槛（高影响面要求更高置信才敢在 Tier 1 停），不改变链路结构。

3.3 各 Tier 的实现机制与参考项目#

三者是同一条链路的确定性递进，各级未命中自动递进至下一级并继承已有证据，而非并列的三种模式。

对百炼 RPM/TPM 限流的意义：越多告警在 Tier 1/2 被消化，越少 LLM 出站调用，直接缓解已知的 TPM 隐患。

3.4 各 Tier 的置信判定与递进降级#

• impact_score 只调门槛不改结构：影响面越大，Tier 1/2 的置信门槛越高，极端情况强制走 Tier 3 复核后才允许处置——影响面越大，越不敢便宜地停。
• 优雅降级（架构副产品，值得点名）：百炼限流或 LLM 完全不可用时，Tier 1 纯规则、Tier 2 检索侧仍然工作，系统从”智能诊断”退化为”确定性自愈 + 相似案例推荐”，而不是整体瘫痪。这是把规则层放在 LLM 前面的直接收益，也是对 DeepSeek-V4 出站脆弱性（已知隐患）的架构级兜底。

3.5 假设驱动式调查机制（Tier 3 核心）#

Tier 3 不做无目标的 ReAct 循环，采用两阶段推理把发散收敛分离：

阶段一：假设生成

• LLM 结合 IncidentContext（告警详情、拓扑关联、Tier 1/2 的排除结论）+ RAG 检索注入，生成 3-5 条根因假设。
• 每条假设包含：假设描述、涉及组件、所需验证的证据类型、可能性排序（ranked by prior probability）。
• 假设间应具有互斥性或至少不同故障域覆盖，避免同类假设堆叠。

阶段二：定向取证 ReAct Loop

• 按可能性排序逐条假设调用工具定向取证（orchestrator-workers 模式，高优先假设可并行取证）。
• 每轮输出结构化假设状态：INVESTIGATING / CONFIRMED / REFUTED / INSUFFICIENT_EVIDENCE，附置信度分数。
• 某假设达到 CONFIRMED + 置信度达标 → 立即终止，不继续验证剩余假设，避免非必要推理和 token 消耗。
• 所有假设遍历完仍无 CONFIRMED → 取置信度最高者标记为 BEST_EFFORT，进入 ESCALATED 交人工复核。

参考：ReAct 论文（reason-then-act）；HolmesGPT 的 investigation 模式；Anthropic《Building Effective Agents》Orchestrator-Workers 模式。

3.6 Runbook 冷启动与自增长闭环#

Tier 1 的确定性 Playbook 覆盖率直接决定系统的”零 LLM 消化率”。Runbook 从哪来、怎么长是核心问题：

冷启动（Day 0）

• 导入通用 Runbook 种子库（磁盘清理、服务重启、OOM 处理等高频场景），schema 借鉴 §11.1 playbooks.ts（detect / diagnose / action / escalate / cooldown）。
• 从现有 app/skills/ 剧本批量转换为结构化 Runbook 格式，补齐前置条件校验（precondition check）。

自增长（Tier 3 → Tier 1 飞轮）

• Tier 3 调查产出的根因 + 证据链 + 处置步骤，经人工确认（RCA 采纳 + 验证门禁通过）后，触发 Runbook 生成流水线：
  1. LLM 自动从证据链中提炼前置条件（告警指纹匹配规则）与处置步骤（结构化动作序列）。
  2. 生成结构化 Runbook 草稿（含 detect/diagnose/action/verify/rollback 各阶段）。
  3. 草稿进入审核队列（人工审核 or 自动化回归测试），审核通过后入库。
• 入库后同类告警下次触发时命中 Tier 1，调查深度从 Tier 3 前移至 Tier 1——这是”越用越准”飞轮的具体机制。

防污染（与 L6 联动）

• 只有”验证门禁通过 + 人工确认”的案例才允许生成 Runbook，未确认的不进入生成流水线。
• 生成的 Runbook 版本化管理，支持下架；命中后 verify 失败的 Runbook 自动标记待审查。
• Golden Set 周回归覆盖 Runbook 有效性（Runbook 命中率 + 命中后处置成功率）。

参考：StackStorm pack 生态（社区 Runbook 共享）；Robusta playbooks（种子 + 自定义）；PagerDuty Runbook Automation。

4. 分层设计（融合六层 + 参考）#

L1 接入层（Ingestion）#

• 统一 Alert Envelope，resource 字段结构化（cluster/service/host/instance），作为关联/写闸/CMDB 对齐的锚点。
• 幂等：fingerprint(labels+startsAt) 做 key，Redis SET NX。
• 零智能：只归一化 + 入队（现有 Redis Streams），重活全下沉，webhook 202 立即返回。
• 参考：Prometheus Alertmanager（label 模型 / 重推机制）；Keep(keephq) 接入层；OpenTelemetry Resource 语义约定。

L2 预处理层（Pre-processing，纯规则不进 LLM）#

• 去重 / 抑制 / 时间窗聚合：直接对标 Alertmanager 的 group_wait/group_interval/inhibit_rules，不自创窗口逻辑。
• 拓扑关联：同 node/service + 依赖上游 = 根因候选；拓扑来源 K8s API + OTel Service Graph。
• 抖动检测 + Impact 评分：保留原草案加权模型；Impact 不改变调查链路结构，只调节 §3 各 Tier 的置信门槛（影响面越大越不敢提前停）。
• 产出 IncidentContext 推入调查队列。
• 参考：Alertmanager；BigPanda Open-Box ML / Moogsoft Situations（告警关联成事件）；PagerDuty Intelligent Alert Grouping。

L3 调查层（Investigation，核心，承载 Tier 1/2/3 三级递进）#

• Tier 1 Runbook 匹配：告警指纹精确匹配 + 前置条件校验，命中则跑确定性剧本不进 LLM（种子 Runbook 冷启动 + 自增长闭环见 §3.6）。
• Tier 2 历史根因复用：pgvector + pg_search(BM25) + RRF 混合检索相似 Incident，命中后限定 3 轮定向验证适用性（便宜档小模型复核），省 token 又防误命中。语料是 incident_vectors（已解决 Incident 在迁到 RESOLVED 时向量化落库），与知识库 kb_chunks 分表——语料性质不同，混表会让知识库检索被历史故障报告污染。RRF 只用于排序；命中门槛用向量 cosine（BM25-only 命中回落字面相似度），因为 RRF 分数没有 [0,1] 量纲。误命中记入负样本，按 sim/(1+w·n) 反哺检索降权。三档降级：embedding 挂→只走 BM25；没装 pg_search→退纯向量；语料空→回落字面相似 + Wiki。
• Tier 3 假设驱动式两阶段推理（核心差异化，详见 §3.5）：LLM 先生成 3-5 条根因假设按可能性排序，再在 ReAct Loop 中逐条调用工具定向取证，每轮输出结构化假设状态与置信度，达标即终止。
• 并行 subagent 取证 = Orchestrator-Workers：现有 deep 图的多 subagent 保留并正名，用于 Tier 3 高优先假设的并行取证。
• 工具输出压缩：三级（源头过滤→JSONPath→小模型摘要），小模型用便宜档（Qwen-turbo）。
• 参考：ReAct 论文；HolmesGPT；RCACopilot；Anthropic Orchestrator-Workers。

L4 决策层（Decision）#

• 自治等级矩阵（AUTO / APPROVAL / MANUAL）= 运维版自动驾驶分级，按 confidence × risk × 白名单判定。
• 审批流：接现有飞书长连接一键审批 + 超时降级 escalate_then_deny。
• 参考：Shoreline autonomy levels；Google SRE（先建议后自动、错误预算约束）；AWS SSM Automation approval step。

L5 执行层（Execution，承载 bullet 4+5：安全治理 + 事务化闭环）#

• 资源域建模：将修复操作按资源域建模为参数受限的结构化工具（restart_service / clean_disk / scale_replicas…），LLM 产出的是白名单动作类型 + 参数，以调用白名单工具替代生成自由 shell 命令，消除命令注入与越权风险。
• 事务化修复（reconcile / plan-apply 思想）：为修复方案创建补偿事务并预生成补偿操作；执行前进行 CAS 漂移检测（快照→比对→确认状态未漂移再执行），失败自动补偿回滚。
• 三级递进验证门禁：执行后逐级验证，形成执行-验证-回滚的自校验闭环：
  1. 命令成功：执行返回码 + 状态变更确认
  2. 服务健康：目标服务健康检查通过（verify_metric）
  3. 指标恢复：关键业务指标恢复到告警前基线（metric_recovery），resolved ≠ 根治，OOM/Crash 类额外观察 N 分钟
• 护栏：熔断（同组件 1h 内 3 次失败 → 停）、Redis 分布式锁（同组件串行）、RBAC/SA 隔离、命令安全闸（危险命令分级 × 角色授权矩阵 + 子 shell/base64/curl|sh/命令链绕过拦截，翻写 §11.1 commandFilter）。
• 高风险审批：高风险操作通过飞书移动端一键审批，超时自动降级（escalate_then_deny）。
• 参考：K8s Controller reconcile；Terraform plan-apply + drift；Argo Rollouts（analysis + 自动回滚）；StackStorm guardrails；Shoreline Op。

L6 学习层（Learning，跨事件进化闭环，承载 Runbook 自增长）#

• Postmortem 回流 RAG：关闭即沉淀，下次相似告警在 Tier 2 命中历史，形成越用越准的飞轮。
• Runbook 自增长闭环（核心，详见 §3.6）：Tier 3 调查经人工确认后，LLM 自动从证据链中提炼前置条件与处置步骤，生成结构化 Runbook 经审核入库，持续扩充 Tier 1 覆盖率——这是”Tier 3 → Tier 1”知识飞轮的具体落地路径。
• 防污染（飞轮的刹车）：只有”验证门禁通过 + 人工确认”的 Incident 才允许回流入库和生成 Runbook；沉淀条目版本化可下架；Tier 2 误命中记负反馈降权。用 Golden Set 周回归监控”越学越错”的漂移。
• 人工反馈入口：RCA 采纳/驳回、审批拒绝原因、ESCALATED 后的人工结论，都作为 human_feedback 写回 IncidentReport，是 L6 最高质量的监督信号。
• Golden Incident Set + 每周回归：复用现有 eval_ragas / eval_router 底子。
• 指标目标（沿用草案）：RCA 准确率 > 80%、平均调查轮次 < 8、调查耗时 < 5min、修复成功率 > 90%、误操作率 < 1%。
• 参考：Google SRE Postmortem 文化；Ragas / LangSmith Datasets / OpenAI Evals。

5. 安全纵深防御架构（Security by Design，本次重构第二主线）#

流程闭环回答”Agent 能不能把事做完”，本节回答”凭什么敢让它做”。AIOps Agent 的独特风险：LLM 的输出最终会变成对生产环境的真实变更，而它读入的告警 / 日志 / 工具输出全部是不可信内容。安全设计对齐两套成熟坐标系，每条机制都有出处，不自创：

• 传统运维自动化护栏：StackStorm RBAC / Rundeck ACL / AWS SSM Automation（审批步 + 最小权限执行角色）
• LLM 应用安全：OWASP LLM Top 10（LLM01 提示注入、LLM02 不安全输出处理、LLM06 敏感信息泄露、LLM08 过度代理 Excessive Agency）、NIST AI RMF

总纲一句话：默认拒绝、分级放行、全程留痕、失败即回滚。 一个处置动作要真实落地，必须依次穿过四道防线：

D1 输入侧 —— 不可信内容进模型之前#

D2 决策侧 —— 动作产生之后、执行之前#

D3 执行侧 —— 动作执行之中（核心：资源域建模 + 事务化闭环）#

D4 事后 —— 可审计、可回滚、可追责#

参考：OWASP LLM Top 10、NIST AI RMF、Google SRE Book（渐进放量 / 错误预算）、StackStorm / Rundeck / AWS SSM Automation、Terraform plan、Argo Rollouts。

6. 核心数据模型（沿用草案，落到本项目命名）#

四个对象在层间传递（详细字段见原草案 §核心数据模型，此处仅列骨架，Layer 文档补全）：

• IncidentContext（L2 → L3）：source_alerts、alert_group_reason、root_cause_candidate、impact_score、is_flapping、topology_context、matched_runbooks。
• Investigation（L3 → L4）：hypothesis_tree（含 Evidence）、root_cause（component/failure_mode/evidence_chain）、total_iterations。
• RemediationPlan（L4 → L5）：actions（type/command/target/risk_level/rollback_command）、confidence、autonomy_decision、verification_steps。
• IncidentReport（L5 → L6，最终产出，活文档随状态更新版本）：timeline、root_cause、remediation_result、verification_results、human_feedback、knowledge_extracted。

7. 编排引擎选型（草案未覆盖，本文补充）#

事件响应是 长时运行 + 有等待（verify 30s~5min）+ 有人工审批 + 要重试 的工作流，不应用裸循环写。

建议：先用 LangGraph 把 Incident 状态机做扎实（复用现有 checkpoint 经验），L3~L5 建成一张可中断可续跑的图；不要一步到位上 Temporal。

8. 技术栈映射（草案 Spring 版 → 本项目 Python 版）#

9. 与现有代码的迁移路径#

按 ROI 排序，逐个模块深挖时按此顺序推进：

1. P0 — L2 预处理 + Incident 状态机 ✅ 已实现（app/incidents/state_machine.py + app/preprocessing/）
   • 降噪率埋点已就位（suppressed / dedup_count），数字未实测。
2. P1 — 合并 fast/deep 为分层自适应调查引擎（确定性三级递进） ✅ 已实现（app/investigation/，fast/deep 双图已删除）
   • diagnosis_graphs/(deep) 与 fast 主链路合并成一张 LangGraph 图，图内按 Tier 1→2→3 顺序执行、命中即止、未命中自动递进并继承证据，删除入口的模式分流开关。
   • skills/（剧本）承接 Tier 1 的确定性 Runbook；subagents/ 承接 Tier 3 的假设驱动并行取证（orchestrator-workers）。
   • Tier 2 限定 3 轮定向验证，复用 rag/ 混合检索 + 便宜档小模型适用性复核。
   • Tier 3 实现两阶段推理：假设生成 + 定向取证 ReAct Loop（§3.5）。
3. P1.5 — 安全治理 + 事务化闭环（§5 D3，对应 bullet 4+5）
   • 资源域建模已有基础（写工具已资源化），补齐命令安全闸（D3）、爆炸半径上限、变更冻结窗口；事务化执行补 CAS 漂移检测明确化 + 三级验证门禁统一接口。
4. P2 — Runbook 冷启动 + 学习闭环
   • ✅ 种子 Runbook（data/runbooks/，5 个）+ 自增长流水线（app/runbooks/generator.py → reviewer.py → api/v1/runbooks.py）已实现。
   • ⬜ evidence/ + wiki/ + eval 脚本接 L6，补 Golden Set 回归 —— 未做。
5. 执行层几乎不动
   • services/remediation 的事务化工具接 L5，仅需被状态机驱动。

10. 参考出处汇总（防”拍脑袋”清单）#

11. 参考实现借鉴：itops-agent-platform（可抄清单）#

仓库：https://github.com/qinshihu/itops-agent-platform ↗ · License MPL-2.0（文件级 copyleft）。 抄法约定：对方是 TypeScript，我们是 Python，一律「借鉴设计 + Python 自实现」，不逐行复制。MPL 是文件级 copyleft——把思想重写为自有表达无义务；仅当逐行 port 某个源文件时，才需在该 Python 文件保留 MPL 署名并公开。故本清单全部走「翻写逻辑」，零风险。

11.1 可抄清单（按性价比排序）#

11.2 真正动手翻写的三项（其余只抄思路/清单）#

1. ⬜ commandFilter.ts → Python 处置命令安全闸：未做（P1.5）。最值钱，把自己想不全的绕过手段（子 shell、base64、curl|sh、命令链）都列全了，直接补进 §5 D3（执行侧防线）。

   注：当前 Runbook / 处置提案里根本没有”命令”这个字段（资源域建模，只有 action_type + params），所以命令安全闸目前只对”确需自由命令”的未来通道有意义 —— 那条通道还没开。

2. ✅ playbooks.ts 的 schema + 种子剧本 → 填 Tier 1 Runbook 冷启动空白：已实现（app/runbooks/models.py + data/runbooks/*.yaml）。
3. ✅ verificationGates.ts 的 5 级门禁 → 补齐 L5：核心三级已实现（build_standard_gates），baseline_comparison / impact_assessment 仍是 P2 backlog。

熔断（4）与策略匹配（5）抄思路不抄码（Python 有 tenacity/pybreaker）；花名册（6）只抄那张角色表。

11.3 拖拽可视化编排工作流：借鉴，但限定用途#

对方前端 @xyflow/react 拖拽编辑器 + 后端 workflow/services/WorkflowEngine.ts（command/script/agent/condition/message 节点 + 串并行/条件分支 + Cron）。

判定：有条件借鉴。

• 绝不用于整条诊断链路。我们刚把 fast/deep 收敛成「确定性三级递进」（§3）；把诊断做成人类拖拽的静态 DAG 是开倒车——Tier 3 未知故障要的是假设驱动 ReAct Loop（§3.5），不是预先画死的流程图。整链路可视化编排 = 复杂度回潮。
• 只借鉴到 Tier 1 的确定性 Runbook。Runbook 本质就是「串行/并行/条件 + 人工节点」的确定性流程，天生适合可视化，让 SRE 不写代码也能维护剧本——这正好和 §11.1 的 playbooks.ts 借鉴 + §3.6 Runbook 冷启动合流。
• 落地节奏：先 YAML/代码化 Playbook（MVP，够用、可 diff、可测试）；可视化拖拽编辑器列为产品化 backlog。真要做时，WorkflowEngine.ts 的节点类型与分支执行器是现成后端蓝本，@xyflow/react 是现成前端选型。

12. 后续深挖计划（每个模块单独开文档）#

• layers-v4/P0-incident-statemachine-and-adaptive-investigation.md（P0，含状态机 + L2 预处理 + Tier 1/2/3 调查引擎 + Runbook schema + Hypothesis model + DDL + diff 清单）
• layers-v4/P0-IMPLEMENTATION-REPORT.md（P0 实施报告：做了什么 / 没做什么 / 已知缺口） ← 2026-07-09 落地
• layers-v4/L3-adaptive-ladder-investigation.md（P1，深挖 Tier 3 prompt 模板 + subagent 编排细节）
• layers-v4/L4-decision-autonomy.md
• layers-v4/L5-execution-reconcile.md
• layers-v4/L6-learning-loop.md
• layers-v4/orchestration-engine-choice.md（LangGraph vs Temporal 决策记录）
• layers-v4/security-defense-in-depth.md（§5 展开：RBAC 授权矩阵、命令闸规则集、脱敏 pattern、审计表 DDL，随 P1.5 推进）
• layers-v4/metrics-and-acceptance.md（§12 展开：基线测量方法、告警风暴回放数据集、Golden Incident Set 构建）

本文为总纲。逐模块深挖时，先补齐该模块的：状态迁移/接口契约、数据表 DDL、与现有代码的 diff 清单、以及对应参考项目的具体做法对照。