最近我看完 incident.io 在 AI SRE、RCA、事故管理方向上的一系列产品动作，最大的感受是：AI RCA 不能只从可观测性数据里长出来，它还必须从事故现场里长出来。
很多监控和可观测性厂商现在都在做 AI RCA。常见做法是把大模型接到告警、日志、指标、链路上，让它解释“为什么出问题”。这个方向当然重要，但如果只做到这里，我觉得还不够。
因为真实事故里，根因从来不是一个孤立答案。
它背后有告警风暴，有最近发布，有 Slack 群里的讨论，有电话会议里的口头判断，有临时降级，有客户沟通，有值班交接，有复盘文档，有遗留 follow-up，还有下次事故能不能少踩一次坑。
incident.io 最值得学习的地方，恰恰在这里。
它不是一家传统可观测性厂商。它不拥有最底层的 metrics、logs、traces 数据。但它抓住了另一个更容易被低估的入口：事故发生之后，工程团队真正工作的地方。
这件事对所有做监控和可观测性的公司，都很有提醒意义。
AI RCA 不应该从“根因按钮”开始
如果我们把 AI RCA 做成一个按钮，用户点击之后生成一段“疑似原因”，Demo 会很好看。
但真实生产环境里，这种体验很容易失效。
原因很简单：事故刚发生时，很多信息是不完整的。告警只是症状，日志只是片段，指标只是投影。系统如果在证据不足的时候急着给唯一答案，只会让一线工程师更不信任它。
incident.io 的思路不是这样。
它把 AI 放进事故处理的完整流程里：告警触发之后创建 incident，在 Slack 里拉起事故频道，AI 可以帮忙总结现状、查询历史事故、整理会议纪要、推荐 follow-up、生成复盘草稿，甚至在 AI SRE 场景里继续关联代码变更、遥测数据和历史处理经验。
这不是“点一下生成根因”。
这是把事故处理过程本身变成 AI 可以理解、可以参与、可以沉淀的工作流。
我认为这是一个很关键的产品分水岭。AI RCA 的价值不在于它能不能说出一句“根因可能是数据库连接池耗尽”，而在于它能不能回答一线响应者真正关心的问题：
- 现在发生了什么？
- 已经确认了什么？
- 还有哪些是假设？
- 影响了谁？
- 最近谁改了什么？
- 以前有没有类似事故？
- 上次是谁处理的？
- 这次下一步该看哪里？
- 事故结束后哪些动作必须补上？
这些问题加在一起，才是 RCA 的真实形态。
incident.io 抓住的是“事故事实”
传统可观测性平台很强，因为它们掌握机器事实。
它们知道哪个服务延迟高了，哪个接口错误率上升了，哪条 trace 变慢了，哪段日志开始异常，哪个节点 CPU 飙升。
但事故处理中还有另一类事实，叫事故事实。
谁声明了 incident？谁是 incident lead？哪些人进了频道？哪条判断被确认？哪个方向被排除了？什么时候决定 rollback？什么时候通知客户？哪些 follow-up 被创建？最后 postmortem 是怎么写的？
这些信息往往不在 metrics、logs、traces 里。
它们在 Slack、Teams、Zoom、Google Meet、工单系统、复盘文档和人的脑子里。
incident.io 的强项就是把这些“事故事实”产品化。它的 @incident 在事故频道里工作，Slack assistant 可以在侧边栏里私下追问，Scribe 可以加入事故会议做转录和总结，Post-mortems 可以基于 timeline、Slack threads、PR、custom fields 生成和审阅，Related incidents 可以用 embeddings 找相似历史事故。
这些能力单独看都不神秘。
但组合起来，它就不只是一个 AI 助手，而是一个围绕事故现场持续收集上下文的系统。
这也是我觉得它对可观测性厂商构成压力的地方。可观测性平台拥有底层遥测数据，但如果用户处理事故的主要入口变成 incident.io，观测平台就可能被降级成数据源。
用户不一定打开你的 dashboard。他可能直接在 Slack 里问：最近有没有可疑部署？相关日志是什么？以前有没有类似问题？谁 on-call？现在应该先回滚还是先扩容？
如果 incident.io 的 AI agent 能调 Datadog、Grafana、Splunk、Honeycomb、GCP Cloud Logging，再把证据和建议发回事故频道，那用户心智里的“排障入口”就已经变了。
AI 要在事故频道里“合群”
我很喜欢 incident.io 对 @incident 的一个产品方向：它不只是要聪明，还要合群。
事故频道是一个很特殊的工作场所。
里面有人在查日志，有人在看 dashboard，有人在和客户沟通，有人在判断是否升级，有人刚加入完全不知道前因后果。AI 如果每次都输出一大段看似专业的分析，反而会制造噪音。
incident.io 在 2026 年初对 @incident 做过一次升级，其中一个重点就是让它更懂当前频道里的上下文：哪些信息是人类已经确认的，哪些只是 AI SRE 的技术发现，什么时候应该短回答，什么时候应该展开，什么时候应该承认不知道，什么时候应该给下一步动作。
这很重要。
企业级 AI 产品最难的地方，不是“回答得像不像专家”，而是“能不能在人的工作流里不添乱”。
很多 AI 功能失败，不是因为模型不够强，而是因为它不懂场景节奏。事故处理中，大家要的是清晰、克制、可验证的信息，而不是一个随时想表现自己的聊天机器人。
好的 AI SRE 应该像一个靠谱的值班同事：
它能帮你整理现场，但不会抢指挥权。
它能提出假设，但会标注证据和不确定性。
它能建议动作，但知道哪些动作必须人来确认。
它能承认不知道，而不是硬编一个合理解释。
这比“全自动修复”听起来没那么刺激，但更接近真实企业客户愿意采用的路径。
组织记忆会成为 AI SRE 的复利
incident.io 的 Related incidents 很值得单独拿出来讲。
它用 embeddings 找和当前事故相似的历史事故。这个功能看起来不如“自动根因分析”酷，但我认为它非常接近真实 SRE 的工作方式。
一个资深工程师为什么排障快？
很多时候不是因为他现场推理能力比别人强十倍，而是因为他见过类似问题。他知道去年这个服务也因为某个配置出过问题，知道上次 rollback 为什么没成功，知道某个看起来很吓人的告警其实经常是下游连锁反应，知道应该先找谁。
这就是组织记忆。
incident.io 在事故中持续沉淀 summary、timeline、follow-up、postmortem、Scribe transcript、related incident link。下一次事故发生时，这些内容又会变成 AI SRE 的上下文。
这条闭环很有价值：
事故中收集证据。
事故后生成复盘。
复盘里沉淀行动项。
行动项推动改进。
历史事故反哺下一次调查。
很多公司做 RCA，最大的问题是每次事故都像第一次发生。
复盘写完就沉到知识库里，follow-up 没人追，历史经验无法在下一次告警时自动浮出来。于是同类问题反复发生，组织经验主要靠老员工记忆维持。
AI SRE 如果不能打破这个循环，就只是更会总结日志。
真正有价值的 AI SRE，应该让每一次事故都变成下一次事故的资产。
“外骨骼”，不是“机器人”
incident.io 早期讲 AI 的时候，用过一个很准确的表达：exoskeletons, not robots。
也就是做外骨骼，不是做机器人。
这个说法我很认同。AI 在事故管理里的第一价值，不应该是立刻替代 SRE，而是增强一线响应者：减少上下文收集成本，减少重复文档工作，减少遗漏，帮人更快进入状态。
所以 incident.io 的 AI 演进很克制。
先做 suggested summaries，让 AI 起草事故摘要，人来确认。
再做 suggested follow-ups，让 AI 从事故讨论里找遗漏行动项。
再做 related incidents，让 AI 推荐相似历史事故，人来接受或 dismiss。
再做 Scribe，把会议里的关键判断变成可检索上下文。
最后才逐步走向 AI SRE、自动调查、建议修复和生成 PR。
这是一条很典型的信任爬坡路线。
对 ToB 产品来说，信任不是靠发布会上说“我们很准”建立的。信任来自长期的小场景：这次摘要写得不错，这次 follow-up 没漏，这次历史事故推荐有用，这次 AI 没有在不知道的时候胡说。
当用户在低风险场景里持续感受到可靠，才可能把更高风险的调查、处置、修复权限逐步交给 AI。
这也是很多 AI RCA 产品容易犯的错：一上来就想做“全自动根因”和“自动修复”，但前面的数据、反馈、权限、审计、评估都没铺好。
产品太急，反而会破坏信任。
对可观测性厂商的真正启发
如果我们是一家监控、可观测性厂商，看 incident.io 不能只看它有哪些 AI 功能。
更应该看它占住了哪几个关键位置。
第一，它占住了事故入口。事故一发生，频道、角色、状态、协作都在它这里组织。
第二，它占住了组织上下文。谁负责什么服务，谁参与过什么事故，哪些 follow-up 没完成，哪些复盘和这次相似。
第三，它占住了 post-incident learning。事故不是 resolved 就结束，而是要变成复盘、行动项和下一次调查的知识。
第四，它正在把自己变成 agent tool layer。Remote MCP server 让 Claude、ChatGPT、Cursor、Codex 或内部 agent 能查询 incident history、alerts、on-call、postmortem、telemetry 和 catalog。
这对可观测性厂商是一个很直接的提醒：只拥有 telemetry 不够。
未来的 AI RCA 需要同时拥有三类上下文：
机器上下文：指标、日志、链路、拓扑、告警、变更。
事故上下文：频道、角色、状态、决策、时间线、复盘、follow-up。
组织上下文：团队、owner、on-call、历史经验、运行手册、权限边界。
传统可观测性厂商天然有第一类，但第二类和第三类往往很薄。incident.io 天然有第二类和第三类，但第一类需要连接外部系统。
所以未来很可能不是谁完全替代谁，而是谁先把这三类上下文打通。
国内厂商应该怎么做
如果把 incident.io 的路线压缩成一句话，我的理解是：
AI RCA 的关键不是更快给结论，而是更好地组织事故现场。
对国内 ToB 可观测性厂商来说，我会优先考虑几件事。
先把告警变成 incident，而不是让 AI 对每条告警单独写小作文。真实生产环境里，用户处理的是一组相关症状背后的事故，不是一条孤立告警。
然后把事故工作台做完整。至少要有负责人、影响范围、时间线、近期变更、相关服务、历史事故、运行手册、状态更新、复盘草稿和 follow-up。
再把 AI 放到协作工具里。国内客户可能用飞书、企业微信、钉钉，也可能用 Slack 或 Teams。事故在哪里协作，AI 就应该在哪里出现。控制台里的 AI 页面不是不重要，但它不能是唯一入口。
接着做相似历史事故和组织记忆。这个能力可能比很多复杂的自动根因推理更早产生价值，因为它非常符合一线工程师的真实需求：以前有没有遇到过？上次怎么处理？找谁最快？
最后再做 investigation agent 和半自动处置。让 AI 自动拉证据、提出假设、排除方向、生成下一步检查计划。等用户信任足够，再在权限、审批、审计和回滚机制下，让它起草命令、生成 PR、建议 rollback 或扩容。
这个顺序不花哨，但更扎实。
最后的判断
incident.io 给我的最大启发是：AI RCA 的终局不是一个更聪明的聊天框，而是一个围绕事故生命周期运转的智能系统。
它要能连接告警和事故，连接机器事实和人类判断，连接当前现场和历史经验，连接根因分析和后续行动。
未来这个赛道的竞争，可能不会简单地发生在“谁的模型更会总结日志”。
真正的竞争会发生在几个更底层的问题上：
- 谁有更完整的事故对象模型？
- 谁能拿到真实协作上下文？
- 谁能把历史事故变成组织记忆？
- 谁能让 AI 在 ChatOps 里自然工作？
- 谁能把 RCA 输出变成行动和复盘闭环？
- 谁能在权限、审计和审批下逐步走向自动化？
New Relic 代表的是 observability-native 的 AI RCA 路线。incident.io 代表的是 incident-native 的 AI RCA 路线。
我越来越觉得，真正好的答案不会是二选一。
可观测性厂商要做 AI RCA，不能只在 dashboard 里加一个大模型入口。我们需要把遥测数据的深度，和事故工作流的现场感结合起来。
谁能同时拥有证据、工作流、组织记忆和行动闭环，谁才有机会把 AI RCA 从 Demo 做成生产力。
参考资料
- incident.io AI SRE
- incident.io AI Platform
- Using @incident
- Slack assistant
- Remote MCP server
- Scribe
- Finding relationships in your data with embeddings
- Building an AI incident responder
- The timeline to fully automated incident response
- incident.io raises $62M to build AI agents that resolve incidents with you
