做 AI 事件响应之前，凌晨三点被 page 的人是我。我在 Roblox 当数据库 SRE，支撑一亿多日活用户，太多个晚上一边定位生产问题，一边在 Slack 里回各方的问题。后来我开始利用晚上和周末做一个自主 AI SRE，最后通过 YC 创业全职做这件事。但做了几个月之后我发现，全自主是个错误的方向。真正难的是搞清楚 AI 到底在哪儿能用，在哪儿不行。
AI SRE 市场估值超过 320 亿美元。Gartner 预测到 2029 年 85% 的企业会用 AI SRE 工具，现在不到 5%。有一家 AI SRE 创业公司 18 个月不到就到了独角兽。YC 也投了好几家。钱是真的。但行业承诺的和生产里真正发生的，差得远。
日志读得飞快，推理一塌糊涂
Alex Palcuie 在 Anthropic 做 AI 可靠性工程，工作就是让 Claude 别挂。他之前在 Google Cloud Platform 做事件响应。他在这个月的 QCon London 上把事件响应分成四步：观察、定向、决策、行动。AI 在观察上”特别强”。“它读日志的速度就是 I/O 的速度，不会烦。“这方面没人能比。
他讲了一个 AI 最牛的故事。除夕夜 Claude Opus 4.5 开始返回 500。Palcuie 打开 Claude Code，几秒钟 AI 就写了 SQL、找到出问题的 class、追踪到 200 个可疑账号——全在同一时间发 22 张图。AI 没停，继续挖，发现 4000 个同时创建的休眠账号，然后说：“别看 500 了，这是欺诈。” Palcuie 说没有 AI 他会当 bug 提了，不会叫反欺诈的人。AI 的优势不是比人聪明，是不嫌烦，愿意一直追。
然后他讲了另一个故事。Claude 的推理靠 KV cache，用他的话说”又敏感又脆弱”。cache 一挂，系统重算，监控上就是请求量飙升。每次 Palcuie 问 Claude 怎么回事，它都给同一个错误答案：“请求量上升了，容量问题，加机器。“实际原因每次都是 cache 挂了。Claude 看到尖峰就匹配到历史上的容量事件，不会退一步想想这个尖峰是原因还是症状。
“跟团队新人一样，“Palcuie 说，“他们看到请求多了就想’哦容量问题’，其实是 cache 没了。”
这不是个例。一项针对 ChatGPT、Claude 和 Gemini 的研究发现分析生产事件时，技术细节的幻觉率 23%。四个事实里差不多错一个。写代码的话可以改，但线上事件不行——Splunk 和牛津经济研究院的数据显示，Global 2000 公司每分钟损失 $9,000。而且幻觉在多步 agent 里会滚雪球：上游一个时间戳错了，下游每一步推理都跟着错，最后得出一个看着很自信但完全不对的结论。
Palcuie 还提到事后分析：“它能写出 80 分的报告，好看好读，很有说服力，但根因分析很烂。” 他说：“Claude 会说’就是这个原因’，但我们都知道从来不是一个原因。不是那次发布，不是那次代码改动。是公司里所有让事故能发生的流程。“Claude 不了解你系统的历史，尤其是十年的老系统。
为什么 AI SRE 比 AI 写代码难得多
这有个结构性原因。AI 写代码的工具有几十亿行公开代码可以训练：GitHub、Stack Overflow、文档。初级开发者问，高级开发者答，答案是公开的，可以验证。
AI SRE 几乎没有这些。事件报告、runbook、事后分析全是私有的，锁在各家公司里，格式也不统一。公共领域里根本没有这些数据。通用 LLM 就没在 SRE 工作上训练过，因为训练数据不存在。
| AI 写代码 | AI SRE | |
|---|---|---|
| 训练数据 | 几十亿行公开代码 | 基本全是私有的（事件报告、runbook、事后分析） |
| 知识循环 | 公开问答、开源、文档 | 锁在个人经验里，没有公开验证 |
| 容错 | 改了再试、可以回滚 | 直接影响生产 |
| 问题格式 | 标准化（代码进代码出） | 碎片化（日志、指标、trace、架构、历史） |
在尝试缩小这个差距的公司里，进展都还很早。Meta 用 5000 个内部调查微调了 Llama 2，top 5 建议里 42% 命中根因。来自 Gradient、UC Santa Cruz、Georgia Tech 和 UCL 的强化学习方法在失败的诊断轨迹上训练了 14B 模型，在 AIOpsLab benchmark 上追平了 Claude Sonnet 4.5。微软测了 10 万个真实云事件，用 in-context learning 的 GPT-4 比微调过的 GPT-3 高 24.8%，但还是需要人来验证结果。Zalando 试着用 LLM 挖事后分析，发现人工审核仍然是瓶颈。
方向对了，但还很早。
AI 需要人的时候，人已经忘了怎么干
还有个不太容易注意到的问题。AI 接手了越来越多的日常排查，工程师自己练手的机会就越来越少。Palcuie 管这叫”伤疤组织”——被烧过才能长出来的直觉。“SRE 需要被烧过，“他说，“才有伤疤组织。“如果 AI 处理了大部分事件，这种直觉就会退化。AI 终归会挂——到那时候本该接手的工程师已经好几个月没亲手干过了。
这不是新问题。1983 年认知心理学家 Lisanne Bainbridge 写了《自动化的讽刺》，现在被引用超过 1800 次。她发现：你把大部分工作自动化了，人在剩下那些任务上的练习就变少了——而那些恰好是自动化挂掉时需要人来做的任务。两个讽刺：第一，设计者觉得人不靠谱才搞自动化，结果设计者自己的错误才是故障的主因。第二，自动化做了简单的，难的留给人，但人因为不练就越来越不会做难的。
航空业验证了她的观点。法航 447 航班 2009 年坠毁，228 人遇难。A330 高度自动化。皮托管结冰、自动驾驶断开后，飞行员需要在夜间湍流中手飞。他们飞不了。一项对 30 名飞行员的研究发现全部低于认证标准。43% 说转到自动化座舱后手动技能下降了。FAA 和 EASA 现在强制定期手动飞行训练，不是建议，是强制。
Google 很早就明白了。他们的 DiRT 项目从 2006 年开始运行，故意往生产系统里注入故障，让工程师在没有紧急情况的时候练习事件响应。Netflix 的 Chaos Monkey 同理。跟航空业一个逻辑：等自动化挂了才让团队练，已经晚了。
Palcuie 担心软件行业在走同一条路。他把这比作开发者担心 AI 编程工具在退化自己的技能。“以前 on-call 你对系统了如指掌，现在多了个大语言模型——有时候它比你先找到问题，有时候它像个过度自信的新人。”
他问自己是不是在把自己自动化掉：“说 Claude 能搞定一切那是自欺欺人。我的团队在，我们还在招人。这说明——不，它还不行。“然后他说：“如果以后真行了，我们也不会意外。今天的模型是它们有史以来最差的。“但他的结论是：继续培养可靠性工程师，你还是需要他们。
系统膨胀的速度超过了人能理解的速度
AI 编程工具在以前所未有的速度产出代码。很多代码没人完整读过就上线了。系统更复杂了，但运维的人对新加的东西没有对应的理解。出了问题，工程师要调试的是自己没写过、也不认识的代码。
Observability Pulse 调查显示 MTTR 从 2021 年起年年恶化：
- 2021：47% 的组织恢复超过一小时
- 2022：64%
- 2023：74%
- 2024：82%
这发生在可观测性和 AIOps 工具投资最多的时期。工具越多，恢复越慢。2024 年只有 18% 能在一小时内恢复。11% 需要超过一天。2% 需要好几周。
同时根据 Uptime Institute 2025 的分析，故障总数其实在减少。但出的那些故障更严重也更贵。2024 年 CrowdStrike 事件搞崩了全球 850 万台 Windows，Fortune 500 损失超过 50 亿美元。医疗 19.4 亿，银行 11.5 亿，5000 多航班取消。起因是一个跳过了质量检查的配置更新。
AI 让系统长大的速度，远超它让故障变便宜的速度。
管理层觉得 AI 有用，干活的人不这么看
Catchpoint SRE 报告用同一套方法连续追踪 toil 追踪了八年。2020 到 2024 年 toil 稳步下降。2025 年开始反弹。2026 年中位数从 20% 跳到了 34%。
问 AI 是不是减少了 toil：49% 说是，35% 说没变，16% 说反而多了。报告的原话：“AI 不会自动消除 toil，它只是换了个地方。“新增的 toil：维护 AI 工具、审核 AI 的建议、调 prompt、检查 AI 做得对不对、跟别人解释 AI 做了什么。
管理层和一线的认知差距最值得注意。管理层看到的是 AI 的产出：更干净的报告、更快的摘要、更短的会议，所以觉得 toil 少了。一线工程师面对的是 AI 的过程：验证结论、抓错误、AI 基于错误数据操作后的善后。自动化把工程师的活从”做事”变成了”检查事”。两边说的都对，他们看的是不同的部分。
只有 13% 的团队对自己监控 AI 可靠性的能力有信心。大多数团队用了 AI 但看不到 AI 组件在生产里的实际表现。看不到 AI 为什么这么决定，时间就从执行变成了验证。报告说：“从外面看像是 toil 没减少。从里面看更像是小心。”
Reddit 上工程师的说法也一样。一个 DevOps 的人发帖：“我们不停加 AIOps 和 Autonomous 工具想减 toil，但感觉 toil 只是换了个地方。我们不修代码了，改成调试 AI agent 为什么觉得 503 是个’自愈’机会然后重启了错的服务。“高赞回复：“我们不再直接调试 pipeline 和基础设施了，改成调试那个本来应该替我们调试的自动化工具。”
开发者信任度数据也类似：84% 的开发者在用或打算用 AI 编程工具，但信任度从 2024 年的 40% 跌到 29%。只有 3% 高度信任。一项随机对照试验发现用 AI 的开发者实际上比不用的慢 19%，但他们自己觉得快了 20%。这个感知偏差很关键——你觉得工具在帮你的时候，就不容易发现它其实没有。
AI agent 搞崩生产环境
信任问题不是纸上谈兵。有生产权限的 AI agent 已经造成了真实损失。
2025 年 12 月，Amazon 的 Kiro AI agent 自己删了整个 AWS 生产环境，停机 13 小时。它有 operator 级权限，没有强制 review。让它修一个 AWS Cost Explorer 的小问题，它选择把整个环境删了重建。Amazon Q Developer 不久后也出了几乎一样的事。
AI agent 事故汇编里的其他案例：LangChain agent 陷入无限对话循环 11 天，烧了 47000 美元 token 费。一个 agent 周末搞出了 230 万次非预期 API 调用。Claude Code 误读 Terraform state 跑了 terraform destroy，删了 2.5 年生产数据。Replit AI agent 在代码冻结期间删了生产数据库，毁了 1200 多条高管数据，然后伪造 4000 条假数据补上。
所有这些的共同问题：自主操作没有执行时的治理、审批和审计。没有权限边界，没有对危险操作的强制审核，没有预算上限。
数据也证实了这点。88% 的组织过去一年报告了 AI agent 安全事件。64% 的十亿美元级公司因 AI 故障损失超过 100 万美元。
什么是真正有用的
Palcuie 说 AI 当不了完整的 SRE 替代品，但他自己还是会在打开监控面板之前先问 Claude——从 2026 年 1 月开始就这样。关键是他用 AI 做什么：观察，不是诊断。读日志、关联信号、抓住凌晨三点人会漏掉的模式。判断还是工程师做。
2025 年 Stanford-CMU 的研究让 48 个人用四个 AI agent 框架做 16 个真实任务。人主导 + AI 辅助比全自主 agent 好 68.7%。全自动快 88%、省 90%，但成功率低 32-50%。算上验证和调试的时间，全自动实际上还慢了 17.7%。医疗领域的一项针对 70 个医生的随机试验发现 AI 当第二意见时，诊断准确率从 75% 提到 82-85%，警报负担降了 80%。
我们行业最好的例子是 Meta 的 DrP 平台。每天在 300 个团队里跑 5 万次自动根因分析，MTTR 降了 20-80%。但 DrP 不是自主的。工程师用 SDK 把自己的排查逻辑编码进去，机器大规模执行。知识来自人。这个系统在生产里跑了五年了。这才是有效的模式：人编码判断，机器执行规模。
Google 类似。他们的 SRE 用 Gemini CLI 做事件响应，但有分层的安全管控。Gemini 分类症状、选缓解预案，但人在执行前验证。“一个环境下安全的操作在另一个环境下可能不安全。“他们关注 MTTM（平均缓解时间）而不是完整的 MTTR。而且他们形成了闭环：每次事件后的事后分析变成 Gemini 的训练数据。这个细节值得注意——这是少有的 AI SRE 系统能从自己的生产经验中变聪明的真实案例。
Traversal 借鉴自动驾驶的分级，提了个有用的框架：
- L0：全手动。工程师在 war room 盯仪表盘。
- L1：自动化已知故障。规则 + 静态 runbook。
- L2：LLM 做摘要、上下文检索、日志解读。人决定怎么回事、怎么办。
- L3：Agent 在单一领域独立排查（一个 K8s 集群、一个可观测性平台、一类事件）。
- L4：跨整个生产环境的自主排查，包括多跳、跨边界事件。
- L5：自动驾驶式生产运维。系统自己检测、诊断、修、验证、预防。
大多数自建 AI SRE 做到 L2 就到头了。有的在窄领域到 L3。没人到 L4 或 L5。Traversal 还算了笔成本账：每个应用一个 agent，每天 100 万+告警，每次排查大概 5 美元，一天 500 万美元 API 费用。账算不过来。
还有一个经常被忽略的角度。W. Ross Ashby 的必要多样性定律说控制者的复杂度得至少跟被控系统一样高。AI SRE 行业都在增强控制者——做更聪明的工具。但 Ashby 定律还有第二招：降低系统本身的复杂度。把微服务整合回更简单的架构，MTTR 和云成本都能大幅下降。有时候最有效的可靠性投资不是更好的 AI，是更简单的系统。
现在在哪儿
我做 AI SRE 是因为觉得自动化能解决 on-call 的问题。做了一年之后想法变了：AI 在运维里的价值不是替代工程师的判断，是让工程师把判断花在对的问题上——因果推理、跟系统相关的上下文、“这事从来没发生过”的时刻——同时 AI 几秒钟就把日志和指标过了一遍。
模型会越来越好。但更难的是组织层面的问题：团队怎么学会跟 AI 配合，不是只是部署它。团队得知道 AI 强在哪（观察、关联、不知疲倦地匹配模式），弱在哪（因果、系统历史、新型故障）。还得在不用 AI 的时候继续练。Google 跑 DiRT，航空业强制手飞训练，道理一样：不能只在出事的时候才练。
Bainbridge 1983 年就预言了：自动化会造出一种同时更被需要、却更没准备好的操作者。四十年后我们在软件运维里走的就是这条路。做对的公司会像航空业对待自动驾驶一样对待 AI：一个要求你练得更多而不是更少的工具。做错的会学到法航的教训——自动化挂的时候，挂在最糟的时刻，本来该被它帮的人还没准备好。
如果你在做或者买 AI SRE 工具——或者任何 AI agent——我希望这篇文章能让你从人机交互的角度想想这件事。这里面有真实的故事和数据，希望能帮你避开别人已经踩过的坑。