Beyond Fault Localization: A Trajectory-Level Study of LLM Agents for Microservice Root Cause Analysis 精读

论文链接：arxiv.org/abs/2608.21310 发表时间：2026年8月（arXiv v1: 2026-08-21） 发表机构：香港中文大学（深圳）CUHK-Shenzhen × 西安交通大学 领域：cs.SE（AIOps / 智能体 / 根因分析） 作者：Qisheng Lu、Aoyang Fang、Junjielong Xu 为共同一作，Aoyang Fang 与 Pinjia He（何佩佳）为共同通讯作者；西安交大的 Jin’ao Shang 参与合作

一、论文背景

1.1 微服务 RCA 是什么

微服务架构是当今大型云应用的主流形态。它的代价是：一个局部故障（比如某个服务的内存泄漏）会沿着松耦合的服务调用链一路传播，引发级联故障。故障发生时，值班的地表可靠性工程师（SRE）必须从分布式追踪、日志、指标这"遥测三件套"中把故障源挖出来，修复才能开始。这个"从症状回溯到病根"的过程，就是根因分析（Root Cause Analysis, RCA）。

1.2 现有评测为何只看终点

自动化 RCA 研究已经积累了大量方法，而基准驱动的研究几乎都把 RCA 简化成一个"服务定位"任务：预测哪个服务引发了故障。于是 Top-k 定位准确率（Acc@k）、MRR、MAP 这些指标成了通用标尺。它们确实让不同方法可以横向比较，但也把整个诊断过程压缩成了一个最终标签。

论文开篇的 Figure 1 给了一个极具说服力的例子：一个 RCA 智能体的轨迹显示，它在第 37–40 步就已经到达了真正的故障源服务，却没有检查该服务的指标（决定性证据被省略），随后回头复查症状，最终报告了受影响服务作为答案——诊断错误。终点指标只能告诉你"答错了"，无法解释为什么错、错在诊断的哪一步。

1.3 SRE 为什么需要传播路径与证据

一个类比：终点评测好比只看医生开的药对不对，轨迹级评测则是检查医生有没有做正确的检查、推理链是否成立。因为修复动作是基于诊断执行的，SRE 需要的不只是一个根因标签，还有让这个标签可信的证据与推理——否则无法判断"这个自动化诊断是否值得直接执行修复"。同一个正确的标签背后可能是强证据也可能是弱证据（甚至是幸运猜测）；而一个错误标签只有在其失败的推理过程可被检视时，才对持续改进有用。

有意思的是，正是工具使用的 LLM 智能体让这个缺失的"诊断过程"重新变得可见：智能体通过可观察的步骤行动（查询遥测、修正假设、综合证据），运行后留下轨迹——智能体消息、遥测查询、工具返回证据的完整记录。轨迹可以暴露智能体"如何调查"，而不仅是"给出什么答案"。

二、论文定位和关联工作

论文处在微服务 RCA、工具使用 LLM 智能体、智能体轨迹分析三条线的交汇处，核心贡献是补上两块被忽略的拼图。

传统 RCA：四大方法家族——统计相关性、基于图的故障传播、因果推断、多模态可观测性数据上的学习式框架——都只返回根因排序，不返回推理过程。

LLM-based RCA：分为工作流与智能体两派。工作流派把多模态遥测预处理成结构化提示做单次推理（分类、置信度估计、解释修复），但系统状态的单张快照无法捕捉专家诊断那种渐进式、假设驱动的本质；智能体派（MABC、OPENRCA 等）在多轮工具调用循环中推理，是更过程化的方向。但无论哪派，几乎都只在终点层面被评估——缺少过程级真值是根本原因。

通用智能体：深度研究智能体和编码智能体在知识密集任务上已能匹敌甚至超越领域专用方法。论文把 THINKDEPTH.AI、AIQ、TASKWEAVER、CLAUDE CODE 这些"非 RCA 原生"智能体与 RCA 专用智能体放进同一测试装置直接对比——此前从未有人系统做过。

