本文整理自 QCon 北京 2026 郭勇良分享《复杂业务场景下RCA Agent的探索实践》，通过AI音视频总结工具 Ai好记
进行转录整理，以下为视频转文字整理后的会议笔记内容。

AI Coding 解决了之后，下一个要解决的问题是什么？快手的答案是排障。

在复杂业务场景里做 Root Cause Analysis（RCA），靠人靠传统监控都不够，团队把 AI 排障从可选项做成了必选项。

本文把他们在业务视角下做 RCA Agent 的三个核心挑战和解决思路讲透，对做运维、做可观测、做 AI Agent 落地的人很有启发。

为什么 AI 排障会成为必选项

CloudCode 负责人曾在一个播客里说，编码工作大体上已经被攻克了。那软件工程真的被解决了吗？

从两份调研看，2025 年 DORA 报告显示 AI Coding 落地后个人效能提升显著但组织效能有限；

微软对约 6000 名开发者的统计显示，除会议沟通外，开发和排障是占比最大的两块。

所以结论很直接，AI Coding 解决后，排障就是下一个要解决的目标。加上 OpenClaw 这类大量由 AI 生成代码的平台，人对自己代码的掌控在下降，AI 排障就从一个可选项变成必选项。

业务层排障的四个挑战

他们将系统分为基础设施层、中间件层、业务层三层，主要面向业务层，也就是核心指标下跌的问题。业务层排障具有三个显著特点：

1. 直接体现用户体验和收入：业务指标（如请求量、成功率、时长）直接影响用户感知和公司收益。
2. 业务代码迭代快、易变：功能频繁上线，代码变更快，故障模式也随之快速演变。
3. 问题无法预测排查步骤：同一个现象（如"时长下跌"）的根因可能千差万别，可能是 Redis 慢查询、服务 GC，也可能是下游服务引入了 bug。在落地 AI 排障时，团队主要面临以下四个挑战：

挑战一：如何让 AI 理解业务

引起业务指标波动的事件类型复杂：

• 来源多样：既有内源（如代码发布、配置变更），也有外源（如节假日、热点事件）。
• 性质混杂：既有主动操作（如压测），也有被动触发（如依赖故障）。
• 信号与噪声并存：很多事件（如中小学开学引起的流量自然变化）不一定会导致故障。这些事件构成了一个巨大的状态空间，让问题排查变得异常复杂。

挑战二：如何对抗噪声

一个系统中超过 75% 的告警是噪声，真正需要关注的不到四分之一。告警疲劳严重，且让 AI 处理所有告警成本极高（单次推理消耗数十万至上百万 Token）。

挑战三：如何衡量生产级系统的不确定性

生产环境充满 edge cases 和 silent error，确定性因素在 AI 推理中可能变为不确定性，同一问题多次输入可能产生不同推理路径，微小的变量变动可能导致结果巨大偏差。

挑战四：跨部门、反常识的复杂链路定位

以一个真实案例为例：某天主站 feed 流请求量突破告警阈值上涨，入口服务 A 直接承载流量，下游可用率均正常，但 A 依赖数百个服务、横跨多个部门。

最终根因是内部推荐质量下降导致用户反复刷视频，异常沿着 A → B → E（Coredump）→ F（配置变更引入 bug） 这条链传播。这个案例具有反常识（推荐质量下降反而请求上涨）、异常传播链路中断、涉及跨部门协同等特点，排查群拉了 100 多人，传统监控工具难以关联。

让 AI 理解业务，消除 Context 代差

用传统监控三板斧（trace、metrics、log）排查上述案例，至少存在两个断点：

1. A 到 B 的请求在 metrics 上表现正常，无法直接关联异常。
2. 推荐系统内部 F 调用 F 因字段缺失，没有留下有效日志。
   最终都依靠人工沟通才确认问题。因此，要让 AI（或人）有效排查，必须在技术指标之外深入理解业务。核心思路：引入代码作为“唯一真实的文档”

• 初期尝试：使用 Claude Agent SDK 分析代码，单个代码库需 30 分钟。
• 优化后：换用 OpenClaw 内核，单库分析时间降至 5 分钟。
• 瓶颈：一次完整排查需跨 3 到 5 个代码库，总时间仍需 15-25 分钟，无法满足实时性要求。

根本问题与解决方案
问题在于代码的抽象层次太低，直接让 AI 阅读效率低下。解决方案是构建业务资产，以消除人与 AI 之间的 Context 代差。

业务资产的分类

1. 业务语义标注的 Code Value：为关键代码段添加业务含义注释。
2. 指标之间的拓扑图谱：描绘各业务指标间的依赖与影响关系。
3. 开关变更影响地图：记录功能开关、配置变更对业务指标的影响范围。

