本文介绍了 云智慧Castrel AI（SRE 智能体）的核心设计理念，包括：假设驱动的调查方法、人机协同机制 和 业务知识沉淀。这一设计旨在帮助运维团队高效实现从“问题发现”到“根因定位或快速升级”的完整闭环。

在深入各模块之前，我们先来看一下云智慧Castrel AI的核心工作流程：

Castrel AI 工作的前提：可观测性上下文（Observability Context）

AI 故障排查的效果，在很大程度上取决于它所能访问的上下文数据是否完整。而一个高质量的可观测性上下文，应覆盖可观测性数据 以及 系统拓扑关系 等关键维度。

三大核心可观测性数据类型

可观测上下文中包含 Metrics（指标）、Logs（日志） 和 Traces（链路追踪） 三类数据：

• Metrics 告诉你“出问题了”，
• Logs 告诉你“具体发生了什么错误”，
• Traces 告诉你“问题发生在调用链的哪个环节”。

三者结合，才能形成完整的故障视图；而仅依赖任何单一数据类型，都难以高效完成故障排查。

下表总结了这三类数据的核心用途及典型来源：

数据类型	用途	典型来源
Metrics（指标）	检测异常、量化问题严重程度	Prometheus、Zabbix、CloudWatch
Logs（日志）	定位具体错误、获取上下文细节	Elasticsearch、Loki、Splunk
Traces（链路追踪）	跟踪请求路径、定位慢调用位置	Jaeger、Tempo、SkyWalking

系统拓扑关系

除了上述三类可观测性数据，AI 还需要理解系统的拓扑结构。这一结构主要由以下两类关系构成：

• 调用关系：描述服务之间的依赖关系（通常由 APM 提供）；
• 部署关系：说明服务运行在哪些主机或容器上（可来自 APM、Zabbix 或 Kubernetes）。

有了调用关系，AI 可以判断故障是上游传播而来，还是当前服务自身的问题；有了部署关系，AI 则能将应用层的异常与基础设施层面的问题（如主机 CPU 飙升、磁盘满等）关联起来。

构建完整上下文的实践建议

在实际实施中，我们建议按以下优先级逐步完善数据接入：

• 优先集成 APM：APM 通常同时提供 Traces、调用关系和部署关系，是最具性价比的数据源。
• 补充基础设施监控：Zabbix、Node Exporter 等提供的主机级指标是重要补充。
• 纳入 Kubernetes元数据：如果使用 K8s，其 Events、Pod 状态和 Deployment 记录都是关键上下文。
  
  综上，数据完整性直接决定 AI 排障能力的上限：数据越完整，AI 分析越准确。缺失任一数据类型，都会显著降低排查效率。

Castrel AI 的核心方法：假设驱动，让 AI 像人类 SRE 一样思考

传统的 AI 分析方式通常是一次性收集所有可观测数据，然后由模型生成摘要。这种“摘要引擎”式的做法存在明显局限：随着数据量增加，模型容易被无关信号干扰，输出质量反而下降。

更高效的方式是让 AI 像人类 SRE 一样思考。具体而言，这一过程遵循一个迭代式的调查循环，包含以下四个关键步骤：

更高效的方式是让 AI 像人类 SRE 一样思考：

• 形成假设：基于告警和初步数据，生成可能的根因假设；
• 验证假设：针对每个假设，查询特定的可观测数据进行验证；
• 递归深入：当某个假设被验证后，继续生成更深层的子假设；
• 剪枝分支：当某个假设被证伪，立即放弃该方向，聚焦其他可能性。

下图展示了一个典型的假设分支调查过程，从“API P95 延迟飙升”开始，逐步定位到“数据库索引被删除”这一根因：

与传统的“摘要引擎”模式相比，假设驱动方法在多个维度上具有显著优势：

维度	传统摘要模式	假设驱动模式
数据处理	一次性收集所有数据	按需查询特定数据
噪声干扰	易被无关异常分散注意力	聚焦因果关系
调查深度	停留在表面症状	递归深入至根因
可解释性	结论难以追溯	拥有完整的假设验证链

正因具备上述特性，假设驱动的调查方式使 AI 的分析过程透明、可追溯——每一个结论都有明确的数据支撑。

Castrel AI 的关键机制：人机协同

