跳到主要内容

低置信度核实：从调查结论到二次审计

· 阅读需 9 分钟
wbsxhh

基于 sre-agent feature/alert-verify-agent 的 worker 设计与 alert-verify skill 落地整理。承接 SRE Agent 构建思考。

调查大约 5 分钟就能交出 planner_verdict，但低置信度结论仍会原样到达 oncall。证据薄、工具有缺口、推理方向可疑、预算耗尽后的 partial synthesis，都会让第一轮分析「看起来完整、其实站不住」。

alert-verify-agent 不是第二套调查入口。判断规则在 skill，不在框架：worker 只管消费、子进程和校验；「查什么、怎么判」只在 alert-verify。原则是 核实疑问，而不是默认重查一遍。目标是准确的结论，含准确地知道还不知道什么——禁止为凑 0.85 硬抬置信度。

要解决什么问题​

上一篇把排障 Agent 的目标定为自动化 Observe：让每个 oncall 快速拿到资深工程师级别的初步分析。第一轮解决的是有没有分析；落地之后更尖锐的问题是分析能不能信。

L1 演进 已经写下三个缺口：反馈闭环、短/长报告、同类复用。低置信度核实是第四个——调查已经写出结论，人却只能整份重读，才能判断该不该信。

量化锚点：默认 confidence 低于 0.85 才发布核实任务，等于不发。核实 worker 不覆盖原结论、不发通知、不当第二调查入口；回写是非破坏 overlay，人左右对照。

为什么不是「再跑一轮调查」​

方案做法问题
降低阈值直接发布低置信也当结论oncall 被不可靠结论误导
同一套 planner 再跑一遍同样工具、同样预算重复烧 token，补不上第一轮缺口
独立核实 worker（采用）审计证据链 → 针对疑问取证 → 维持 / 修正 / 推翻多一套运行时，但职责清晰
告警 → sre-agent 调查 → planner_verdict
                              │
                    confidence < 0.85
                              │
                              ▼
                    Redis 薄指针（job_id / trace_id）
                              │
                              ▼
                    alert-verify-agent（框架）
                              │
                              ▼
                    alert-verify skill
                      审计 → 拆问 → probe 取证 → 综合
                              │
                              ▼
                    overlay：maintain / revise / overturn

框架与 skill 的分层细节见 核实 Worker；判断规则见 核实 Skill。

Skill 才是核实的大脑​

上一篇写过 领域知识的结构化注入：worker 可以换 CLI，判断不能写进框架。

相对第一轮调查，skill 多出三项增量：读业务代码（第一轮系统性缺口）、采样原始日志（第一轮主走聚合）、更宽松的时间窗与工具轮次。缩小 scope 的做法也落到两个 Agent 上：

角色Skill负责不负责
alert-verifieralert-verify审计 → 拆问 → 调度 → 是否升级 → 合成自己去扫数据源找题
alert-verify-probealert-verify-probe执行一条已定义断言，返回三态整案根因、再规划、写最终产物

主代理决定查什么，probe 只负责跑。

核实方法论：短路径 + 分类驱动​

默认走「围绕疑问点核实」的短路径；独立重查是条件升级，不是默认步骤。

取材 → 审计 → 拆成可证伪疑问 → 定向补查
                              │
                    是否升级独立重查？
                     否 / 是
                              ▼
                    dispositions → VerifyOutcome → 核实产物
Skill 阶段目的人对应的动作
0 物化case + 压缩后的审计简报（不整读 trace）打开上次报告
1 审计结论 → 推理 → 事实倒查，给疑问分类挑站不住的句子
2 定向补查每问三态关闭补日志 / 代码 / 更长窗口
升级（条件）原调查降为线索觉得方向错了才重开
3 综合维持 / 修正 / 推翻改结论或写明还不知道

疑问四类决定策略——这是 skill 最值钱的设计：

类型典型信号策略
证据单薄confidence 约 0.4–0.6、单层信号、窗过窄沿原方向扩窗、补第二层独立证据
工具缺口自认缺数据、handoff 没跟、无原始日志 / 代码直接补缺失维度
方向可疑引用的锚点不存在、事实与结论冲突升级独立重查候选
兜底降级部分完成、硬降级、派发中断从中断点只补没做完的维度

升级只允许两种情况：阶段 1 判定方向可疑，或阶段 2 关键支撑证据被反驳。不要因为「可能还有更好根因」主动升级。

拆问必须一路一问：一个可证伪断言 + 一个对象 + 一个时间窗 + 一条取证路径。反例是把「client 构成 + server QPS + 是否自愈」揉成一问；正例拆成三问——爆发是否发生、server QPS 是否同步下跌、异常后是否自愈。只有 B 的参数依赖 A 时才串行。

Probe 入参必须带齐疑问、路由、时间窗和完整可执行命令，禁止自己探索参数。它只返回确认 / 反驳 / 仍未知，仍未知必须写清缺什么。每问只派一次；失败先回收已有输出，不够就标未知。禁止把原调查轨迹当作新证据。 独立疑问不少于 3 个时同轮并发（单轮最多 6 路），呼应上一篇的并行调查。

