DistDebug-Bench：文件能找到，根因块对不准

DistDebug-Bench: Can LLM Agents Diagnose Bugs in Distributed Systems? DistDebug-Bench：大语言模型智能体能诊断分布式系统中的缺陷吗？

Yuxuan Jiang Chenglin Liu John Rose1 Mason Miller Ruthesh Thavamani Juntao Wu Yinwei Huang1 Jiahao Xu Peng Huang University of Michigan（密歇根大学）†

译注：原文把作者姓名与单位写在同一行；John Rose 与 Yinwei Huang 姓名后的“1”疑为上标脚注被压成普通数字；“University of Michigan †”是机构名而非作者，“†”所指脚注未出现在所译范围内。译文保留原拼写与标记，仅在单位英文后括注中文。

###### 摘要

大语言模型智能体（LLM agents）在软件工程任务中展现出很强的潜力，例如竞赛编程与代码合成。然而，现有基准大体聚焦于小规模设定，例如自包含的 Python 模块，使得分布式系统这一类至关重要的生产软件未得到充分考察。我们提出 DistDebug-Bench（分布式调试基准），一个用于评测智能体在代码层诊断复杂系统故障之能力的基准。它从 11 个广泛使用的分布式系统中整理出 120 个高质量的真实缺陷，覆盖 5 种编程语言与 10 种失效模式。通过对最先进大语言模型与智能体的广泛评测，我们发现当前智能体与真实世界调试任务之间存在显著差距。一个反复出现的差距是隧道视野（tunnel vision），它源于缺少显式的推理结构，以及由不一致的工具使用范围所带来的非确定性（nondeterminism）。基准与评测器可在 https://github.com/OrderLab/distdebug-bench 获取，智能体轨迹与排行榜见 https://distdebug.com。

译注：原文作 “A recurring gap is tunnel vision due to a lack of explicit reasoning structure and nondeterminism from inconsistent tool-use scope.” 主谓用单数 “a recurring gap is”，却并列了隧道视野与非确定性，“due to” 的修饰范围也不清楚。译文按字面把二者都处理成这一差距的来由，未改写成后文里相互独立的两个问题。

1 引言

大语言模型（LLM）与智能体在软件工程任务上取得了迅速进展，包括代码合成、仓库导航与问题修复。早期代码基准衡量大语言模型在短程序合成上的能力 [4, 3]；编程竞赛基准评测更具挑战性的算法问题求解 [12, 36]；RepoBench 衡量跨文件的仓库上下文使用 [17]；其后的 SWE-bench 与 SWE-bench Verified 等基准评测智能体能否通过生成一个通过测试套件的补丁来解决 GitHub 问题 [14, 6]。这些基准有助于塑造模型与智能体运行框架（agent harness）这两者的设计。

然而，现有基准评测有许多聚焦于小规模或局部范围的设定，例如独立函数、自包含模块以及库风格的仓库。这些设定是有用的，但留下一个关键的真实世界目标未得到充分考察：调试大规模生产系统。现有评测也常常强调补丁生成，而这会把诊断与修复合成混为一谈。一个补丁可能压住症状，却没有处理根因；即便最终修复只改动少数几行，找到该原因也可能需要理解一条长得多的因果链。因此，在许多生产工作流中，工程师必须先诊断故障，再编写恰当的修复。这一调试工作流至关重要，却没有被现有基准直接衡量。

分布式系统调试是这一空白中特别重要、也特别有挑战性的设定。生产级分布式系统，包括分布式存储、协调与流处理，支撑着现代计算服务。它们的故障代价高昂，并且由于若干原因而难以调试。第一，这些系统的代码跨许多子系统与分层抽象，规模达数百万行，从而形成一个巨大的搜索空间，真正的根因只占其中极小的一个子集。第二，故障涉及跨模块、网络调用与服务层级的交互。观察到的症状常常只暴露下游效应，而发源故障远在他处。第三，可用证据嘈杂且不完整：问题报告、日志、栈追踪与制品只提供部分观测。大规模分布式系统还会经历症状含糊的灰色故障（gray failures）[11, 18]。因此，调试要求在薄弱证据下从高层症状推理到低层代码。开发者需要生成并检验相互竞争的假设，把证据与代码上下文相互印证，跨模块以及历史设计决策追踪因果关系，并在新证据出现时修正假设。于是，分布式系统调试考验着对大语言模型与智能体设计至关重要的能力：长上下文检索、大型仓库导航、多跳因果推理、在嘈杂且不完整的证据下做决策，以及信念修正。

为填补这一空白，我们提出 DistDebug-Bench，一个用于评测大语言模型智能体对真实分布式系统故障做代码级诊断的基准。在每个基准实例中，给予智能体一份事件报告、伴随证据（例如栈追踪）以及修复前的仓库快照，智能体必须识别出一个或多个最能解释所观察故障的源代码块。输出对照人工标注的标签加以评判，这些标签捕捉根因区域。该基准包含来自 11 个分布式系统、5 种语言的 120 个经整理事件，以及 218 个黄金根因块。它捕捉了使分布式系统调试变得困难的那些性质：45% 需要多个块才能表达根因，23% 跨越多个文件，69% 的报告没有提及黄金方法，63% 不含可用的内部栈追踪。基准仓库见 https://github.com/OrderLab/distdebug-bench，项目文档与更新见 https://distdebug.com。

我们在该基准上评测最先进的大语言模型与智能体。结果揭示出宽泛的仓库导航与精确诊断之间存在显著差距。最强配置达到很高的文件级覆盖率，但块级覆盖率（block coverage）与精确率低得多。智能体常常能找到一个相关组件，却未能定位作为因果源头的那些代码行。对不透明报告与跨组件缺陷，性能下降最为明显。通过检查轨迹，我们发现一种反复出现的失效模式：智能体很早便承诺于一个看似合理的局部解释，而当最初的搜索范围错过因果区域时，很少能够挽回。我们将这种行为称为隧道视野，并分析它如何由证据结构与工具调用轨迹产生。非确定性进一步加剧这一问题：即便是领先方案，也会在 17% 的事件上给出不稳定的诊断（flaky diagnoses）；在没有栈追踪的不透明报告上，这一比例升至 26%。

我们的贡献如下：

• • 一项面向分布式系统诊断的基准任务，其中智能体定位最能解释所观察故障的修复前代码块。
• • 一个由广泛使用的分布式系统中的真实故障整理而成的数据集，其标签设计流程侧重于可复现性与非平凡的因果结构。
• • 对当前大语言模型智能体及其运行框架的实证评测，显示出在精确因果定位上的差距，对弱证据故障与跨组件故障尤其如此。
• • 一项失效模式分析，指出可靠调试所面临的关键障碍。

2 相关工作

代码生成与仓库上下文基准。 HumanEval 与 MBPP 等早期代码基准，针对短编程任务评测功能正确性 [4, 3]。LiveCodeBench 与 LiveCodeBench Pro 以更新的竞赛编程任务以及更广的代码执行信号延续这一路线 [12, 36]。RepoBench 等仓库上下文基准超越单文件合成，测试跨文件的检索与补全 [17]。这些基准衡量代码合成能力，而不是故障诊断。

