PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Haiyu Huang, Jiewei Lyu, Zhihan Jiang, Jinyang Liu, Xiao He, Tieying Zhang, Wu Xiang, Michael R. Lyu

arXiv:2608.25661v1cs.SEcs.AI

TL;DR

基于 LLM 的 RCA 仍未达到生产需求，主要差距来自外部 harness，而非通用 agent 的能力。OpsHarness 是一种自演化 RCA harness，通过复用运维知识与经验改进诊断，在 top-1 accuracy 上达到 59.0%，相较于裸通用 agent 提升 63.4%，相较于专用 RCA agent 提升 4.02×。

  • 问题

    基于 LLM 的 RCA 缺乏生产级准确率，因此需要外部 harness 将通用 agent 适配到特定于诊断的基础设施，并积累系统特定经验。

  • 方法

    OpsHarness 将分层运维知识和 idea-card 工具，与挖掘正确和错误轨迹并验证提议更新的控制流程相结合。

  • 结果

    在两个公开 benchmark 和一次工业部署中，top-1 accuracy 达到 59.0%，相较于裸通用 agent 提升 63.4%，相较于专用 RCA agent 提升 4.02×。

  • 要点与局限

    这些结果支持将基于 LLM 的 RCA 工作重点从重建 agent 转向围绕高能力通用 agent 构建自演化 harness。

  • 要点与局限

    由于 LLM agent 具有非确定性，评估报告的是多个 backbone、agent framework 和子数据集上的汇总准确率，而非单次运行结果。

Abstract

from arXiv · show

Automated root cause analysis (RCA) with large language models (LLMs) has drawn growing attention. Today, SREs typically automate RCA with LLMs in one of two ways: directly using a general-purpose agent (e.g., Codex or Claude Code) for diagnosis, or building a specialized RCA agent from scratch. As mainstream general agents grow more capable and iterate quickly, our quantitative study finds that the former now often surpasses the latter. Its accuracy, however, still falls short of production needs, and this gap stems mainly from the external adaptation layer outside the agent's general capabilities, namely the harness. We therefore argue that LLM-based RCA should focus on this external harness, reusing the strong general capabilities of a modern agent rather than rebuilding an agent from scratch. A key capability of such a harness is to self-evolve, accumulating system-specific experience from past diagnoses so that it gets better the more it is used. We introduce OpsHarness, a self-evolving RCA harness that turns diagnosis experience into reusable expertise. Its data plane combines layered operational knowledge with an idea-card tool library, while its control plane coordinates setup, diagnosis, evolution, and verification. During evolution, OpsHarness contrasts successful and failed trajectories, converts their evidence into atomic proposals, and admits updates only through a dual-gate verification process designed to prevent overfitting and regression. Across two public benchmarks and an industrial deployment, OpsHarness achieves 59.0\% top-1 accuracy, improving over a bare general agent by 63.4\% and over baseline RCA agents by 4.02$\times$.

I. 引言

现代微服务的复杂性使 RCA 变得困难，而日益成熟的通用 agent 正提供强大的可复用能力。本文认为，关键在于面向任务的外部 harness，而非重新构建 agent，并提出 OpsHarness：一种自演化 harness，在多个基准和工业部署中实现了 59.0% top-1 accuracy。

  • 背景: RCA 旨在从 metrics 、logs 和 traces 中定位原因，因为微服务症状往往远离其根因，并沿依赖关系传播。引言将 RCA 界定为一项需要在时间压力下完成的站点可靠性工程任务。
  • 动机: 通用 agent 如今已具备成熟的工具使用、代码执行、沙箱和长程规划能力，因此从头重构 agent 很难超越它们。引言将 Claude Code 、OpenAI Codex 和 OpenCode 列为示例。
  • 动机: Codex (GPT-5.5) 在测试数据集上的平均准确率仅为 51.2%，说明外部 harness 仍有很大的 RCA 改进空间。论文认为，剩余差距主要来自 harness：这一外部软件层为任务提供专用工具、领域知识和控制逻辑 –。
  • 方法: OpsHarness 是一种自演化的外部 RCA harness，在复用通用 agent 能力的同时，加入面向诊断的技能、工具和控制回路。其 data plane 包含分层的运维知识库和 idea-card 工具库，control plane 则管理 harness 的生命周期。
  • 结果: 在两个基准和一次工业部署中，59.0% top-1 accuracy 相比裸通用 agent 提升 63.4%，相比专用 RCA agent 提升 4.02×。该结果取四个 backbone 的平均值，且各设计组件均对整体增益有所贡献。
  • 方法: 其自演化过程通过 dual-gate verification 从正向和负向诊断轨迹中学习，在提炼系统最佳实践的同时抵御过拟合。该过程旨在使 harness 随使用次数增加而持续改进诊断能力。