业务资产的建立方式

1. 离线沉淀：通过 Coding Agent 提前将核心代码关系分析、沉淀为 Markdown 知识库。
2. 实时生成与沉淀：对于未提前构建资产的部分，让 Agent 在排查时实时分析并生成，随后沉淀到知识库中。

通过这套机制，研发人员脑中的代码逻辑、指标关系、业务常识（如“大主播开播会增送礼请求”）得以系统化地“喂”给 AI，使其能在更高的抽象层次上工作。

对抗噪声，告警置信度评估加证据分级

挑战：告警泛滥与成本压力

• 系统内超过 75% 的告警是噪声，有效告警不足 25%。
• 告警疲劳：团队曾复盘一个 P2 故障，指标已波动告警，但值班人员因该告警 7 天内触发 15 次而直接静默。
• 成本不可控：若让 AI Agent 处理所有告警，单次完整推理需消耗数十万至百万 Token。以快手主站月均两三万条告警计，全处理则需每月 100 亿 Token，年化成本达数百万，且 ReAct 交互次数难以控制。

解决方案：两层过滤机制

第一层：告警置信度评估

通过一个轻量的告警置信度评估 Agent/Workflow，为告警提取“画像”，依据包括：

• 周期性规律：是否在特定时间规律性触发？
• 阈值偏离程度：偏离历史基线多少？（例如，可用率平时降至 98% 与某天突然降至 60% 意义不同）。
• 恢复时间：告警是否自动快速恢复？
• 服务分布聚集情况：是否集中在某个服务或集群？
  通过此层过滤，可筛除大量低置信度、周期性或轻微偏离的告警。

第二层：排障推理阶段的证据分级

在剩余的告警中，排障推理仍会关联大量噪声（例如，某个服务恰逢 GC 但不足以影响核心指标；发布高峰期一小时内关联出 500 多个变更）。团队借鉴循证医学的“证据金字塔”，建立证据分级体系：

1. L5 原始信号：最底层的原始 metrics、trace、log 数据。
2. L4 背景上下文：外部事件趋势、静态服务依赖图、工程师经验等。
3. L3 单点观测证据：单一的、未关联的指标异常、日志错误等。
4. L2 多源融合证据：通过 trace 或拓扑关联后形成的证据链（如链路关联变更、匹配历史故障模式）。
5. L1 因果推断证据：能直接建立因果关系的证据（如指标拓扑 DAG 关联、源码层面实锤、故障时间点与变更直接匹配）。
   这套体系引导 AI 优先采信高层级证据，控制推理路径，有效对抗噪声。

衡量不确定性

第三个挑战是怎么衡量生产级系统的不确定性。

跑 happy path 很容易，但生产环境要消除 edge cases 非常难，存在大量 silent error。

原因是确定性因素在 AI 里变成不确定性,同一问题多次输入可能推理出不同路径,庞大的业务系统中任一变数变动都会导致结果巨大偏差,类似蝴蝶效应。

这提醒我们,生产级 RCA Agent 不能只看 demo 漂亮,要对不确定性有系统性的度量和兜底。

总结

快手这套 RCA Agent 实践,核心是用业务资产消除人和 AI 的 Context 代差让 AI 理解业务,用告警置信度评估加循证医学式证据分级来对抗噪声,再对生产环境的不确定性保持清醒。

对做可观测、做 AI Agent 落地的团队,这套"先理解业务、再对抗噪声、再度量不确定性"的路径很有借鉴意义。部分细节和后续数据见原场次内容。

常见问题

1、RCA Agent 为什么必须让 AI 理解业务?
因为排查业务层问题只靠监控指标不够,还必须理解代码逻辑、指标关系、业务常识,否则在反常识、链路中断、跨部门场景下无法定位根因。

2、如何降低 AI 排查代码的成本?
通过建业务资产,把代码语义、指标拓扑、开关影响地图沉淀成 Markdown 知识库,让 AI 在更高抽象层次上工作,避免逐行读代码。

3、告警太多了 AI 全处理不现实怎么办?
先加一层告警置信度评估做画像过滤,把真正需要关注的异常筛出来,再用证据分级引导排障推理,控制 Token 成本和时间。

4、RCA Agent 怎么应对错误结论?
对生产环境的不确定性保持清醒,结合证据分级和因果推断,对高置信结论再人工确认,避免 silent error 误导新同学。

以上内容由 Ai好记 转录整理。
Ai好记 是一款音视频转图文笔记的AI音视频转录总结工具，支持解析B站、抖音、小红书、小宇宙等平台链接及本地/网盘音视频文件，转录后自动视频转文字生成精华速览、思维导图和结构化笔记等内容形式，帮助你把几小时的视频内容变成可搜索、可复习的图文笔记。