From General Agents to RCA Experts: A Self-Evolving Harness for Root Cause Analysis

I. 引言

• 根因分析用于定位故障，其症状会沿微服务依赖关系传播，往往在远离根因的位置显现。根因分析利用指标 、日志 和链路追踪 ；值班工程师定位生产故障可能需要数十分钟, [5]。出处：§I · p. 1
• 基于 GPT 5.5 的原生 Codex 能解答 45% 的 OpenRCA 查询，而使用相同基座模型的 RCA-Agent 仅为 32%。在所有受测基准上的综合评估中，通用智能体在每种受测基座模型上均保持优势。与从零设计的专用 LLM RCA 智能体 [13]– 不同，通用智能体已具备成熟的工具使用、代码执行、沙箱隔离和长程规划能力。出处：§I · p. 1
• Codex（GPT-5.5）的平均准确率为 51.2%，在 RCA 上仍有很大提升空间；瓶颈在于缺乏诊断经验、对目标系统不够熟悉，而非通用能力不足。论文提出以 harness 工程弥补这一差距，即适配提供工具、领域知识和控制逻辑的外部层 –。出处：§I · pp. 1–2
• OpsHarness 将分层运维知识、思路卡片工具库与控制平面的四项工作流相结合：初始化、诊断、演进和验证。论文将其定位为首个可自演进的外部 RCA harness，复用通用智能体的能力并兼容其快速迭代，而非从零重建智能体。出处：§I · p. 2
• 自演进将成功与失败的诊断轨迹提炼为原子化提案，仅采纳通过双重门控沙箱验证的更新，以抑制过拟合。该 harness 从历史诊断中积累系统专属的最佳实践、知识和工具，供后续故障诊断复用，也适用于起初不熟悉的系统。出处：§I · p. 2
• 在四种基座模型上，平均 top-1 准确率达到 59.0%，较原生通用智能体相对提升 63.4%，性能为专用智能体的 4.02×。评估覆盖 OpenRCA 、RCAEval [25] 和工业生产部署。各组件均对性能提升有所贡献，开销与原生通用智能体相当。出处：§I · p. 2

II. 背景与相关工作

• OpsHarness 被提出为首个自演进外部 RCA 支撑框架，既兼容现代通用智能体，又能在部署期间持续演进。软件开发领域已有 Superpowers 和 OMX 等先例，而运维领域仍普遍缺少类似的外部支撑框架。出处：§II · pp. 2–3
• 以往多数基于 LLM 的 RCA 方法构建面向特定系统的专用智能体，限制了对快速进步的通用智能体的复用，以及在未见场景中的学习与泛化。这些方法包括基于多模态遥测数据开展诊断的智能体、遵循 SOP 的角色分工协作，以及利用工单和日志提供故障辅助。出处：§II · p. 2
• 外部支撑框架封装完整的通用智能体，为其提供任务专属支持；更广义的支撑框架则提供工具、上下文、记忆、控制循环和评估 。这一区分将通用智能体的现有能力视为基础，而非在任务专用智能体内部重新构建这些能力。出处：§II · pp. 2–3

A. 外部支撑框架已成为基于 LLM 的 RCA 的关键

• 在四种骨干模型和两个基准上，通用智能体的平均总体 top-1 准确率为 36.1%，优于 RCA-Agent（17.9%）和 mABC（5.6%）。相同骨干模型下的比较使用 Codex 或 Claude Code，在 OpenRCA 和 RCAEval [25] 上进行。在 RCAEval 上，通用智能体达到 38.0%，而 RCA-Agent 仅为 5.1%，暴露出专用智能体的泛化短板。出处：Table I · p. 3, A. External Harness is Now the Key to… · p. 3

III. 研究动机

• OpsHarness 的研究动机结合了受控定量实验与大型商业云服务提供商 A 公司的生产系统案例研究。这些工业案例研究提供了真实生产环境中的证据。出处：§III · p. 3

A. 外部支撑框架已成为基于 LLM 的 RCA 的关键