II. 背景与相关工作 · III. 动机 · A. 外部 Harness 已成为基于 LLM 的 RCA 的关键

通用 Agent 凭借成熟的规划、工具调用和上下文管理能力，正日益超过专用 RCA Agent，但其生产环境准确率仍受限于缺乏系统特定的诊断专业知识。OpsHarness 通过在通用 Agent 外部加入可自演化的 Harness，弥补这一差距，将 Harness 工程拓展到运维领域。

  • II. 背景与相关工作: 基于 LLM 的 RCA 研究涵盖经典的基于图、因果和频谱的方法，以及能够进行规划、编写代码、检查遥测数据并协调专门角色的 Agent。示例包括 MicroRCA 、Sage 、Eadro 、BARO 、RCAgent [14]、RCA-Agent 、mABC 和 Flow-of-Action [16]。
  • II. 背景与相关工作: 如今，Agent 越来越被视为模型加外部 Harness：后者提供工具、上下文、记忆、控制和评估能力。CoALA [31] 及近期综述 、[33] 将 Agent 构建描述为把能力外置到记忆、技能和工具中。
  • II. 背景与相关工作: Superpowers 和 OMX 等软件开发 Harness 提供可复用的技能、命令和工作流，而运维领域中可比的 Harness 仍基本缺失。OpsHarness 被提出为首个可自演化的 RCA 外部 Harness，为通用 Agent 弥补了这一空白。
  • III. 动机: 这一动机建立在受控定量实验和工业案例研究之上，所用数据来自 Company A（一家大型商业云服务提供商）的生产系统。这些来源共同支持论文关于通用 Agent 能力以及外部适配必要性的观察。
  • A. 外部 Harness 已成为基于 LLM 的 RCA 的关键: 通用 Agent 开箱即用地提供稳健的工具调用循环、长时域规划和上下文管理，因此，从头构建的 RCA Agent 很可能需要重新实现这些能力，却仍无法达到预期效果。比较采用 Codex 或 Claude Code 作为通用 Agent 框架，并在 OpenRCA 和 RCAEval [25] 上评估 GPT-5.5、Claude Sonnet 4.6、GLM-5.2 和 DeepSeek-V4。
  • A. 外部 Harness 已成为基于 LLM 的 RCA 的关键: 裸通用 Agent 的总体 top-1 准确率平均为 36.1%，而其最强配置 GPT-5.5 达到 51.2%。这一不足被归因于缺乏诊断专业知识，而非通用推理能力不足。
  • A. 外部 Harness 已成为基于 LLM 的 RCA 的关键: 一个具有代表性的失败案例说明了外部专业知识为何重要：Agent 选择了噪声较大的网络错误计数器，而不是导致延迟尖峰的轻微 CPU 饱和信号。错误源于相对于各信号自身基线和长期噪声而言，绝对偏差具有误导性。
  • A. 外部 Harness 已成为基于 LLM 的 RCA 的关键: 通用 Agent 目前往往超过以往的 RCA Agent，但其准确率仍受外部支持层的限制。论文基于四个 backbone 模型和两个公开 benchmark 上的受控定量实验，并结合工业证据，得出这一结论。

