几乎每起事故的前 15 分钟都是机械式的。拉取每个人都会拉取的那四张图表。对比事故开始时的部署差异。检查今天翻转了哪些功能标志（feature flags）。在运行手册（runbook）维基中搜索错误字符串。这些都不需要判断力——它只需要你保持清醒，而在凌晨 3 点，你的值班工程师正把这些时间花在找笔记本电脑、加入语音会议（bridge），以及回忆哪个仪表盘才是真正有用的那个。在人类解锁屏幕之前，智能体（agent）就可以完成这一切。
然而在大多数组织中，关于 AI 在事故响应中应用的讨论往往止于一个段子：“我们听说有个团队的自动修复脚本搞垮了生产环境。”于是，整个想法就被禁绝了——不是限制范围，不是分阶段实施，而是直接禁绝。这是一个范畴错误。那些恐怖故事讲的是自主权阶梯的最顶层，而团队的反应却是拒绝踏上最底层。在最底层，智能体没有任何写入权限，它能做的最坏的事情也就是在 Slack 里发了一段错误的话。
解决方法不是更多的勇气。而是一个拥有明确阶梯、明确晋升证据要求，以及——这是每个人都会忽略的部分——明确降级标准的阶梯，从而防止一次糟糕的经历演变成永久性的禁令。
无人定价的不对称：分类是免费的，修复则不然
事故处理工作分为两种行动，它们的风险状况迥异，而将它们混为一谈正是在阶梯开始之前就将其扼杀的原因。
只读调查 ——将延迟激增与最近的提交相关联、遍历服务依赖图、拉取最后一次部署的差异——其失败成本是以注意力来衡量的。如果智能体的总结是错误的，工程师读到一段误导性的文字后将其丢弃即可。现代事故处理工具已经以这种方式工作：调查智能体在警报触发的那一刻就会激活，并在团队读完通知之前运行并行假设检查，引用每个假设背后的具体日志和代码更改。
写入操作 ——重启服务、回滚部署、扩展集群——其失败成本是以爆炸半径来衡量的。在部分故障期间一次错误的重启可能会将其演变为全面故障；Google 的 SRE 手册专门用了一整章来讨论出发点良好的缓解流量和重启是如何放大级联故障的。2017 年的 S3 停机事故始于一条过于宽泛的删除命令；Amazon 汲取的教训不是“永远不要自动化”，而是“限制单个命令所能做的范围”。
这两个类别值得拥有不同的信任阈值、不同的推广速度和不同的失败预算。阶梯使这一切变得明确。
四个阶梯
第 1 阶梯 — 叙述者。 智能体拥有对可观测性、部署历史、功能标志和运行手册库的只读访问权限。当告警触发时，它会向事故频道发布一份分类摘要：最近发生了什么变化、哪些图表看起来异常、哪些运行手册章节匹配、它认为的主要假设是什么——并附带证据链接。人类执行所有操作。
智能体无法接触生产环境，因此这一阶梯的唯一风险是叙述错误。这种风险带来了其自身的纪律：每一项主张都必须带有工程师可以在 30 秒内验证的引用。没有证据链接的假设只是带着置信度分数的噪声。
第 2 阶梯 — 建议者。 智能体草拟具体的行动——“回滚部署 4f2a，它与错误开始时间相关”——作为事故频道中的审批卡。人类点击批准；智能体执行并报告结果。判断仍归人类；输入交由机器。这一阶梯比看起来更重要：它将智能体的建议转化为带标签的数据集。每一次批准和拒绝都是一个训练信号，更重要的是，是你将用来争取（或反对）晋升的审计轨迹。
第 3 阶梯 — 受控执行者。 对于一小部分列举出来的运行手册——清除无状态节点上的满磁盘、回收卡住的工作池、切换到热备节点——智能体无需等待批准即可执行，但需在严格限制内：速率限制、爆炸半径上限（“一次不超过一个节点”）、预检状态检查，以及带有指标未恢复则自动升级的后置验证。运行手册列表是一个白名单，像代码一样经过审查，其中的每一个条目都是通过在第 2 阶梯证明其过往记录而进入的。
第 4 阶梯 — 受限自动修复者。 智能体端到端地处理一类事故——从检测到验证恢复——且仅在置信度下降或达到其边界时才呼叫人类。对于大多数事故类别，大多数团队都不应该处于这个阶段，这没关系。
这一阶梯的存在是为了让那些真正机械化的类别（证书轮转失败、已知的故障金丝雀回滚）能够完全脱离人类的关注——而不是为了让智能体在新型停机期间即兴发挥。人类判断仍然是应对无人见过的故障的工具；第 4 阶梯是为每个人都见过一百次的故障准备的。
晋升需要证据，而非感觉 只有当晋升变得枯燥且官僚化时，这种阶梯机制才有效。每次晋升都应由三种证据把关。
记录中的准确率。 在第 1 阶，跟踪 Agent 的领先假设与 Postmortem 根因的匹配频率。这个数字会让你清醒：最近一项针对 SRE Agent 的基准测试发现，基准误报率高达 67% —— Agent 会言之凿凿地描述根本没有发生的事件，其中一个案例甚至归咎于 74 分钟前的一次 Pod 重启。同一项研究表明，将 Agent 与因果拓扑数据进行 Grounding 可以使该比率大幅下降。重点不是 Agent 没救了，而是你在允许 Agent 起草行动方案之前，应该了解你的 具体数据。大规模下的提案质量。 在第 2 阶，衡量批准率，以及更说明问题的 —— 撤销率 ：即那些不得不撤销的已批准行动。如果一个 Agent 的回滚提案在 50 次事件中被批准了 90%，那么它在“回滚”这一特定领域就赢得了第 3 阶的地位。但这并不意味着它在扩容或故障转移方面也达到了这一水平。晋升是针对每个 Runbook 的，而不是针对每个 Agent。受限故障行为。 在进入第 3 阶之前，验证 Agent 在情况失控时是否遵守其边界：注入一个无法成功的 Runbook，并确认 Agent 会选择升级上报，而不是盲目重试。一个能处理成功的 Agent 并不出奇；一个能干净利落地交还控制权的 Agent 才值得晋升。 请注意这里缺少了什么：模型基准测试、供应商演示和热情。证据来源于你的事件、你的批准日志和你的 Postmortem。维持一个季度的第 1 阶运行除了一个 Slack 频道的分散注意力外，不会让你付出任何代价，但它能产生后续所有论证赖以生存的数据集。
“犯错一次”是降级，而非废除 这是大多数阶梯机制崩溃的地方。Agent 误诊了一次事件，或者第 3 阶的 Runbook 执行失误，Postmortem 的行动项就变成了“禁用 AI”。团队回到了第 0 阶并停滞不前，因为重新讨论禁令所需的政治资本超出了任何人的承受能力。
对比一下我们对待人类的方式。当一名值班工程师在凌晨 3 点重启了错误的业务时，我们不会撤销整个团队的生产权限。我们会写一份 Postmortem，修复 Runbook 中的歧义，或许再增加一个确认步骤 —— 然后该工程师下周照常值班。无责 Postmortem 文化之所以存在，正是因为惩罚个人错误会破坏防止系统性错误的各种信息流。出于同样的利己原因，Agent 也值得拥有同样的协议：一个在每次失败后都废除自动化的组织，永远无法积累安全使用自动化所需的运营证据，只能永远默默地缴纳“琐事税（Toil Tax）”。行业层面的数据显示，这种税收数额巨大 —— 在事件响应中广泛使用自动化的组织，解决漏洞的速度比没有自动化的组织快得多，成本也低得多。
降级应该像晋升一样有明确的范围：针对失败的特定能力，向下降低一阶。第 1 阶的错误假设意味着需要修复 Agent 的数据访问或 Grounding，而不是让它闭嘴。第 3 阶的错误执行意味着该 Runbook 降至第 2 阶 —— 再次受到批准限制 —— 直到它重新赢得信誉记录，而其他列入白名单的 Runbook 则继续运行。Postmortem 的问题从“Agent 是否该存在”转变为“缺失了哪个边界”，这与你询问任何其他生产系统的问题是一样的。
在第一次失败之前 写下降级标准。一份一页纸的政策 —— “撤销一次第 3 阶行动会导致该 Runbook 降级；十次事件中出现两次误诊将触发 Grounding 审查” —— 能将必然发生的第一次错误从一场大辩论转变为一个标准程序。
从今晚开始，真的 枯燥的真相是，第 1 阶在当前季度就可以利用现有工具部署，它直接攻击值班中最丑陋的部分：从响应到定位之间的“冷启动时间”。平均响应时间（MTTA）是一个已解决的问题 —— 寻呼机很管用。未被衡量的差距是“上下文获取时间（Time-to-Context）”，而这纯粹是琐事：每一次都是同样的四张图表、同样的部署差异、同样的 Wiki 搜索。
所以，让 Agent 先回答寻呼。给它只读凭据，将其接入告警流，并让它在人类加入之前发布其叙述。记录一个季度的得分：假设准确率、证据质量、节省的上下文获取时间。然后让数据 —— 而非恐怖故事，也不是炒作 —— 来决定它是否晋升。
在事件响应中能从 AI 获得持久价值的团队，不会是那些对自主性最勇敢的团队。相反，他们是那些对阶梯机制最守纪律的团队：廉价阶梯先行、凭证据晋升、按范围降级，以及一份能熬过第一个糟糕夜晚的书面政策。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