• 最强的无额外支撑通用智能体配置 GPT-5.5 的总体 top-1 准确率为 51.2%，仍未达到生产需求；作者将其归因于诊断专长不足。作者区分了诊断专长的缺口与通用推理能力的不足。出处：A. External Harness is Now the Key to… · p. 3
• Telecom 中的一个失败案例显示，通用智能体将噪声较大的网络错误计数器误判为根因，却忽略了 CPU 饱和指标相对近零基线的偏移。智能体正确定位了异常时间窗口，却将根因归于主机 os_022，而非容器 docker_003 的 CPU 饱和。由于缺乏系统专属的噪声知识，智能体被原始数值的大小误导。出处：A. External Harness is Now the Key to… · p. 3
• 作者主张优先构建外部 RCA 支撑框架，复用通用智能体的成熟能力，同时改进制约诊断准确率的外部支持层。通用框架已提供稳健的工具调用循环、长程规划和上下文管理能力, [23]；重新构建专用智能体可能无法充分实现这些能力。出处：A. External Harness is Now the Key to… · p. 3

• 有故障排查指南记录的事件中，36.2% 至少发生两次 ，因此应持续学习，而非将诊断视为一次性任务。本节指出，持续提炼经验、总结最佳实践，是资深 SRE 区别于能力出色的新人的关键。出处：B. The Ability to Self-Evolve is… · p. 3
• 复用最初一次误诊事件的经验，帮助一名 SRE 定位到容器 CPU 饱和，并通过重启解决了后续事件。最初的排查将数据库会话数下降误判为原因；实际故障从容器 CPU 饱和，经由 RemoteProcess 延迟，传播至前端异常。记录这条传播链，并指出数据库会话数不宜单独作为可靠信号，为后续诊断提供了指导。出处：B. The Ability to Self-Evolve is… · p. 4
• 关联合适的故障排查指南，可将 Microsoft 严重级别为 2 的事件的平均缓解时间从约 18 小时缩短至 13 小时 [45]。Microsoft 将超过 4,000 份指南与数千起事件关联，但指南仍由人工编写和执行 [45]。152 起高严重级别事件中，超过 90% 通过此类流程得到缓解 ，而更深入的根因知识仍留存在无法直接复用的事后复盘报告中 [28], [46]。出处：B. The Ability to Self-Evolve is… · p. 4
• 自演进 RCA 框架应将诊断经验转化为可复用的专业知识，帮助智能体持续改进，并泛化到陌生系统。框架应自动从诊断过程中提炼最佳实践、知识和工具。SRE 和智能体都需要这种经验提炼与复用能力，但目前这些工作仍主要依靠人工。出处：B. The Ability to Self-Evolve is… · p. 4

A. 概述

• OpsHarness 将持续演进的系统专属数据平面划分为分层运维知识库和思路卡片工具库。控制平面围绕这些系统专属状态协调工作流。出处：A. Overview · p. 4
• 控制平面协调初始化、诊断、演进和验证，可观测性子系统则记录每次运行。初始化和诊断负责适配并应用该框架；演进和验证构成自演进闭环，推动框架版本迭代。出处：A. Overview · p. 4

B. 分层运维知识

• 四层运维知识将诊断流程经验与具体操作的最佳实践区分开来，各层采用独立的披露和更新策略。出处：B. Layered Operational Knowledge · p. 4
• K0 定义通用 RCA 流程和预期诊断输出，随根文档提供，并在每次诊断时加载。出处：B. Layered Operational Knowledge · p. 4
• K1 在初始化后自动获取目标系统画像，替代逐数据集适配器，无需硬编码加载器。系统画像包含数据模式、磁盘布局和组件清单等元数据，每次诊断开始时均完整读取。出处：B. Layered Operational Knowledge · p. 4
• K2 和 K3 在演进阶段从诊断轨迹中挖掘而来，构成目标系统的有向诊断知识图谱。节点表示操作，有向边指明合理的后续操作，规则标注诊断状态。工作流骨架是该图中的一条路径。出处：B. Layered Operational Knowledge · p. 4

端到端使用流程