B. 自我演化能力对 RCA 至关重要

由于故障会反复发生，RCA 是一个持续进行的过程，因此，自我演化对于挖掘专家经验并将其复用于后续诊断至关重要。然而，运维知识及其演化仍主要依赖人工，这促使我们构建能够持续提取系统特定 expertise 并提升性能的 harness。

  • 为何自我演化至关重要: 在有故障排查指南记录的事件中，36.2% 至少重复发生两次，因此诊断是持续进行的过程，而非一次性任务 。该段将持续总结最佳实践、挖掘经验，视为资深 SRE 与有能力的新手之间的区别。
  • 当前运维实践: 152 起高严重性事件中，超过 90% 通过故障排查流程得到缓解，但这些流程仍由人工编写和执行 。在 Microsoft，超过 4,000 份 Troubleshooting Guides 与数千起事件关联；使用正确指南可将 severity-2 缓解时间从约 18 小时缩短至 13 小时 [45]。
  • 对 harness 的启示: 不断演化的 harness 应自动从每次诊断中挖掘可复用的最佳实践、知识和工具，然后将其应用于同一系统的后续诊断。这直接应对了当前依赖人工的演化过程，并支持性能持续提升。
  • 为何自我演化至关重要: 自我演化使 SRE 和 agent 能够从诊断案例中挖掘专家经验，将其复用于后续诊断，并随着时间推移改进分析。它使系统能够泛化到不熟悉的系统，同时在诊断过程中逐步提取系统特定 expertise。

IV. OPSHARNESS 设计 · A. 概述 · B. 分层运维知识

OpsHarness 将系统特定状态与生命周期协调分离：其数据平面结合分层运维知识与 idea-card 工具库，控制平面则运行设置、诊断、演化、验证和可观测性。其四层知识库区分通用 RCA 指导、系统画像和从轨迹中挖掘的诊断知识，并为各层制定不同的披露与更新策略。

  • A. 概述: OpsHarness 将其 harness 划分为数据平面和控制平面：前者承载可按系统适配的状态，后者负责生命周期工作流与可观测性。数据平面包含分层知识库和 idea-card 工具库；控制平面记录每次运行。
  • A. 概述: 控制平面协调 setup、diagnose、evolve 和 verify，使演化与验证将 harness 从 h_i 推进到 h_i+1。Setup 和诊断负责适配并应用 harness，演化与验证则构成其自演化闭环。
  • B. 分层运维知识: OpsHarness 将运维知识组织为四层，每层具有独立的披露与更新策略，因为诊断流程经验不同于具体步骤级的最佳实践。这种分层结构体现了运维知识并非扁平结构。
  • B. 分层运维知识: K0 提供通用 RCA 流程知识，通过每次诊断都会加载的根文档定义诊断输入与输出。该知识随 harness 以 AGENTS.md 或 CLAUDE.md 等文本形式提供。
  • B. 分层运维知识: K1 在 setup 后自动构建每个目标系统的 schema、磁盘布局和组件画像，并在诊断开始时完整加载，以避免硬编码的数据集适配器。它告诉 agent 如何读取系统。
  • B. 分层运维知识: K2 和 K3 在演化过程中从诊断轨迹中挖掘，二者共同构成系统特定的诊断知识网络，类似于积累的 SRE 专业经验。该网络组织为有向图 G = (O, E, R)。
  • B. 分层运维知识: 在诊断知识图中，操作是节点，有向边编码合理的下一步操作，规则则是附着于诊断状态的带类型标注。该图定义为 G = (O, E, R)。

端到端使用流程 · C. Idea-Card 工具库