传统的 AI 分析通常是单向的：AI 给出结论，用户被动接受或拒绝。而国内主流SRE Agent产品 Castrel 采用的是双向协作机制——AI 与人类在调查过程中持续交换信息，共同推进根因定位。
在这一机制中，双方各司其职：

• AI：
  • 掌握通用知识：理解系统架构、常见故障模式和标准排查方法论；
  • 快速扫描数据：在海量 Metrics、Logs 和 Traces 中迅速定位异常；
  • 并行验证假设：同时测试多个可能的根因方向。
• 人类：
  • 提供业务上下文：例如，“晚上 9 点 CPU 升高是因为营销活动，属于正常现象”；
  • 输入经验知识：例如，“我们的网络不太稳定，上次是 DNS 服务器抖动”。

下面是一个典型的协作场景：

AI：（完成初步假设分析） 
“已验证 3 个假设： 
✓ 数据库慢查询增多 —— 与告警时间吻合
 ✗ 网络延迟 —— 无异常
 ✗ 资源不足 —— CPU/内存充足 
正在数据库方向继续深入调查……”
用户：（看到假设列表，想起上周的变更）
 “DBA 上周修改了订单表的索引。”
AI：（新增假设并验证）
 “新假设：索引变更导致执行计划变化
  → 检查 DDL 变更记录：发现订单表索引于上周四被删除  
→ 对比执行计划：删除前使用索引扫描，删除后变为全表扫描  
→ 时间相关性：索引删除时间与慢查询开始时间一致  
✓ 假设验证通过，确认为根因。”
用户：（验证成功）
 “确认！需要恢复索引。”

这一机制表明：AI 擅长处理海量数据和通用知识，人类擅长提供业务上下文和历史经验。双向协作，使排查效率远超纯 AI 或纯人工。

Castrel AI 的务实设计：退出策略

AI 并不总能直接找到根因——尤其是在数据集成不完整的情况下。但这并不意味着 AI 的分析没有价值。云智慧SRE 智能体——Castrel AI的“退出策略”正是为了在这种情况下，依然交付可操作的洞察。

在多组件问题的深度调查中，递归深挖至真实根因

在复杂事件中，根因可能跨越多个系统，或需要多个步骤才能发现。假设驱动的方法允许 AI 递归地深入调查，直到搜索空间耗尽。
以下是一个 “Pod 频繁重启（CrashLoopBackOff）” 案例：

• 告警：Kubernetes Pod 进入 CrashLoopBackOff 状态
• 第一层分析：
  → 假设：内存不足导致 OOM Kill
  → 验证：检查 Pod events，确认为 OOMKilled
  → 结论：已验证，但这只是表面原因
• 第二层分析（递归深入）：
  → 假设：异常大的请求负载导致内存激增
  → 验证：检查入站流量，发现 Kafka 消息大小异常
  → 结论：已验证，继续深入
• 第三层分析：
  → 假设：上游系统发送了异常大的消息
  → 验证：检查消息来源，发现某些批处理数据包含损坏的大文件
  → 结论：根因确认——上游数据异常导致消息大小溢出

早期版本的 AI 可能会在第一层就停止，给出“Pod OOM”的结论。但这对工程师帮助有限——他们从告警中早已知晓这一点。真正有价值的是找出为什么发生 OOM。

排除干扰项，节省工程师排查时间

即使 AI 无法定位最终根因，其排查过程本身仍具价值。具体而言，它通常能够：

• 指出大致调查方向：例如，“问题很可能在数据库层”或“与最近的部署变更相关”
• 排除无关干扰项：例如，确认网络连通性正常、资源利用率充足、缓存命中率无异常

这种“排除法”本身就能为用户节省大量时间。在传统排查中，工程师往往需要逐一检查网络、资源、缓存等基础设施，才能排除这些可能性。而 AI 可在几分钟内完成这些检查，让用户直接聚焦于真正可能的问题方向。

结构化交接排查成果，避免排查工作从零开始

当 AI 因数据不足无法继续深入时，它可以将已有成果以结构化方式交接给用户，避免排查工作从零开始：

下面是一个调查进展交接的示例：

📋 调查进展交接

⏱️ 分析耗时：5 分钟 | 扫描组件数：12

