Taming System Complexity: Demystifying Software Engineering Agents in Diagnosing Linux Kernel Faults¶

会议: ACL2026
arXiv: 2505.19489
代码: https://github.com/FudanSELab/LinuxFLBench
领域: 软件工程Agent / 代码智能
关键词: 故障定位、Linux内核、LLM Agent、代码定位、系统复杂性

一句话总结¶

通过建立大规模 Linux 内核故障定位基准 LinuxFLBench，揭示现有 LLM Agent 在复杂系统中的局限，并提出 LinuxFL+ 框架通过目录感知和潜在原因双维扩展，以低成本显著提升故障定位精度。

研究背景与动机¶

领域现状：故障定位（Fault Localization, FL）是软件工程中的经典问题，目标是从给定的 bug 报告和源代码中自动找出有缺陷的代码位置。近年来，大语言模型驱动的 Agent（如 SWE-Agent、AutoCodeRover、Agentless）在通用软件系统上取得了显著进展，在 SWE-bench 基准上达到了 70% 左右的准确率，展现了 Agent 自主探索代码库的能力。

现有痛点：然而，这些 Agent 的评估主要集中在中等规模的通用软件项目（如 Python 库）上，对于真实存在的大型复杂系统（如 Linux 内核）的适用性仍然未知。Linux 内核面临三重独特挑战：（1）代码规模庞大，内核 v5.8 包含 69K 个文件和 28M 行代码，是 SWE-bench 中最大项目的 30 倍以上；（2）可观察性受限，由于内核运行在特权模式且需最小化开销，用户报告的 bug 通常缺乏详细的运行时信息和调试线索；（3）影响因素多维多样，硬件配置、系统负载、时序因素等都可能导致 bug，大大扩展了诊断的推理空间。

核心矛盾：现有 Agent 虽然在通用软件中表现优异，但这些优势可能完全无法转移到 Linux 内核这样的极具挑战的真实系统，需要深入研究其在该领域的真实表现并找到改进方向。

本文目标：一是构建首个大规模 Linux 内核故障定位基准，二是全面评估现有顶级 LLM Agent 在该任务上的表现，三是诊断其主要失败原因并提出有效的增强方案。

切入角度：作者从实证研究出发，先通过大量实验数据揭示 Agent 的真实缺陷，随后针对性地设计改进策略。关键观察包括：Agent 通常能准确识别相关的高层次模块，但在模块内难以精确定位具体文件；同时 Agent 的探索范围过于狭窄，只关注少数可能的原因，遗漏了许多相关的根因。

核心 idea：通过两个维度的结构化扩展来弥补 Agent 的不足——在空间维度上利用目录结构扩展搜索范围，在知识维度上通过直接假设和邮件知识辅助假设扩展潜在原因池，最后通过聚合重排产生最终预测。

方法详解¶

整体框架¶

LinuxFL+ 的工作流分为三个阶段。首先，任意 LLM Agent（如 AutoCodeRover）独立运行，生成初始的可疑文件预测。然后，进入扩展阶段，包括（1）目录感知扩展：从初始预测所在目录出发，扩展候选集范围，让 LLM 在更大的相关文件集合中重新筛选；（2）潜在原因扩展：生成多种可能的 bug 原因假设，每个假设映射到需要修改的文件列表；（3）候选集成：汇聚三个来源的预测结果，使用聚合评分和 LLM 重排最终确定文件顺序。该设计充分利用了 LLM 的生成和理解能力，同时借助结构化的外部知识（代码库结构和邮件知识库）来纠正 Agent 的盲点。

关键设计¶