OpsHarness 将可复用的运维知识组织为分层工作流与规则层级，同时逐步开放 Idea-Card 工具库，并从经验中不断扩展。该设计使 agent 能够实施针对性诊断，而无需一次性加载全部知识或工具。

  • 端到端使用流程: OpsHarness 将分层知识库 K 与逐步开放的工具库 T 相结合，其整体设计概览对此进行了总结。知识以文本形式存储在 harness 根目录下，而不是每次诊断都整体加载。
  • 端到端使用流程: 知识库将 K2 中的粗粒度挖掘工作流与 K3 中的细粒度操作和规则分离开来，分别表示首选诊断路径与可复用的诊断动作。工作流骨架 π = (o1, . . . , om) 对操作进行排序，例如确认 KPI 时间窗口、跨层定位，以及区分原因与传播。
  • 端到端使用流程: K3 规则将条件与动作或注意事项及极性配对，同时编码正向诊断提示和不应单独驱动诊断的负向反模式。例如，通过延迟追踪容器 CPU 激增至前端，并避免将数据库会话数作为诊断的唯一依据。
  • C. Idea-Card 工具库: Idea cards 通过原理说明、简要伪代码、输入/输出契约、使用条件和参数来规定分析算法，agent 会在诊断过程中按需实现这些算法。它们以自然语言工具规范取代预先编写的脚本，支持异常检测、特征评分和嫌疑对象排序。
  • C. Idea-Card 工具库: 该工具库采用渐进式披露：agent 首先阅读一页式算法菜单，然后仅打开当前诊断所需的卡片。这样可以避免一次性暴露整个工具库。
  • C. Idea-Card 工具库: 在冷启动时，工具库仅包含脚手架；但经过演化，它会将正确轨迹中反复出现的固定代码逻辑提炼为针对系统调优的诊断卡片。因此，工具库会随着诊断经验的积累而不断增长。

D. 诊断生命周期 · V. OPSHARNESS 中的自我演化 · A. 轨迹挖掘

OpsHarness 通过 setup 和 diagnose 命令实现诊断流程，随后挖掘带标签的轨迹、综合演化动作，并仅应用通过分阶段验证的提案，从而实现自我演化。轨迹挖掘会提取诊断区块、纳入用户反馈，并依据正确性和诊断成本对会话进行划分。

  • D. 诊断生命周期: Setup 无需针对每个数据集编写代码即可完成遥测数据画像，检测语义列，构建实体和指标清单，并通过 profile YAML 写入 K1。在系统接入时或结构发生变化后，它还可以将已有的系统知识和工具整合进 K1。
  • D. 诊断生命周期: Diagnose 以斜杠命令的形式提供，用户或自动化流程可在 setup 完成后携带查询调用该命令。系统首次接入或结构发生变化时会运行 setup。
  • V. OPSHARNESS 中的自我演化: 自我演化循环包含三个阶段：挖掘轨迹，将证据综合为演化动作，以及应用通过双重门控 sandbox 验证的提案。证据挖掘从正向轨迹中提取成功模式，并从负向轨迹中提取可执行的修复方案。
  • A. 轨迹挖掘: 轨迹挖掘将每个最大的 diagnose 命令区块转换为一条按时间排序的轨迹，同时丢弃 OpsHarness 逻辑之外的片段，将其视为噪声。斜杠命令标记界定会话活动，每个区块在其结束标记处闭合。
  • A. 轨迹挖掘: 问题解决后，轻量级用户反馈提供实际根因，并将每条轨迹的准确性标记为正确、部分正确或错误。反馈钩子请求用户点踩或点赞，而可观测性指标则衡量 token 和时间成本。
  • A. 轨迹挖掘: 这些标签将批次划分为正集和负集，其中 D+ 包含正确轨迹，D− 包含错误轨迹。每次诊断的轨迹成本会与准确性一并记录。

B. 证据挖掘与提案综合 · C. 分阶段双门验证