• K3 包含可复用的诊断操作和条件规则，其中正向规则推荐行动，负向规则指出诊断反模式。每条规则将条件与行动或注意事项配对，并标明正负极性。K3 操作通常对应一张思路卡，由卡片提供实现该诊断操作的算法。出处：END-TO-END USAGE FLOW · p. 5, C. The Idea-Card Tool Library · p. 5
• K2 将优选诊断流程表示为操作的有序路径，将粗粒度流程结构与 K3 的细粒度操作和规则分离。例如，流程可先确认前端 KPI 时间窗口，再自上而下跨层定位，最后区分根因与故障传播。出处：END-TO-END USAGE FLOW · p. 5
• 渐进式知识加载机制常规加载 K0 和 K1，根据摘要选择完整的 K2 工作流，并按需检索相关的 K3 操作和规则。知识以文本形式存储在框架根目录下；加载全部层级会挤占智能体的上下文空间，削弱推理能力。出处：END-TO-END USAGE FLOW · p. 5

C. 思路卡工具库

• 思路卡用自然语言描述算法，使智能体能够依据当前数据模式实现分析工具，而非依赖预先编写的脚本。每张卡片规定核心思路、简要伪代码、输入输出约定、适用条件和关键参数。不同系统和时间窗口的数据布局各异，因此需要根据当前环境编写并迭代代码。出处：C. The Idea-Card Tool Library · p. 5
• 演化过程从正确诊断轨迹中提炼反复出现的代码逻辑，形成系统专用工具卡，逐步扩充起初仅含占位项的工具库。冷启动时，库中不含任何系统专用工具。出处：C. The Idea-Card Tool Library · p. 5
• 工具库采用分阶段加载：智能体先阅读附有使用指引的单页算法菜单，再仅打开所需卡片。智能体从不加载整个工具库。出处：C. The Idea-Card Tool Library · p. 5

D. 诊断生命周期

• 用户在系统接入或结构变更时调用 /opsharness:setup，只需提供遥测数据位置即可启动系统画像构建。诊断通过 /opsharness:diagnose <query> 提供，可由用户发起或由告警触发。出处：D. The Diagnosis Lifecycle · pp. 5–6
• 诊断自顶向下展开，利用分层知识和跨模态验证，定位异常时间窗口、责任层级与组件以及故障类型。智能体加载 K0 和 K1，并按需查阅 K2 和 K3；指标用于确认，日志用于解释，链路追踪用于展示影响路径。出处：D. The Diagnosis Lifecycle · p. 6
• 设置阶段通过多次采样推断遥测数据语义，建立实体清单和指标分类，并写入 K1 和画像 YAML 文件，无需为各数据集单独编写代码。若用户提供了现有知识或工具的访问路径，设置阶段会将发现的内容纳入 K1。出处：D. The Diagnosis Lifecycle · p. 6
• 诊断智能体将所需的思路卡片实现为适配当前场景的代码并执行，生成根因排序报告，同时由可观测性机制记录轨迹。报告中的每项根因均注明组件、故障类型和起始时间。出处：D. The Diagnosis Lifecycle · p. 6

V. OpsHarness 中的自演化

• 自演化挖掘带标签的轨迹，从成功模式和可执行的失败修正方案中生成提案，仅应用通过沙箱双重门控验证的提案。三个阶段依次为轨迹挖掘、证据挖掘与提案合成、分阶段验证。出处：§V · p. 6

A. 轨迹挖掘

• 以命令为边界划分的诊断块被转为轨迹，并标注基于反馈的准确性和实测开销；OpsHarness 逻辑之外的区段则被丢弃。问题解决后，用户通过点赞或点踩提供反馈，并给出实际根因；准确性分为正确、部分正确或错误，开销则记录 token 用量和耗时。正确轨迹构成正例集，错误轨迹构成负例集。出处：A. Trajectory Mining · p. 6

B. 证据挖掘与提案合成