缺陷、修复与调试数据集。 Defects4J、ManyBugs、Bugs.jar、Bears、BugSwarm 与 BugsInPy 等长期延续的软件工程数据集，提供可复现的真实缺陷以及失败版本与通过版本，用于测试、故障定位与自动程序修复 [15, 16, 26, 19, 30, 31]。DebugBench 等较新的大语言模型调试基准，直接测试模型能否修复或推理被注入的有缺陷代码片段 [29]。在这些数据集中，主要判定依据（oracle）通常是一套测试、一个已修复版本，或一个片段级修复目标；诊断并不被直接评测。DistDebug-Bench 显式衡量根因定位。智能体必须识别出精确的因果块。它面向大规模分布式系统。它的缺陷取自有挑战性的真实世界故障。它的诊断任务刻画真实事件所具有的多来源、嘈杂证据。

问题修复智能体基准。 SWE-bench 把评测目标从独立合成转变为真实 GitHub 问题的修复，后续套件加入了人工核验、可视化软件领域、实时任务采集、多语言生态系统、更广的仓库语言，以及长程的企业风格任务 [14, 6, 33, 35, 34, 25, 9]。SWE-Gym 进一步面向软件工程智能体的训练环境与验证器 [23]。DistDebug-Bench 共享基本形式（仓库级上下文与自然语言问题报告），但在若干轴向上有所不同：（1）它们为补丁打分，而 DistDebug-Bench 直接为根因定位打分；（2）SWE-bench 风格的实例以因果链较短的单进程项目为主；（3）它们的评测需要一套测试，这一约束使整理过程偏向那些其修复能被既有测试执行到的缺陷。对许多分布式系统故障而言，在诊断之时很少已经存在回归测试。

运维基准。 近期基准评测大语言模型智能体在信息技术自动化与故障定位上的表现。AIOpsLab 在微服务中评测 AIOps 智能体，包含故障注入、负载生成与遥测导出 [5]。ITBench 在各项信息技术自动化任务上评测人工智能智能体 [13]。SREGym 在一个受控平台中评测站点可靠性工程（SRE）智能体 [7]。OpenRCA [32]、RCAEval [24] 与 PetShop [10] 等基准评测大语言模型的故障定位：根据遥测、指标、追踪以及被注入的性能异常，识别出有故障的服务、机器或资源。这些基准对 AIOps [8] 工作流是有价值的。它们通常在遥测数据上运作，并聚焦于粗粒度定位。DistDebug-Bench 处理一个互补的问题：精确的源码级调试。在事件响应中，工程师仍然需要完成最后一公里的推理，把症状连接到代码中的根因块，而这一步往往最为耗时。DistDebug-Bench 评测大语言模型在这一任务上的能力。它保留仓库级的、以源代码为根据的设定，同时捕捉分布式系统调试所特有的薄弱证据、交互与含糊性。

3 基准

图 1：DistDebug-Bench 任务流程。

DistDebug-Bench 是面向真实世界分布式系统故障的代码级诊断基准。DistDebug-Bench 在真实世界的系统维护工作流中评测编程智能体：在这种工作流里，开发者必须从高层症状出发，依据部分证据形成并检验多个因果假设，从而探索可能的根因，并在施加任何修复之前，识别出根因被编码在代码中的何处。每个基准实例要求智能体根据一份事件报告、一份贴近真实的证据包以及修复前快照，识别出最能解释所观察故障的那个代码块或那一组代码块。

3.1 任务工作流

图 1 展示任务流程。面向智能体的输入包括一份事件报告、日志或栈追踪等问题侧制品、修复前的仓库快照，以及一个结构化输出模式。修复性改动与人工根因标签被留出，供标注与打分使用。智能体必须返回一个或多个位于仓库之内的源代码块，这些代码块编码修复前的故障机制。评测器校验结构化输出，将符号规范化，并评判预测块是否捕捉到解释该事件的最小因果区域。

基准发布包含来自 11 个生产规模分布式系统、横跨 5 种语言的 120 个事件。每个事件都经过选取，使之能够仅凭问题侧上下文加以诊断，并已剥离会泄漏答案的讨论，且标注了精确的修复前根因块。由于 DistDebug-Bench 建立在公开的历史缺陷之上，我们也在任务工作流中加入泄漏控制。准备好的工作区会匿名化目录名，并移除任务快照之后的提交。图 1 中的泄漏防护会扫描可见的推理以及工具的输入与输出，查找那些对智能体隐瞒的原始问题标识符。被标记的尝试予以丢弃并重新运行；第 A.6 节描述该防护以及后续审计流程。对 GPT-5.4 而言，在移除未来提交之后，被标记的尝试从 102/360 降至 4/360。在 66 份不含精确黄金文件名或函数名的报告上所做的闭卷探测（closed-book probes）中，揭示问题标识符并不带来优势：带有该标识符时函数覆盖率（function coverage）为 17.3%，不带时为 21.4%，而能够访问仓库时为 45.5%。在这些探测中，访问仓库会大幅改善定位，尽管不能排除预训练暴露的影响（第 G.2 节）。

3.2 缺陷选取

DistDebug-Bench 由取自大规模生产分布式系统的问题报告与修复性改动构建而成。我们用三条原则选取候选缺陷：问题应当描述一种有代表性的生产故障；可用证据应当支持诊断，同时不揭示答案；修复性改动应当支持精确的根因标注。

真实的生产故障。 我们优先考虑稳定版本上那些高影响、面向用户的缺陷。合格的问题必须已经关闭，有相关联的修复，并且描述的是具体故障，而不是功能请求或内部清理。

贴近真实且可诊断的证据。 我们偏好这样的报告：它们暴露工程师在实践中真正使用的那类信号，即栈追踪、日志、复现步骤、交叉链接的先前问题，或明确的症状描述。我们也检查该问题是否仅凭问题侧上下文即可诊断。问题讨论串中后来揭示根因或补丁策略的评论会被移除或忽略，因为那些内容不再反映真实的诊断情形。

可标注的根因修复。 我们保留那些修复足够局部、因而能够支持精确根因标注的缺陷。大规模重构、仅涉及测试的改动，以及由无关清理所主导的补丁被排除在外，因为它们会使最小因果跨度变得含糊。作为一种实用过滤器，我们也排除改动的源代码超过 100 行的修复，除非因果跨度仍然能够与辅助性编辑清楚分开。

3.3 根因标注

对每一个被接受的问题，标注者根据修复性改动及其周围上下文，导出最小的补丁前根因跨度。每条标签用文件路径、函数或方法符号，以及修复前快照中的起始行与结束行范围，标记一个有缺陷的代码块。第 A.1 节展示具体的标签格式。

在实践中，标注者检查问题报告、修复补丁以及受影响的代码，然后只标记那些在修复之前体现该缺陷的代码。我们排除测试、辅助性重构、防御性加固以及附带的清理，除非它们是最小因果解释的必要组成部分，因为这类编辑并不直接编码原来的故障机制。每个问题由三名标注者独立标注，然后归并为一套最终的黄金标签；第 A.5 节报告标注者间一致性。

除根因标签之外，我们还为每个缺陷记录刻画性元数据。这些字段包括文本性代码锚点、崩溃到修复的距离、问题侧信号，以及粗粒度的根因类型。它们不是打分目标，也不是面向智能体的提示，但它们为第 4 节中的细粒度分解提供基础。

扩大采集规模。 已发布的 DistDebug-Bench 标签完全由人工整理，并经人工归并；黄金标注流程中不使用大语言模型的输出。由于人工审阅仍然是扩大规模的主要瓶颈，我们也开发了一条由大语言模型辅助的标签抽取流水线，供今后探索。附录 B 对它加以描述，并报告在一个小子集上，这条流水线、一条非大语言模型的抽取流水线与最终人工标签之间的比较。