轨迹分析：已有工作可视化调试智能体行为、挖掘历史轨迹优化智能体；三个同期工作（Riddell 等的检测后 RCA、Kim 等的单架构跨模型轨迹诊断、STAR 的事后修复）与本文最接近。差异在于：本文直接在遥测数据上评估多个真实智能体框架，对照人工标注的传播路径真值，并把挖出的失败模式转化为预防性干预（DIAGGUARD）。

与 RCABench 的关系：本文使用的基准 RCABench 本身出自同一团队（arXiv:2510.04711），但 RCABench 只提供最终根因标签，本文在其上补齐了过程级标注——这是两代工作的接力点。

三、问题定义

论文把要解决的问题抽象为一个"诊断过程可观测性"问题，可以形式化为两点：

**第一，终点正确性无法区分幸运猜测与真实因果推理。**同样一个正确的根因标签，可能来自完整的证据链，也可能来自对表面症状的草率排名。终点指标对这两者给出相同分数，导致它既高估了弱诊断，也无法定位错误诊断的可改进环节。

第二，轨迹要成为可评估的过程证据，还缺两样东西。（1）过程级真值：此前因果图工作捕获的是统计推断的服务依赖，不是某次故障实际走过的路径；智能体轨迹分析又缺少领域级真值对照。本文需要的真值是服务级故障传播路径——故障从故障源服务经服务依赖跳数到达观测症状的路线，形式化为传播图 G*=(V*, E*)，其中节点是受故障影响的服务，有向边是传播步骤（通过逻辑服务调用或物理资源共享实现）。（2）轨迹规范化：异构智能体的轨迹格式和工具接口各不相同，必须归一为"消息—遥测查询—返回证据"的可比结构，否则任何指标都无法回答"智能体是否导航到了相关证据"“每一步的操作意图是什么"“错误诊断为何复发”。

四、问题解法

4.1 传播路径标注：给过程级评估造真值

RCABench 标注了每个案例的根因，但没有标注从根因到 SLO 告警服务的服务级路径。作者自己补：依据故障注入元数据（目标服务与故障窗口）、注入前后的追踪/指标/日志、以及 TrainTicket 静态服务调用图，重建每个案例的传播图 G*。可靠性上，一位作者标注全部 500 案例，第二位独立随机标注 100 例，二者在 93% 的案例上一致。

4.2 轨迹收集与指标体系

在 RCABench 的 1430 个案例中无放回随机抽样 500 例，六个框架 × 共享 Qwen 骨干 + 一个框架换 Sonnet 重跑，共七个"框架—模型"配置，收集 3500 条推理轨迹。每条轨迹是"思考—动作—结果"三元组序列；结尾由一个压缩提示让智能体统一汇报预测根因与自报的因果传播图 G。指标分四层：

• 终点：Acc@1（预测根因落在真值集合内）；多次运行时加 pass@k（k 次内至少一次正确）。
• 重构：Node F1（受影响服务集合恢复程度）与 Edge F1（有向传播边重构程度），对照 G* 计算。
• 难度：因果链深度 d*（G* 上根因到 SLO 告警服务的最短路长度）。
• 预算：有效轮数 rds、千 token 数 ktok、按骨干牌价折算的美元成本。

4.3 行为视图与意图视图

行为视图把每一轮约化为一个"主服务”（该轮最接近根因的服务，平手时取新访问或高频访问者），再打两类标签：10 种导航转移（前进 Step/Dive、后退 Ascend/Backtrack、平移 Branch/Reprobe、回归 Rejoin/Retrace、脱轨 Stray/Wander 五族）刻画调查方向；4 种证据利用（utilized/partial/ignored/no_data）刻画下一轮是否基于上一轮返回的决定性证据行动。

意图视图给每条 SQL 动作打一个 SRE 诊断意图标签（11 种：symptom_scan、log_inspect、keyword_search、trace_follow、callgraph、network_flow、resource_probe、metric_dump、lifecycle_probe、metric_enum、service_enum）加 6 个确定性标签轴（粒度/窗口/时序/遥测发射/资源族/症状信号）。92,501 条 SQL 动作由固定的 LLM 分类器（claude-opus-4.8）按 LLM-as-judge 范式标注；人工分层抽查 1000 个标签，两位作者一致率 99%（Cohen’s κ=0.83），分类器相对共识正确率 97%。