取证与收束拆成两轮：前一轮只写疑问处置底稿，后一轮只读底稿合成，不再取证。底稿是跨 resume 的事实边界。

特殊判定与诚实分档​

领域规则写在 skill 里，不写在 worker 配置里。

昨比 / 同比误报：今日绝对量落在基线、对照日异常、ratio 下跌，应修正为误报，解释对照日，而不是声称「今日业务真跌了」。今日绝对量也明显低于基线，才继续谈真实下降。

接入层空查询：空结果不能直接等于服务下线、配置漂移或不可观测。服务名都解析不了，就标未知，不要直接修正。

Confidence 分档接上一篇「信任靠透明度」：两层独立证据一致约 0.7；单层证据约 0.4–0.6；关键缺口就地封顶。只复述旧数字不能抬置信度；该查的外部源没跑完，不虚高到 0.8 以上。

结论三态里，分类相同不等于维持：对象、机制或时间线变了就是修正；方向被推翻才是推翻。一句话结论只答「根因 → 影响 → 建议」，流水账放证据和推理链。

关键工程决策​

1. 框架与领域知识拆开​

Worker 只管消费、工作目录、子进程、校验和落盘。疑问分类、升级条件、误报规则、confidence 分档只在 skill。对应上一篇「工具和领域知识比 prompt 重要」。

2. 薄队列指针，执行时再拉 case​

队列只传定位字段（任务编号、轨迹编号、站点），不传整份结论。避免大包复制，核实侧拿到的是当时完整材料。见 核实 Worker。

3. 产物驱动成功，退出码 0 不算完​

必须交出通过校验的结构化核实产物。没有合格工件就不确认消费。对应上一篇「信任靠透明度」。

4. CLI Worker，而不是框架内嵌 Agent Loop​

从把 Agent 循环嵌在框架里，收到「框架只管子进程」。本地可以用桩命令测通，安全边界更清，provider 可换。目录级细节进框架文档。

5. Overlay 不覆盖​

核实结论与原 planner_verdict 并存。核实失败、回写失败都不阻断原调查。对应「AI 调查 + 建议，人审批执行」。

诚实原则贯穿始终：confidence 只随证据上升；数据不够就标未知，禁止凑阈值。undetermined 是合格产出，不是失败。

落地映射：人工动作 ↔ skill / 框架​

#人工动作系统对应归属
1看结论心里没底confidence 低于阈值 → 发布核实任务框架
2打开原报告，不从头翻完整轨迹预拉 case + 审计简报框架预拉 / skill 阶段 0–1
3把怀疑拆成可证伪的句子一路一问 + 四类归类skill
4指定查哪、带着参数去查主代理派 probe，禁止空跑探索skill
5证据不够就承认不知道仍未知 + 写明缺什么skill
6改结论或维持维持 / 修正 / 推翻skill
7和原结论对照overlay，不自动覆盖框架
8拉群、静默、止损仍在编排外人

已知局限​

框架侧：第一版解析 HTML 轨迹，脆弱；今天只做 overlay，不自动改原结论、不重发通知；校验失败默认可恢复重试，有成本风险。

Skill 侧：聚合查询或指标通路覆盖不齐时只能标未知，不能靠原轨迹凑证据；接入层空查询、昨比误报等规则依赖数据地图质量，模板失效会误判；probe 一问只派一次，漏拆的子问不会被自动补查。

上一篇写过 LLM 在因果推断上系统性不可靠。Skill 补的是证据、工具缺口和可证伪拆问，不解决因果方向。方向可疑时升级重查，仍是假设驱动，不是让模型再自信一次。详见 Anthropic SRE Agent 调研。

演进路径​

Phase 3 已落地：调查 + 置信度
        │
        ▼
Phase 4a：低置信度异步核实 + overlay 对照   ← 本篇
        │
        ▼
Phase 4b：结构化轨迹、按需自动修订、核实后通知
        │
        ▼
Phase 5：与短报告 / 历史复用汇合（上一篇 L1 未完成项）

最后​

  1. 调查解决「有没有分析」，核实解决「分析能不能信」
  2. 判断规则版本化在 skill；框架只保证任务跑完并交出合格工件
  3. 一路一问、probe 不发现题目；默认短路径，重查是升级
  4. Overlay 对照，不覆盖、不代替人决策
  5. 诚实优于凑置信度：标未知是合格产出，不是失败

核心原则没有变：AI 调查 + 建议，人审批执行。 核实让低置信度结论变得可审计，而不是变得更自信。

延伸阅读​

文档主题
核实 Skill状态机、疑问分类、probe 契约、confidence 分档
核实 Worker分层职责、两阶段 CLI、产物校验、overlay
SRE Agent 构建思考上一篇：编排落地与 L1 缺口
Anthropic SRE AgentOODA 能力边界、因果推断局限