让 Agent 先接警：AI 故障响应的信任阶梯

几乎每起事故的前 15 分钟都是机械式的。拉取每个人都会拉取的那四张图表。对比事故开始时的部署差异。检查今天翻转了哪些功能标志（feature flags）。在运行手册（runbook）维基中搜索错误字符串。这些都不需要判断力——它只需要你保持清醒，而在凌晨 3 点，你的值班工程师正把这些时间花在找笔记本电脑、加入语音会议（bridge），以及回忆哪个仪表盘才是真正有用的那个。在人类解锁屏幕之前，智能体（agent）就可以完成这一切。

然而在大多数组织中，关于 AI 在事故响应中应用的讨论往往止于一个段子：“我们听说有个团队的自动修复脚本搞垮了生产环境。”于是，整个想法就被禁绝了——不是限制范围，不是分阶段实施，而是直接禁绝。这是一个范畴错误。那些恐怖故事讲的是自主权阶梯的最顶层，而团队的反应却是拒绝踏上最底层。在最底层，智能体没有任何写入权限，它能做的最坏的事情也就是在 Slack 里发了一段错误的话。

解决方法不是更多的勇气。而是一个拥有明确阶梯、明确晋升证据要求，以及——这是每个人都会忽略的部分——明确降级标准的阶梯，从而防止一次糟糕的经历演变成永久性的禁令。

无人定价的不对称：分类是免费的，修复则不然

事故处理工作分为两种行动，它们的风险状况迥异，而将它们混为一谈正是在阶梯开始之前就将其扼杀的原因。

只读调查——将延迟激增与最近的提交相关联、遍历服务依赖图、拉取最后一次部署的差异——其失败成本是以注意力来衡量的。如果智能体的总结是错误的，工程师读到一段误导性的文字后将其丢弃即可。现代事故处理工具已经以这种方式工作：调查智能体在警报触发的那一刻就会激活，并在团队读完通知之前运行并行假设检查，引用每个假设背后的具体日志和代码更改。

写入操作——重启服务、回滚部署、扩展集群——其失败成本是以爆炸半径来衡量的。在部分故障期间一次错误的重启可能会将其演变为全面故障；Google 的 SRE 手册专门用了一整章来讨论出发点良好的缓解流量和重启是如何放大级联故障的。2017 年的 S3 停机事故始于一条过于宽泛的删除命令；Amazon 汲取的教训不是“永远不要自动化”，而是“限制单个命令所能做的范围”。

这两个类别值得拥有不同的信任阈值、不同的推广速度和不同的失败预算。阶梯使这一切变得明确。

四个阶梯

第 1 阶梯 — 叙述者。 智能体拥有对可观测性、部署历史、功能标志和运行手册库的只读访问权限。当告警触发时，它会向事故频道发布一份分类摘要：最近发生了什么变化、哪些图表看起来异常、哪些运行手册章节匹配、它认为的主要假设是什么——并附带证据链接。人类执行所有操作。

智能体无法接触生产环境，因此这一阶梯的唯一风险是叙述错误。这种风险带来了其自身的纪律：每一项主张都必须带有工程师可以在 30 秒内验证的引用。没有证据链接的假设只是带着置信度分数的噪声。

第 2 阶梯 — 建议者。 智能体草拟具体的行动——“回滚部署 4f2a，它与错误开始时间相关”——作为事故频道中的审批卡。人类点击批准；智能体执行并报告结果。判断仍归人类；输入交由机器。这一阶梯比看起来更重要：它将智能体的建议转化为带标签的数据集。每一次批准和拒绝都是一个训练信号，更重要的是，是你将用来争取（或反对）晋升的审计轨迹。

第 3 阶梯 — 受控执行者。 对于一小部分列举出来的运行手册——清除无状态节点上的满磁盘、回收卡住的工作池、切换到热备节点——智能体无需等待批准即可执行，但需在严格限制内：速率限制、爆炸半径上限（“一次不超过一个节点”）、预检状态检查，以及带有指标未恢复则自动升级的后置验证。运行手册列表是一个白名单，像代码一样经过审查，其中的每一个条目都是通过在第 2 阶梯证明其过往记录而进入的。

第 4 阶梯 — 受限自动修复者。 智能体端到端地处理一类事故——从检测到验证恢复——且仅在置信度下降或达到其边界时才呼叫人类。对于大多数事故类别，大多数团队都不应该处于这个阶段，这没关系。

加载中…