• 每个提案由原子化、带类型的操作符组成，修改单个骨架路径、操作、规则或工具卡，生成候选数据平面状态。骨架路径属于 K2，操作和规则属于 K3，工具卡属于 T。出处：B. Evidence Mining and Proposal… · p. 6
• 成功轨迹通过反复出现的步骤顺序、操作、代码和观测结果，提炼出可复用的诊断骨架、操作节点、工具卡和正向规则。演化模块通过对已标注批次进行推理，近似判断是否达到重复出现的阈值。骨架保留决定性步骤，剔除探索性绕路。出处：B. Evidence Mining and Proposal… · p. 6
• 失败轨迹在首个与已确认根因不一致的步骤处生成纠正性修改，并从反复出现的误导模式中提炼负向规则。对于诊断结果一对一错的相似故障，分歧后被跳过的操作可提供修正依据。若失败源于过时的演化知识，则触发更新或删除。出处：B. Evidence Mining and Proposal… · p. 6

C. 分阶段双关卡验证

• OpsHarness 仅在隔离沙箱中通过两道验证关卡后，才以原子方式正式采纳提案；验证过程不改动线上支撑框架。未通过的提案会返回细化，以失败案例作为新的负例，最多重试三轮。仍未通过的提案将被丢弃，其暂存环境也会被移除。出处：C. Staged Dual-Gate Verification · pp. 6–7
• 内层关卡要求源案例准确率不下降、token 成本无实质增加，且至少一个目标严格改进。成本容差为 β = 0.05。严格改进排除无实际效果的修改，成本上限则拒绝靠失控探索换取的准确率提升。出处：C. Staged Dual-Gate Verification · pp. 6–7
• 外层关卡在每次演化前重新采样的留出测试集上检查性能不退化，并按故障类别和发生时间对累积案例分层抽样。样本与用于挖掘的案例保持互斥，样本量默认等于演化窗口大小，避免反复拟合静态测试集。任务提示不包含私有标签，线上支撑框架每次变更后都会刷新基线。出处：C. Staged Dual-Gate Verification · p. 7

• 评估考察 OpsHarness 的效果，尤其是自演化后的效果。出处：§VI · p. 7
• 评估考察 OpsHarness 各项设计的贡献。出处：§VI · p. 7
• 评估考察 OpsHarness 的成本及其在工业部署中的表现。出处：§VI · p. 7

1) 数据集：

• 评估涵盖企业系统、微服务和生产变更场景，使用 335 个 OpenRCA 案例、270 个 RCAEval [25] 案例及 88 个工业异常。OpenRCA 涵盖三个企业系统和 28 类根因；RCAEval 在三个微服务基准中注入 CPU、内存、网络、磁盘及代码故障。A 公司提供 773,340 个遥测数据点，异常标签来自值班 SRE 的反馈和原始日志。出处：1) Datasets · p. 7
• 各数据集中最新的 20% 案例构成留出测试集；较早的 80% 用于预热，避免各方法接触未来案例。预热数据用于 OpsHarness 的自演化，以及上下文学习基线的示例检索；除非另有说明，报告结果均来自留出测试集。出处：1) Datasets · pp. 7–8

B. RQ1：有效性

• 完整 OpsHarness 的 Final A@1 达到 59.0%，在每个骨干模型上均为表现最好的框架，优于全部五个对比框架。在四个骨干模型上取平均，OpsHarness (no-evolve)、ICL、Direct、RCA-Agent 和 mABC 的 Final A@1 分别为 41.4%、38.4%、36.1%、17.9% 和 5.6%。出处：Table II · p. 8, B. RQ1: Effectiveness · pp. 8–9

2) 基线与实现：

• 四个骨干模型与六个框架组合，共形成 24 种配置；框架包括 RCA-Agent 、mABC 、Direct、ICL、OpsHarness (no-evolve) 和完整 OpsHarness。骨干模型为 GPT-5.5 、Claude Sonnet 4.6 、GLM-5.2 [42] 和 DeepSeek-V4 [43]；Sonnet 使用 Claude Code，其余使用 Codex。所有方法获得相同的环境和信息；Direct 不使用 RCA 适配框架，ICL 则检索三条相似的正确执行轨迹。出处：2) Baselines and Implementation · p. 8

3) 评估指标：

• A@1 和 A@3 衡量根因元组的精确匹配准确率，Avg Score 给予部分正确得分，每个案例的平均 token 用量和耗时用于衡量效率。标注元组包含组件，并在适用时包含故障类型和起始时间。Final A@1 为六个公开子数据集上 A@1 的平均值。出处：3) Evaluation Metrics · p. 8, B. RQ1: Effectiveness · p. 8