OpsHarness 将正确与错误诊断中的证据转化为原子提案，用于修改可复用的数据平面 expertise。提案只有通过分阶段的内层与外层验证后才会被接纳；若验证失败，则进行细化或拒绝。

  • B. 证据挖掘与提案综合: 一个提案由一组原子化、带类型的算子组成，每个算子只编辑数据平面状态中的一个 skeleton path、操作或规则，或一张 tool card。应用提案会生成候选 harness 状态 h′ = Apply(h_i, P)。
  • B. 证据挖掘与提案综合: 正确和错误的诊断轨迹会被挖掘为提案，用于编码来自标注证据的可复用结构与修正。正确运行揭示反复出现的诊断顺序，而错误运行则暴露偏离点，支持对比式修正。
  • B. 证据挖掘与提案综合: 反复出现的完整诊断顺序会被提炼为经过裁剪的 K2 skeleton，使后续诊断能够重放关键步骤，而不是重新探索试探性绕路。裁剪针对正确轨迹共有的结构，从而减少低效探索。
  • C. 分阶段双门验证: 每个提案都会在隔离的 sandbox 中测试，只有验证成功后才会触及运行中的 harness。验证器创建一个 stage，复制运行中的 harness，在其中应用提案，并评估生成的候选状态。
  • C. 分阶段双门验证: 内层门要求准确率不下降、成本不显著增加，并且至少有一个目标得到严格改善。其中的严格条件排除了无操作变更，而成本区间允许少量 token 增加，但会拒绝失控的探索。
  • C. 分阶段双门验证: 外层门在跨时间和故障类别维护的多样化留出测试集上检验无回归，确保源案例上的收益能够泛化。仅通过源案例不足以证明提案能广泛改善 harness。
  • C. 分阶段双门验证: 只有在两道门都通过时，提案才会以原子方式晋升；否则会结合失败案例进行最多三轮细化，或被拒绝并丢弃。失败的 stage 会被拆除以回收空间，运行中的 harness 只有在双门接纳后才会更新。

VI. 评估

评估考察 OpsHarness 在自我演化后的有效性、其设计选择的贡献、成本，以及在工业部署中的表现。

  • 评估考察 OpsHarness 的有效性，尤其是在自我演化之后。
  • 评估探究 OpsHarness 的各项设计分别带来了多大贡献。
  • 评估 OpsHarness 的成本。
  • 评估考察 OpsHarness 在工业部署中的表现。

A. 实验设置 … B. RQ1：有效性

OpsHarness 在多样化的公开和工业 RCA 数据上进行评估，采用匹配的 backbone–agent 实例和标准准确率指标。在公开基准上，完整 OpsHarness 的有效性最强，达到 59.0% Final A@1，并通过冷启动知识和自演化显著优于各基线。

  • 1) 数据集：: 评估涵盖两个公开 RCA 基准和一个工业数据集，覆盖多样化的系统、故障类型和噪声特征。OpenRCA 包含来自电信、银行和市场系统的 335 个真实案例，其中包括 46 个节点、68 个容器、176 个服务网格和 28 个根因类别。
  • 1) 数据集：: 时间切分模拟面向未来的部署，避免方法接触未来案例；报告结果取自留出的测试数据。该设置还为 in-context-learning 基线加入了示例检索。
  • 2) 基线与实现：: 每种方法都作为 backbone-model 与 agent-framework 的组合，在 GPT-5.5、Claude Sonnet 4.6、GLM-5.2 和 DeepSeek-V4 上进行评估。Claude Sonnet 4.6 使用 Claude Code，其他模型使用 Codex；OpsHarness 在相同环境和信息下集成到相应的通用 agent 中。
  • 2) 基线与实现：: OpsHarness (no-evolve) 在禁用自演化的情况下衡量冷启动能力，而完整 OpsHarness 则在 Day-0 基础上启用自演化。各实现均使用厂商支持的通用 agent，并提供完全相同的可用信息。
  • 3) 评估指标：: RCA 有效性通过 A@1、A@3 和 Avg Score 进行衡量，评估对象是带标注的根因元组，其中包括组件、故障类型以及适用时的发生时间。A@k 要求 top-k 候选中包含完整元组，而 Avg Score 则根据根因要素提供部分得分。
  • B. RQ1：有效性: 59.0% Final A@1 使完整 OpsHarness 在每个 backbone 上都成为最强框架，超过 no-evolve 的 41.4%、ICL 的 38.4%、Direct 的 36.1%、RCA-Agent 的 17.9% 和 mABC 的 5.6%。Final A@1 是六个子数据集上 A@1 的平均值；该比较涵盖公开基准上的全部 24 个 backbone–framework 实例。
  • B. RQ1：有效性: 自演化在冷启动基础上增加了 17.6 points，而该基础又比 Direct 高 5.3 points，最终相较于裸 agent 总计提升 22.9 points。性能演进为 Direct 36.1% → OpsHarness (no-evolve) 41.4% → 完整 OpsHarness 59.0%。