目录感知扩展:
- 功能：在 Agent 初始预测的目录内进行二阶段搜索，扩大候选文件范围同时保持局部相关性
- 核心思路：虽然 LLM Agent 通常能正确定位到相关的高层次目录（模块），但在该目录内有大量相关文件时容易混淆。本设计首先收集所有初始预测文件所在目录的完整文件列表（Linux 内核中平均每目录 16 个文件），然后提示 LLM 在这个扩展的候选集中重新筛选、排序 top-10 个最相关的文件。这相当于给 LLM 第二次机会在更完整的信息下做决策，利用目录结构这一代码库的显式组织形式作为导向。
- 设计动机：Linux 内核的目录平均每个包含 16 个文件（SWE-bench 是 8 个），这种高密度给精确定位增加了难度。通过显式利用目录边界作为搜索范围，可以在保持模块粒度有效性的前提下，给 LLM 足够详尽的上下文进行微调。
潜在原因扩展:
- 功能：通过多种假设生成策略系统地扩展可能的 bug 原因，每个原因对应一组需要修改的文件，形成多个候选集
- 核心思路：该设计包含两层假设。第一层 直接假设 仅使用 LLM 的预训练知识，提示模型生成 $k$ 个可能导致该 bug 的原因假设，每个假设还需给出对应的代码修复方案和涉及的文件。第二层 邮件辅助假设 引入外部知识：使用检索增强生成（RAG）从 Linux 内核邮件列表（LKML）中检索相关的历史讨论，这些邮件通常包含开发者对类似 bug 的分析。将检索到的邮件内容和原始 bug 报告一起提供给 LLM，促进其生成更多样化、更有根据的原因假设。为防止数据泄漏，只检索 bug 报告之前发送的邮件；为提高检索质量，对 bug 报告进行关键词提炼（行为、原因、预期行为、解决方案四个维度），然后用 BM25 检索 top-10 相关邮件。
- 设计动机：真实的 bug 诊断是一个迭代的"猜测-验证"过程，不能仅依赖初次直觉。通过系统地生成多个假设，可以覆盖更广的根因空间。直接假设利用 LLM 的通用知识；邮件假设引入领域特定的历史智慧，两者互补。实验表明这种多假设策略能大幅提升性能，特别是在 bug 原因分散（如性能问题跨多个模块）的情况下。
候选集成与重排:
- 功能：将三个来源（目录扩展、直接假设、邮件假设）的文件预测聚合为统一排序，作为最终定位结果
- 核心思路：聚合策略采用倒数排名法。对每个候选文件 $f$，分别从三个来源记录其排名 $R_{dir}(f)$、$R_{direct}(f)$、$R_{mail}(f)$（若文件未出现则记为 $\infty$）。计算聚合得分为 $\text{score}(f) = \frac{1}{R_{dir}(f)} + \frac{1}{R_{direct}(f)} + \frac{1}{R_{mail}(f)}$。该公式使得在任意一个方法中排名靠前的文件获得较高分数，在多个方法中都排名靠前的文件进一步得到优先。之后根据得分降序排列所有候选文件。最后，提示 LLM 基于文件路径与 bug 报告的语义对应关系对这个初步排序进行精排，利用 LLM 的语义理解能力进行最后调整。
- 设计动机：三个信息源各有独特视角——目录扩展擅长捕捉结构关联，直接假设发挥 LLM 通用知识，邮件假设提供领域启发。倒数和聚合是一种经典的 rank fusion 方法，既能综合多源信息，又简洁有效。最终的 LLM 重排引入语义意识，避免纯数值聚合可能的死板。

实验关键数据¶

主实验¶

论文构建的 LinuxFLBench 包含 250 个真实 Linux 内核 bug，覆盖 120 个内核版本和 66 个不同的内核子模块（如驱动、网络、文件系统等）。Bug 报告平均长 283 词，对应的代码库平均 28808 个文件、1149 万行代码，远超 SWE-bench（平均 195 词、3010 个文件、43.8 万行）。

表1 展示了文件级故障定位的性能对比：

方法	Recall@1	Recall@5	Recall@10	MRR
BM25（信息检索基线）	0.168	0.328	0.396	0.231
BugLocator	0.127	0.209	0.272	0.215
BLUiR（传统 IR 最佳）	0.228	0.317	0.404	0.321
SWE-Agent	0.416	0.552	0.584	0.476
SWE-Agent + LinuxFL+	0.524	0.720	0.768	0.610
AutoCodeRover	0.388	0.496	0.496	0.435
AutoCodeRover + LinuxFL+	0.500	0.712	0.744	0.589
Agentless	0.368	0.492	0.504	0.419
Agentless + LinuxFL+	0.440	0.684	0.724	0.549

关键观察：（1）现有 Agent 虽然远超传统 IR 方法，但在 LinuxFLBench 上表现仍远低于在 SWE-bench 上的表现（top-1 recall 下降 15%+ 以上），揭示了系统复杂性的真实挑战；（2）即使最佳 Agent（SWE-Agent）的 Recall@1 也仅 41.6%，说明 Linux 内核 FL 仍是极具挑战的任务；（3）LinuxFL+ 对所有三个 Agent 都带来了显著提升，SWE-Agent 的 Recall@1 从 41.6% 提至 52.4%（+10.8%），AutoCodeRover 从 38.8% 提至 50.0%（+11.2%）。