B. RQ1：有效性

• 完整 OpsHarness 比 Direct 高出 22.9 个百分点：Day-0 适配框架带来 5.3 个百分点的提升，自演化再贡献 17.6 个百分点。无演化变体仅保留 Day-0 基础层，从而区分冷启动能力与经验驱动的改进。出处：2) Baselines and Implementation · p. 8, B. RQ1: Effectiveness · p. 9
• DeepSeek-V4 的 Final A@1 从 20.3% 升至 31.6%，冷启动增益最大；GPT-5.5 则仅从 51.2% 升至 52.8%。在 GLM-5.2、DeepSeek-V4 和 Claude Sonnet 4.6 上，基础层明显改善了 Direct 的表现；在 GPT-5.5 上，适配框架的优势几乎完全来自自演化。出处：B. RQ1: Effectiveness · p. 9
• ICL 的 Final A@1 为 38.4%，相较 Direct 的 36.1%，ICL 的增益有限；而 Avg Score 从 Direct 的 68.8% 降至 67.0%。作者认为，这一局限源于检索原始示例，而非提炼可复用的最佳实践。出处：B. RQ1: Effectiveness · p. 9

C. RQ2：各项设计的贡献

• 在两个基准的训练集上，使用 12 个连续诊断窗口，基于四种骨干模型评估三种变体。按顺序诊断案例，每个窗口触发一次演进，并报告该窗口的平均 A@1。no-evolve 禁用自演进；no-verify 不经验证，直接采纳对其来源案例有效的提案。出处：C. RQ2: Contribution of Each Design · p. 9

2) 验证关卡防止过拟合：

• 在四种骨干模型上取平均，no-verify 最后一个窗口的 A@1 为 0.33，低于 no-evolve 的 0.43。准确率起初上升，随后停滞或回落。能力较弱的骨干模型受影响最大：DeepSeek-V4 从峰值 0.4 跌至 0.0。出处：2) The Verification Gate Prevents… · p. 9

1) 自演进使系统越用越好：

• 在四种骨干模型上取平均，完整 OpsHarness 最后一个窗口的 A@1 为 0.83，高于 no-evolve 的 0.43。完整 OpsHarness 在每种骨干模型上的最终表现均最佳，A@1 在 12 个窗口内约翻一倍，而 no-evolve 基本持平。出处：Figure 5 · p. 9, 1) Self-Evolution Improves with Use · p. 9

2) 验证关卡防止过拟合：

• 37% 的演进提案被验证关卡拒绝；只有在独立且不重叠的留出测试环境中不引起性能退化的改动，才会被采纳。提案平均需尝试 1.7 次才能获准采纳。出处：2) The Verification Gate Prevents… · p. 9
• 未经验证的演进可能过拟合来源案例：提高网络异常的权重后，原先诊断正确的 CPU 和内存案例反而被误判。该提案对其来源案例有效，但随后将网络噪声误判为根因。出处：2) The Verification Gate Prevents… · p. 9

3) 知识与工具机制：

• 高层次知识的召回范围较广，而细粒度的笔记规则和工具则被选择性召回，且效果良好。各类产物通过数量、Recall（召回该类产物的测试案例占比）和 Precision（召回该类产物的案例中诊断正确的占比）来刻画。出处：3) Knowledge and Tool Mechanisms · p. 9

1) 诊断成本：

• OpsHarness 在两个基准上的单例开销约为 106k 词元和 325s，与 Direct 和 ICL 相当。Direct 平均消耗 112k 词元、耗时 317s；ICL 平均消耗 106k 词元、耗时 308s。尽管 OpsHarness 将技能和知识加载到上下文中，但减少了诊断中的试错。出处：1) Diagnosis Cost · p. 9, Figure 6 · p. 10
• 专用智能体的词元消耗为 OpsHarness 的 1.7×–2.7×，实际耗时为 2.3×–3.5×，主要源于更多的重试和重新规划。该比较涵盖了基准评测中的两个专用智能体。出处：1) Diagnosis Cost · pp. 9–10

2) 初始化、演化与验证成本：

