看完 Datadog、Dynatrace、PagerDuty、ServiceNow、BigPanda、AWS 和 Sentry，再看 Honeycomb，会发现它代表的是另一条很不一样的 AI RCA 路线。
Datadog 讲全栈可观测性和 AI SRE agent。 Dynatrace 讲因果图谱。 PagerDuty 和 BigPanda 讲告警、事故和 L1 分诊。 ServiceNow 讲企业运维流程。 Sentry 讲从生产错误直接走到代码修复。
Honeycomb 不一样。
Honeycomb 的核心不是“AI 替你宣布根因”，而是一个更基础的问题：
异常请求和正常请求相比，到底哪里不一样？
这个问题看起来朴素，但它可能是很多 RCA 产品真正缺的东西。
很多 RCA 其实还在看平均值
今天很多监控系统的排障方式，本质上还是看平均值。
平均延迟升高了。 错误率升高了。 CPU 高了。 接口慢了。 数据库连接数多了。 某个服务 QPS 变了。
这些信息当然有用，但它们只告诉你“系统整体有变化”，很少直接告诉你“为什么变化”。
真实生产故障往往不是所有请求都坏了。
可能只是某个租户慢。 可能只是某个用户群慢。 可能只是某个 API route 慢。 可能只是某个 feature flag 打开后慢。 可能只是某个版本、某个机房、某个实例类型、某个浏览器、某个下游组合有问题。
如果你只能看平均值，就只能不断猜。
Honeycomb 的思路不是先猜根因，而是先把异常样本找出来，再问：这些样本有什么共同点？
BubbleUp 才是 Honeycomb 最值得看的 RCA 能力
Honeycomb 最有代表性的能力叫 BubbleUp。
它的用法很简单：你在 heatmap 或图表里框选一块异常区域，比如一群慢请求。然后 BubbleUp 会把这群异常请求和其他正常请求做对比，自动找出差异最大的维度。
结果可能是：
这些慢请求 98% 都来自同一个可用区。 这些错误请求都命中了同一个 endpoint。 这些失败请求只发生在某个 release。 这些高延迟 trace 都经过同一个下游服务。 这些异常只影响某个 tenant。 这些用户都使用同一个浏览器版本。
这不是一句“根因是数据库慢”的 AI 总结。
它更像是把工程师最痛苦的一步自动化了：在几十、几百个字段里找出最可疑的差异。
这点非常重要。
很多 AI RCA 产品喜欢直接输出结论。但如果结论背后没有样本集合、基线集合、差异维度和查询证据，工程师还是不敢信。
BubbleUp 不急着给最终答案。它先给你线索。
这反而更可信。
RCA 的第一步不是因果，而是差异
我觉得 Honeycomb 对国内厂商最大的启发就在这里。
我们经常一上来就想做“根因分析”。
但根因分析太难了。
你要知道拓扑。 要知道变更。 要知道日志。 要知道 trace。 要知道版本。 要知道业务上下文。 要知道历史事故。 还要区分相关性和因果性。
如果这些都没有，上来就让大模型说根因，结果大概率只是把症状包装成答案。
更务实的第一步，是先做差异分析。
慢请求和快请求有什么不同？ 失败请求和成功请求有什么不同？ SLO 燃烧时的请求和正常时段有什么不同？ 某次发布后异常请求和发布前有什么不同？ 投诉用户和未投诉用户有什么不同？
这一步做好了，RCA 才有基础。
没有这一步，AI 说得越流畅，越危险。
Honeycomb 的底座是高基数字段
BubbleUp 能工作，是因为 Honeycomb 从一开始就围绕高基数、高维度数据设计。
所谓高基数字段，就是有很多不同取值的字段。
比如 user_id、request_id、trace_id、tenant_id、order_id、merchant_id、pod_name、instance_id、release、feature_flag、route、SQL fingerprint。
传统指标系统很怕这些字段。
因为一旦把 user_id、request_id 这种字段放进时序指标，成本和存储组合会爆炸。所以很多监控产品会建议你不要加，或者只保留很少的 tag。
问题是，RCA 最需要的往往就是这些字段。
如果一个故障只影响一个大客户，你必须能按 tenant_id 查。 如果一个错误只影响某个版本，你必须能按 release 查。 如果一个慢请求只发生在某条 trace，你必须能跳到 trace。 如果一个问题只发生在某个业务场景，你必须采集业务字段。
没有这些字段，AI 只能看平均值和日志文本。
它能写一段总结，但很难真正定位问题。
Honeycomb 的提醒是：AI RCA 的上限，不是模型决定的，而是你保留了多少可调查上下文决定的。
Canvas 不是聊天框，而是调查工作区
Honeycomb 现在也在做 AI。
但它的 AI 产品 Canvas 不是一个简单聊天框。
Canvas 更像一个 AI-guided workspace。你可以用自然语言问问题，它会生成 Honeycomb 查询、跑查询、展示图表，并在调查过程中保留上下文。
比如你可以问：
为什么 checkout latency 昨天 spike？ 哪个用户群的延迟更高？ 这个 SLO 为什么触发？ production 和 staging 的数据库查询表现有什么差异？ 这条 trace 里发生了什么？
这里最关键的不是“能用自然语言问”，而是 Canvas 会把查询展示出来。
工程师可以看到它查了什么、用了哪些字段、时间窗口是什么、过滤条件是什么，也可以跳回 Query Builder 修改。
这才是 AI RCA 应该有的样子。
AI 不应该只给最终答案。 AI 应该把调查过程摊开。 AI 应该让人检查、接管、继续追问。
一线工程师不会因为 AI 语气自信就相信它。他要看证据。
MCP 让 Honeycomb 进入 AI 编程现场
Honeycomb 另一个很值得看的动作是 MCP。
通过 Honeycomb MCP，Claude Code、Cursor、VS Code、Amazon Q 这类 AI agent 可以直接查询 Honeycomb 里的 observability data。
这件事比表面看起来更重要。
今天很多 AI coding agent 的问题，不是不会写代码，而是不了解生产环境。
它能读仓库。 能改函数。 能写测试。 能解释接口。
但它不知道线上哪个 endpoint 最慢。 不知道哪条 trace 有 N+1 query。 不知道哪个用户群正在失败。 不知道某个改动上线后 p95 有没有变差。 不知道某段代码在真实流量下怎么表现。
没有生产反馈，AI 编程很容易变成静态猜测。
Honeycomb MCP 的价值，就是把生产行为交给 agent。
这和 Sentry 的方向有点像，但侧重点不同。
Sentry 是从 production issue 走向代码修复。 Honeycomb 是从 production behavior 走向代码反馈。
未来 AI 编程工具一定需要这类能力。只会读代码的 agent 不够。它还要能读懂代码在线上怎么运行。
SLO 是更好的调查入口
Honeycomb 还有一个值得借鉴的地方：它把 SLO 和 BubbleUp 连在一起。
很多团队的告警还是围绕基础设施阈值：
CPU 高了。 内存高了。 磁盘满了。 连接数多了。
这些告警不一定没用，但它们经常离用户体验很远。
SLO 不一样。
SLO 关心的是服务目标和错误预算。比如订单创建成功率、支付链路延迟、搜索返回时间、登录成功率。
当 SLO 开始燃烧，工程师最想知道的不是“哪个机器指标变了”，而是：
失败请求和成功请求有什么不同？
Honeycomb 的 SLO detail view 会提供 heatmap，也能结合 BubbleUp 看 passing events 和 failing events 的差异。
这个方向值得国内厂商学习。
AI RCA 不应该只从告警风暴开始，也应该从客户体验目标开始。
Honeycomb 也没有假装自己能自动修复一切
Honeycomb 的路线很克制。
Canvas 可以帮你查。 BubbleUp 可以帮你找差异。 MCP 可以让 agent 访问生产数据。 Anomaly Detection 可以更早发现异常。 Triggers 和 Burn Alerts 可以触发调查。
但它没有把自己包装成“全自动修复系统”。
这点反而成熟。
因为 RCA 和 remediation 之间还有很长一段路：
差异不等于因果。 因果不等于修复方案。 修复方案不等于可以自动执行。 可以执行也不等于可以绕过审批。 执行之后还要验证效果。
尤其是企业客户，自动回滚、重启、扩容、改配置、发变更，都需要权限、审计和流程。
所以更现实的路径是：
先自动调查。 再展示证据。 再给候选假设。 再推荐下一步。 再由人决定是否执行。
这比一句“自动自愈”更可信。
对国内厂商的启发
Honeycomb 对国内监控、APM、AIOps、AI SRE 厂商有几个很直接的启发。
第一，不要只做告警总结。
告警总结是低门槛功能，但壁垒不高。真正有价值的是让系统自动比较异常样本和正常样本，告诉用户最可疑的差异字段。
第二，把高基数字段当成 RCA 资产。
不要一看到 user_id、tenant_id、request_id、order_id 就觉得是成本问题。它们确实会带来存储和查询挑战，但它们也是定位问题最关键的上下文。
第三，AI 查询必须透明。
让用户看到 AI 生成了什么查询、查了什么数据、得到了什么图表。不要只给一段总结。工程师要的是可验证结论，不是漂亮文案。
第四，给 AI coding agent 提供生产上下文。
国内很多 AI 编程产品正在快速发展，但它们需要监控和可观测性平台提供 trace、日志、SLO、错误、性能、发布和历史事故数据。谁能把这些上下文开放出去，谁就可能成为 AI 研发链路里的关键基础设施。
第五，SLO 和业务指标要成为入口。
不要只围绕机器指标做 AI RCA。客户真正关心的是业务是否受影响，核心链路是否坏了，错误预算是否在燃烧。
第六，私有化和成本治理要提前设计。
高基数数据很有价值，但也很贵。AI investigation 也有成本。国内客户还经常要求内网部署、数据不出域、模型私有化、权限继承和审计留痕。这些不是后期补丁，而是产品架构的一部分。
最后的判断
Honeycomb 提醒我们，AI RCA 不只有一条路。
不是所有 RCA 都要从告警压缩开始。 不是所有 RCA 都要从因果拓扑开始。 不是所有 RCA 都要进入 ITSM。 也不是所有 RCA 都要直接修代码。
还有一条很朴素但很强的路线：
先找到异常请求。 再和正常请求对比。 再找出最不一样的维度。 再基于证据形成假设。 再让工程师或 agent 继续验证。
这条路线不花哨，但非常接近真实排障。
AI RCA 最怕的不是没有答案，而是假装自己有答案。
Honeycomb 的价值在于，它没有急着让 AI 扮演专家，而是先把调查过程做扎实。
对国内厂商来说，这可能是更值得学习的地方：
不要让 AI 先猜根因。先让系统回答，异常请求到底哪里不一样。
编者：秦晓辉，ToB 软件创业者，长期关注监控、可观测性、RCA、SRE 方向。曾主导 Open-Falcon、Nightingale 等开源项目建设。极客时间专栏《运维监控系统实战笔记》作者，公众号 SRETALK 主理人。
觉得有用？望不吝转发点赞 :)