3.4 基准特征

图 2：DistDebug-Bench 负载特征。

图 2 在醒目的数据集规模数字之外概括这一负载。该刻画突出三个使诊断变得困难、并在此后使细粒度评测分解成为可能的性质：问题侧证据是异构的，症状常常远离因果代码，而且许多黄金标签需要非局部的解释或多块解释。

问题侧证据与锚点。 DistDebug-Bench 的报告包含的是异构证据，而不是一份整齐划一的问题陈述。代码标识符出现在 96 / 120 份报告中，但直接的调试信号少得多：37 份包含先前分析，28 份包含栈追踪，20 份包含日志，只有 7 份包含随附制品。即便一份报告含有具体的代码名称，它也很少点名最终的修复位置：在 83 / 120 份报告（69.2%）中，精确的黄金方法并没有出现在标题或描述里。

崩溃到修复的距离。 栈追踪同样是一种不完整的定位信号。在 75 / 120 个事件中，报告并不包含可用的、项目内部的栈追踪。在其余具有可观察崩溃点的事件之中，只有 12 个与修复同位，有 27 个需要从崩溃点跨越组件边界才能到达黄金块，有 6 个在邻近的包结构之内彼此相邻。

基准真值结构。 这些标签还表明，诊断并不只是一个单位置搜索问题。DistDebug-Bench 包含 218 个黄金缺陷块，并且 45.0% 的事件需要不止一个块才能表达根因。近四分之一跨越多个文件。与此同时，块长度的中位数只有五行，因此一个有用的智能体既必须跟随非局部的因果链，又必须报告精确的源码跨度。附录 A 给出完整的制品布局、原始实例示例、标签模式，以及用于本基准刻画的分类规则。关于问题证据如何能够指向一个看似合理的、症状侧的调查空间，而实际根因却位于别处，第 A.2 节以 ZooKeeper（分布式协调服务）的 ZooKeeper-2845 为例逐步说明。

4 评测

我们评测当前的软件工程智能体能否为 DistDebug-Bench 的事件识别出源码级根因，以及它们的诊断质量在何处崩溃。核心结果是：当代智能体常常能够到达相关代码，但当薄弱的事件证据要求持续的导航与假设修正时，它们的诊断过程就会崩溃。

4.1 评测设置

我们沿两条轴运行 DistDebug-Bench：（1）模型轴；（2）运行框架轴。我们首先在 Mini-SWE-Agent（迷你软件工程智能体）上做一次十三种配置的扫描，包括 GPT-6 Astra、Claude Opus 5.5、GPT-5.5、GPT-5.4、GPT-5.3-Codex、GPT-5.2-Codex、Hunyuan3、o4-mini、DeepSeek V4 Flash、Kimi K2.6、Gemini 3.5 Flash、MiMo v2.5 与 MiMo v2.5 Pro。然后，我们在 Codex CLI v0.128.0 与 OpenCode v1.4.6 上运行 GPT-5.2-Codex 与 o4-mini，以提供运行框架的比较点。Mini-SWE-Agent 是现有编程基准所使用的通用最小运行框架 [28, 27]；Codex CLI 是 OpenAI 的终端编程智能体 [20]；OpenCode 是一个获得大量星标的开源终端编程智能体 [1]。这一模型集合把近期的高端系统，包括 GPT-6 Astra [22]、Claude Opus 5.5 [2] 与 GPT-5.4 [21]，与流行的经济型选项或面向编程而特化的选项混合在一起，例如 o4-mini、Kimi K2.6、DeepSeek V4 Flash、Gemini 3.5 Flash 与 MiMo。

除这 17 个主要配置之外，我们还用 DeepSeek V4 Pro、Qwen3.6 Max 与 Qwen3-Coder-Next，在该基准的非均匀子集上做了探索性实验。这些运行不计入主要的 120 个缺陷排行榜，但附录 F 报告了在每个模型所完成的确切子集上，相对于 Mini-SWE GPT-5.2-Codex 的配对比较。

当模型暴露这一控制项时，我们把推理力度（reasoning effort）设为 medium。MiMo 的端点并没有暴露推理力度参数，因此那些运行使用提供方的默认值。Claude Opus 5.5 按其应用程序接口的默认力度运行，该默认值为 medium，输出上限为 16,000 个词元，并使用 Anthropic 的提示缓存。对每一个缺陷与配置的配对，我们先在该缺陷内部对三次尝试取平均，再对全部 120 个缺陷等权平均（第 D.3 节）。第 D.1 节报告每一种配置的 95% 缺陷级自助法置信区间（bootstrap CI），以及它们之间的配对比较。

#### 指标。

我们在四种粒度上，用覆盖率与精确率把生成的诊断与标注的基准真值相比较：文件、函数、行与块。文件指标与函数指标衡量智能体是否到达了正确的组件。行覆盖率（line coverage）是更严格的重叠指标，而块覆盖率是更粗的区域命中指标，它询问每一个被标注的因果块是否被到达。我们把块覆盖率用作主要的定位指标，因为它对精确的行边界选择不那么敏感，也更能捕捉智能体是否导航到了因果区域。我们把行覆盖率作为更严格的敏感性指标加以报告（附录 D）。我们还报告提及覆盖率（mention coverage）：即便结构化的块预测是错误的，自然语言的因果链解释是否提及了黄金函数。为衡量非确定性，我们计算各次已记录尝试之间块覆盖率的缺陷内标准差，以及块覆盖率极差超过 0.2 的不稳定（flaky）缺陷的数量。

#### 指标有效性。

块覆盖率衡量的是对被标注因果代码的找回，而不是每一个看似合理的干预点或修复点。大多数零覆盖率的诊断反映的是不正确或不完整的因果推理：在一次对分数设盲的审计中，20 条零覆盖率的 GPT-5.4 诊断里有 16 条不正确或不完整，另外 4 条重构出了故障机制，但归咎于一个不同的干预点。就整个基准而言，大多数被错过的黄金块是真正的遗漏：在来自全部 17 种配置、分层随机抽取的 100 次覆盖不完整的尝试中，两名各自拿到历史修复的独立人工智能审阅者一致认为，被错过的块中有 8.8%（95% 置信区间 4.3–14.3%）实际上已被正确定位；若把它们计算在内，块覆盖率将提高 5.0 个点。覆盖率对下游也重要。在一个包含六个缺陷的、缺陷内部的修复试点中，高覆盖率诊断使修复智能体在 50.0% 的尝试中编辑了黄金块，没有诊断时这一比例为 11.1%，低覆盖率诊断时为 0%（第 G.1 节）。

表 1：在 120 个共同的 DistDebug-Bench 事件上的主要评测结果。带阴影的列是主要定位指标，方括号内为 95% 缺陷自助法置信区间；粗体数值是该列中的最优值。表 9 给出其他指标的置信区间。

4.2 主要评测结果

表 1 概括了各主要模型配置与运行框架配置上的诊断表现。在我们完整的扫描中，GPT-6 Astra 的汇总块覆盖率最高：在 Mini-SWE 上，它达到 83.9% 的文件覆盖率、53.9% 的行覆盖率，以及 67.7% 的块覆盖率。然而，跨各种配置来看，文件覆盖率仍然显著高于行覆盖率与块覆盖率，而且覆盖率较高的设定往往伴随着更宽泛的预测：Mini-SWE GPT-5.5 的块精确率为 34.7%，平均每次诊断点名 3.6 个块。这些汇总结果指向一个一致的主题：当前最先进（SOTA）智能体常常能够到达相关代码，但当薄弱的事件证据要求持续的导航与假设修正时，它们的诊断过程就会崩溃。 下面的类别分解使这一差距变得可见：最弱的情形不仅是那些没有起始证据的情形，也包括报告提供了初始症状位置、却没有点名因果代码的情形。