C. RQ2：各项设计的贡献 … 3) 知识与工具机制：

在四个 backbone 上，self-evolution 持续提升 OpsHarness，而 verification gate 可防止过拟合和回归。演化产物结合了广泛召回的高层知识，以及有选择地召回的高效细粒度规则和工具。

  • C. RQ2：各项设计的贡献: 该消融实验将完整 OpsHarness 与禁用 self-evolution 的版本，以及启用 self-evolution 但移除 verification gate 的版本进行比较，从而分别考察两项设计贡献。每个变体按顺序诊断案例，并将数据流划分为 12 个窗口进行持续评估。
  • 1) 随使用不断改进的 Self-Evolution：: 静态知识无法学习目标系统：no-evolve 基本保持平稳，在不同 backbone 上最终窗口的 A@1 约为 0.2 至 0.6。相比之下，完整 OpsHarness 在 12 个窗口中持续提升。
  • 1) 随使用不断改进的 Self-Evolution：: 完整 OpsHarness 的最终窗口 A@1 为 0.83，而 no-evolve 为 0.43；在四个面板中，完整 OpsHarness 都是准确率最高的变体。在 12 个窗口中，完整 OpsHarness 的 A@1 大致翻倍，例如 GPT-5.5 上从 0.4 提升到 0.9，GLM-5.2 上从 0.5 提升到 0.9。
  • 2) Verification Gate 防止过拟合：: 在 DeepSeek-V4 上，no-verify 的 A@1 从峰值 0.4 降至 0.0，因为较弱的模型可能从源案例中挖掘出虚假模式。一条演化规则提高了网络异常的权重，虽有助于源案例，却在之后错误标记了此前正确的 CPU 类型和内存类型案例。
  • 3) 知识与工具机制：: 更高粒度的知识会被广泛召回，而细粒度的 note-rules 和工具虽被选择性召回，但在被召回时具有很高的有效性。Table III 报告了产物数量、Recall（召回某一产物族的测试案例所占比例）以及 Precision（在召回该产物的正确案例中所占比例）。

D. RQ3：开销 … 1）工业数据集上的结果：