• 每轮验证消耗 1.55M 词元、耗时 421s；对留出样本的并行诊断使验证成为最大的非诊断词元开销，占比达 49.8%。每个数据集仅执行一次初始化，消耗 0.82M 词元、耗时 412s；演化是开销最小的阶段，每周期消耗 0.75M 词元、耗时 184s。演化和验证每周期各执行一次；这些低频阶段作为并行辅助任务运行，成本可分摊到后续诊断中。出处：2) Setup, Evolution, and Verification… · p. 10, Figure 7 · p. 10

3) 适配框架存储占用：

• 预热后的适配框架占用约 228KB，相较于单例遥测数据可忽略不计。可复用工具占用 106KB（46.4%），技能库占用 95KB（41.5%），演化得到的目标系统知识占用 27KB（12.0%）。出处：3) Harness Footprint · p. 10, Figure 7 · p. 10

1) 工业数据集上的结果：

• OpsHarness 在六种配置下的工业评测平均达到 0.74 A@1，高于 Direct 的 0.24，且在每种配置下均优于 Direct。A 公司的变更异常评测采用 Codex 和开源 Open Code，搭配三种模型；平均准确率约为 Direct 的三倍。出处：1) Results on the Industrial Dataset · p. 10
• OpsHarness 搭配 GLM-5.2 达到 0.73 A@1，搭配 DeepSeek-V4 达到 0.57，而 Direct 分别为 0.23 和 0.12，表明 OpsHarness 在 Open Code 上同样有效。这些配置在生产数据集上采用完全开源的智能体与模型技术栈。出处：1) Results on the Industrial Dataset · p. 10

2) 案例研究：

• OpsHarness 在不到 2 分钟内诊断出再次发生的生产故障，将此前排在第三位的数据库同步故障提升至 Top-1。首次诊断时，SRE 否定了前两个候选原因，并用一行反馈确认了第三个。故障再次发生时，OpsHarness 还利用自动挖掘的专业知识定位了故障组件。出处：Figure 8 · p. 10
• 自动配置推断出遥测数据模式，后续演进则将 SRE 确认的诊断转化为可复用的因果规则及 K2/K3 知识。配置阶段写入系统概况和 K1；随后，K0、K1 与系统概况共同指导诊断。告警发生后一小时内，演进过程提炼出因果链，通过双重门控验证并提交知识，SRE 确认这些知识与故障相符。出处：Figure 8 · p. 10, 2) Case Study · p. 10

VII. 讨论

• 冷启动 OpsHarness 与未加适配的智能体相比，Final A@1 为 41.4% 对比 36.1%，因此在系统变化导致已学知识失效时仍可作为回退方案。K0 仍然有效，重新运行配置即可在无需编写代码的情况下重建 K1，随后重新积累经验。当后续轨迹与旧规则矛盾时，演进机制可更新或删除这些规则。出处：§VII · p. 10
• 在抽样的遥测信号交织案例中，超过 75% 连人工运维人员也无法诊断；OpsHarness 的大多数错误发生在首次遇到未见故障模式时。作者指出，积累相应的最佳实践可逐步缓解未见故障导致的诊断失败。出处：§VII · p. 10

VIII. 有效性威胁

• 准确率汇总涵盖四种基座模型、两种智能体框架和六个子数据集；按时间划分训练集与测试集，并禁止访问真实标签，以防止泄漏。汇总用于应对智能体的非确定性。使用相同模型、未加适配的智能体仅达到 36.1% Final A@1，作者据此认为，基座模型的记忆无法解释性能增益。出处：§VIII · pp. 10–11

IX. 结论

• OpsHarness 相较于两个未加适配的智能体，平均准确率提升 63.4%；相较于基线 RCA 智能体，平均准确率提升 4.02×，体现了其整体收益。结论报告了涵盖三个基准、四种基座模型、两种智能体框架及一次工业部署的评估。出处：§IX · p. 11
• OpsHarness 将专业化能力置于外部适配框架中，将分层知识、思路卡片工具与验证经验驱动更新的控制平面相结合。自演进机制从正确和错误的诊断中挖掘最佳实践，仅通过双重门控验证的变更才会被采纳。出处：§IX · p. 11