复杂业务场景下 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 获取传统监控数据相对容易，但研发脑中同时运转着大量其他信息——代码逻辑、指标关系、业务常识，比如主播开播后可能引起送礼请求的增加，以及外部事件。这些与代码逻辑一样，如果想让 AI 去排查，就必须将这些信息全部提供给它。

挑战二：如何对抗噪声

在实际执行中，告警噪声是一个让人极其疲惫的问题。从统计来看，系统中大部分告警是没有用的，告警噪声占比可能超过百分之七十五，真正需要关注的不到四分之一。

告警噪声带来的危害是实实在在的。我们内部曾复盘过一个 P2 级别以上的故障，发现故障发生后大约十分钟，某个指标已经发生波动并发出告警，但当时的值班人员直接点击了静默。此后该指标在十五分钟之内快速偏离到严重程度，却没有人感知，原因正是这个告警在七天之内报警超过十五次，值班人员已经产生了告警疲劳，基本看都不看就直接静默。

但如果让 AI 全量处理所有告警，又会产生新的问题。内部试验下来，Agent 在 ReAct 循环中完成一次完整推理的 Token 消耗大约在六、七十万到一百多万 Token 之间。快手主站每个月的告警事件总量大概在两三万左右，如果让 AI 处理所有告警，每月 Token 消耗接近一百亿，年化成本达到几百万人民币。除了成本问题，ReAct 循环的交互次数不可控，延迟也无法保证。

我们的解决方案是分成两层。第一层引入一个非常轻量的告警置信度评估 Agent 或 Workflow。它的任务是提取告警的“画像”——包括告警的周期性规律、每次触发后阈值偏离程度、恢复时间、服务分布以及曲线的聚集情况，将这些作为统计数据进行评估。举个例子来说明偏离分析的价值：某个可用率告警每天可能都突破四个九到 98%，有一天突然降到 60%，显然需要关注；如果仍然只是到 98%，可能就不需要关注。周期性同理：如果告警每天凌晨都报警，其置信度就相对低；假如某天突然下午开始报警，那这很可能是一个明显的异常信号。

经过置信度评估筛掉一部分噪声后，下一步就是对保留下来的问题进行排障推理。然而即便经过了初步过滤，推理阶段仍然存在大量噪声。系统中充斥大量技术指标的波动，比如服务恰好发生了 GC，但又不足以引起核心业务指标的波动，这些都会造成 Agent 的误判。另一个典型的噪声来源是变更事件：在发布高峰期，一条核心服务的关联链路上可能在一个小时内关联出五百多个变更，这些变更绝大多数都不会导致故障，但当故障真的发生时，Agent 必然会拉到这么多变更，怎么判断它们与告警到底有没有关系？这些都是潜在的误判信号。

我们的应对方法是引入类似循证医学的证据金字塔，建立证据分级体系。这个思路来源于医院看病的场景——医生每天接手大量病例，其中很大一部分病人可能仅仅因为焦虑来就诊，并没有什么实质性疾病，所以医生首先需要过滤噪声。而对于真正有病的病人，则需要进一步排查病因。医学在这个问题上已经是一套非常严谨的科学，有成熟的最佳实践，我们完全可以拿过来借鉴。

在这个金字塔中，最下层是原始信号，往上一层是背景上下文——比如外部趋势热点、静态服务依赖关系、工程师的经验。再往上是单点观测数据，比如单个 Metrics 异常或单服务指标异常。当这些单点异常通过 Trace 或拓扑建立关联时，就组成了多元融合证据，例如链路上关联的变更、匹配历史故障模式等，这构成了更坚实的一层。最上层是直接因果推断：指标之间有明确的有向图拓扑关系，或在源码层面已经实锤，或故障服务恰好对应时间窗口内的直接变更，这些都被认为是直接因果推断。

挑战三：如何衡量不确定性

目前在生产级 AI 系统中存在一个共识：跑一个 Good Case 非常简单，给出几个 Demo 很容易，但真正投入生产环境时，消除 Bad Case 极为困难，存在大量的 Corner Case 与 Silent Error。一位 AI 初创公司 CTO 曾在发文中提到这样一个观点：Demo 演示时只需找到正确路径即可，但在生产环境下，百分之九十的情况都是坏情况。为什么会出现这种情况？因为此前在程序中的确定性因素，在 AI 中变成了不确定性因素——同一个问题多次输入推理，可能形成不同的推理路径，结论也可能不一样。而且在一个极其庞大的业务系统中，影响因素非常多，任何一个变量变动都可能导致结果出现巨大偏差，类似于蝴蝶效应。