图 3：按事件证据划分的块覆盖率。各列按问题文本中最强的代码锚点分组；各行按第一个崩溃栈帧分组。当报告缺少精确锚点、且崩溃点缺失或属于跨组件时，覆盖率下降最多。分面中的计数给出每个单元格的缺陷数；须线表示 95% 缺陷自助法置信区间（仅含一个缺陷的单元格没有须线）。

发现 1。 当报告没有指向精确的代码位置时，智能体就会陷入困境。* 当缺陷报告没有提及基准真值的函数名或文件时，性能急剧下降。这表明，报告的初始内容在很大程度上塑造了最终诊断，而智能体修正早期假设的能力有限。**

附录 E 给出这一失效模式的一个具体轨迹示例。

图 3 依据事件报告能够给予智能体的两类帮助，把缺陷分成 9 类：文本是点名一个精确的黄金方法、点名一个黄金文件或类，还是完全没有因果代码；以及第一个崩溃栈帧相对于修复而言是局部或邻近、跨组件，还是缺失。该图报告每个单元格的样本量以及 95% 缺陷自助法置信区间；对小单元格所作的比较是探索性的。

当报告点名一个精确方法时，智能体往往表现良好：当前最佳配置在局部或邻近、且点名了方法的缺陷上达到 95.8% 的块覆盖率，在无栈追踪、且点名了方法的缺陷上达到 94.8%。当报告不透明时，即便是最佳配置，在 42 个无栈追踪的不透明缺陷上也只达到 65.0%，在七个跨组件的不透明缺陷上只达到 40.5%。就一条固定基线而言，Mini-SWE GPT-5.2-Codex 呈现出同一模式：它在无栈追踪且点名了方法时的覆盖率为 82.8%，但在无栈追踪的不透明缺陷上降至 44.7%，在跨组件的不透明缺陷上降至 14.3%。

加入更新的模型会提高绝对覆盖率，但并没有消除这一弱证据差距。GPT-6 Astra 把无栈追踪的不透明缺陷上的块覆盖率提高到 65.0%，然而这仍然比它在无栈追踪且点名了方法的缺陷上 94.8% 的覆盖率低 29.8 个百分点。这类情形很常见：不透明报告占该基准 120 个缺陷中的 50 个，其中包括 42 个没有栈追踪的缺陷。核心挑战是在没有直接代码引用的情况下，从症状导航到因果代码。

发现 2。 逐次运行的确定性仍然是一项核心挑战。* 对同一缺陷的重复尝试可能产生不同的诊断，因此单次成功的运行可能掩盖脆弱的行为。即便对最强的模型，这种不稳定性在弱证据缺陷上也尤为明显。**

同一缺陷上的重复尝试之间，诊断质量会发生变化。GPT-6 Astra 拥有最好的汇总块覆盖率，但按我们的定义，它的 120 个缺陷中有 15 个是不稳定的。Claude Opus 5.5 有 17 个不稳定缺陷，GPT-5.5 有 20 个，GPT-5.4 有 21 个，GPT-5.2-Codex 有 18 个，Kimi K2.6 与 DeepSeek V4 Flash 各有 32 个，MiMo v2.5 Pro 有 22 个，MiMo v2.5 有 26 个，HY3 有 35 个。在那些需要从弱证据出发进行导航的缺陷上，这种不稳定性最令人担忧。对 Mini-SWE GPT-5.5 而言，无栈追踪的不透明单元格有 11/42 个不稳定缺陷（26%），缺陷内块覆盖率标准差的均值为 9.2 个点；而无栈追踪且点名了方法的单元格只有 2/16 个不稳定缺陷（13%），标准差均值仅为 3.7 个点。Mini-SWE GPT-5.2 呈现出同样的对比：11/42 个无栈追踪的不透明缺陷是不稳定的（26%），而无栈追踪且点名了方法的缺陷为 1/16（6%）。这种方差对诊断很重要，因为它表明：直接代码证据很少的报告所造成的，是脆弱的搜索轨迹，而不只是一律更难的例子。

发现 3。 更新的模型所暴露的是权衡，而不是均匀的性能提升。* 更广的探索可能有助于弱证据情形，但当报告已经提供强证据时，智能体必须保持精确。跨不同模型来看，词元用量与覆盖率并不相关。**

完整的 Mini-SWE-Agent 模型扫描表明，更强的模型并非简单地抬高每一个类别。相对于 GPT-5.2-Codex，GPT-5.5 把汇总块覆盖率从 56.4% 提高到 65.1%，并且改善了困难的弱证据单元格：无栈追踪的不透明缺陷提高了 15.4 个百分点。与此同时，GPT-5.5 每次诊断所给出的预测块多于 GPT-5.2-Codex，为 3.6 对 2.3，而且它的块精确率从 43.1% 降到 34.7%。GPT-5.5 在不透明报告上找回了更多因果代码，但它更宽泛的诊断也包含了更多无关代码。智能体需要超越薄弱的初始线索去搜索，同时又不能在报告已经提供一条强的局部代码引用时失去精确性。

额外的全套件实验与子集实验展示了同一条宽泛的教训。MiMo v2.5 Pro 达到 58.5% 的块覆盖率与 72.6% 的提及覆盖率，但平均每次运行使用 2.6M 个词元。MiMo v2.5 略低，块覆盖率为 58.0%，提及覆盖率为 69.5%，同时每次运行使用 2.3M 个词元。Kimi K2.6 达到 58.3% 的块覆盖率，但平均每次运行使用 2.8M 个词元，并且有 32 个不稳定缺陷；DeepSeek V4 Flash 的块覆盖率大致与 GPT-5.2-Codex 相当，同时使用了后者 3.4$\times$ 的词元，并且块精确率更低。Gemini 3.5 Flash 更为保守：它拥有最高的块精确率，即 51.1%，但块覆盖率只有 47.5%。在附录 F 中，DeepSeek V4 Pro 提高了 5.0 个点，同时使用的词元数是 GPT-5.2 的 2.5$\times$。扩大模型规模可以改善探索，但它不能替代可靠的诊断控制。

发现 4。 运行框架会改变模型点名多少代码，但核心困难仍然存在。* 不同的运行框架鼓励不同的诊断风格：Mini-SWE 点名更多代码，Codex CLI 更窄也更精确，OpenCode 则介于二者之间。这移动了覆盖率–精确率之间的平衡，但当报告缺少直接的因果代码引用时，所有运行框架仍然陷入困境。**

跨运行框架比较 GPT-5.2-Codex，可以看出运行框架会影响诊断被塑造成何种形态。Mini-SWE-Agent 达到 56.4% 的块覆盖率，但块精确率只有 43.1%；而 Codex CLI 的块覆盖率更低，为 46.5%，但块精确率最高，为 49.3%。OpenCode 介于二者之间，块覆盖率为 50.0%，块精确率为 47.7%。表 1 中的“块/诊断”一列与这一权衡相一致：Mini-SWE GPT-5.2-Codex 平均每次诊断预测 2.3 个块，Codex CLI 为 1.6 个，OpenCode 为 1.8 个。这些差异是要紧的，但相对于共同的失效模式而言是次要的：当报告缺少直接的因果代码引用时，每一种运行框架都会急剧退化。

