最近我系统看了一下 Resolve AI 这家公司，感受挺强烈。
它不是又一个把大模型接到日志查询框里的 AI 助手，也不是传统意义上的 AIOps 平台。它真正想做的是一层新的生产系统智能入口：当告警来了，AI 像一个有经验的 SRE 一样，自动去查指标、日志、链路、代码、发布、Kubernetes、云资源、runbook、历史事故和 Slack 讨论，然后给出证据、假设、根因和下一步动作。
这件事听起来像“AI SRE”，但我觉得更准确的说法是：它在尝试把生产环境里的排障经验产品化。
这对国内做监控、可观测性、AIOps、故障定位的厂商很有参考价值。
因为过去几年，我们一直在帮客户“看见系统”：指标、日志、链路、拓扑、告警、仪表盘、事件中心。可是客户真正着急的时候，问题不是“有没有数据”，而是：
到底为什么坏了？
谁应该处理？
最近谁改了什么？
有没有类似事故？
现在应该先止血还是继续查？
哪些证据能支撑这个判断？
下次怎么避免？
Resolve AI 抓住的就是这个空白。
它的判断很直接：可观测性平台让你看见生产系统，AI SRE 要帮你理解生产系统，并推动你采取行动。
它不是替代可观测性，而是在可观测性之上工作
很多人一听 AI SRE，会自然想到“是不是要重新做一个 Datadog、Grafana、Splunk 或 Prometheus？”
Resolve AI 的路线恰恰相反。
它不要求客户替换现有可观测性栈，而是连接客户已有工具：Datadog、Grafana、Splunk、Prometheus、Kubernetes、AWS、GitHub、GitLab、Slack、Teams、Confluence、Notion、PagerDuty、Jira，以及各种内部系统。
这件事很聪明。
可观测性数据迁移成本极高。一个企业不会为了尝试 AI RCA，把多年积累的监控、日志、链路、告警和 dashboard 全部迁走。但它可能愿意给一个 AI agent 只读权限，让它像人类 SRE 一样跨工具查证据。
这也是 Resolve AI 的基本产品定位：它不是数据采集层，而是调查和行动层。
传统可观测性平台问的是：“你要看哪个 dashboard？”
Resolve AI 想问的是：“你被 page 了，我已经先帮你查了一圈，下面是最可能的原因和证据。”
这个入口变化很关键。
过去排障是人围着工具转。人收到告警，打开监控，看 dashboard，查日志，跳 trace，翻 PR，找 runbook，问群里有没有人发版。
AI SRE 的目标是反过来：工具围着问题转。告警一来，系统自动把该看的东西先看一遍，把证据包推到人面前。
AI RCA 不能只是“给根因”，而要给调查包
很多 AI RCA 产品容易犯一个错误：太想给答案。
告警来了，AI 生成一段话：“根因可能是数据库连接池耗尽。”看起来很像回事，但一线工程师通常不会就此相信。
他会继续问：
哪个服务的连接池？
哪个指标证明？
什么时候开始的？
和最近发布有没有关系？
是不是下游服务异常导致的？
影响了哪些用户？
有没有反证？
如果重启会不会更糟？
所以真正有价值的 RCA，不是一个答案，而是一个调查包。
Resolve AI 在公开材料里反复强调几个东西：evidence、confidence、timeline、dependency chain、recent changes、similar incidents、recommended actions。
这很对。
AI RCA 最终应该输出的不是“我觉得是 X”，而是：
这是当前症状。
这是影响面。
这是候选根因。
这是支持证据。
这是被排除的方向。
这是最近相关变更。
这是历史相似事故。
这是建议先做的缓解动作。
这是风险和验证方式。
如果没有证据链，所谓根因就是一段更会说话的告警摘要。
对企业客户来说，可信度不是来自模型语气有多笃定，而是来自它能不能把原始证据摆出来，并允许工程师继续 drill down。
多 Agent 的价值，不是概念，而是并行查证
Resolve AI 很喜欢讲 multi-agent。
这个词现在已经有点被滥用了。很多产品一说 multi-agent，就容易变成营销词。但在 AI SRE 场景里，多 agent 确实有现实意义。
真实事故不是线性的。
一个延迟升高，可能是应用发布引起的，也可能是数据库慢查询，也可能是下游接口抖动，也可能是 Kubernetes 节点资源争抢，也可能是某个 feature flag 放量，也可能是云厂商托管服务异常。
如果一个 agent 顺序排查，很容易一开始就押错方向，然后在错误假设里越查越深。
更合理的方式是并行探索多个假设：
一个 agent 查指标和 dashboard。
一个 agent 查日志模式。
一个 agent 查 trace 和依赖链。
一个 agent 查最近代码和 PR。
一个 agent 查部署、配置、云资源和 Kubernetes 事件。
一个 agent 查 runbook 和历史事故。
最后再由 planner 或 coordinator 汇总证据，判断哪些假设被支持，哪些假设被排除。
这才是多 agent 在 AI RCA 里的实际价值：不是为了显得先进，而是为了缩短第一轮调查时间，并减少单一路径误判。
好的 AI SRE 界面也应该把这个过程展示出来。
用户不只想看最终答案，还想知道 AI 查了什么，没查什么，为什么排除了某个方向，为什么把当前候选根因排在第一位。
这也是我认为 AI RCA 和普通聊天机器人的根本区别：聊天机器人重在回答，AI RCA 系统重在调查。
代码上下文会变成 AI RCA 的核心能力
Resolve AI 的客户案例里，经常强调它能定位到具体 PR、具体方法、具体代码变更。
这点非常重要。
过去很多 RCA 产品主要围绕指标、日志、链路和拓扑做关联。但真实故障里，很多根因最终都要落到变更上。
哪个版本发布了？
哪个配置改了？
哪个 PR 引入了行为变化？
哪个方法导致重试风暴？
哪个 feature flag 改变了流量路径？
哪个 Terraform apply 改了基础设施？
如果 AI 只能看 telemetry，它最多能说“这个服务从 10:03 开始错误率上升”。但工程师真正想知道的是：“10:03 前后到底发生了什么改变？”
所以 AI SRE 必须连接代码仓库、CI/CD、部署记录、配置中心、feature flag、IaC 变更和工单系统。
我甚至觉得，未来 AI RCA 的竞争会从“谁的日志总结更好”转向“谁能更快把生产异常和代码变更连起来”。
这对国内厂商也是一个提醒。
我们做监控和可观测性，不能只盯着机器数据。客户的生产系统是由代码、配置、发布、依赖、人员和流程共同组成的。只看指标日志链路，RCA 的上限会很明显。
Satellite 这类本地代理，是企业级 AI SRE 的底座
Resolve AI 有一个很关键的组件叫 Satellite。
它运行在客户自己的基础设施里，主要作用是安全地代理查询本地系统。比如访问 observability 工具、Kubernetes API、内部域名、云资源和私有数据源。credentials 留在客户侧，AI 通过受控通道获取必要结果。
它的设计里有几个关键词：read-only、redaction、RBAC、audit log、mutual TLS、domain allowlist、secret manager。
这不是细节，而是企业级 AI SRE 能不能落地的前提。
很多 AI 运维产品做 demo 时很好看，因为 demo 环境里什么权限都有，什么数据都能拿。但一到真实客户现场，马上会遇到一堆问题：
日志能不能出内网？
token 能不能给 SaaS？
AI 查了什么能不能审计？
敏感字段能不能脱敏？
能不能只读？
能不能限制命名空间？
能不能私有化部署？
模型会不会拿客户数据训练？
这些问题不解决，AI RCA 很容易停在 POC。
对国内 ToB 市场来说，这一点只会更强。金融、运营商、能源、制造、大型政企客户，不会因为你有一个很炫的 AI 演示，就放开生产权限。
所以我认为，AI SRE 产品从第一天就要考虑本地代理和权限架构，而不是等客户问安全时再补。
默认只读、最小权限、数据脱敏、操作审计、审批流、动作回滚，这些不是企业版高级功能，而是进入生产环境的门票。
真正的壁垒是 production context
Resolve AI 反复讲 production context 和 dynamic knowledge graph。
翻译成更朴素的话，就是：AI 要懂这个客户的生产环境。
它要知道哪个服务属于哪个团队，哪个 dashboard 对这个服务最有用，哪个日志字段代表业务订单号，哪个告警经常误报，哪个数据库不能随便重启，哪个接口是核心交易链路，哪个历史事故和这次很像。
这些东西通用大模型不知道。
而且这些知识不是一次性导入文档就够了。生产系统每天都在变：代码在变，服务在变，依赖在变，值班人和团队边界在变，告警规则在变，runbook 也会过期。
这就是 AI SRE 比普通企业知识库难很多的地方。
企业知识库的知识相对静态，生产上下文是动态的。
Resolve AI 很重视 environment matching 这种看起来很小的事情。例如 production、staging、us-west 这些环境名，如果在 Satellite、Datadog、Grafana、告警源里不一致，系统就很难把告警、日志和 dashboard 正确连接起来。
这类细节决定了 AI RCA 的实际效果。
国内客户现场更复杂：Kubernetes、虚拟机、物理机、公有云、私有云、自研中间件、老系统、CMDB、工单、中文命名、缩写、历史包袱，全都混在一起。
如果服务名不统一、环境标签不统一、trace 覆盖率不足、变更记录不完整，AI 就只能基于残缺现场讲故事。
所以 AI RCA 不是接一个大模型 API 就能做成。它首先是数据治理、实体映射、上下文建模和工具编排问题，然后才是模型问题。
组织记忆不能乱学
Resolve AI 的公开表达里有一个很有意思的张力。
官网营销会说它能从每次交互中学习。但在更具体的 Slack 文档里，它又比较谨慎：反馈主要用于质量评估和产品改进，不会自动变成长时记忆；组织记忆来自已连接、已整理的 runbook、最佳实践和 dashboard。
我觉得这个克制非常重要。
事故群里的信息，并不都应该变成知识。
里面有初始误判，有临时猜测，有情绪化表达，有过期命令，有不适合复用的 workaround，有被推翻的假设，也可能有敏感数据。
如果 AI 把所有聊天内容都自动写入长期记忆，下次事故很可能复用错误经验。
更合理的做法是把记忆分层：
当前事故里的讨论，可以作为短期上下文。
复盘确认过的根因，可以进入历史事故库。
被验证有效的修复动作，可以进入 runbook。
被用户 dismiss 的建议，可以作为负反馈。
聊天里的猜测，不应该自动变成长期知识。
这点对所有 AI SRE 产品都很重要。
AI 要学习组织经验，但不能污染组织记忆。记忆必须可审计、可编辑、可删除，也必须区分“猜测”和“确认事实”。
NOC / L1 可能是国内更好的切入口
Resolve AI 单独做了 AI-first NOC 产品页，我觉得这条线很值得国内厂商关注。
相比“全自动 AI SRE”，AI NOC 或 AI 一线值班助理可能更容易落地。
很多大客户的真实痛点不是没有专家，而是专家被大量低质量告警和无效升级拖住了。一线运维每天面对很多告警，但不知道哪些严重，哪些可以忽略，哪些要升级，升级时应该带哪些证据。
于是二线、三线工程师经常被拉进来重新查一遍。
AI 在这个场景里的价值非常明确：
先帮 L1 做告警分诊。
把相关告警聚合起来。
查最近变更和影响面。
生成证据包。
推荐 owner 和升级路径。
根据 runbook 给出处理步骤。
升级时把上下文带完整。
事故结束后自动生成交接和复盘材料。
这不需要 AI 一开始就“替代 SRE”。它只要让每次升级质量更高，让专家少被无效打扰，客户就能感知价值。
对国内监控厂商来说，这可能比直接讲“AI 自动修复生产故障”更务实，也更容易被客户接受。
不要从自动修复开始
Resolve AI 的宣传有时候很激进，会讲自动调查、自动修复、生成 PR、执行命令。但仔细看它的产品设计，仍然是分级自治。
先只读调查。
再给建议动作。
再生成命令或 PR，让人 review。
再在审批和护栏下执行低风险动作。
最后才谈 human-on-the-loop。
这条路径是对的。
AI SRE 最危险的不是不够智能，而是太早拥有生产写权限。
一个建议错了，工程师可以忽略。
一个摘要错了，工程师可以纠正。
一个 PR 不好，工程师可以 reject。
但一个自动执行的生产动作错了，后果完全不同。
所以 AI RCA 产品应该先把低风险、高频、可验证的事情做到极致：
自动查证据。
自动总结。
自动找 owner。
自动关联变更。
自动找相似历史事故。
自动生成复盘草稿。
自动生成建议命令，但让人执行。
自动生成 PR，但让人 review。
信任不是靠一句“我们能自动修复”建立的。信任来自一百次低风险场景里的稳定表现。
AI SRE 最终会把可观测性产品推向新形态
Resolve AI 最值得我们学习的，不是某个具体功能，而是它对产品形态的判断。
过去可观测性产品的核心是 dashboard、query、alert、trace、log search。
未来 AI SRE 时代，产品核心可能会变成：
生产上下文。
自动调查。
证据链。
假设验证。
组织记忆。
行动建议。
审批和自动化。
事故复盘。
日常生产问答。
这意味着可观测性平台不能只做“数据展示层”，还要变成“生产系统推理层”和“行动编排层”。
对国内厂商来说，机会也很清楚。
我们不一定要照搬 Resolve AI 的 SaaS 路线。国内市场有自己的特点：私有化、混合云、国产中间件、企业微信/飞书/钉钉、ITSM、CMDB、等保合规、复杂权限、中文语境。
但核心方向是一致的。
第一，AI RCA 要从告警自动调查切入，而不是等用户在聊天框里提问。
第二，RCA 输出要做成调查包，而不是根因小作文。
第三，要把 telemetry、code、infra、change、incident、knowledge 打通。
第四，默认只读、证据优先、审批可控、动作可审计。
第五，要建设客户专属 production context 和组织记忆。
第六，要把飞书、企微、钉钉、工单和事故群做成一等入口。
第七，要从 NOC/L1、on-call handoff、SLO check-in 这些高频场景建立信任。
我越来越觉得，AI RCA 不是一个功能，而是监控和可观测性产品的下一次入口重构。
谁能让客户从“看见问题”更快走到“理解问题、验证问题、处理问题”，谁就会成为下一代生产系统的默认工作台。
Resolve AI 只是一个很早的样本。
但这个样本已经足够说明：真正值钱的 AI SRE，不是更会聊天，而是更懂生产。
参考资料：Resolve AI 官网、官方文档、AI SRE Buyers Guide、客户案例、融资新闻、Lightspeed / Greylock 投资文章，以及 AI RCA 相关公开论文。
