---
source_url: "https://mp.weixin.qq.com/s/tYGC7iPIEgc4TmRegpOgzw"
title: "复杂业务场景下 RCA Agent 的探索实践"
source: "QCon / InfoQ"
ingested: 2026-06-15
sha256: "e1f2a3b4c5d6e7f8091a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3"
type: raw
tags: [rca, agent, kuaishou, root-cause-analysis, multi-agent, evaluation, benchmark, hallucination, alert-noise, evidence-pyramid, qcon-2026]
---

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

作者 | 郭勇良，快手资深服务端架构师
审核 | Kitty
策划 | QCon 全球软件开发大会

在 AI coding 工具日益成熟的今天，代码生成能力已被视为接近攻克的领域，但软件工程的全局难题远未解决。本文整理自快手资深服务端架构师郭勇良在 QCon 全球软件开发大会 2026 北京站的分享《复杂业务场景下 RCA Agent 的探索实践》。

背景和痛点：为什么需要 RCA Agent

Claude Code 负责人 Boris Cherny 曾在播客中提出一个观点：编码工作大体上已经被 AI 攻克了。这个判断引发了一个更加深层的问题——软件工程真的被解决了吗？

从两份调研报告来看，答案是否定的：2025 年的 DORA 报告统计了 AI Coding 落地后的效能变化，个人效能的提升相当显著，但组织效能的提升却相当有限。微软内部的一项调研也给出了类似的方向，开发和排障仍然是研发人员时间占比最大的两块。

另一个现象：OpenClaw 在今年三月份发布了一个重大版本重构，版本上线后大量用户反馈插件出现瘫痪或功能失效。值得留意的是，OpenClaw 的代码绝大部分是通过 AI Coding 生成的。这意味着什么？随着 AI 时代人对代码掌控度的下降，AI 排障有可能从一个可选项演变成一个必选项。

技术系统三层切分：基础设施层（容器、节点、网络故障）→ 中间件层（Cache、DB、MQ 异常）→ 业务层（核心指标下跌、风暴告警、跨系统传播）。业务层三个特点：(1) 用户体验和营收的直接体现 (2) 业务代码迭代极快，高度易变 (3) 业务问题无法预测排查步骤。

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

典型案例：主站 Feed 流请求量上涨，入口服务 A 的下游可用率全部正常。实际根因是推荐质量下降导致用户反复刷视频，引发请求量异常上涨。故障传播链：A→B（有兜底降级，指标正常）→E（Core Dump）→F（配置变更引入未走过的逻辑路径）。

传统监控三板斧（Trace/Metrics/Log）在此案例中有两个断点：(1) A调B请求正常，Metrics无法关联，只能依赖业务经验人工确认 (2) E调F因逻辑此前未走到过，很可能没有打Log。

解决方案：除常规监控数据外，引入业务代码 GIT（代码是唯一真实的文档）。最初用 Claude Agent SDK 分析一个代码库约 30 分钟，切换到 PI Coding Agent 后降至 5 分钟，但完整排障需分析 3-5 个库仍需 15-25 分钟。

建立"业务资产"层（代码抽象）：(1) 错误码业务语义标注 (2) Metrics 业务化描述 (3) 指标拓扑关系（如下游推荐服务可用率降低→上游兜底率变化→Feed下发量变化）(4) 开关配置影响地图。两种构建模式：离线沉淀（Coding Agent 生成关系描述→Markdown 知识库）+ 排障中按需生成（Agent 分析后沉淀为 Skill）。

挑战二：如何对抗噪声

告警噪声占比超过 75%。内部复盘 P2 级故障：指标波动后 10 分钟已发出告警，值班人员直接静默——该告警 7 天内报警超 15 次，告警疲劳。

AI 全量处理成本：Agent ReAct 循环一次消耗 60-130 万 Token，快手主站月告警 2-3 万，月 Token 消耗近 100 亿，年化成本几百万人民币。

