看完 Chronosphere，我觉得它给 AI RCA 市场补了一条非常重要的路线。
这家公司最值得看的，不是它也做了 AI，也不是它也出了 MCP Server，而是它一直在强调一件很多厂商不愿意认真讲的事：
如果 telemetry 本身是混乱、昂贵、低价值的，AI RCA 只会更快地产生错误结论。
这句话不性感，但很关键。
今天很多 AI RCA 产品的默认叙事是：把指标、日志、链路、告警都交给大模型，模型就能帮你找根因。
Chronosphere 的判断更冷静：
数据太多，不等于上下文完整。
日志太多，不等于证据充分。
指标维度太多，不等于 AI 就能理解系统。
把 raw telemetry 接进 MCP，也不等于 agent 真懂生产环境。
所以它的路线不是先做“AI 自动宣布根因”，而是先做 control。
控制数据体量。
控制高基数。
控制存储成本。
控制字段质量。
控制服务上下文。
控制变更事件。
控制 AI 能看到什么、能做什么、不能做什么。
这条路线，对国内监控和可观测性厂商特别有参考价值。
Chronosphere 不是从聊天框开始的
很多产品做 AI，第一步是加一个聊天框。
用户问：为什么这个接口慢？
AI 答：可能是数据库连接数过高。
用户问：这条日志是什么意思？
AI 答：这是某个服务调用失败。
用户问：帮我生成 PromQL。
AI 答：给你一段查询。
这些功能有用，但离可靠的 AI RCA 还很远。
Chronosphere 的底层产品哲学是 Observability Built for Control。它从 Uber M3 的大规模云原生监控经验里长出来，核心问题不是“如何收集更多数据”，而是“如何让团队只为真正有价值的数据付费，并且还能在故障时找到证据”。
这点很重要。
传统可观测性厂商经常鼓励客户多采集、多存储、多关联。到了 AI 时代，这个问题会被放大。因为 AI investigation 会消耗更多查询、更多上下文、更多模型调用，也会把更多噪声带进推理过程。
如果基础数据没管住，AI 看起来更聪明，实际可能更危险。
Control Plane 是 AI RCA 的前置条件
Chronosphere 的 Control Plane 很值得研究。
它做的事情听起来不花哨：drop rules、rollup rules、mapping rules、recording rules、recommendations、quotas、pools、license overview。
翻译成产品语言，就是：
哪些指标不该存。
哪些标签应该聚合。
哪些高基数字段会制造成本。
哪些数据过去 30 天没人用。
哪个团队用了多少额度。
哪些数据超出容量会被丢。
哪些规则会影响查询和告警。
这些听起来像成本治理，但放到 AI RCA 里，就是可信度治理。
因为 AI RCA 最怕两件事。
第一，关键证据没采到，或者被错误采样、聚合、丢弃了。
第二，无关数据太多，AI 被噪声带偏，还写出一段很自信的错误结论。
所以 telemetry control 不是财务部门的事，而是 AI RCA 的地基。
国内很多客户也有同样的问题。一边希望全量采集日志、指标、链路，一边又要求私有化资源可控、存储成本可控、模型调用成本可控。
这几个目标天然冲突。
如果产品里没有数据治理、配额、采样、聚合、脱敏、保留策略和影响预览，只靠 AI 总结故障，迟早会遇到客户信任问题。
DDx 的价值：先找差异，不急着说根因
Chronosphere 的 Differential Diagnosis，简称 DDx，是它 RCA 能力里最值得看的部分。
DDx 的思路很简单：当你看到一个指标异常或 trace 性能问题，不要先猜数据库、网络、缓存、发布，也不要先让大模型写结论，而是先比较异常和基线。
什么变了？
什么没变？
哪些维度和错误更相关？
哪些标签只出现在慢请求里？
哪个 region、cluster、version、environment、operation 和异常最相关？
这和 Honeycomb 的 BubbleUp 有相似之处。
它们都在提醒我们：RCA 的第一步不是因果判断，而是差异发现。
很多所谓 AI RCA 最大的问题，是把症状包装成根因。
CPU 高，所以根因是 CPU。
错误率高，所以根因是接口错误。
数据库慢，所以根因是数据库慢。
下游超时，所以根因是下游超时。
这些经常只是现象。
DDx 更务实。它不急着宣布最终答案，而是先帮工程师缩小调查空间。它告诉你哪些维度值得看，哪些方向可能是噪声，哪些假设更值得验证。
这比一段漂亮总结更接近真实排障。
Trace 里的 Leaf Errors 也很关键
Chronosphere Trace Explorer 里有一个细节很有意思：Leaf Errors。
分布式 trace 里的错误经常会传播。
一个下游服务真正失败，上游服务也报错，API gateway 也报错，前端也报错。最后你会看到一串错误 span。如果 AI 只是统计错误最多的服务，很容易把受害者当成根因。
Leaf Errors 关注的是没有失败子 span 的 error spans。它们往往更接近失败传播的源头。
这个设计说明 Chronosphere 没有把 RCA 简化成“看谁错得多”。它在用 trace 的结构理解错误如何传播。
国内产品做 AI RCA，也应该补这类基础能力。
不要只让模型总结 trace。要先把 trace 里的错误传播、关键路径、慢 span、失败源头、上下游关系分析清楚。
Guided Troubleshooting 是克制的 AI
Chronosphere 现在推 AI-Powered Guided Troubleshooting。
这个产品里有几个关键能力：
Suggestions。
Temporal Knowledge Graph。
Investigation Notebooks。
Natural Language Assistance。
听起来很 AI，但它的产品态度其实很克制。
Suggestions 会在你打开 alert 时给出证据化建议，告诉你最可能的方向、背后的 timing correlation、service dependencies、historical patterns，以及哪些东西被排除了。
但它不说“我已经找到最终根因”。
它说的是：这是最可能的下一步，你来验证。
这个边界很重要。
真实生产环境里，AI 不应该每次都强行给答案。很多事故一开始信息不足，很多信号只是相关，很多变化只是巧合。一个愿意展示证据、说明推理、让工程师验证的 AI，比一个自信宣布根因的 AI 更可靠。
Chronosphere 把阶段分得很清楚：
过去是 manual workflow，工程师自己查。
现在是 guided workflow，AI 提建议，人来判断。
未来才是 autonomous workflow，AI 尝试修复，人来监督。
这条演进路径比“我们已经实现全自动 AI SRE”更可信。
Temporal Knowledge Graph 不是普通服务拓扑
Chronosphere 反复强调 Temporal Knowledge Graph。
它不是简单画一张服务依赖图，而是把服务、基础设施、依赖、metrics、traces、logs、system changes、人类注释、resolution notes、runbooks 和 investigation outcomes 连起来。
这里最关键的词是 temporal。
生产系统不是静态的。
服务会发布。
实例会替换。
Kubernetes workload 会扩缩容。
feature flag 会切换。
配置会变化。
流量形态会变化。
依赖关系也会变化。
RCA 需要知道的不只是“现在谁依赖谁”，还要知道“问题发生之前发生了什么变化”。
这也是很多 AI RCA 产品容易失败的地方。它们可以读 raw telemetry，但 raw telemetry 不等于系统知识。外部 agent 通过 MCP 查到一堆指标，也不代表它理解这些指标和服务、变更、团队、历史事故之间的关系。
Chronosphere 的答案是，把这些关系做成持续更新的知识图谱，再让 AI 基于这个图谱给建议。
这对国内厂商很有启发。
不要把知识图谱理解成展示拓扑图。真正有价值的是把监控数据、变更数据、工单数据、复盘结论、runbook、告警历史、服务 owner、业务影响都连接起来。
AI RCA 需要的不是一张漂亮图，而是一套能被查询、能随时间更新、能吸收人类反馈的生产知识系统。
Investigation Notebook 把事故变成组织记忆
Chronosphere 的 Investigation Notebooks 也很值得借鉴。
它会记录工程师调查过程中的步骤、查询、证据、发现和结论。调查结束后，这些结果会反馈到 Temporal Knowledge Graph，后续类似事故出现时，系统可以更快给出建议。
这解决了一个非常真实的问题：很多公司的故障经验并没有进入系统。
它们散落在 Slack、飞书、微信群、会议纪要、个人脑子和 postmortem 文档里。
下次同类事故发生，新人还是从零开始。
值班工程师还是问老同事。
AI 还是只能看当下 telemetry。
系统没有真正变聪明。
Investigation Notebook 的价值，就是把一次调查变成可复用资产。
国内很多客户非常重视复盘，但复盘往往是事故结束后的文档工作，和监控系统、告警系统、工单系统割裂。
更好的方式是从调查发生时就开始记录。
查了什么。
排除了什么。
误判了什么。
确认了什么。
最后怎么修。
后续如何避免。
这些都应该结构化沉淀。否则 AI RCA 永远只能做一次性总结。
MCP 要开放，但边界要清楚
Chronosphere 的 MCP Server 也值得看。
它让 Codex、Claude Code、Cursor、Gemini 这类 AI-enabled developer tools 可以查询 Chronosphere 里的 observability data。
能查 metrics、logs、traces、change events。
能看 dashboards、monitors、SLO。
能帮你解释 monitor 为什么触发。
能帮你写 PromQL。
甚至能查看 shaping rules，理解数据为什么被保留或丢弃。
但它有一个非常关键的边界：只读。
AI agent 可以查，可以分析，但不能更新 dashboard，不能写 metrics / logs，不能删除 monitors。
这是一个很务实的设计。
未来监控平台必须给外部 AI agent 提供生产上下文。只会读代码的 AI coding agent 不够，它还要知道代码在线上怎么运行，哪个服务正在报错，哪条 trace 变慢，哪个 SLO 在燃烧，哪个版本刚发布。
但开放上下文不等于开放生产动作。
国内厂商做 MCP 或 agent 接入时，第一阶段也应该坚持只读优先：
先让 agent 看见事实。
再让 agent 生成建议。
高风险动作必须走权限、审批、审计和回滚。
不要让一个外部 AI 工具直接改生产监控规则或执行修复。
对国内厂商的启发
Chronosphere 这条路线，给国内厂商至少五个启发。
第一，AI RCA 不是模型功能，而是数据工程和产品工程。
先把 telemetry 的采集、标签、字段、基数、保留、采样、聚合、脱敏、成本和权限管住，再谈 AI。
第二，变更事件要成为核心数据。
发布、配置、feature flag、数据库变更、网络变更、扩缩容、重启、工单动作，都应该能和指标、日志、trace、SLO 放在同一个时间轴里。
第三，先做差异诊断。
异常窗口和正常窗口有什么不同，慢请求和快请求有什么不同，失败 trace 和成功 trace 有什么不同，发布前后日志模式有什么不同。这些能力比“AI 总结故障”更扎实。
第四，把调查过程产品化。
不要只生成最终 RCA 文案。要记录证据、查询、假设、反证、确认结论和修复动作，让每次事故变成系统知识。
第五，MCP 和 agent 接入要先做只读上下文。
监控平台应该成为 AI coding / AI DevOps / AI SRE agent 的生产上下文提供者，但权限边界必须清楚。
最后的判断
Chronosphere 提醒我们，AI RCA 之前还有一层更基础的工作：
把 telemetry 从成本黑洞变成高信号上下文。
没有这层能力，AI 只是更会说话的 dashboard。
有了这层能力，AI 才可能真正帮助工程师查问题。
国内厂商现在很容易被“AI 自动根因”“AI 自动修复”“AI SRE Agent”这些词带着走。
但更务实的路线可能是：
先管住数据。
再找出差异。
再连接变更。
再记录调查。
再开放上下文。
最后才谈自动化修复。
Chronosphere 的价值就在这里。
它没有急着让 AI 扮演全自动专家，而是先把 AI RCA 所需的底座拆清楚：
可信 AI RCA，不是从大模型开始，而是从 telemetry control 开始。