我们有一个非常真实的案例。最初做 Agent 时，我们想要召回“单点抖动”问题，因为大量 RPC 可用性告警可能是由于下游某个 Pod 的单点抖动造成的整体指标波动。做法比较简单，引入传统异动分析算法并增加下钻维度，将这个工具提供给 Agent 使用。然而加上这个工具之后，单点问题虽然被成功召回了，整体 Case 的准确率反而劣化了。原因在于，单点问题是一个极其高频的问题，在一个几千 Pod 的集群中发生概率很高，当核心业务指标波动时，往往伴随有单点问题。Agent 在排查访问量下降时找到单点问题，在排查搜索量下降时也找到单点问题，于是错误地建立了因果关系。这个案例的根因很清楚：它跟传统软件的确定性修复不同，优化了一个 Case，可能又引入了其他 Bad Case。

解决方法在这个问题上也有比较强的共识。Andrej Karpathy 在三月份的一篇推文中提到了一个观点：现在的 Benchmark 已经是新的 Meta 了。去年那篇颇具影响力的文章《Agent Design is Still Hard》也表达了类似的观点：评估和测试是最难的问题，到了一定程度之后必须引入 Benchmark。

我们的 Benchmark 体系分为两个阶段。第一个阶段是 Case 收集：故障发生后，从发生到智能归因，经过专家标注后进入评测阶段，Case 被加入评测集，判断其是否值得纳入，相关数据进行转储，然后跑一个评测 Agent，进行效果对比。在评测集设计阶段，目标是覆盖真实的业务问题空间，所有 Case 全部来源于线上真实的异常场景。在评测集数据构造阶段，目标是复现真实的排障环境，我们采用了快照式的监控数据转储方案。快手每天会产生大量监控数据，部分数据有过期机制，我们需要将故障发生期间的监控数据尽量转储出来。

之所以没有采用仿真环境或混沌工程的方案，是因为我们要解决的是业务场景的问题，这类问题非常难以通过混沌工程来模拟。比如搜索量下降，你不可能真的去构造一个搜索量下降的故障——请求量太大，模拟成本太高。所以我们更多是从真实异常中收集案例，保存故障现场。在评估阶段，目标则是衡量模型效果，关注核心指标，比如线索命中率，进行量化评分，与预期行为做比对。

挑战四：对抗幻觉

大模型幻觉是一个绕不开的话题。有一个在去年 Claude Opus4 模型下发现的典型案例，虽然现在有了 4.7 可能已经不存在了，但它带来的启示仍然有效。有一次一位同事发给我一段 Prompt，我直接发给了 Claude，Prompt 非常简单，就是让它把时间转换成时间戳。结果发现它几乎做不了这件事，每次转换都不准确。后来我只是稍微修改了一下提示词，告诉它通过运行 Python 脚本的方式来帮我转换，结果就变得极其精准了。这个小小的实验非常清楚地说明了一件事：大模型本质上是一个概率预测器，并不擅长数值计算任务。

在实际业务场景中，我们遇到的第一个问题是识别监控图片中的简单趋势，比如八点到八点二十之间某个指标是上升还是下降。这本来是一个非常简单的事情，但我们用大模型尝试的时候却出现了明显的幻觉。最初想到的方案是用多模态去识别，直接把监控截图发给了大模型。这种方式幻觉相当严重——图片中 8:00 到 8:20 之间确实有下降，但时间点不够精准，模型只能给出非常模糊的时间范围。更糟糕的是，有时大模型对纵轴的理解也不准确，甚至会突然说一句“我在 8:30 发现了一次下降”，这显然是严重的幻觉。而且这种方案还依赖于图表样式的稳定，前端同学随意调整一下图表的颜色或布局，准确率可能就立刻受影响。

第二种方案是用时序数据进行识别，把一段时间内所有数据点的“时间-值”对构成一个巨大的 JSON List 直接发给大模型。结果依然逃不出计算出错的问题。首先是 Token 消耗太高，数据序列实在太长了。其次，它仍然需要执行计算，比如判断到底下降了多少百分比，大模型对此还是处理不好。

最终我们把这件事转变成了传统算法的任务，用孤立森林算法结合一些规则去判断。采用这种方式后，准确率显著提高，也不消耗 Token，确定性也得到了根本性的增强。由此得出的一个结论是：当确定性要求超过一定程度时，工程化封装成 Tool 和 Skill 是更优解。

