核心要点
- New Relic 的启发是：AI RCA 不应该是“点击生成根因”的按钮，而应该是从告警进入系统到复盘沉淀的一条故障处理流水线。
- RCA 的可信度不主要来自 LLM，而来自实体模型、拓扑关系、告警事件、遥测数据、变更记录、历史事故、runbook、权限和工作流。
- New Relic 先把 alert event 聚合成 issue，再在 issue 页面提供影响分析、历史相似问题、潜在原因和检查项，这比直接解释单条告警更接近真实排障。
- 算法、拓扑、因果模型和 path-based ranking 适合负责候选根因筛选，LLM 更适合做解释、摘要、建议和协作编排。
- 对国内厂商来说，AI RCA 的产品化顺序应该是先闭环，再智能：先做好 issue、上下文包、证据链和工作流，再逐步引入 Agent。
最近我系统看了一圈 New Relic 在 AI SRE、AIOps、RCA 方向上的产品动作，越来越强烈地感受到一件事：AI RCA 这件事，绝不能被做成一个“点击生成根因”的按钮。
如果一个可观测性厂商只是把大模型接到告警详情页，然后让它基于几段日志和几条指标生成一段“可能原因”，这个功能 Demo 一定好看，但大概率不会在真实生产环境里形成长期信任。
真正有价值的 AI RCA，不是“会解释告警”，而是要把故障处理的整条链路重新产品化。
New Relic 现在走的路线很清楚：先用统一遥测数据和实体关系做告警降噪、事件关联，再在 Issue 页面给一线响应者提供影响面、历史相似问题、检查项和潜在原因，最后用 SRE Agent、MCP、ServiceNow、Slack、Zoom、Workflow Automation 这些入口，把诊断和处置建议带进工程师真正工作的地方。
这不是一个聊天机器人能解决的问题。
这是一次可观测性产品从“看数据”到“接管故障处理流程”的升级。
一句话结论
New Relic 的路线说明，AI RCA 的产品单位不应该是“单条告警解释”，而应该是“围绕一个 issue 的完整调查和处置流程”。这个流程需要事件关联、上下文收集、候选根因排序、影响分析、相似历史问题、运行手册、自动化动作和复盘沉淀一起工作。
最重要的判断：RCA 的可信度不来自 LLM
很多人现在谈 AI RCA，第一反应还是模型能力。
模型够不够强？上下文窗口够不够大？能不能读 10 万行日志？能不能把 trace、metrics、logs 都丢进去？
这些当然重要，但它们不是核心。
RCA 的可信度，首先来自平台有没有足够完整、结构化、实时、可关联的上下文。LLM 更像解释器和编排器，真正决定效果的是底下那层东西：
- 实体模型
- 服务拓扑
- 告警事件
- 指标、日志、trace
- 部署和配置变更
- 历史事故和复盘
- 运行手册
- 权限和审批
- 自动化工作流
没有这些东西，LLM 再强，也只能基于残缺现场讲一个看起来合理的故事。
这也是我看 New Relic 最有启发的地方。它并没有把 AI RCA 狭义地理解成“让 AI 猜根因”，而是把 AI 放在自己的 observability platform 上，用已有的数据模型、事件模型和工作流去约束 AI。
换句话说，New Relic 真正在卖的不是一个 AI 功能，而是一个让 AI 能够可靠工作的运行时上下文系统。
| 上下文层 | 包含内容 | 对 RCA 的作用 |
|---|---|---|
| 实体模型 | 服务、主机、数据库、队列、Kubernetes 对象 | 定义系统中的分析对象 |
| 拓扑关系 | 上下游依赖、调用路径、基础设施关系 | 判断影响路径和故障传播 |
| 遥测数据 | metrics、logs、traces、events | 提供异常证据和时间序列变化 |
| 变更记录 | 部署、配置、代码、云资源变化 | 解释事故前后发生了什么 |
| 组织记忆 | postmortem、runbook、历史事故、专家信息 | 让 AI 复用团队经验 |
| 工作流 | Slack、ServiceNow、Zoom、Workflow Automation | 把建议带到响应者实际工作的地方 |
第一步，不是找根因，而是先把告警变成 Issue
很多团队做 RCA 的第一个误区，是直接从告警开始分析。
CPU 高了，延迟高了，错误率高了，某个接口超时了，某个探测失败了，于是就让 AI 去看这些告警。
问题是，真实生产环境里，告警本来就是噪音极高的症状集合。一个底层问题，可能同时触发几十个告警；一个上游故障，可能让一堆下游服务一起叫；一个 Kubernetes 节点异常，可能表现为应用延迟、容器重启、探测失败、数据库连接错误。
如果没有先把这些症状聚合成一个“问题单元”，RCA 很容易变成对每个告警分别写小作文。
New Relic 的做法是先建立 Issue 抽象。
在它的产品里，alert event 是症状，issue 才是一线响应者真正要处理的问题容器。New Relic 会通过 alert event intelligence、correlation decisions、实体拓扑关系、相似属性、时间窗口等信息，把多个相关 alert events 合并成一个 issue。
这个设计很关键。
因为 RCA 不是对单条告警做解释，而是对一组相关症状背后的共同问题做判断。你必须先定义“我们到底在分析哪个问题”，后面的影响面、根因推断、处置建议才有意义。
这件事听起来很基础，但我认为它决定了 AI RCA 的成败。
如果一个产品没有 issue 抽象，没有事件关联，没有拓扑聚合，却直接说自己能做 AI RCA，我会非常怀疑它在真实告警风暴里的效果。
从产品设计上看，Issue 抽象解决的是 RCA 的起点问题。只有先定义“这一组症状共同指向哪个问题”，后续的影响面、时间线、候选根因和处置动作才不会散。
一线响应者真正关心的，不是“根因是什么”
New Relic 的 Response Intelligence 很有意思。
它没有把界面设计成一个宏大的“Root Cause Analysis Center”，而是直接嵌在 Issue 页面里，围绕一线响应者最紧急的几个问题展开：
第一，影响了谁？ 第二，以前发生过吗？ 第三，我现在应该先检查什么？
这比直接问“根因是什么”更接近真实故障现场。
很多事故刚开始的时候，根本不可能马上给出唯一根因。一个负责的系统不应该在证据不足时装作已经知道答案。它更应该先告诉响应者：哪些实体受影响，终端用户是否受影响，最近有没有类似历史事故，哪些指标和日志值得先看，有哪些候选原因需要验证。
这也是 AI RCA 和传统 dashboard 的区别。
传统 dashboard 把信息摊开给你看，让你自己找线索。AI RCA 应该做的是把调查路径压缩出来：先看哪里，为什么看这里，看到什么算支持这个假设，看到什么又应该排除它。
New Relic 在 Issue 页面里做 AI summary、historical incidents、postmortem RAG、potential causes、contextual checks，本质上就是把老师傅脑子里的第一轮排查路径产品化。
它替代的不是最终责任人，而是那种“出事之后先凭经验看一圈”的人肉流程。
一线响应者在事故早期最需要的是排序能力：先看什么、为什么看、看到什么意味着假设成立、看到什么意味着假设被排除。AI RCA 的价值，首先是缩短第一轮排查时间，而不是抢着宣布唯一根因。
日志摘要是一个很好的 AI RCA 切入口
我尤其喜欢 New Relic 在 AI Log Alert Summarization 上的切入。
日志是排障里最费时间的部分之一。问题不在于日志没有，而是太多、太碎、太吵。响应者真正需要的不是一个聊天框，让他自己贴日志、问问题、追问，再继续贴更多日志。
更好的体验应该是：当 log-based alert 触发时，系统自动分析告警上下文时间窗口内的日志，抽取几个关键发现，给出可能原因和下一步建议。
New Relic 现在就是这样做的。它在 alert issue 里自动分析触发实体相关日志，输出 What happened、Findings、Recommendations。
这个方向很务实。
因为它不要求 AI 一上来就理解全公司系统，也不要求它直接闭环修复。它只是在一个边界清楚、价值明确、用户痛点强烈的场景里，先把人读日志的时间压下来。
如果我是一个 ToB 监控或可观测性厂商，我会优先做这类能力，而不是一开始就喊“全自动 AI SRE”。
日志告警摘要、近期变更关联、相似历史故障检索、影响面分析、推荐检查项，这些能力比“万能 Agent”更朴素，但也更容易落地，更容易被用户信任。
| 切入口 | 为什么适合先做 | 输出形态 |
|---|---|---|
| 日志告警摘要 | 边界清楚，用户痛点强，价值容易感知 | What happened、Findings、Recommendations |
| 近期变更关联 | 很多事故与发布或配置变化相关 | 变更时间线、关联实体、风险提示 |
| 相似历史故障 | 组织经验可复用 | 历史 issue、postmortem、已验证处置动作 |
| 影响面分析 | 事故响应首先要判断影响谁 | 受影响实体、用户路径、下游服务 |
| 推荐检查项 | 降低第一轮排障成本 | 候选方向、验证步骤、排除条件 |
真正的 RCA 引擎，应该是算法和 LLM 的分工
New Relic 在 2026 年提到的 Intelligent RCA，也就是 iRCA，我认为更能代表未来方向。
它的核心不是让 LLM 直接在海量数据里自由推理，而是自动搜索实体拓扑图，使用概率因果模型给图打分，再用 path-based ranking algorithm 缩小问题空间。
这条路线非常重要。
因为企业级 RCA 不能只靠大模型“读懂上下文”。真正可靠的做法应该是：
先用规则、统计、拓扑、相似度、因果模型、时间相关性，把候选问题空间压小；再让 LLM 基于这些高置信度候选原因做解释、摘要、下一步建议和协作编排。
也就是说，算法负责筛选和排序，LLM 负责解释和编排。
这比让 LLM 直接在指标、日志、trace 里凭语言能力猜根因要可靠得多，也更容易给企业客户解释：为什么系统认为这个数据库、这个部署、这个下游依赖更可疑？证据是什么？时间线是什么？影响路径是什么？
我甚至觉得，这会成为 AI RCA 产品能不能进入生产环境的分水岭。
没有证据链的 RCA，只是更会说话的告警摘要。 有拓扑、有候选排序、有置信度、有时间线、有可验证证据，才像一个真正的排障系统。
这也是 AI RCA 产品需要避免的误区：不要把所有推理压力都丢给 LLM。企业级 RCA 更需要可解释的候选生成和排序机制，让模型在更小、更可靠的证据空间里工作。
组织记忆会成为 AI SRE 的复利
New Relic 的 Knowledge Connector 也值得认真看。
它做的事情并不复杂：把客户内部的 postmortem、runbook、历史复盘、专家信息接入 New Relic AI。这样类似问题再次发生时，AI 不只是看实时指标和日志，还能看到过去这个组织是怎么处理类似事故的。
这件事的价值被很多人低估了。
企业里的运维经验，很大一部分不是写在代码里，也不是写在监控指标里，而是散落在复盘文档、工单、聊天记录、值班经验和老员工记忆里。
某个服务为什么不能随便重启？ 某个告警为什么历史上经常误报？ 某个数据库参数为什么不能轻易调？ 去年类似事故最后是谁解决的？ 上一次回滚为什么失败了？
这些才是企业真实的运行时知识。
如果 AI SRE 没有组织记忆，它每次事故都像一个新来的值班同学，只能从现场数据重新开始猜。如果它能把历史事故、变更、负责人、处置动作和结果反馈串起来，它才开始拥有“经验”。
这也是为什么我认为，未来 AI SRE 的竞争不会只发生在模型层，而会发生在运行时知识图谱和组织记忆层。
谁能把事故处理过程沉淀下来，并在下一次事故中自动拿出来使用，谁就能形成真正的复利。
组织记忆的关键不是“把文档放进知识库”这么简单，而是要能在事故现场被召回：这个服务过去出过什么问题、上次怎么恢复、谁参与过、哪些动作有效、哪些动作失败过。
Agent 不应该比工具和权限先出现
现在行业里很容易出现一种冲动：既然 AI 火，那就赶紧做一个 SRE Agent。
但 New Relic 的路径恰恰说明，Agent 不是起点，而是结果。
在 SRE Agent 之前，它已经有 Alerts、Issues、correlation decisions、New Relic AI、Knowledge Connector、MCP、Workflow Automation 这些能力。Agent 更像是这些能力之上的编排层。
这点非常关键。
如果没有可靠的数据查询能力，Agent 查不到证据。 如果没有事件聚合能力，Agent 会被告警风暴淹没。 如果没有实体拓扑，Agent 不知道依赖关系。 如果没有变更记录，Agent 很难判断最近发生了什么。 如果没有 runbook 和 workflow，Agent 只能给建议，不能推动动作。 如果没有权限和审计，Agent 根本不应该碰生产环境。
New Relic 在 SRE Agent 上也比较克制。它强调 system identity、只读默认权限、人工审核、human-in-the-loop、可控的 workflow automation。这不是保守，而是企业级产品必须有的底线。
AI SRE 最危险的不是不够智能，而是太早拥有动作权限。
真正合理的演进路径应该是：先让 Agent 会调查，再让它会建议，最后才让它在护栏内执行低风险动作。高风险动作必须有审批、回滚、审计和责任边界。
| 阶段 | Agent 能力 | 风险控制 |
|---|---|---|
| 调查 | 查询数据、聚合上下文、生成候选原因 | 只读权限、查询审计、数据边界 |
| 建议 | 推荐检查项、runbook、处置路径 | 标注证据、保留人工判断 |
| 执行 | 触发低风险自动化动作 | 审批、回滚、权限隔离、操作留痕 |
这个顺序的底层逻辑是：生产环境里，可信比炫技重要。Agent 先证明自己会调查，再讨论自动执行。
MCP 的意义：可观测性平台要成为上下文提供者
New Relic 现在也在推 MCP Server，这一点我觉得很有战略意义。
过去可观测性产品默认认为，用户应该进入我的控制台，看我的 dashboard，用我的查询语言，在我的页面里完成排障。
但 AI 时代，这个前提会被动摇。
工程师处理故障的地方，可能是 Slack，可能是 ServiceNow，可能是 IDE，可能是 Claude Code，可能是终端，可能是 Zoom 会议，也可能是某个内部运维平台。
可观测性平台如果还只把自己当 UI 产品，就会错过一部分入口。更准确的定位应该是：我是整个工程系统的事实底座和上下文提供者。
MCP 的价值就在这里。
它让外部 AI agent 能以统一协议访问 New Relic 的 observability context，查询指标、分析日志、检查告警、评估部署影响。这样 New Relic 不一定非要成为工程师唯一打开的页面，但它可以成为很多 AI 工具背后的上下文来源。
我认为这会是可观测性厂商接下来必须思考的问题：你的产品到底是一个页面，还是一个可以被人和 agent 同时调用的运行时数据平台？
如果只是页面，价值会被入口稀释。 如果是上下文平台，反而会在更多工作流里变得不可替代。
MCP 的意义不只是多一个集成协议。它改变的是可观测性平台的角色：从“用户必须打开的页面”，变成“人和 AI agent 都能调用的运行时事实底座”。
对国内可观测性厂商的启发
如果把 New Relic 这套东西压缩成一句话，我的理解是：
AI RCA 的产品化顺序，应该是先闭环，再智能。
不要一开始就做一个“AI 根因分析大师”。更现实的路径是：
第一步，做好 issue 抽象和事件关联。先把告警风暴压成可处理的问题单元。
第二步，做好上下文包。把指标、日志、trace、变更、拓扑、历史事故、运行手册放到同一个故障现场里。
第三步，做好可解释 RCA。不是只给结论，而是给候选原因、证据链、时间线、影响路径和置信度。
第四步，做好一线响应体验。优先回答“影响谁、以前有没有、先看什么”，而不是急着宣布“根因就是它”。
第五步，做好组织记忆。把复盘、runbook、专家经验变成下一次故障的上下文。
第六步，再做 Agent 和自动化。让 Agent 先调查，再建议，再在权限和审批下执行低风险动作。
这个顺序看起来没那么性感，但它更接近真实生产环境。
AI RCA 最大的敌人不是模型不够强，而是产品太急。太急着展示智能，太急着给结论，太急着自动修复，反而会失去用户信任。
如果把这条路径落到产品规划上，可以拆成下表：
| 优先级 | 产品能力 | 目标 |
|---|---|---|
| 1 | Issue 抽象和事件关联 | 把告警风暴压成可处理的问题单元 |
| 2 | 上下文包 | 聚合指标、日志、trace、变更、拓扑、历史事故和 runbook |
| 3 | 可解释 RCA | 输出候选原因、证据链、时间线、影响路径和置信度 |
| 4 | 响应者体验 | 优先回答影响谁、以前有没有、先看什么 |
| 5 | 组织记忆 | 把复盘、runbook 和专家经验变成下一次事故的上下文 |
| 6 | Agent 和自动化 | 在权限、审批和审计下执行低风险动作 |
最后的判断
New Relic 给我的最大启发是：未来可观测性厂商的竞争，不会只是 “谁的 AI 助手更会回答问题”。
真正的竞争会发生在这几件事上：
- 谁有更完整的实体模型和拓扑关系
- 谁能把告警噪音压成高质量 issue
- 谁能把实时遥测、历史事故和组织知识串起来
- 谁能用算法和因果模型先缩小问题空间
- 谁能让 LLM 在证据之上解释和编排
- 谁能把建议变成有权限、有审批、有审计的动作
所以，AI RCA 最终不会是一个按钮，也不会只是一个聊天框。
它会变成一条故障处理流水线：从告警进入系统开始，到事件聚合、影响分析、上下文收集、候选根因排序、运行手册推荐、自动化执行、复盘沉淀，整个过程都被 AI 和数据重新组织。
谁能把这条流水线做顺，谁才真正有机会在 AI SRE 时代赢。
谁只是给 dashboard 套一个大模型入口，谁就还停留在演示层。
FAQ
Q1：为什么 AI RCA 不应该从单条告警开始？ A：真实事故常常会触发多条相关告警。先把 alert event 聚合成 issue，才能围绕一个问题单元做影响分析、候选根因和处置建议。
Q2：LLM 在 RCA 中应该承担什么角色？ A：LLM 更适合做解释、摘要、建议和协作编排。候选问题空间的筛选和排序，仍然需要实体拓扑、规则、统计、因果模型、时间相关性和历史数据共同完成。
Q3：为什么组织记忆对 AI SRE 很重要？ A：因为很多关键经验存在于 postmortem、runbook、工单、聊天记录和值班经验里。没有组织记忆，AI 每次事故都像从零开始；有组织记忆，类似事故可以更快进入有效排查路径。
Q4：国内厂商做 AI RCA 的第一步是什么？ A：不是先做万能 Agent，而是先做好 issue 抽象、事件关联、上下文包和证据链。只有闭环清楚，AI 的解释和自动化才有可信基础。
参考资料
- New Relic AI overview https://docs.newrelic.com/docs/agentic-ai/new-relic-ai/
- Response intelligence with New Relic AI https://docs.newrelic.com/docs/alerts/alert-event-management/response-intelligence-ai/
- SRE Agent overview https://docs.newrelic.com/docs/agentic-ai/sre-agent/overview/
- New Relic MCP overview https://docs.newrelic.com/docs/agentic-ai/mcp/overview/
- New Relic SRE Agent and AI-strengthened platform innovations press release https://newrelic.com/press-release/20260224
- AI Log Alert Summarization preview https://docs.newrelic.com/whats-new/2025/11/whats-new-11-13-ai-log-alert-summarization/
- New Relic AIOps solution page https://newrelic.com/solutions/aiops