4.3 失效模式与设计启示

上面的结果描述的是一个隧道视野问题。智能体常常到达相关文件，但它们的诊断是宽泛的、不稳定的，并且在报告没有点名因果代码时尤其薄弱。接下来，我们概括各种失效模式，以及它们对未来运行框架设计的启示。这一分析也表明，DistDebug-Bench 的细粒度证据分解为何有用：它为诊断当前智能体失败于何处、以及未来的运行框架应当改进什么，提供了具体信号。

失效模式 1：工具调用的非确定性驱动着诊断的非确定性。 命令选择上的细微差别，就可以把各次运行带入不同的证据范围，因此未来的运行框架需要自适应工具，在早期证据不完整时自动扩充上下文。

工具调用是弱证据诊断变得不稳定的一个核心原因。模型一旦处于某个相关区域，往往擅长高层的意义建构，但这一任务要求许多精确的执行决策：搜索哪些关键词，进入哪一个目录，打开哪一个文件，跟随哪一个符号，以及何时放弃一条分支。当报告点名了相关方法时，不同的命令顺序仍然可能收敛到同一个局部区域。当报告不透明时，搜索词、目录选择或第一个被打开的文件上的微小差别，就可以把各次尝试送进不同的子系统。

例如，在 ZooKeeper-3769 中，节点日志是可用的。成功诊断的核心促成条件，是识别出 node1.log 内部的 BufferUnderflowException。我们观察到，成功的运行与失败的运行都很早读取了 node1.log，但成功的运行在日志中搜索 Exception，而失败的运行查看的是特定行号，或者搜索与选举相关的日志。那些读取揭示了其他瞬时错误，却错过了 BufferUnderflowException。ZooKeeper-2845 中出现类似的行为。根因位于更宽的 /server 路径之下的 ZooKeeperServer.java 中，但问题报告强烈强调法定人数（quorum）行为。现有智能体常常很早便收窄到 /server/quorum 子目录。一旦到了那里，关键词搜索就不再把正确的类浮现出来，于是该次运行被导向一个错误但自洽的诊断。

设计启示 1。 为了降低非确定性，运行框架应当提供这样的工具层：它们推断模型的意图，并自动用相关信息扩充上下文。例如，当智能体搜索某个关键词时，静态分析可以返回相关的类定义、符号使用，以及上游与下游的上下文。当两条命令在语义上相互对齐、但又有细微差别时，这会使工具执行更为精确。未来的运行框架不应当把上下文构建完全留给即兴的 shell 命令：它们需要自适应的检索工具与上下文扩充工具，以便在当前搜索范围支撑不足时，把相邻文件、调用路径、相关符号以及相互竞争的假设浮现出来。

失效模式 2：智能体很少修正初始假设，也很少在初始证据之外发现因果代码。 当第一个看似合理的代码区域并不是那个因果区域时，智能体常常继续深化那个局部解释，而不是重新打开搜索。在我们的轨迹代理指标中，只有 21.0% 的可解析运行表现出后期挽回（late recovery），而在成功的运行中，这样做的只有 11.25%。

我们将后期挽回定义为其最终诊断文件并未出现在最先被检查的两个源文件之中的那一次运行。在至少检查了两个源文件的 124 次可解析的 Mini-SWE-Agent 与 OpenCode 运行中，后期挽回只出现 26 次（21.0%）：Mini-SWE-Agent 为 7/21，OpenCode 为 19/103。在成功的运行之中，只有 9/80（11.25%）属于后期挽回。

ZooKeeper-2845 与 Ray-8889（Ray 为分布式计算框架）这类缺陷说明了这种锁定。即便智能体找到了看似与所报告症状相匹配的代码（例如那个抛出异常的下游数据消费者），它也常常停在那个显眼的位置，而不是去追问是怎样一种更早的生命周期状态使该症状成为可能。对轨迹的检查表明，智能体可以提出相关的后续问题，但它们是否去探索那些问题是高度不确定的，并且受早期探索所塑造。这种早期锁定强化了失效模式 1：因为智能体难以调整自己的范围与推理，工具执行上的微小不准确就可以变成诊断失败。

设计启示 2。 分布式系统调试要求每一条假设路径都积累它自己的证据。在当前这种单一的、不断增长的上下文之下，各种替代方案变得更难比较。这就要求超出上下文压缩或子智能体委派之外的上下文管理策略，例如在追究不同假设时切换上下文，或者主动剪除已被否定的假设。

失效模式 3：诊断之所以困难，是因为智能体在定稿之前缺少可靠的自我修正信号。 分布式系统故障常常受困于可复现性方面的挑战。智能体往往不能运行测试，并迅速得到关于诊断是否正确的反馈；相反，它们必须依靠对源代码与所观察制品所作的严格推理。

诊断常常缺少一种廉价的通过或失败检查，用以判断所提出的源码区域是不是真正的根因。智能体在定稿之前，往往无法分辨所选代码区域是否解释了完整的因果链，也无法分辨是否仍有另一个假设需要加以探索。即便存在一个可运行的环境，智能体也可能放弃测试，因为它们优先考虑的是复现整个事件，而不是把它分解成更小的、单元测试式的检查。类似地，当智能体很早便收敛时，它们有时会出于工程实践方面的理由而停止，并且缺少显式的正确性规约，来决定应当归咎于上游代码还是下游代码。

我们的核心洞见是：缺陷诊断并非天生就缺少正确性信号。相反，诸如被抛出的异常、崩溃点、日志与文档之类的信号，需要经过一致的评估与交叉核对，然后才会变得有用。

设计启示 3。 未来的运行框架应当主动把正确性信号注入智能体的上下文，或者使用一个评测器子智能体，去核验所提出的诊断是否从头到尾充分解释了有缺陷的行为，以及归咎于某一个组件的决定是否有具体证据作为支撑。

5 结论与未来工作

我们提出了 DistDebug-Bench，一个用于评测大语言模型智能体对真实世界分布式系统故障进行代码级根因诊断的基准。我们的评测表明，当前智能体常常能够到达相关的仓库区域，但难以定位精确的因果位置，当问题报告缺少直接的代码引用或栈追踪时尤其如此。轨迹分析凸显了不一致的工具使用，以及对初始假设所作的有限修正。证据分解、逐次运行的不稳定性以及失效模式分析合在一起表明，分布式系统调试所需要的，多于更广的搜索或模型规模的扩大。这些发现激励未来的研究以及智能体运行框架的设计去支持自适应的上下文构建、感知假设的上下文管理以及正确性检查，从而使探索、修正与验证成为智能体式诊断工作流中的显式组成部分。

6 致谢与披露

本工作得到国家人工智能研究资源试点资助项目 NAIRR Pilot 250038 的支持，并获得 OpenAI 应用程序接口额度以及 Jetstream2 与 CloudBank 的资源；部分工作由美国国家科学基金会（NSF）资助项目 CNS-2317698、CNS-2317751 与 CCF-2318937 支持。

参考文献

• [1] Anomaly. OpenCode: The open source coding agent, 2026. URL https://github.com/anomalyco/opencode. Accessed 2026-05-06.

中文题名：OpenCode：开源编程智能体 著录：Anomaly，2026 年。网址 https://github.com/anomalyco/opencode。访问日期：2026-05-06。 作者姓名不音译，编号与原文一致。