OpsHarness 将单案例诊断成本控制在接近轻量级基线的水平，同时比专用 agent 需要显著更多的资源。在 Company A 的工业数据集上，它在全部六种配置中都提升了相对于 Direct 的 A@1，包括开源技术栈。

  • 1）诊断成本：: 每个案例使用 106k tokens、耗时 325s，使 OpsHarness 尽管将 skills 和 knowledge 加载到上下文中，仍接近 Direct 和 ICL。在两个 benchmark 上取平均后，Direct 使用 112k tokens、耗时 317s，而 ICL 使用 106k tokens、耗时 308s。
  • 1）诊断成本：: 专用 agent 比 OpsHarness 多消耗 1.7×–2.7× tokens，并多耗时 2.3×–3.5× wall-clock，成本显著更高。成本增加主要归因于诊断期间更多的重试和重新规划。
  • 2）Setup、Evolution 和 Verification 成本：: setup 使用 0.82M tokens、耗时 412s，evolution 使用 0.75M、耗时 184s，verification 使用 1.55M、耗时 421s，量化了每轮非诊断开销。setup 在每个数据集上运行一次，而 evolution 和 verification 在每个周期运行一次。
  • 2）Setup、Evolution 和 Verification 成本：: 非诊断 tokens 账单的 49.8% 来自 verification；由于它并行运行留出集诊断，因此占据主导。Evolution 是最轻量的阶段；这些阶段作为 sidecar 很少运行且并行执行，可在大量诊断之间摊销。
  • 3）Harness 占用：: 228KB 是预热后的磁盘占用，由可复用工具、skill library 和演化后的目标系统 knowledge 构成。这些组件分别占用 106KB、95KB 和 27KB；相对于单案例 telemetry，总量可忽略不计。
  • 1）工业数据集上的结果：: 0.74 A@1，相比 Direct 的 0.24：OpsHarness 在 Company A 的全部六种配置中都优于 Direct，包括开源 agent 和模型。在 Open Code 上，使用 GLM-5.2 时达到 0.73 A@1，使用 DeepSeek-V4 时达到 0.57；Direct 对应为 0.23 和 0.12。

2) 案例研究：……IX. 结论

该案例研究展示了 OpsHarness 从系统画像、诊断到反馈驱动演化的自演化闭环。讨论与有效性分析表明，系统变化下性能会平滑退化，失败主要集中在新颖或纠缠的遥测数据上，同时还具备防范非确定性与数据泄漏的保护机制；结论则将 harness 设计定位为发挥通用 agent 能力的关键杠杆点。

  • 2) 案例研究：: 生产案例研究追踪了三天内的配置、诊断与演化过程：OpsHarness 对遥测数据进行画像、为根因排序，并从 SRE 反馈中学习。排名第三的诊断正确识别出上游数据库同步故障，该故障导致重复的空记录查询；SRE 用一句反馈确认了这一点。
  • VII. 讨论: OpsHarness 能够平滑应对系统变化：即使 profile K1 和挖掘出的知识失效，有效的 K0 仍支持冷启动回退，其效果可媲美或超过 bare agent；同时，setup 无需修改代码即可重建 K1。报告中的回退对比为 41.4% vs. 36.1% Final A@1。
  • VII. 讨论: 大多数失败源于首次遭遇未见过的故障模式，另一类则涉及过于纠缠、难以提炼可复用模式的遥测数据；后续自演化会逐步缓解第一类问题。该段指出，第二类样本中超过 75% 具有上述纠缠遥测特征，但该发现的其余部分已被截断。
  • VIII. 有效性威胁: 为应对非确定性 LLM agent 带来的内部有效性问题，评估报告了四个 backbone、两个 agent framework 和六个子数据集上的总体准确率，而不是单次运行结果。这种汇总被作为论文的内部有效性保护措施。
  • VIII. 有效性威胁: 评估通过时间切分的训练-测试划分，以及在诊断和自演化期间阻止访问 ground truth 的 guard script，限制了数据泄漏。使用相同模型的 bare agent 达到 36.1% Final A@1，因此仅凭 backbone 记忆无法解释这些增益。
  • IX. 结论: 结论认为，在具备强大能力的通用 agent 条件下，RCA 的进展更多取决于外围 harness，而不是从头构建专用 agent。OpsHarness 被介绍为一种自演化的外部 RCA harness：在 data plane 中结合分层知识与 idea-card 工具，由 control plane 负责协调，同时从正确和错误的诊断中挖掘实践，并应用双重门控验证。
Loading 2608.25661v1…