4.4 失败模式编码：三类证据处理失败

对 154 条失败轨迹（Sonnet 50 条、Qwen 104 条），对照每种故障类型的"期望证据"（能确认相关服务与依赖的类型化查询集），用开放编码法提炼出三族失败，人工编码一致率 93.5%（144/154）：

• 协议遗漏（OMIT）：证据在遥测中可得但从未查询——无基线对比（OMIT1）、无调用边测试（OMIT2）、无具名资源探针（OMIT3）、无同信号同伴排名（OMIT4）、无粒度下钻（OMIT5）、无时序校验（OMIT6）。
• 语义误读（MIS）：证据查到了但读错了——沉默当作健康（MIS1）、最响的信号被过度信任即"显著性别偏"（MIS2）、遥测文本的服务语义读反（MIS3）。
• 无证据推断（GEN）：与单一证据无关的推理失败——早期锚点锁死（GEN1）、编造出 schema 之外的因果状态（GEN2）、工具受挫后放弃证据通道（GEN3）。

4.5 DIAGGUARD：从 taxonomy 到防御架构

失败分类不只是诊断书，更是设计规格。三个失败族暴露出裸推理循环的一个结构性缺陷：既"欠接地"（承诺从未收集或编造的证据），又"欠校验"（下结论前不复查证据读法）。DIAGGUARD 用两段纵深防御包裹推理核心（Diagnostician，即适配 AIOps 2025 遥测接口的 THINKDEPTH.AI）：

• Grounder（前置接地）：定位之前系统巡视可用观察——把"遥测里实际有什么"（去重值、更宽的证据面）怼到智能体面前，针对 OMIT 族。
• Verifier（后置校验）：对照观察审计诊断——诊断纪律自查（例如"任何信号成为根因锚点前，必须与正常窗口对比；若错误/延迟在正常期已存在，那是慢性背景而非事件证据"这一条就映射自 OMIT1）+ 结论前的健全性检查，针对 MIS 与 GEN 族。

每条检查都从具体的挖掘失败模式映射而来，且在验证运行前冻结。

五、评估指标与实验证据

5.1 RQ1：终点与成本——架构决定下限，骨干决定上限

六个框架（共享 Qwen）的 Acc@1 分成明显两档：开放式自适应调查的 THINKDEPTH.AI（79.2%）、CLAUDE CODE（79.6%）、AIQ（77.6%）占据头部，且彼此只差 2.0 个百分点；约束更紧的设计依次落后——按固定计划走的 TASKWEAVER 65.2%，能出答案就提交的 OPENRCA 46.6%，完全不迭代证据的 MABC 42.6%。值得注意的是，头部没有一个是为 RCA 而生的。换骨干（Sonnet 跑 THINKDEPTH.AI）直接拉到 90.0%（+10.8 个百分点）——模型增益是框架间差距的五倍多，骨干是主导杠杆。

深度衰减：所有 Qwen 框架的 Acc@1 都随因果链深度从 d*=2 跌到 d*=5（如 CLAUDE CODE 89.5→57.1、AIQ 86.8→42.9），而 Sonnet 基本不衰减（85.7–96.8%），最强与最弱骨干的差距在最难案例上拉到最大。

Edge F1 全面落后 Node F1：每一行都是如此（MABC 0.41 对 0.09，CLAUDE CODE 0.76 对 0.57）。从正确到错误案例，Node F1 下降 16–32%，Edge F1 下降 43–67%——失败的运行仍能检测出多数异常服务，只是无法把它们串成传播路径。识别异常节点只需检测异常遥测；恢复有向边则要推断服务之间的传播方式，是更难、更有区分度的能力。更扎心的发现是：即便定位正确，✓ Edge F1 从不超过 0.67，且把 Acc@1 抬高 10.8 个百分点的模型替换几乎没有抬高这个重构天花板（Node F1 0.82 对 0.83，Edge F1 0.67 对 0.66）——正确答案下面常常只有一张残缺的因果图。