• [2] Anthropic. Claude Opus 5.5 model documentation, 2026. URL https://platform.claude.com/docs/en/models/opus-5-5/overview. Accessed 2026-10-27.

中文题名：Claude Opus 5.5 模型文档 著录：Anthropic，2026 年。网址 https://platform.claude.com/docs/en/models/opus-5-5/overview。访问日期：2026-10-27。 作者姓名不音译，编号与原文一致。

• [3] Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, and Charles Sutton. Program synthesis with large language models, 2021. URL https://arxiv.org/abs/2108.07732.

中文题名：用大语言模型进行程序合成 著录：2021 年。预印本 arXiv：https://arxiv.org/abs/2108.07732。 作者姓名不音译，编号与原文一致。

• [4] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fotios Chantzis, Elizabeth Barnes, Ariel Herbert-Voss, William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shantanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Josh Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, and Wojciech Zaremba. Evaluating large language models trained on code, 2021. URL https://arxiv.org/abs/2107.03374.

中文题名：评测在代码上训练的大语言模型 著录：2021 年。预印本 arXiv：https://arxiv.org/abs/2107.03374。 作者姓名不音译，编号与原文一致。

• [5] Yinfang Chen, Manish Shetty, Gagan Somashekar, Minghua Ma, Yogesh Simmhan, Jonathan Mace, Chetan Bansal, Rujia Wang, and Saravan Rajmohan. AIOpsLab: A holistic framework to evaluate AI agents for enabling autonomous clouds, 2025. URL https://arxiv.org/abs/2501.06706.

中文题名：AIOpsLab：一个用于评测人工智能智能体、从而使云能够自治的整体框架 著录：2025 年。预印本 arXiv：https://arxiv.org/abs/2501.06706。 作者姓名不音译，编号与原文一致。

• [6] Neil Chowdhury, James Aung, Chan Jun Shern, Oliver Jaffe, Dane Sherburn, Giulio Starace, Evan Mays, Rachel Dias, Marwan Aljubeh, Mia Glaese, Carlos E. Jimenez, John Yang, Leyton Ho, Tejal Patwardhan, Kevin Liu, and Aleksander Madry. Introducing SWE-bench verified, 2024. URL https://openai.com/index/introducing-swe-bench-verified/.

中文题名：介绍 SWE-bench Verified 著录：OpenAI，2024 年。网址 https://openai.com/index/introducing-swe-bench-verified/。 作者姓名不音译，编号与原文一致。

• [7] Jackson Clark, Yiming Su, Saad Mohammad Rafid Pial, Yifang Tian, Lily Gniedziejko, Hans-Arno Jacobsen, Yinfang Chen, and Tianyin Xu. SREGym: A live benchmark for AI SRE agents with high-fidelity failure scenarios, 2026. URL https://arxiv.org/abs/2605.07161.

中文题名：SREGym：面向人工智能站点可靠性工程智能体、包含高保真故障场景的实时基准 著录：2026 年。预印本 arXiv：https://arxiv.org/abs/2605.07161。 作者姓名不音译，编号与原文一致。

• [8] Yingnong Dang, Qingwei Lin, and Peng Huang. AIOps: real-world challenges and research innovations. In Proceedings of the 41st International Conference on Software Engineering: Companion Proceedings, ICSE ’19, pages 4–5. IEEE Press, 2019. doi: 10.1109/ICSE-Companion.2019.00023. URL https://doi.org/10.1109/ICSE-Companion.2019.00023.

中文题名：AIOps：现实世界中的挑战与研究创新 著录：《第 41 届国际软件工程会议：配套论文集》（ICSE ’19），第 4–5 页。IEEE Press，2019 年。doi：10.1109/ICSE-Companion.2019.00023。网址 https://doi.org/10.1109/ICSE-Companion.2019.00023。 作者姓名不音译，编号与原文一致。

• [9] Xiang Deng, Jeff Da, Edwin Pan, Yannis Yiming He, Charles Ide, Kanak Garg, Niklas Lauffer, Andrew Park, Nitin Pasari, Chetan Rane, Karmini Sampath, Maya Krishnan, Srivatsa Kundurthy, Sean Hendryx, Zifan Wang, Vijay Bharadwaj, Jeff Holm, Raja Aluri, Chen Bo Calvin Zhang, Noah Jacobson, Bing Liu, and Brad Kenstler. SWE-bench pro: Can AI agents solve long-horizon software engineering tasks?, 2025. URL https://arxiv.org/abs/2509.16941.

中文题名：SWE-bench Pro：人工智能智能体能解决长程软件工程任务吗？ 著录：2025 年。预印本 arXiv：https://arxiv.org/abs/2509.16941。 作者姓名不音译，编号与原文一致。

• [10] Michaela Hardt, William R. Orchard, Patrick Blöbaum, Shiva Kasiviswanathan, and Elke Kirschbaum. The PetShop dataset: Finding causes of performance issues across microservices, 2024. URL https://arxiv.org/abs/2311.04806.

中文题名：PetShop 数据集：寻找跨微服务的性能问题成因 著录：2024 年。预印本 arXiv：https://arxiv.org/abs/2311.04806。 作者姓名不音译，编号与原文一致。

• [11] Peng Huang, Chuanxiong Guo, Lidong Zhou, Jacob R. Lorch, Yingnong Dang, Murali Chintalapati, and Randolph Yao. Gray failure: The Achilles’ heel of cloud-scale systems. In Proceedings of the 16th Workshop on Hot Topics in Operating Systems, HotOS ’17, pages 150–155, Whistler, BC, Canada, 2017. ACM. ISBN 978-1-4503-5068-6. doi: 10.1145/3102980.3103005. URL http://doi.acm.org/10.1145/3102980.3103005.

中文题名：灰色故障：云规模系统的阿喀琉斯之踵 著录：《第 16 届操作系统热点问题研讨会论文集》（HotOS ’17），第 150–155 页，加拿大不列颠哥伦比亚省惠斯勒，2017 年。ACM。ISBN 978-1-4503-5068-6。doi：10.1145/3102980.3103005。网址 http://doi.acm.org/10.1145/3102980.3103005。 作者姓名不音译，编号与原文一致。

• [12] Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Armando Solar-Lezama, Koushik Sen, and Ion Stoica. LiveCodeBench: Holistic and contamination free evaluation of large language models for code, 2024. URL https://arxiv.org/abs/2403.07974.

中文题名：LiveCodeBench：面向代码的大语言模型之整体且无污染的评测 著录：2024 年。预印本 arXiv：https://arxiv.org/abs/2403.07974。 作者姓名不音译，编号与原文一致。

• [13] Saurabh Jha, Rohan R. Arora, Yuji Watanabe, Takumi Yanagawa, Yinfang Chen, Jackson Clark, Bhavya Bhavya, Mudit Verma, Harshit Kumar, Hirokuni Kitahara, Noah Zheutlin, Saki Takano, Divya Pathak, Felix George, Xinbo Wu, Bekir O. Turkkan, Gerard Vanloo, Michael Nidd, Ting Dai, Oishik Chatterjee, Pranjal Gupta, Suranjana Samanta, Pooja Aggarwal, Rong Lee, Pavankumar Murali, Jae-Wook Ahn, Debanjana Kar, Ameet Rahane, Carlos Fonseca, Amit Paradkar, Yu Deng, Pratibha Moogi, Prateeti Mohapatra, Naoki Abe, Chandrasekhar Narayanaswami, Tianyin Xu, Lav R. Varshney, Ruchi Mahindru, Anca Sailer, Laura Shwartz, Daby Sow, Nicholas C. M. Fuller, and Ruchir Puri. ITBench: Evaluating AI agents across diverse real-world IT automation tasks. In Proceedings of the 42nd International Conference on Machine Learning, volume 267 of Proceedings of Machine Learning Research, pages 27134–27197. PMLR, 2025. URL https://proceedings.mlr.press/v267/jha25a.html.