消融与细粒度分析¶

表2 展示了不同难度下的表现（按 bug 报告中是否显式提及文件名来区分）：

难度等级	Agentless 基线	AutoCodeRover 基线	SWE-Agent 基线	LinuxFL+ 平均提升
Easy（文件提示清晰）	0.605	0.623	0.664	+0.105
Hard（无文件提示）	0.273	0.287	0.341	+0.127

结果表明 LinuxFL+ 特别擅长处理"难"的情况（无显式文件线索），这正是扩展策略的目标场景。在症状层面，LinuxFL+ 对模糊症状的 bug（如性能问题，基线 MRR 0.165）的提升最显著（提升至 0.458，+177%），而对症状清晰的 bug（如 Watchdog 错误）虽然也有提升，但基线本身已很高（0.833）。成本方面，LinuxFL+ 每任务额外使用 11.8K-15.3K tokens，成本约 $0.04，仅为各 Agent 基础成本的 10% 左右。

亮点与洞察¶

首个大规模内核 FL 基准：过往的内核相关基准要么规模太小（Linux-3.16 仅单一版本）、要么来源不切实际（模糊器检测的崩溃）。本文的 LinuxFLBench 覆盖 250 个真实用户报告的多样化 bug，跨越 120 个版本和 66 个组件，是首个真正反映内核故障定位难度的基准，对后续研究极具参考价值。
揭示 Agent 能力的真实边界：通过实证数据清晰地展示了通用 Agent 在大型复杂系统中的局限——性能掉点 15%+ 以上，并定性分析出两个主要失败模式：混淆相关文件和探索范围过窄。这些洞察对理解何时何地应该增强 Agent、如何有效增强具有重要指导意义。
低成本、高效的增强方案：与从头重新训练 Agent 或微调模型相比，LinuxFL+ 作为一个后处理框架，仅需极少额外成本（$0.04/task）却能带来显著性能提升。特别是邮件知识的引入展示了如何有效融合领域特定知识和通用 LLM 能力的范式。
设计的通用性：虽然针对 Linux 内核设计，但目录感知扩展和潜在原因扩展的思想完全可迁移到其他大型复杂系统（如操作系统、数据库等）的故障定位任务，具有超出本文范畴的推广空间。

局限与展望¶

作者承认的主要局限包括：

LLM 选择的局限性：虽然实验中使用了 GPT-4o 和 Qwen3-32B，但重点仍在 GPT-4o。其他更小或更大的模型、特别是开源模型的表现还需深入探索。
邮件数据的粗粒度利用：LKML 邮件内容丰富但杂乱，过滤策略（避免外链、限制修改文件数等）仍然较为启发式，未来可以探索更精细的邮件内容抽取和匹配方法。
函数级定位仍需改进：表显示函数级 Recall@1 仅 0.089-0.138，远低于文件级，说明 LinuxFL+ 虽然改进了文件级定位，但细粒度定位的挑战仍未充分解决，可能需要更细致的代码理解策略。

具体改进方向：

探索更高级的邮件检索策略，如结构化邮件解析、多跳推理等，以提取更精准的根因知识。
为不同内核组件定制专有的假设生成策略，而非全局通用策略。
结合程序分析（如数据依赖、控制流）来增强基于 LLM 的推理。

评分¶

新颖性: ⭐⭐⭐⭐ 首个系统评估 LLM Agent 在 Linux 内核故障定位上的研究，基准构建和问题定义都很清晰。增强方案的两维扩展思想虽然相对直观，但组合方式有效且落地性强。
实验充分度: ⭐⭐⭐⭐⭐ 250 个真实 bug 的基准规模可观，对三个主流 Agent 的评估系统全面，消融实验揭示了各组件的贡献，细粒度分析（症状、难度、成本）覆盖面广。方法级 FL 的扩展评估虽然指标较弱，但加强了多维度论证。
写作质量: ⭐⭐⭐⭐ 文章组织清晰，从基准构建→问题分析→方案设计→全面实验的逻辑递进自然，可读性强。定性分析的两个失败模式（混淆和探索窄）诊断明确。少许地方定式化表述较多，创意表达欠缺。
价值: ⭐⭐⭐⭐ 对工业界 Linux 内核维护团队有实用价值，基准对后续研究的参考意义重大。增强方案的成本低、效果显著，可快速落地。但受限于内核特殊性，通用化程度有限；对 Agent 根本架构改进的启发有限。