技术摘要：超越 LLM 知识截止日期：面向全员的实时内核崩溃修复基准测试

问题陈述

修复 Linux 内核中的系统崩溃（特别是通过 Syzkaller 等模糊测试工具发现的崩溃）仍然是一个关键且尚未得到充分探索的挑战。尽管基于大语言模型（LLM）的智能体（Agent）在用户态软件工程领域已展现出潜力，但其在内核崩溃修复方面的应用面临着显著障碍：

1. 静态基准测试与数据污染： 现有的评估基准（例如 KBENCHSYZ）依赖于静态且陈旧的数据集。这些数据集无法捕捉 Linux 内核快速演进的特性，并且容易受到数据污染的影响，即 LLM 可能记住了训练数据中的修复方案，而非真正解决了新问题。
2. 缺乏标准化的执行环境： 当前的基准测试通常不对执行环境进行具体说明，迫使智能体开发者必须构建沉重且复杂的内核编译与测试环境。这种紧耦合使得在不同的智能体框架之间进行公平、可扩展的比较变得十分困难，尤其是考虑到编译和测试内核补丁所需的时间和资源成本极高。
3. 评估差距： 目前对于最先进的智能体在处理现实世界中新鲜的内核崩溃时的表现缺乏深入见解，特别是在其定位根因以及生成与人类开发者修复方案等效补丁的能力方面。

方法论

为了解决这些局限性，作者引入了一个由两部分组成的框架：KENV 和 LIVE-KBENCH。

1. KENV：智能体无关的标准环境

KENV 是一个标准化的环境层，旨在将智能体工作流与沉重的执行任务解耦。

• 架构： 它使用一个基础 Docker 镜像，其中包含正确提交版本的 Linux 源代码、崩溃上下文以及一个崩溃修复反馈（CRF）工具。随后，通过在基础镜像上应用特定于智能体的叠加层（Overlay）来实例化该智能体。
• 执行： “智能体调用器”（Agent Invoker）在该环境中执行智能体。智能体可以对崩溃进行推理、探索源代码并利用工具。
• CRF 工具： 一个核心特性是 run_kernel 工具，它允许智能体将补丁提交到远程、可扩展的平台（KGYM-SUITE）进行编译和执行。这提供了即时反馈（例如“崩溃已解决”、“崩溃已复现”或“编译错误”），从而实现迭代式的修复策略。
• 目标： 通过标准化环境搭建、执行和反馈过程，KENV 能够在相同的条件下实现不同智能体框架之间的公平比较。

2. LIVE-KBENCH：自我演进的基准测试

LIVE-KBENCH 是一个持续策展新鲜内核漏洞的实时评估框架。

• 数据策展： 它从 Syzbot（向 Linux 内核邮件列表报告 Syzkaller 发现的工具）获取数据。爬虫收集新漏洞，并丰富其元数据（提交信息、复现程序、崩溃报告），并过滤出具有可复现性的漏洞。
• 工作流：
  1. 策展并存储漏洞。
  2. 为每个漏洞调用 KENV 以构建环境。
  3. 注册的智能体生成补丁。
  4. 在多个维度上评估补丁：崩溃解决率、根因定位能力以及与人类修复方案的等效性。
• 指标：
  • 崩溃解决率 (CRR)： 补丁成功停止崩溃的漏洞百分比。
  • 等效补丁率 (EPR)： 与真实开发者修复方案在结构和逻辑上等效的补丁百分比（由 LLM 裁判判定）。
  • 定位准确度： 通过修改的文件和函数的交并比（IoU）进行衡量。

核心贡献

1. KENV： 一个用于 Linux 内核崩溃修复的标准化、智能体无关的环境，它实现了环境搭建的自动化，并将执行任务卸载到可扩展的后端，从而实现可重复且公平的智能体评估。
2. LIVE-KBENCH： 一个包含 534 个新鲜 Linux 内核漏洞（LIVE-KBENCH-2512）的实时、自我演进的基准测试。它支持针对时间敏感性和基于属性的评估，允许研究人员研究分布偏移和数据污染。
3. 实证洞察： 该框架提供了一个公开的仪表板和基础设施来追踪智能体的进展，从而能够研究 LLM 知识截止日期、智能体脚手架（Scaffolds）以及测试时扩展（Test-time scaling）的影响。

实验结果

作者使用各种 LLM 后端（Gemini 3 Pro/Flash, Claude Sonnet/Opus 4.5）在 LIVE-KBENCH-2512 上对三种最先进的智能体（mini-SWE-agent, SWE-agent, OpenHands）进行了基准测试。

• 知识截止日期的影响： 智能体在处理修复时间在 LLM 知识截止日期之前的漏洞时，表现明显优于处理截止日期之后的漏洞。
  • 在 Gemini 3 Pro 上，预截止日期数据的等效补丁率（EPR）比后截止日期数据高出 25%。
  • 崩溃解决率（CRR）也显示出明显的优势（最高提升约 8.7%）。
• 智能体性能：
  • 智能体在首次尝试时达到了 74% 的 CRR（即生成了合理的补丁），但仅有 ~20% 的 EPR（即生成的补丁与开发者修复方案匹配）。
  • 在各类脚手架中，SWE-agent 拥有最高的 EPR，而 mini-SWE-agent 和 OpenHands 则表现出更高的 CRR。整体性能差异相对较小，这表明需要从根本上改变方法才能提高 EPR。
• 反馈（CRF）的影响： 启用 run_kernel 反馈工具使崩溃解决率提高了 29%（在 Mean@3 中从 58.11% 提升至 75.03%）。然而，它并未显著提高 EPR 或定位 IoU，这表明虽然反馈有助于修复崩溃，但并不一定会导致生成符合人类逻辑的补丁。
• 定位： 提供完美的定位信息（Oracle 模式）增加了 EPR，但略微降低了 CRR，这表明当智能体缺乏精确的定位能力时，它们有时会通过修改无关代码来抑制崩溃。
• 成本： 使用 CRF 会显著增加执行时间（聚合后的 run_kernel 延迟比 LLM 推理时间高出约 7 倍）和计算成本。

重要性与主张

本文将 LIVE-KBENCH 定位为软件工程基准测试的一次必要演进。其主要意义在于：

• 缓解数据污染： 通过使用新鲜的、处于知识截止日期之后的漏洞，它能更准确地衡量智能体的泛化能力，而非其对训练数据的记忆能力。
• 标准化： 它通过将智能体逻辑与沉重的执行环境解耦，解决了内核修复评估中的可扩展性和公平性问题。
• 现实基准： 实验结果凸显了当前智能体与人类开发者之间的巨大差距。虽然智能体通常能找到一种停止崩溃的方法（高 CRR），但它们很难生成正确的修复方案（低 EPR），尤其是在面对新颖的漏洞时。
• 社区基础设施： 作者提供了一个公开的仪表板和基础设施来追踪进展，使社区能够研究分布偏移、漏洞属性以及智能体性能随时间的变化。

作者总结道，尽管目前的智能体展现出了潜力，但由于在后截止日期数据上的性能大幅下降以及等效补丁率较低，这表明内核崩溃修复仍然是一个具有挑战性的前沿领域，需要超越当前提示词工程和脚手架技术的进一步研究。