中文题名：ITBench：在多样的真实世界信息技术自动化任务上评测人工智能智能体 著录：《第 42 届国际机器学习会议论文集》，《机器学习研究论文集》第 267 卷，第 27134–27197 页。PMLR，2025 年。网址 https://proceedings.mlr.press/v267/jha25a.html。 作者姓名不音译，编号与原文一致。

• [14] Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R Narasimhan. SWE-bench: Can language models resolve real-world GitHub issues? In The Twelfth International Conference on Learning Representations, 2024. URL https://openreview.net/forum?id=VTF8yNQM66.

中文题名：SWE-bench：语言模型能解决真实世界的 GitHub 问题吗？ 著录：第十二届学习表征国际会议（The Twelfth International Conference on Learning Representations），2024 年。网址 https://openreview.net/forum?id=VTF8yNQM66。 作者姓名不音译，编号与原文一致。

• [15] René Just, Darioush Jalali, and Michael D. Ernst. Defects4J: A database of existing faults to enable controlled testing studies for Java programs. In Proceedings of the 2014 International Symposium on Software Testing and Analysis, pages 437–440, 2014. doi: 10.1145/2610384.2628055.

中文题名：Defects4J：一个既有故障数据库，用以支持针对 Java 程序的受控测试研究 著录：《2014 年软件测试与分析国际研讨会论文集》，第 437–440 页，2014 年。doi：10.1145/2610384.2628055。 作者姓名不音译，编号与原文一致。

• [16] Claire Le Goues, Neal Holtschulte, Edward K. Smith, Yuriy Brun, Premkumar Devanbu, Stephanie Forrest, and Westley Weimer. The ManyBugs and IntroClass benchmarks for automated repair of C programs. IEEE Transactions on Software Engineering, 41(12):1236–1256, 2015. doi: 10.1109/TSE.2015.2454513.

中文题名：用于 C 程序自动修复的 ManyBugs 与 IntroClass 基准 著录：《IEEE 软件工程汇刊》（IEEE Transactions on Software Engineering），41(12)：1236–1256，2015 年。doi：10.1109/TSE.2015.2454513。 作者姓名不音译，编号与原文一致。

• [17] Tianyang Liu, Canwen Xu, and Julian McAuley. RepoBench: Benchmarking repository-level code auto-completion systems, 2023. URL https://arxiv.org/abs/2306.03091.

中文题名：RepoBench：对仓库级代码自动补全系统进行基准评测 著录：2023 年。预印本 arXiv：https://arxiv.org/abs/2306.03091。 作者姓名不音译，编号与原文一致。

• [18] Chang Lou, Peng Huang, and Scott Smith. Understanding, detecting and localizing partial failures in large system software. In Proceedings of the 17th Usenix Conference on Networked Systems Design and Implementation, NSDI ’20, pages 559–574, USA, 2020. USENIX Association. ISBN 9781939133137.

中文题名：理解、检测并定位大型系统软件中的部分失效 著录：《第 17 届 USENIX 网络系统设计与实现会议论文集》（NSDI ’20），第 559–574 页，美国，2020 年。USENIX Association。ISBN 9781939133137。 作者姓名不音译，编号与原文一致。

• [19] Fernanda Madeiral, Simon Urli, Marcelo Maia, and Martin Monperrus. Bears: An extensible Java bug benchmark for automatic program repair studies. In Proceedings of the 26th IEEE International Conference on Software Analysis, Evolution and Reengineering, pages 468–478, 2019. doi: 10.1109/SANER.2019.8667991.

中文题名：Bears：一个用于自动程序修复研究的可扩展 Java 缺陷基准 著录：《第 26 届 IEEE 软件分析、演化与再工程国际会议论文集》，第 468–478 页，2019 年。doi：10.1109/SANER.2019.8667991。 作者姓名不音译，编号与原文一致。

• [20] OpenAI. Codex CLI documentation, 2026a. URL https://developers.openai.com/codex/cli. Accessed 2026-05-06.

中文题名：Codex CLI 文档 著录：OpenAI，2026a。网址 https://developers.openai.com/codex/cli。访问日期：2026-05-06。 作者姓名不音译，编号与原文一致。

• [21] OpenAI. GPT-5.4 model documentation, 2026b. URL https://developers.openai.com/api/docs/models/gpt-5.4. Accessed 2026-05-06.

中文题名：GPT-5.4 模型文档 著录：OpenAI，2026b。网址 https://developers.openai.com/api/docs/models/gpt-5.4。访问日期：2026-05-06。 作者姓名不音译，编号与原文一致。

• [22] OpenAI. GPT-6 Astra model documentation, 2026c. URL https://developers.openai.com/api/docs/models/gpt-6-astra. Accessed 2026-10-27.

中文题名：GPT-6 Astra 模型文档 著录：OpenAI，2026c。网址 https://developers.openai.com/api/docs/models/gpt-6-astra。访问日期：2026-10-27。 作者姓名不音译，编号与原文一致。

• [23] Jiayi Pan, Xingyao Wang, Graham Neubig, Navdeep Jaitly, Heng Ji, Alane Suhr, and Yizhe Zhang. Training software engineering agents and verifiers with SWE-gym, 2025. URL https://arxiv.org/abs/2412.21139.

中文题名：用 SWE-gym 训练软件工程智能体与验证器 著录：2025 年。预印本 arXiv：https://arxiv.org/abs/2412.21139。 作者姓名不音译，编号与原文一致。

• [24] Luan Pham, Hongyu Zhang, Huong Ha, Flora Salim, and Xiuzhen Zhang. RCAEval: A benchmark for root cause analysis of microservice systems with telemetry data. In Companion Proceedings of the ACM on Web Conference 2025, WWW ’25, pages 777–780, 2025. doi: 10.1145/3701716.3715290. URL https://arxiv.org/abs/2412.17015.

中文题名：RCAEval：一个带遥测数据的微服务系统根因分析基准 著录：《ACM 万维网会议 2025 配套论文集》（WWW ’25），第 777–780 页，2025 年。doi：10.1145/3701716.3715290。预印本 arXiv：https://arxiv.org/abs/2412.17015。 作者姓名不音译，编号与原文一致。

• [25] Muhammad Shihab Rashid, Christian Bock, Yuan Zhuang, Alexander Buchholz, Tim Esler, Simon Valentin, Luca Franceschi, Martin Wistuba, Prabhu Teja Sivaprasad, Woo Jung Kim, Anoop Deoras, Giovanni Zappella, and Laurent Callot. SWE-polybench: A multi-language benchmark for repository level evaluation of coding agents, 2025. URL https://arxiv.org/abs/2504.08703.

中文题名：SWE-polybench：一个用于在仓库层级评测编程智能体的多语言基准 著录：2025 年。预印本 arXiv：https://arxiv.org/abs/2504.08703。 作者姓名不音译，编号与原文一致。

