SRE Agent 设计笔记 03：证据先于工具

发表于 更新于 分类于

状态：大纲

核心论点

设计 oncall triage agent 时，第一步不是接 MCP、不是调 Grafana API，而是定义证据格式。结构化 triage trace 的 schema 决定了产出质量的上限，工具集成只是填充 schema 的手段。手段可以换，格式不能乱。

大纲

1. 叙事 vs 结构

  • 人类 incident case 是叙事体：「凌晨 3 点收到告警，先看了 dashboard……」
  • Agent 需要结构化 trace：Signal → Routing → Decision Trace → Evidence Chain → Verifier Checklist
  • 从叙事到结构的转换不是 fine-tuning 能解决的，是信息编码方式的根本变化

2. Structured Triage Trace Schema

各字段的设计理由：

  • Signal：告警的原始信息，未经 agent 解读
  • Routing Logic：从 signal 到故障域的映射逻辑
  • Decision Trace Table：每步有 Step / Action / Tool Call / Observation / Inference / Confidence
  • Evidence Chain：支撑结论的观测证据序列
  • Blast Radius：影响范围、human gates、rollback path
  • Verifier Checklist：二值门控，全部通过或 escalate

2.1 三层持久化（Plan / Process / Result）

证据链的持久化不只是「结果的证据」，而是三层：

  • Plan persistence（执行前）：agent 开始 MCP 查询之前，先写出打算查什么、需要用户执行什么命令。用户在 agent 动手前就能看到方向是否正确。对应 output 的 Section 0: Investigation Plan。
  • Process persistence（执行中）：每步 MCP 查询实时写入 investigation log，加 Decision 字段（「基于这个结果，下一步做什么」）。不是等结束后回填，session 中断后新 agent 读文件即可继续。对应 Section 6: Investigation Log + Decision + Timestamp。
  • Result persistence（执行后）：最终输出（Slack response + internal notes + evidence + 操作命令）。verify.py 检查完整性和一致性。

动机来自一个观察：「证据」不只是「结论由什么支撑」，还包括「agent 打算做什么」和「agent 实际做了什么」。三层都持久化才构成完整的可审计链条。这也解决了 oncall 场景中一个实际问题：agent 调查到一半 session 中断，断点续传需要 process 层的实时记录。

3. 验证者检查证据链，不检查答案正确性

  • 一个正确答案如果没有支撑证据，在生产系统中不可接受
  • Verifier 的工作：逐项检查链是否完整、每步是否有对应观测证据
  • 这区分了「demo」和「infrastructure」

4. 六个故障域集群

从实际 case 提炼，不是从分类学推导：

  1. Routing（哪一跳断了）
  2. Scheduling（为什么放不上去）
  3. Stateful（下游是否拥塞）
  4. Signal Fidelity（信号是否真实）
  5. Identity/Access（谁缺权限）
  6. Change Management（什么变更了）

原则：no trace → no routing table。routing table 从真实 case 积累，不从理论推导。

5. 三层执行架构

  • Orchestrator：signal → 故障签名匹配 → 路由到集群策略
  • Worker：bounded MCP call，无状态执行，有 input/output contract
  • Verifier：审计证据链完整性（必须独立于 Worker）
  • Human Gate：设计原语，不是补丁

6. 为什么工具集成放在最后

  • 先有 schema 再接工具，确保工具产出的数据有地方放、有格式约束
  • MCP 集成、VictoriaMetrics 查询、Loki 日志读取都是填充手段
  • 如果先接工具再想格式，容易被工具返回的数据结构牵着走

涵盖的 Topic

  • Topic 5: 证据先于工具
  • Topic 10: 六个故障域 + routing table 从 case 积累

源文件引用

  • contexts/thought_review/ai_triage_control_plane_2026-03-30.md — 六个故障域集群定义，结构化 triage trace schema，三层架构，Verifier 设计
  • contexts/thought_review/agentic_control_theory_primitives_20260413.md — 证据链作为 Loop 的验证基础
  • contexts/thought_review/agent_sre_production_systems_synthesis_20260330.md — 验证者检查证据链完整性，不检查答案正确性
  • contexts/thought_review/eval_as_measurement_system_20260331.md — cost inversion 作为「证据先于工具」的经济学基础