预算不预测质量：头部智能体每案消耗 45–54 有效轮、超 1500 ktok、约 0.2 美元；约束型智能体停在 700 ktok 以下。但所有迭代配置中，错误案例跑的轮数比正确案例更多（最多多 11.4 轮），且两个 F1 都更低——多出来的轮数是无产出的搜索，不是证据积累。

5.2 RQ2：行为与意图——成功的调查"贴着故障影响面走证据"

正确的运行靠 Reprobe（同深度重查在路径上的服务）推进，错误的运行则频繁 Stray/Wander（脱轨游走）与 Retrace，且更多忽略上一轮结果或查空。两个骨干的真正分歧在证据接地：Sonnet 有 54.3% 的轮次基于上一轮结果行动，Qwen 只有 24.9%——Sonnet 的回退与前进是证据引导的确认，Qwen 则无视返回证据在浅层深层节点间摆动。

意图层面，Qwen 卡在浅层的 trace_follow 与 keyword_search 循环里（连续 5 个 trace_follow 的意图 5-gram 每轨迹出现 0.96 次，Sonnet ≤0.12 次）；Sonnet 则在轨迹中段转向 metric_enum、callgraph、resource_probe（82.8% 的轨迹用到，Qwen 仅 16.6%）与 network_flow。这直接映射到按故障类型的准确率差距：最需要具名资源指标的类型差距最大（RESOURCE 75% 对 94%、CODE(JVM) 66% 对 93%），而 NETWORK（82% 对 89%）接近、HTTP 持平（88% 对 87%）。意图 repertoire 的广度决定了搜索能到达的深度，窄 repertoire 把智能体锁在证据的一个浅切片里。

5.3 RQ3：失败 taxonomy 的跨模型规律

证据锚定的两族失败刻画了两种"推理姿态"：Qwen 主要败于省略（OMIT1 基线缺失 51.9%、OMIT3 资源探针缺失 63.5%，均远高于 Sonnet），Sonnet 主要败于误读（MIS3 语义读反 86.0%、GEN2 编造 schema 外状态 82.0%，远高于 Qwen 的 20.2%）。Sonnet 有更强的假设新方向的能力，但联想过强时因幻觉出错、综合时难以在矛盾信号中钉死要害。

5.4 RQ4–RQ5：DIAGGUARD 的独立验证

验证刻意选在 held-out 设置：不同厂商骨干（豆包 Seed 2.0 Pro）、不同基准（AIOps 2025，400 起故障、十个核心服务）、不同服务拓扑。结果：Acc@1 从 43.5% 提到 52.5%（+9.0），pass@3 从 56.9% 提到 67.1%（+10.2），pass@5 从 62.3% 提到 73.0%（+10.7），九种故障类型全部为正增益，从 +1.0（DNS，44.8% 对 43.8%）到 +20.8（I/O，22.9% 对 2.1%），基础设施层的 Node 类型从 4.1% 翻到 19.5%。

消融显示两段防御近可加：只留 Grounder +4.5，只留 Verifier +4.1，完整 +9.0。预算上还有个反直觉细节——最贵的配置（只留 Verifier，343.8 ktok）增益最小，全栈反而更便宜（318.5 ktok）。

绝对精度为何低于 RCABench 上的数字？论文给两个原因：AIOps 2025 一半故障类型位于服务层之下（存储节点、Pod 层），根本不触发 SLO 告警，智能体"起点即盲"；且目标粒度按故障类型分别指定在服务/Pod/节点某一层，而 RCABench 统一在服务层计分。

六、效果优势的根源解释

