基于 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 建设方案讨论、L1 演进问题与编排流程分析整理。

要解决什么问题​

告警响应的现状：oncall 收到告警后，需要登录多个系统拉取上下文（监控指标、日志、最近发布、配置变更、服务依赖），判断影响范围，定位根因，执行修复。这个过程依赖工程师的经验和对系统的熟悉程度，新人和老手之间的效率差距可以是数倍。

排障 Agent 的目标是把 Observe 阶段——收集上下文、关联信号、生成初步假设——自动化，让每个 oncall 工程师都能快速获得资深工程师级别的初步分析。

行业成功落地的案例都遵循「AI 调查 + 建议，人审批执行」的模式。

整理自日常 Ubuntu 22.04 服务器初始化笔记。

自从我折腾了一台e5洋垃圾服务器，往里面装了pve虚拟机系统，当我每次新增ubuntu虚拟机时——我都会做几件事：配静态 IP、加固 SSH、装 Docker、按需做系统瘦身。这些步骤不复杂，但 cloud-init 会在两处让人踩坑：SSH「写了却不生效」、静态 IP「重启又变 DHCP」等问题就是我踩到的坑。