• [26] Ripon K. Saha, Yingjun Lyu, Wing Lam, Hiroaki Yoshida, and Mukul R. Prasad. Bugs.jar: A large-scale, diverse dataset of real-world Java bugs. In Proceedings of the 15th International Conference on Mining Software Repositories, pages 10–13, 2018. doi: 10.1145/3196398.3196473.

中文题名：Bugs.jar：一个大规模、多样化的真实世界 Java 缺陷数据集 著录：《第 15 届软件仓库挖掘国际会议论文集》，第 10–13 页，2018 年。doi：10.1145/3196398.3196473。 作者姓名不音译，编号与原文一致。

• [27] SWE-agent Team. mini-SWE-agent documentation, 2026. URL https://mini-swe-agent.com/latest/. Accessed 2026-05-06.

中文题名：mini-SWE-agent 文档 著录：SWE-agent 团队，2026 年。网址 https://mini-swe-agent.com/latest/。访问日期：2026-05-06。 作者姓名不音译，编号与原文一致。

• [28] SWE-bench Team. SWE-bench verified leaderboard, 2026. URL https://www.swebench.com/verified.html. Accessed 2026-05-06.

中文题名：SWE-bench Verified 排行榜 著录：SWE-bench 团队，2026 年。网址 https://www.swebench.com/verified.html。访问日期：2026-05-06。 作者姓名不音译，编号与原文一致。

• [29] Runchu Tian, Yining Ye, Yujia Qin, Xin Cong, Yankai Lin, Yinxu Pan, Yesai Wu, Haotian Hui, Weichuan Liu, Zhiyuan Liu, and Maosong Sun. DebugBench: Evaluating debugging capability of large language models, 2024. URL https://arxiv.org/abs/2401.04621.

中文题名：DebugBench：评测大语言模型的调试能力 著录：2024 年。预印本 arXiv：https://arxiv.org/abs/2401.04621。 作者姓名不音译，编号与原文一致。

• [30] David A. Tomassi, Naji Dmeiri, Yichen Wang, Antara Bhowmick, Yen-Chuan Liu, Premkumar Devanbu, Bogdan Vasilescu, and Cindy Rubio-González. BugSwarm: Mining and continuously growing a dataset of reproducible failures and fixes. In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), pages 339–349, 2019. doi: 10.1109/ICSE.2019.00048. URL https://doi.org/10.1109/ICSE.2019.00048.

中文题名：BugSwarm：挖掘并持续增长一个可复现故障与修复的数据集 著录：2019 年 IEEE/ACM 第 41 届软件工程国际会议（ICSE），第 339–349 页，2019 年。doi：10.1109/ICSE.2019.00048。网址 https://doi.org/10.1109/ICSE.2019.00048。 作者姓名不音译，编号与原文一致。

• [31] Ratnadira Widyasari, Sheng Qin Sim, Camellia Lok, Haodi Qi, Jack Phan, Qijin Tay, Constance Tan, Fiona Wee, Jodie Ethelda Tan, Yuheng Yieh, Brian Goh, Ferdian Thung, Hong Jin Kang, Thong Hoang, David Lo, and Eng Lieh Ouh. BugsInPy: A database of existing bugs in Python programs to enable controlled testing and debugging studies. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE ’20, pages 1556–1560, 2020. doi: 10.1145/3368089.3417943. URL https://doi.org/10.1145/3368089.3417943.

中文题名：BugsInPy：一个 Python 程序中既有缺陷的数据库，用以支持受控的测试与调试研究 著录：《第 28 届 ACM 欧洲软件工程会议与软件工程基础研讨会联合会议论文集》（ESEC/FSE ’20），第 1556–1560 页，2020 年。doi：10.1145/3368089.3417943。网址 https://doi.org/10.1145/3368089.3417943。 作者姓名不音译，编号与原文一致。

• [32] Junjielong Xu, Qinan Zhang, Zhiqing Zhong, Shilin He, Chaoyun Zhang, Qingwei Lin, Dan Pei, Pinjia He, Dongmei Zhang, and Qi Zhang. Openrca: Can large language models locate the root cause of software failures? In The Thirteenth International Conference on Learning Representations, 2025. URL https://openreview.net/forum?id=M4qNIzQYpd.

中文题名：Openrca：大语言模型能定位软件故障的根因吗？ 著录：第十三届学习表征国际会议（The Thirteenth International Conference on Learning Representations），2025 年。网址 https://openreview.net/forum?id=M4qNIzQYpd。 作者姓名不音译，编号与原文一致。

• [33] John Yang, Carlos E. Jimenez, Alex L. Zhang, Kilian Lieret, Joyce Yang, Xindi Wu, Ori Press, Niklas Muennighoff, Gabriel Synnaeve, Karthik R. Narasimhan, Diyi Yang, Sida I. Wang, and Ofir Press. SWE-bench multimodal: Do AI systems generalize to visual software domains?, 2024. URL https://arxiv.org/abs/2410.03859.

中文题名：SWE-bench multimodal：人工智能系统能泛化到可视化软件领域吗？ 著录：2024 年。预印本 arXiv：https://arxiv.org/abs/2410.03859。 作者姓名不音译，编号与原文一致。

• [34] Daoguang Zan, Zhirong Huang, Wei Liu, Hanwu Chen, Linhao Zhang, Shulin Xin, Lu Chen, Qi Liu, Xiaojian Zhong, Aoyan Li, Siyao Liu, Yongsheng Xiao, Liangqiang Chen, Yuyu Zhang, Jing Su, Tianyu Liu, Rui Long, Kai Shen, and Liang Xiang. Multi-SWE-bench: A multilingual benchmark for issue resolving, 2025. URL https://arxiv.org/abs/2504.02605.

中文题名：Multi-SWE-bench：一个用于问题修复的多语言基准 著录：2025 年。预印本 arXiv：https://arxiv.org/abs/2504.02605。 作者姓名不音译，编号与原文一致。

• [35] Linghao Zhang, Shilin He, Chaoyun Zhang, Yu Kang, Bowen Li, Chengxing Xie, Junhao Wang, Maoquan Wang, Yufan Huang, Shengyu Fu, Elsie Nallipogu, Qingwei Lin, Yingnong Dang, Saravan Rajmohan, and Dongmei Zhang. SWE-bench goes live!, 2025. URL https://arxiv.org/abs/2505.23419.

中文题名：SWE-bench 上线了！ 著录：2025 年。预印本 arXiv：https://arxiv.org/abs/2505.23419。 作者姓名不音译，编号与原文一致。

• [36] Zihan Zheng, Zerui Cheng, Zeyu Shen, Shang Zhou, Kaiyuan Liu, Hansen He, Dongruixuan Li, Stanley Wei, Hangyi Hao, Jianzhu Yao, Peiyao Sheng, Zixuan Wang, Wenhao Chai, Aleksandra Korolova, Peter Henderson, Sanjeev Arora, Pramod Viswanath, Jingbo Shang, and Saining Xie. Livecodebench pro: How do olympiad medalists judge llms in competitive programming?, 2025. URL https://arxiv.org/abs/2506.11928.

中文题名：Livecodebench Pro：奥林匹克竞赛奖牌获得者如何在竞赛编程中评判大语言模型？ 著录：2025 年。预印本 arXiv：https://arxiv.org/abs/2506.11928。 作者姓名不音译，编号与原文一致。

附录 A–D，以及附录 E–G 与 NeurIPS 核对清单，另文发布。它们仍是同一篇论文，不是另外的来源。