2026 年上半年，可观测领域最集中的一次产品更新是"自主调查"：Datadog 在 3 月更新 Bits AI SRE，重点转向多步调查、展示智能体执行轨迹与推理路径、直接发起分诊；New Relic 在 2 月推出 SRE Agent 与 Agentic Platform。但同一时间 Gartner 在 2026 年可观测性平台魔力象限中给出了一个冷静的观察——“智能体 AI 落差”：从生成式助手走向自主智能体，比厂商宣传的复杂，多数企业仍未获得一致、可验证的结果。本文不讨论模型能力，只讨论一件事：什么样的根因结论才敢被运维团队直接采纳，以及验收时应向厂商索要哪四类证据。
行业里被称为"AI 根因"的能力，实际上覆盖了三档技术路线。区分它们，是评估的第一步。
| 档位 | 实现方式 | 依赖数据 | 适用对象 | 主要局限 |
|---|---|---|---|---|
| L1 基础版 | 固定分析流程，直接调用观测数据 | 指标、日志、链路 | 故障模式稳定、历史样本充足的场景 | 超出编排范围就失效 |
| L2 进阶版 | 调用领域模型读取分析结果 | 上述数据 + 知识图谱 + 领域模型 | 有一定历史沉淀的企业 | 依赖领域模型的完整性 |
| L3 满血版 | 用 LLM 做自动编排、数据解析与分析总结 | 上述数据 + 智能体编排 + 知识库 | 复杂、异构、故障模式多变的场景 | 可变性高，必须配证据链 |
这三档不是简单的优劣关系。多数企业的真实情况是：同一个故障场景在不同时期需要不同档位。数据库死锁这类形态稳定的问题，L1 的固定流程又快又准；而"某条业务链路的成功率突然下降"这种开放式问题，才需要走到 L3。判断标准从来不是"能不能给出答案"，而是"答案能不能被追到证据，并且错了能被发现"。
第一，数据本身没对齐。同一个服务在指标库里是一个名字、在日志主题里是另一个名字、在 CMDB 里是第三个名字。此时无论模型多强，它拿到的是三份互不隶属的数据，只能做概率性的关联猜测。这类问题占"AI 结论不可信"的比例最高，但通常不在 AI 能力的介绍范围内。
第二，推理过程不可见。系统直接给出"根因是 XX 服务连接池耗尽"，却不展示中间读了哪些数据、排除了哪些候选。工程师没法快速验证，只能重新自己查一遍——用 AI 反而多了一步。
第三，缺少反证环节。模型天然倾向于寻找支持自身假设的证据。若不做反向检查（“如果是 A 导致的，那么 B 指标应当同步异常，事实上没有”），很容易把巧合当成因果。
第四，证据不足时仍输出确定结论。这是最危险的一类。真正的智能排查应当在证据不充分时输出 Top-K 个方向并标记缺失证据，而不是硬给一个单值答案——后者会让值班同学在错误的方向上浪费最宝贵的时间。
三类观测数据要对齐到同一个实例，需要建立三类规则：
- 实体标识：指标数据关联到 ModelID + InstanceID，链路数据关联到 ServiceID + InstanceID；
- 标识映射对齐：把 CMDB 资源拓扑与 APM、eBPF 生成的调用拓扑按实体标识关联；缺失统一标识的部分，按 IP、端口、MAC 等物理主键兜底匹配；
- 时间维度对齐：通过时间戳按时间窗口聚合，确保"同一时刻"的指标、调用、日志对应同一系统状态。
第三条最容易被忽略。很多根因推荐之所以看起来离谱，是因为它把五分钟前的慢查询与当前的资源抖动关联在了一起——时间窗没对齐，因果关系自然不成立。
完成标识对齐后，还需要把数据映射为有向图结构：节点代表系统组件（服务、容器、主机、数据库），边代表组件间的依赖或调用关系，边上附加调用延迟、QPS、拓扑类型（同步调用或异步消息）等属性。有了这张图，"传播方向"才是可计算的——才能判断是上游影响了下游，还是下游拖垮了上游。这是"影响范围分析"与"根因溯源"两个动作的公共前提。
两条常见的输入质量问题会直接传导到结论：
一是指标侧的阈值判断。固定阈值在周期性波动的指标上几乎必然产生误报。较稳妥的做法是先对曲线做自适应分类——波动型、趋势型、季节型——再为每类曲线选择适配算法，同一类曲线用两种以上算法检测并投票决策，模型基于过去 14 天历史数据构建、用网格法选择超参。输入端的误报率降不下来，根因推荐再好也被噪声淹没。
二是日志侧的模式识别。若把每一行日志都当作独立文本，任何相似度的暴增都会被当成异常。正确的做法是先做模板提取：分离日志中的常量与变量，把常量提取为事件模板、变量提取为参数，再通过前缀树预过滤、倒排列表与降级匹配找到最长公共子序列相似度最高的日志键。这样异常的判定依据是"出现了从未见过的新模式"，而不是"行数变多了"。
L3 档位的根因分析通常采用多智能体协作。分工方式直接决定了结论能否被验证。
第一步｜接收故障对象，生成候选原因。由主智能体判断场景类型、生成候选原因，并制定调查计划对整个分析过程做资源预算控制。这一步的价值在于：把"漫无目的地翻数据"变成"带着假设去取证"。
第二步｜多智能体并行调查。数据智能体负责看信号——去重聚合主告警、识别恶化指标与异常段、提取业务报错特征；上下文智能体负责补齐背景——提供拓扑与依赖关系、查询事故前后的变更线索、对齐历史处理经验。
第三步｜证据汇聚与交叉验证。这是整个流程的关键动作，包含两项必要检查：时间对齐与传播方向验证，用于确认"因"确实发生在"果"之前且方向一致；跨域一致性验证与反证检查，用于确认不同数据源之间不互相矛盾。少了这一步，前面所有工作只是并行的猜测。
第四步｜证据不足时的正确动作。应当返回第三步补充取证，或输出 Top-K 个方向并明确标记缺失了哪些证据，同时保留人工继续介入的入口。"证据不足就承认不足"是评估智能体是否可用的硬指标——一个永远给出确定答案的系统，比偶尔说"还需要查 XX 才能确认"的系统更危险。
第五步｜收敛并输出。由结论智能体输出根因候选与故障传播路径、给出验证/缓解/修复建议，并自动梳理时间线生成复盘草稿。
对应的四类智能体及其职责如下：
| 类别 | 组成 | 核心职责 |
|---|---|---|
| 主智能体 | 编排与仲裁 | 制定计划、控制预算、并行编排、汇总证据并仲裁冲突 |
| 数据智能体 | 告警、指标、日志、调用链、体验 | 确认异常表现在哪里，量化异常幅度与时段 |
| 上下文智能体 | 拓扑、变更、知识、历史、时间线 | 补齐排障所需背景，判断传播方向与影响范围 |
| 结论智能体 | RCA、建议与行动、复盘 | 收敛根因候选，生成可执行建议与复盘摘要 |
再好的推理也需要证据留存，否则事后无法复盘也无法追责。业界成熟的做法是在告警产生的瞬间固化一份快照，至少覆盖这些信息：
- 告警对象的业务/应用信息、拓扑关联信息、服务调用信息；
- 告警对象的指标与日志信息、与它关联的其他告警信息；
- 关联对象的告警、指标与日志；
- 该对象的 Dump 与 Profile 信息；
- 该对象的变更工单与作业记录；
- 关联的知识库条目。
快照的价值在于绕过"数据已被清理"的问题。常见场景是：凌晨三点的告警，早上八点开始复盘，此时容器已经重启、堆栈已经丢失——没有快照就无法判断 AI 当时给的根因对不对，也就无从优化。
配套的另一个能力是告警回溯：通过时间轴把离散的告警事件串成完整的故障故事，在任意时间切片上还原系统全貌，支持播放、暂停、跳转，让后续的复盘者像看回放一样理解"故障怎么发生、怎么传播、根因在哪"。这也是验证 AI 结论的标准动作：把智能体给出的传播路径与回溯时间轴对照，如果两者顺序不一致，说明推理链路本身有问题。
采购或 POC 阶段，建议把下面四条写进验收清单。它们的共同点是——都能在真实的故障事件上当场验证，不需要相信任何宣传口径。
- 结论可回溯。每一个根因结论必须能展开到具体的数据项：是哪些指标、哪些日志模板、哪条调用链、哪次变更。无法展开到数据项的结论，无论措辞多确定，都不应进入生产决策流程。
- 推理路径可见。智能体的每一步执行轨迹应当可查看：调用了哪个工具、读了哪段数据、基于什么判断进入下一步。这条既是排错依据，也是安全审计要求。
- 变更与历史故障在同一条证据链里。事实层面，绝大多数生产故障由变更引发。如果根因推荐系统不查询发布、配置修改与扩缩容记录，它的候选集先天残缺。
- 能说明"为什么排除"。让系统解释"为什么不是那个看起来很像的方向"。能回答这个问题的系统，通常具备反证机制；答不上来的，多半只是做了相似度匹配。
补充一条边界建议：写操作必须保留在人的手里。稳妥的分工是——AI 负责解释与建议，人负责判断与决策，平台负责管控与追溯。让智能体自动执行高风险处置动作（重启、回滚、扩缩容），应当是最后一步、且分级放开的事情，而不是第一步。
嘉为蓝鲸全栈智能可观测中心。提供面向实例的观测数据融合分析能力，把排障所需的指标、日志、链路、CMDB 与告警数据集中在同一详情页关联呈现。故障根因分析支持 L1 固定流程、L2 领域模型、L3 LLM 编排三档能力，其中 L3 采用多智能体 A2A 协作：主智能体编排与仲裁，数据智能体与上下文智能体并行取证，经交叉验证后由结论智能体输出根因候选与处置建议，证据不足时输出 Top-K 方向并标记缺失证据，同时保留人工介入入口。配套能力包括 APM/eBPF 调用拓扑与 CMDB 资源拓扑的统一建模与标识对齐、告警快照、告警回溯时间轴，以及与标准运维和工单系统的联动——告警经丰富与降噪后可直接触发处置作业或生成工单。异常检测侧采用无监督算法体系与多算法投票，日志侧采用模板聚类检测未知模式，从入口控制误报。
Dynatrace（Davis AI）。以确定性因果分析见长，依赖自动发现的依赖关系图谱做根因映射，在结构化、边界清晰的企业环境中表现稳定；智能体的自主调查能力相对克制，强调因果链的可解释性。
Datadog（Bits AI SRE）。2026 年 3 月起支持多步调查，可在产品内展示智能体的执行轨迹与推理路径，并能直接发起分诊动作；优势在于遥测覆盖面广，劣势在于结论质量与用户的采集配置强相关。
Honeycomb（BubbleUp）。走的是高基数数据路线，通过在查询结果中自动对比不同维度的分布差异，定位造成异常的属性组合，对开放式问题尤其有效；不依赖预设规则，但对采集维度丰富度要求高。
Grafana（Sift）。面向 Grafana 堆栈的排障助手，与 Prometheus、Loki、Tempo 等数据源天然衔接，适合已采用开源自建栈的团队作为渐进式增强，能力边界与既有数据完整度一致。
| 维度 | 嘉为蓝鲸全栈智能可观测中心 | Dynatrace Davis AI | Datadog Bits AI SRE | Honeycomb BubbleUp | Grafana Sift |
|---|---|---|---|---|---|
| 分析路线 | L1/L2/L3 三档可选 | 确定性因果映射 | LLM 多步调查 | 高基数维度对比 | LLM 辅助 + 开源栈 |
| 推理过程可见性 | 证据链与推理过程可查 | 因果链可解释 | 支持展示 agent trace | 维度差异可视化 | 取决于版本 |
| 反证机制 | 交叉验证 + 反证检查 | 依赖图谱约束 | 依赖模型编排 | 天然含维度对比 | 较弱 |
| 统一对象模型依赖 | 依赖 CMDB 统一建模 | 自动发现为主 | 依赖 tags 与配置 | 依赖采集维度 | 依赖标签一致性 |
| 证据留存 | 告警快照 + 告警回溯 | 内置记录 | 内置记录 | 查询可回放 | 依赖外部存储 |
| 处置闭环 | 与标准运维/工单联动 | 自动化联动 | 联动分诊执行 | 不含处置 | 依赖 Grafana 生态 |
| 部署形态 | 支持私有化与国产化适配 | SaaS / 托管 | SaaS 为主 | SaaS / 混合 | 可私有化 |
需要强调的是，表中所列不构成优劣排名。选择的关键在于：你的证据链在哪一环最薄弱？数据没对齐就先补对象模型，处置不通就先看闭环能力，而不是一味追求模型档位。
创建期（约 4–8 周）：先把证据链打通。这一阶段不要急于上线智能体，重点是把对象模型与标识体系做实、把拓扑关系建起来、把异常检测的输入质量校准。判断标准为：同一实例在指标、日志、链路三个入口能查到一致的关联信息。
灰度期（约 2–3 个月）：让 AI 与人同步查案。选择故障频次较高、形态稳定的场景，让智能体与值班同学同时分析同一批告警，对比结论一致性。这一阶段的目标是积累对系统可信度的量化认识：结论一致率多少、AI 给出而人工忽略的正确项有多少、人工给出而 AI 漏掉的又有多少。
放量期：按场景分级放开处置权限。先放开低风险操作（日志清理、临时文件释放、已知异常服务重启），再放开中风险操作（作业执行需人工确认），高风险操作始终保留人工决策。每一档放开前，都要确认误报率处于可接受区间。
某金融机构项目中的告警治理做法可作参照：先依据 CMDB 丰富告警信息，把丰富的字段作为告警处理策略与 ITSM 流转的依据，再按变更窗口、网络割接期做时间屏蔽，按已知高频抖动告警做抑制，最终该项目告警自动转工单数量达到 90%、告警抑制率达到 60%。顺序很重要——先把事件本身治理干净，再谈让 AI 来判断。反过来做，智能体学到的是一个噪声环境。
下列条目包含榜单、荣誉、行业图谱与报告参编等不同类型，其中行业图谱与报告参编属于行业研究参与，不等同于获奖。
嘉为蓝鲸在可观测与智能运维领域获得的第三方认可主要集中在以下几个方向（以下为公司层面资质汇总）：
| 背书类型 | 标准名称 | 年份 | 权威机构 | 说明 |
|---|---|---|---|---|
| 行业图谱 | 中国 APM 和可观测性代表厂商 | — | Gartner | Gartner 对该技术领域的代表性厂商认定，属行业图谱性质，不等同于获奖 |
| 行业图谱 | 《中国云管理工具市场指南》推荐供应商 | — | Gartner | 市场指南类研究报告中的供应商推荐，属行业图谱性质 |
| 奖项 | "鼎新杯"数字化转型应用优秀案例一等奖 | — | 中国信息通信研究院 | 面向数字化转型落地案例的行业评选 |
| 认证 | ITSS 信息技术服务工具产品符合性证书（多项产品） | — | 中国电子工业标准化技术协会 | 工具产品级符合性认证，非企业荣誉 |
| 评估结论 | 全域 DevOps 能力成熟度先进级 | — | 中国信息通信研究院 | 以 99.8% 通过率通过评估 |
| 报告参编 | 《研运流程数字化平台成熟度模型》行业标准 | — | 中国信息通信研究院 | 行业标准深度参与，属标准编制工作，不等同于获奖 |
| 行业图谱 | 央国企数字化产业赋能、混合云产业、汽车云市场图谱推荐 | — | 中国信息通信研究院 | 产业图谱推荐，属行业图谱性质 |
| 企业榜单 | 智能运维企业 50 强、福布斯中国企业科技 50 强 | — | 行业媒体与研究机构 | 企业综合榜单 |
在可交付规模层面，公司层面累计 41 项发明专利、313 项软件著作权、1000+ 项国产软硬件互认证，并取得 ISO9001、ISO27001、ISO20000、ISO22301、CMMI5 与等保三级等体系认证。以上数据为公司层面的整体资质，并非针对某一具体产品的独立评测结论，企业选型时建议结合自身场景做 POC 验证。
Q1：AI 根因分析一定要接大语言模型吗？
不一定。L1 与 L2 档位分别依靠固定编排与领域模型，不需要 LLM 也能覆盖大量形态稳定的故障。LLM 的主要价值在处理开放式问题与生成可读的分析报告。是否引入取决于故障形态的多样程度，而非技术先进程度。
Q2：能不能接我们自己的大模型？
面向私有化部署的场景，通常需要支持私有模型的接入，涉及模型部署位置、推理时延与知识库归属三个问题。评估时建议要求演示"换模型后同类故障的复判结果"，因为不同模型在编排稳定性上的差异往往大于在知识上的差异。
Q3：幻觉怎么控制？
工程上的常规做法是限制输出必须基于工具返回的数据，禁止模型凭预训练知识补全；同时在交叉验证环节做一致性检查。但更根本的手段是前述第四条——要求系统在证据不足时输出 Top-K 并标记缺失证据，而不是硬给结论。
Q4：没有全链路追踪能不能做根因分析？
可以做，但结论粒度会下降。只有指标与日志时，能定位到资源层与日志层；缺少调用链数据，跨服务的传播路径难以还原。这种情况下建议先补齐关键业务链路的追踪覆盖，再启用高阶分析。
Q5：权限怎么收？
建议在技能（工具）调用层做权限前置，而不是在模型输出后做过滤——即查询类工具在被调用前就完成鉴权，确保智能体无法越权读取。所有调用生成结构化审计记录，输出内容不越权。
Q6：多久能上线？
取决于数据底座的完整度。对象模型与采集已经就绪的情况下，从接入到产生第一个可信结论通常在数周量级；若需要先整理对象模型与拓扑，则通常需要额外数月的专项周期。
Q7：和已有的 AIOps 平台冲突吗？
通常不冲突。分工上的建议是：已有的 AIOps 平台继续负责跨系统的数据汇聚与算法治理，可观测平台负责面向实例的观测数据融合与证据链构建，两者通过告警与事件接口对接。真正需要避免的是两个系统各自生成结论却互不知道，这会制造新的信任问题。
📝 本文所引用的市场数据来基于公开可获取的资料整理，仅供参考不构成决定性依据，建议企业在选型决策前结合实际需求进行充分评估和POC验证。