将某个判别能力封装为标准化算子之后，它就拥有了标准化的接口，可以被复用，也可以配置可调参数。一旦沉淀为标准化算子，就可以逐步积累成一个算子库。借鉴类似 AutoResearch 与 CodeAct 的思路，把确定性重复问题沉淀成算法，然后为这些算法准备一系列输入输出——本质上就是一个函数。我们准备一些 Case，要求在输入 A 的情况下输出 B，在输入 C 的情况下输出 D，不断去跑，目的就是提高算法的得分。这一步就非常容易量化了，很容易形成一个有正向反馈的迭代回路，持续地打磨算法。

有一个值得认真思考的问题：从 Workflow 演进到 Agent，一定是更优的选择吗？Workflow 的优点很明确，确定且可控，但它的局限性也同样明显——它严格依赖编排好的流程，依赖固定的流程编排，非常缺乏灵活性。Agent 解决了灵活性的问题，非常发散，有泛化能力，但同时也带来了不确定性。同时把 Workflow 换成 Agent 还会产生延迟的增加——ReAct 循环多轮必然导致延迟大幅上升，Token 消耗也是巨量爆炸。Workflow 不存在这些问题，延迟更低，Token 消耗更少，确定性更强。所以我们发现 Agent 对 Workflow 并不是一个纯粹的取代关系，Agent 更像是一个更灵活的升级，而非一个“更智能”的代名词。在某些场景下，用 Workflow 的效果确实更好。

那么为什么要用 Agent？因为在复杂的业务排障场景中，存在相当多的高度不确定性问题，这些问题没有办法用静态 SOP 覆盖。这就是引入 Agent 的核心价值所在。

整体告警治理的架构也是分层的。最下层是告警噪声，通过传统的告警治理、常规策略治理以及智能告警的引入，先把噪声降下来。上面的两层就是 AI 去处理的范畴。第一层通过一些 Workflow 进行“快思考”，将相对固定的系统类告警场景处理好，比如 SOP 场景、Redis 排障场景、Java 异常场景。这些东西相当套路化，可以变成快思考的简单问题来处理。最上层则是核心业务指标的突变，我们引入 Agent 进行“慢思考”，做深度推理。

在快思考这一层，从告警事件发出，经过抑制规则判定，比如被认定为一个单点问题，直接就可以处置，把单点重启一下，告警抑制掉即可。然后结合特征画像分析，会抑制掉相当一部分告警。剩下的告警进行简单的复杂度判定，有些问题通过维度分析、简单影响范围分析，就被认为可以在 Workflow 内解决，直接同步归因。对于那些比较复杂的问题，就走异步的 Agent 分析流程，可能耗时十分钟以上。Workflow 这一块的确定性相对较高，也会比较快速地出结论。

在复杂问题的慢思考层面，我们采用 Multi-Agent 架构。告警事件触发后进入平台，进入主 Agent 循环，创建一个 Plan 计划，动态调用底层的若干 Sub-Agent。底层有业务资产和数据基建作为支撑，最后输出可解释的报告。这里用到了几个关键技术点：第一是 SubAgent 领域封装。我们的工具加起来有八十多个，如果把这八十多个工具直接全量抛给主 Agent，其认知负担极大，Token 消耗压力也巨大。因此我们会把相近领域的 Tool 组成 SubAgent 封装起来。第二是在长任务中仍然可能需要代码分析，我们将这种代码分析异步化，投递到信箱中，让主 Agent 进行消费。第三，由于采用 SubAgent 的排查方式，各 SubAgent 之间的信息是隔离的，个别 SubAgent 容易陷入无效路径。比如某个 Agent 已经发现了关键线索，找到了关键的变更事件，那可能就没有必要继续做 RPC 下钻了。我们的解决方法是组成 Agent 通信 Team，让 SubAgent 之间进行必要的通信，以缩短整个排查路径。

在 Agent 自进化方面，我们的思考是这样的：大模型存在两个极端。如果非常泛化，不给它任何 Case 参考，就是 Zero-shot 的推理模式，可能会过于发散。但如果把 SOP 在 Prompt 里完全定死，第一步做什么、第二步做什么，又会产生过拟合。所以我们采用 Few-shot 的模式，告诉他类似故障大概要怎么处理。但构建 Few-shot 案例的过程中存在人工成本，需要人一个个去构建。为了解决这个问题，我们设计了一套自动构建案例集的系统。事先准备好一些问题和正确答案，然后让 Agent 启动迭代模式，不断去跑。过程中把模型换成小模型，提高温度，让它跑出非常多的路径，直到命中那个正确答案。当评估 Agent 认为它命中了，就把整个评估过程抽取出来，做一份摘要，加入到经验库中沉淀下来。