**为什么 grounding + verification 有效？**因为失败归因显示错误主要源于证据处理环节而非知识缺失：Qwen 不是"不懂微服务"，而是"该查的没查"（OMIT 族高发）；Sonnet 不是"查不到"，而是"查到了读错、读不矛盾"（MIS/GEN 高发）。两段防御正好一一对应地封住证据闭环的进出口——Grounder 保证决定性证据进入上下文（治 OMIT），Verifier 保证读法与结论被对照观察复核（治 MIS 与 GEN）。消融的近可加增益也印证二者互补而非冗余：一个拓宽证据面，一个压实纪律。Figure 6 的案例很典型：TiKV 存储节点的磁盘 I/O 故障只在下游表现为尾延迟，基线锚定在长期背景噪声大的 Ad 服务上出不来（MIS2+OMIT1/3/5/6+GEN3 多种旧模式同时复发——也证明失败模式在新模型新数据上仍然成立），DIAGGUARD 穿过服务层下钻到基础设施层定位到真根因。

**为什么轨迹级评测有必要？**三个证据链：其一，正确与错误案例的 Edge F1 差距（43–67% 对 16–32%）远大于 Node F1 差距，终点指标根本看不见"重构传播"这个维度；其二，即便 Acc@1 高达 90% 的 Sonnet，✓ Edge F1 天花板仍是 0.66——“能点名根因"与"能重构因果"是两种能力，只有前者被现有基准度量；其三，失败轨迹的编码（154 条全部归入三族）证明错误不是随机的，而是有结构、可复用、可防御的——这正是终点指标永远给不出的改进路线图。

七、必要知识反推

要做出这项研究，以下三层知识是必备的，反推如下：

领域层：微服务故障如何经服务调用与资源共享跨服务传播；遥测三件套（trace/metric/log）各自的证据价值与查询方式（文中统一封装为 SQL over telemetry）；SLO 告警与"服务层之下故障不触发 SLO"的盲区问题；TrainTicket、RCABench、AIOps 2025 等基准的结构与差异；SRE 真实诊断的意图词汇表（这正是 11 种意图 taxonomy 的来源）。

方法论层：轨迹规范化与"思考—动作—结果"三元组建模；过程级真值的人工标注与双标注信度检验（93%/99%/93.5% 三处）；LLM-as-judge 的用法与人工校验边界；开放编码构建 codebook 的扎根理论式流程；对照传播路径的导航/证据利用标签体系设计；控制变量式的七配置实验设计（框架效应与骨干效应分离）。

工程层：把六个异构智能体框架适配到同一 SQL 遥测接口的 harness 工程；92,501 条 SQL 动作的批量标注管线；跨骨干厂商、跨基准、跨拓扑的 held-out 验证设计（这是"经验可迁移"论点成立的关键）；按 token 牌价核算成本的成本-效果联合报告。

八、通用性灵感

**灵感一：过程审计优于终点审计。**任何诊断型、推理型系统（不止 RCA，还包括代码审查、法律检索、医学辅助诊断、深度研究报告）都不该只检查最终答案，还应检查证据链完整性——答案对不等于过程对（幸运猜测），答案错时过程记录是唯一改进素材。这篇论文给了一套可直接移植的方案：给"理想过程"造真值 + 把执行轨迹对照真值打标签。

**灵感二：失败 taxonomy 是改进路线图。**把错误案例系统编码成少量高复现的失败族（本文三族十二式），每族映射一条防御性检查——“先归因、再设计"的顺序让每个工程改动都有证据支撑，避免了"堆 trick"式改进。任何 LLM 应用上线前的失败分析都可以走这条"开放编码 → codebook → 模式到防御映射"的流水线。

**灵感三：防御性包装是 LLM 系统加固的通式。**前置 grounding（让系统先穷尽可用观察再表态）+ 后置 verification（表态后对照观察自查）是答案无关的两段式包装，不改动核心推理模型就能拿到近可加的增益。这个"外壳模式"对任何容易省略证据或过度自信的 LLM 系统都适用——成本只是一次推理循环的加粗，收益却随失败族的覆盖率扩展。

**灵感四：更强模型不自动修复结构性短板。**换骨干带来 +10.8 的终点增益，却几乎没抬高因果重构天花板（Edge F1 0.67 对 0.66）——模型能力掩盖不了评估维度缺失。评估体系要先能"看见"短板，模型的进步才有方向。

附录：关键数字速查