解决方案分两层：
(1) 轻量告警置信度评估 Agent/Workflow——提取告警"画像"（周期性、偏离程度、恢复时间、服务分布、曲线聚集），做统计评估
(2) 证据金字塔（借鉴循证医学）——最下层原始信号→背景上下文→单点观测→多元融合证据→最上层直接因果推断（有向图拓扑/源码实锤/时间窗口直接变更）

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

真实案例：引入单点抖动召回工具后，虽然单点问题成功召回，但整体准确率反降。原因：单点问题是极高频问题，Agent 在排查各种不同问题时都找到单点问题，错误建立因果关系。优化一个 Case 可能引入其他 Bad Case。

Benchmark 体系：(1) Case 收集——故障发生→智能归因→专家标注→评测阶段 (2) 评测集设计——覆盖真实业务问题空间，全部来自线上真实异常 (3) 数据构造——快照式监控数据转储（未采用混沌工程，因为业务场景如搜索量下降无法模拟）(4) 评估——线索命中率+量化评分+与预期行为比对。

挑战四：对抗幻觉

典型案例：Claude Opus4 做时间转时间戳几乎不准，但让它运行 Python 脚本就极其精准——大模型本质是概率预测器，不擅长数值计算。

监控图片趋势识别三种方案：(1) 多模态直接识别截图——幻觉严重，时间点不准，纵轴理解错误 (2) JSON List 时序数据——Token 消耗高，计算出错 (3) 传统算法（孤立森林+规则）——准确率显著提高，不消耗 Token，确定性根本增强。

结论：当确定性要求超过一定程度时，工程化封装成 Tool 和 Skill 是更优解。借鉴 AutoResearch 与 CodeAct 思路：确定性重复问题沉淀成算法→准备输入输出 Case→持续跑评测提高得分→正向反馈迭代回路。

核心架构设计

演进路线：Rule-Based → Prompt 编排 SOP → Workflow + MCP → Agent 自主决策。

关键洞察：Agent 对 Workflow 不是纯粹取代关系。Workflow 确定可控但缺乏灵活性，Agent 灵活但不确定且延迟高/Token 消耗大。Agent 的核心价值在于处理高度不确定性问题。

告警治理分层架构：
- 底层：告警噪声治理（传统策略+智能告警）
- 中层：Workflow"快思考"——SOP 场景/Redis 排障/Java 异常等套路化场景
- 上层：Agent"慢思考"——核心业务指标突变，深度推理

Multi-Agent 架构关键技术：
(1) SubAgent 领域封装——80+ 工具按领域分组，降低主 Agent 认知负担
(2) 代码分析异步化——投递到信箱，主 Agent 消费
(3) Agent 通信 Team——SubAgent 间通信，避免陷入无效路径

自进化机制：
(1) Few-shot 模式（Zero-shot 过发散，完全 SOP 过拟合）
(2) 自动构建案例集——准备问题+正确答案→小模型+高温度跑多路径→命中正确答案→抽取摘要→经验库沉淀
(3) 记忆合并——Agent 自己整理，减少人工

产品交互演进：Chatbot（人提问→Agent 推理）→ AI Native 自驱模式（Agent 自动发现问题→自动拉群→抛关键线索→排障处置→协同处理→经验沉淀）

核心指标：(1) MTTR 缩短 (2) 有效线索率（推理过程每发现关键线索就抛出）(3) 归因准确率 (4) 归因时长。整体准确率 80%+（含告警噪声），推理层面主要衡量有效线索准确率。

稳定层 vs 易变层：
- 稳定层（持续积累）：问题域业务资产、Eval 评价体系、结构化案例集、人机协作模式
- 易变层（减少投入）：Prompt 描述、工具选型、协议规范

认知总结：
(1) "拿着旧地图，找不到新大陆"——现有监控系统围绕人构建（认知带宽限制），Agent 不存在此限制，可观测体系可能被整体重构
(2) 组织按人分工，Agent 不需要分工，人与人信息隔离在 Agent 层面不存在
(3) 终态方向：AI Native 自主化、AI 自进化（辅助决策→Agent 出决策+人审批→Agent 自主闭环）

作者介绍

郭勇良，快手资深服务端架构师，目前在快手负责主站归因排障 Agent 建设，曾在华为云、美团 Infra 任职工作。