在 Agent 记忆方面，排障需要查询的信息量非常庞大，告警画像的统计信息、研发脑中的业务知识，这些可能都需要在推理启动时初始化到 Context 中，初始化到 System Prompt 里。推理过程中则会有动态的检索搜索过程，去搜索历史离线业务资产、过去推理过程所沉淀下来的长期记忆，以及场景化的 Skill，这部分 Skill 可能比较偏 SOP。这些东西我们会尽量让 Agent 自己去进行合并与整理，而不是消耗大量人力去人工解决。

在产品交互层面，我一直在思考一个问题。从去年 Claude Code 出来，到今年一月份 OpenClaw 发布，我身边的很多程序员同事并没有对 OpenClaw 展现出很大的热情，但它在社会上却产生了巨大的反响。Claude Code 为什么没有产生类似的反响？增量究竟是什么？观察下来，我们发现 OpenClaw 有一些独特的能力：接入了 IM，默认给全所有超级权限，有心跳机制来感知任务进展。总结起来，现在同类产品统一的特点就是让 AI 越来越 Proactive，越来越主动。

所以我们产品迭代的思路也是沿着这个方向走。最初形态是研发输入一个问题，Agent 进行推理，过程中给出一些关键发现，实时绘制链路拓扑，整个产品以 Chatbot 的形式对外提供服务。但未来的方向还是要发展成更加 AI Native 的自驱模式，让 Agent 能够自动发现问题，需要拉群就自动拉一个群，不断把它发现的关键线索抛在群里，最终实现从问题感知到排障处置到协同处理，甚至自己也可以进行经验沉淀，这种完全的闭环才是理想中的终态。

在核心指标运营上，面向告警和故障处置，我们最终要衡量的是 MTTR 的缩短。但实际过程中真正遇到故障的频次相对较低，案例数量有限，所以我们引入了一些过程指标。第一个过程指标是“有效线索率”。为什么会有线索这个概念？是因为整个 Agent 推理时间比较长，一个任务可能十分钟以上才能完成，不可能等到十分钟才告诉研发结论。过程中每发现一个值得分享的关键线索，就应该抛出来。因此关键线索的准确率就成为一个重要的衡量维度。同时我们也有归因的准确率以及归因时长，这些都需要持续运营。

目前我们在整体准确率上达到了百分之八十以上，但这个数字包括了非常多的告警噪声。实际推理层面的准确率并没有这么高。在推理层面目前主要衡量有效线索的准确率，让 Agent 最终把根因推对是相当困难的，但只要过程中发现了有效线索，就已经能给业务带来实际价值。

在实践中我们也踩过很多坑。比如遇到大模型层频繁失败的问题，API 接口不匹配的问题，不同模型厂商之间的大模型接口存在非常大的差异。这些问题本质上是软件工程的问题，需要去处理故障、防范故障、增强系统的容错能力。在过去做分布式系统开发时，我们就一直在对抗环境的不确定性。AI 的引入是把这种不确定性进一步增强，变成了一个常态。理解这一点之后，我们的心态反而变得坦然了：只能去拥抱它。

另外还有一点，现在的整个组织都是按照人来组织架构的，人是高度分工的。但 Agent 不需要分工，而且人与人之间存在信息隔离，组织上的某些问题会跟技术问题纠缠在一起，比如谁掌握更多信息谁就掌握了主动权。但对于 Agent 来说也并非如此。从第一性原理出发，有些东西已经变了。

再说回现在的发展。Agent 领域发展极快，很多结论过两个月就可能已经过期。那到底能积累下什么东西呢？我们认为有一些东西是可以复用的——问题域业务资产、Eval 评价体系、结构化案例集、人机协作模式，这些东西是稳定层，可以持续积累。同时也有易变层，随着模型迭代，下半年出了一个更强大的模型，很多当前适用的东西可能就没用了，Prompt 描述、工具选型、协议规范都在这个范畴。我们的思路是把更多精力投入到稳定层上，尽量减少在易变层上的投入，因此会更多地构建数据上下文。

最后，我认为整个方向还是要向着 AI Native 自主化、AI 自进化的方向演进。目前 Agent 能做到的是提供辅助决策，由人主导排查问题。后面可能会发展到一个新阶段：Agent 自己出决策建议，人进行最终审批，起到一个把关兜底的作用。最终，如果这个阶段运行得足够久，我们发现在百分之九十九的场景下 Agent 都是准确的，人的审批已经没有提出任何有效修订的空间，那就可以完全走向 Agent 自我进化、自主闭环了。