✅ 已排除项：
• 网络连通性正常（Ping <1ms，无丢包）
• K8s 资源充足（CPU <60%，内存 <70%）
• 缓存命中率正常（Redis 99.2%）

🎯 大致方向：
• 问题集中在 order-service → mysql-cluster 链路
• 数据库性能相关问题的概率较高


⚠️ 需人工确认（缺失数据源）：
• 数据库慢查询日志（未接入）
• 近期 Schema 变更记录（未接入）


正如“退出策略”所体现的，早期的扫描结果不会被浪费。即使 AI 无法给出最终答案，用户也可以从一个更小的排查范围开始，而不是从零开始。
 

Castrel AI 的持续进化能力：知识沉淀

如果没有标准操作流程（SOP）或运行手册（Runbook），AI 在首次遇到某些类型的问题时可能需要进行大量探索。但这些探索结果不应被浪费。

因果验证为何困难？业务语义无法从可观测数据中直接获取

假设驱动调查方法的核心是验证因果关系——判断某个异常是否确实导致了当前告警。然而，因果验证远比看起来复杂，需从以下多个维度综合判断：

验证维度	描述	挑战
时间相关性	异常发生时间是否与告警时间匹配	分布式系统中时间戳可能存在偏差
传播路径	异常是否位于告警的上游/下游链路上	需要完整的调用拓扑图
影响范围	异常影响的资源是否与告警相关	需要理解资源之间的依赖关系
业务语义	异常在业务层面是否合理	需要深入理解业务逻辑

最后一项“业务语义”尤其依赖对客户业务的深入理解。例如：

• 订单服务延迟增加，AI 发现数据库中的慢查询。但这个慢查询是定时报表任务（每天午夜运行，与核心业务无关），还是核心订单查询？只有了解业务的人才能判断。
• 某服务的错误率上升，AI 发现近期有代码部署。但这次部署属于新功能的金丝雀发布（预期存在一定错误），还是一个意外的缺陷？需要了解发布计划才能判断。

这类业务知识无法直接从可观测数据中获取；必须通过知识沉淀来积累。
 

从排查过程中积累知识

为解决上述挑战，当一次事件调查完成后，AI 可以将排查过程总结为知识条目：

• 问题特征：哪些告警/症状组合触发了本次调查
• 排查路径：尝试了哪些方向，最终定位到什么根因
• 解决方案：如何修复，需要注意哪些事项
   

将知识绑定到特定告警和资源，以复用于同类问题

所积累的知识可以绑定到特定的告警类型或资源上。当下次遇到类似问题时：

• AI 自动检索相关知识
• 参考之前的排查方法，快速确认是否为同一问题
• 如果症状匹配，直接提供修复建议；如果不匹配，至少排除该方向

场景示例

以下展示了同一问题的两次排障过程：第二次通过复用第一次积累的知识，将排查时间从 30 分钟缩短至 5 分钟。

第一次排障：

• 告警：order-service P95 延迟增加
• 排查过程：检查网络 → 检查资源 → 检查数据库 → 发现索引问题
• 积累的知识：绑定到 order-service + 延迟类告警

第二次排障：

• 相同告警触发
• AI 自动关联知识：“上次类似问题是由索引引起的，是否应优先检查数据库？”
• 用户确认后，直接跳转到数据库检查，跳过网络和资源排查
• 排查时间从 30 分钟缩短至 5 分钟

正如本节所述，因果验证的准确性依赖于对业务的深入理解。通过知识沉淀，团队的业务经验不再仅存在于个人头脑中，而成为 AI 判断因果关系的重要依据。
 

总结

综上所述，智能运维Agent——云智慧 Castrel AI的事件排障能力可归纳为以下五个关键方面：

能力	描述
可观测性上下文	集成指标（Metrics）、日志（Logs）、调用链（Traces）与调用拓扑
假设驱动调查	提出假设 → 验证 → 递归深挖，而非简单汇总信息
人机协同	AI 扫描数据，人类提供业务上下文与历史经验
退出策略	即使无法定位根因，也能排除干扰项并输出关键发现
知识沉淀	积累业务知识，持续提升后续排障的准确性与效率

上述能力共同服务于一个核心目标：云智慧 Castrel AI 故障排查智能体并非旨在“AI 取代人类”，而是让人机协同的效率远超纯 AI 或纯人工的单独工作方式。