复杂业务场景下 RCA Agent 的探索实践

在 AI coding 工具日益成熟的今天，代码生成能力已被视为接近攻克的领域，但软件工程的全局难题远未解决。本文整理自快手资深服务端架构师郭勇良在 QCon 全球软件开发大会 2026 北京站的分享《复杂业务场景下 RCA Agent 的探索实践》。 郭勇良在分享中详细介绍了一套基于大模型的业务排障体系，拆解业务中面临的四个核心挑战：如何让 AI 理解业务、如何对抗告警噪声、如何衡量不确定性、如何抑制模型幻觉，以及围绕这些挑战所构建的 Agent 架构设计、评测体系与持续演进思路。 以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。 背景和痛点：为什么需要RCA Agent Claude Code 负责人Boris Cherny曾在播客中提出一个观点：编码工作大体上已经被 AI 攻克了。这个判断引发了一个更加深层的问题——软件工程真的被解决了吗？ 从两份调研报告来看，答案是否定的：2025 年的 DORA 报告统计了 AI Coding 落地后的效能变化，个人效能的提升相当显著，但组织效能的提升却相当有限。微软内部的一项调研也给出了类似的方向，他们收集了约六千份工作日时间分配的样本，除去会议、沟通、学习与行政事务，开发和排障仍然是研发人员时间占比最大的两块。一个自然而然的推论就是：如果 AI Coding 带来的红利已经趋于稳定，那么排障就是下一个需要被攻克的生产力瓶颈。 另一组现象也印证了这个判断。OpenClaw 在今年三月份发布了一个重大版本重构，版本上线后大量用户反馈插件出现瘫痪或功能失效。值得留意的是，OpenClaw 的代码绝大部分是通过 AI Coding 生成的。这意味着什么？随着 AI 时代人对代码掌控度的下降，AI 排障有可能从一个可选项演变成一个必选项。当人不再能完整理解自己的系统时，就必须有一个同样由 AI 驱动的诊断体系作为对等的保障。 整个技术系统大致可以切分为三层：基础设施层涉及容器、节点、网络故障，中间件层涵盖 Cache、DB、MQ 的异常，而我们主攻的业务层故障则直接面向核心指标下跌、风暴告警和跨系统传播。业务层有三个显著特点：第一，它是用户体验和营收的直接体现；第二，业务代码迭代极快，高度易变；第三，业务问题无法预测排查步骤。举个例子，同样是视频时长下跌，根因可能来自 Redis 慢查询，可能来自服务自身的 GC，也可能来自下游某个服务引入的 bug，排查路径的不确定性正是业务层排障最大的难点。 业务场景落地挑战 在实际落地过程中，我们面临着四个层层递进的核心挑战。第一个是如何让 AI 理解业务。一个典型的四象限图中，能引起业务指标波动的因素同时包含内源的与外源的、主动的与被动的，信号与噪声高度混合。中小学开学导致的流量自然变化与代码缺陷引发的异常下跌混在一起，共同构成了一个巨大的状态空间。第二个挑战是对抗噪声——在一个告警噪声占比可能超过 75% 的系统中，如何让 Agent 不会在无效信号上耗尽算力。第三个是如何衡量 AI 排障的不确定性本身，即建立可重复、可量化的评测体系。第四个则是直接对抗大模型在数值计算与趋势识别中的幻觉问题。 挑战一：如何让AI理解业务 举个例子，主站某次突然遭遇用户 Feed 流请求量上涨，突破了告警阈值，入口服务 A 作为直接承载 Feed 流的核心服务，它的所有下游可用率都显示正常。但服务 A 的下游依赖极其庞大，横跨几百个服务与多个部门。这种情况下，摆在值班工程师面前有两个层次的问题：首先，这个指标异常本身到底是不是一个问题？它是内部故障导致的，还是纯粹由外部热点自然引发？其次，即便决定把它当问题处理，逐一拉取所有下游业务的同事来排查，显然不现实。 事实上的根因出在推荐质量的下降上——信息流质量下降导致用户反复刷视频，引起了请求量的异常上涨。故障传播链非常复杂：入口服务 A 调用了下游 B，B 之所以没有表现出异常，是因为它内部存在兜底降级逻辑，但 B 所依赖的下游部门服务 E 发生了 Core Dump。而 E 发生 Core Dump 的原因，是其请求的另一个服务 F 出现了接口字段缺失，最终归因于 F 服务的配置变更引入了先前未走过的逻辑路径。 这个案例中出现了几个反常识的地方。一般来说推荐质量下降会导致用户请求量降低，但这个问题恰恰相反地引发了请求增加。整条异常传播链在 A 调 B、E 调 F 两个节点上被中断，指标层面看起来一切正常，依赖 Metrics 根本无从关联。跨部门协同更是人为增加了难度——主站的同学不了解下游部门内部的变更事件。这个问题最终耗费了大量人力，排障群一度达到一百多号人。 用传统的监控三板斧——Trace、Metrics、Log，在这个案例中至少存在两个明显的断点。第一个断点出现在 A 调 B，请求正常，Metrics 无法关联，只能依赖业务经验，主站同学不得不去找部门B的同学人工确认。第二个断点更隐蔽：E 调 F 的故障由接口字段缺失引发，请求也是正常的，且由于这个逻辑此前没有走到过，很可能根本没有打 Log。这个断点的发现同样依赖内部同学的人工沟通。 由此得出的结论非常清晰：如果想让 Agent 去做这件事，必须在技术指标之外理解业务，否则永远无法跨越这两个断点。 怎么做到？除了常规的 Trace、Metrics、Log 与变更事件外，我们引入了业务代码GIT。因为代码是唯一真实的文档，所有系统都构建在代码之上。最初的实践非常直接，引入 Coding Agent 对代码进行实时分析。一开始使用的是 Claude Agent SDK，分析一个代码库的时间大约三十分钟，这在排障场景中显然不可接受。切换到 PI Coding Agent 后，单库任务分析时长降低到五分钟左右。但即便降到五分钟，实际场景中依然有效率瓶颈。一次完整的业务排障任务通常涉及一条链路上多个服务，而且 Java 系统中还有大量 SDK 的底层依赖需要梳理，往往需要同时分析三到五个库，总共需要十五到二十五分钟，这个时间对于故障响应来说依然太长了。 问题的根源在于，代码虽然是唯一真实的文档，但它是抽象层次极低的东西。低抽象必然带来低效率。人在排障时，即使是服务的维护者，也绝不可能记住每一行代码，人脑中对业务代码进行了一定程度的抽象。如果让 AI 去理解，就必须降低它的认知成本。 我们的做法是建立一层代码抽象，称之为“业务资产”。比如对错误码标注其业务语义，对 Metrics 含义进行业务化描述，建立指标之间的拓扑关系——以 Feed 流场景为例，下游 推荐服务 可用率降低可能导致上游服务兜底率变化，最终引起 Feed 下发量的变化。还有一些开关配置会直接影响业务逻辑，我们也把它们的影响地图建立起来。这些资产的构建有两种模式：一部分通过离线沉淀，用 Coding Agent 离线生成核心代码的关系描述，放入知识库并以 Markdown 文档形式存储；另一部分则在排障过程中按需生成，Agent 实时分析完某个任务后，将其沉淀为 Skill，纳入知识库。通过这两种方式，业务资产就转起来了。 总结起来，解决“让 AI 理解业务”这一挑战的本质，就是消除人和 AI 之间的上下文代差。AI 获取传统监控数据相对容易，但