DistDebug-Bench 附录 E–G：轨迹、子集实验与污染检验

DistDebug-Bench 附录 E–G

这是同一篇论文的附录后半与 NeurIPS 核对清单，不是另一篇来源。原文：https://arxiv.org/abs/2611.03523

附录 E 失败模式轨迹细节

本附录给出第 4 节失败模式讨论背后的操作细节。主要类别分解在结果层面衡量延迟发现：在跨组件不透明缺陷中，报告给出了初始栈轨迹锚点，但没有点名因果代码，而智能体仍然很少到达正确的块。下面的诊断利用对执行轨迹的事后测量，对同一些失败模式加以量化；它们不属于基准评分。

E.1 轨迹产物

每一次完成的运行都保存最终的结构化诊断、运行统计，以及一条按时间排列的轨迹：

run-XX/ diagnosis.json # 框架输出的最终结构化诊断 diagnosis_scores.json # 相对人工标签的重叠分数 session_stats.json # 成本、token、耗时与调用次数摘要 trajectory.json # 模型消息以及工具调用与工具输出

全部 6,120 次已评分尝试的运行目录发布于 https://huggingface.co/datasets/OrderLab/distdebug-bench-traces。https://github.com/OrderLab/distdebug-bench 中的 paper/reproduce.py 用已发布的评估器对其重新评分，并重建表 1、图 2 与图 3。

下面的轨迹分析在评估结束后读取 trajectory.json。它们不改变评分。我们用这些轨迹检查每一次运行在给出最终诊断之前搜索了哪些文件、日志和符号。

E.2 延迟发现代理指标

对于具有可解析执行轨迹的运行，我们把延迟恢复定义为：最终诊断文件中没有任何一个出现在最先检查的两个源文件之中。这是对「从早期搜索失误中恢复」的一个保守代理指标。它并不能证明智能体是通过回溯进行推理的，但能识别出最终答案并非已经出现在第一个局部源代码范围之中的情形。

表 13：可解析的 Mini-SWE-Agent 与 OpenCode 轨迹上的延迟恢复代理指标。

在该轨迹子集的 80 次成功运行中，只有 9 次是延迟恢复（11.25%）。因此，当前框架强烈受早期搜索范围塑造：它们能跟随初始区域内的证据，但成功的诊断很少出现在正确文件缺席于最初两个被检查源文件的情况之后。

E.3 工具调用非确定性扫描

工具调用的非确定性是诊断非确定性的一个具体驱动因素。我们在 120 个缺陷的主评估集上，对 Mini-SWE-Agent 轨迹做了一次轻量扫描。对每个缺陷和每个模型，我们比较三次已完成运行的前五条 shell 命令。我们还提取了文件读取或代码搜索命令中最先提到的源文件路径。这衡量的是早期搜索分歧，而不是正确性。

表 14：每个缺陷三次 Mini-SWE-Agent 尝试之间的早期工具使用分歧。

前五条命令这一指标故意做得很粗，不应被理解为错误率：命令标志或顺序之类的无害差异就足以计为分歧。首个源文件这一指标与诊断更相关。它表明，有不可忽略的一部分重复尝试一开始就在阅读不同的代码区域。在弱证据缺陷上，这些早期差异可以决定该次运行后来试图证成哪一种局部解释。这促使我们采用自适应工具：当早期搜索范围不完整时，自动扩充智能体的上下文，而不是依赖单一序列的手工 shell 命令去发现正确证据。

E.4 代表性轨迹摘录

表 15 给出原始轨迹的紧凑摘录。该表改写了很长的 shell 命令和工具输出。每一行比较同一框架、同一模型在同一缺陷上的两次尝试；它不是跨模型比较。这些摘录的目的是让分支点可见：检索词、代码窗口和后续文件上的细小变化，就可以把同一模型锁进不同的局部解释。

表 15：失败模式分析背后、同一模型的代表性轨迹对比。

这些例子表明，工具调用的非确定性如何变成诊断的非确定性。在 ZooKeeper-3769 中，把日志查询从选举状态用语改成异常与接收线程用语，会改变下一个被检查的文件以及最终的因果叙述。在 ZooKeeper-2845 中，两次尝试都以同一套保留数据库词汇开始，但一次不断加深同步假设，另一次则追问哪条关闭路径保留了陈旧状态。

E.5 尝试级提升空间

重复运行的设置还提供了一个简单的上界检查：若执行更可靠并具备自我修正，智能体能否做得更好。对每个缺陷，我们把三次尝试所报告的平均块覆盖率，与一个对该缺陷取最佳尝试的预言机相比较。这不是一个可部署的指标，但它表明失败是否完全由模型能力决定，还是执行一致性仍留下可测量的提升空间。

表 16：在 120 个缺陷的共同队列上，每个缺陷所选三次 Mini-SWE-Agent 尝试的最佳尝试提升空间。

对 GPT-5.5 而言，有 14 个缺陷至少在一次尝试中被完全覆盖，但并非在全部三次尝试中都被覆盖。这意味着有些失败并非因为绝对没有能力识别正确的源码区域。同一模型与同一框架有时能找到正确的块，但执行路径还不够可靠，因而不能稳定地做到这一点。

E.6 ZooKeeper-2845 的轨迹模式

ZooKeeper-2845 是早期范围锁定的一个例子。报告描述了领导者选举期间被保留的数据库状态、超前于快照的事务日志，以及重启后不一致的法定人数。这种表述使法定人数与同步代码成为一个合理的第一目标。因此若干轨迹一开始就在 src/java/main/org/apache/zookeeper/server/quorum 下搜索或阅读。

然而，金标准块位于：

src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java function: ZooKeeperServer.shutdown lines: 555--558

停留在法定人数代码内的运行，可以围绕领导者选举或同步构建出连贯解释，同时错过控制数据库保留的生命周期块。智能体并非找不到任何相关代码；它停在了最明显的症状侧位置，而没有继续寻找使该症状成为可能的更早状态转换。当报告没有直接点名确切的因果代码时，最初的问题叙述会把智能体引向一个邻近但不完整的诊断。

E.7 对未来框架的启示

这些观察提示出三项具体的框架要求。第一，框架应当提供自适应的上下文构造：当早期范围证据不足时，工具应当显露出相邻文件、调用路径、数据流边、相关符号以及替代子系统。第二，框架应当把各个假设保存为彼此独立的状态，从而使为一个分支收集的证据不会成为此后全部推理的默认上下文。第三，框架应当增加正确性检查，追问所提出的源码区域是否解释了整条因果链，而不是仅仅匹配某个症状、栈帧或局部代码路径。

附录 F 探索性子集实验

我们还在 Mini-SWE-Agent 与 OpenCode 下，用 DeepSeek 和 Qwen 模型做了探索性实验。这些运行对模型选择的背景有用，但不能与排行榜比较：每个模型完成的缺陷子集各不相同。为使比较更公平，我们只在该模型恰好完成的同一缺陷子集上，将其与 Mini-SWE GPT-5.2-Codex 比较。

表 17：探索性子集实验。每个模型都只在它自己完成的缺陷子集上，与 Mini-SWE GPT-5.2-Codex 比较。Cov.、prec. 与 std. 分别是覆盖率、精确率与标准差的缩写；均为百分数。Mini-SWE 表示 Mini-SWE-Agent，子集报告的是已完成缺陷数／所代表系统数。括号中的值是相对同一子集上 GPT-5.2-Codex 的配对差值。不稳定缺陷为计数，不稳定差值是该模型计数减去 GPT-5.2-Codex 计数。token 用量是每次运行的平均 token 数，乘数相对于同一批缺陷上的 GPT-5.2。

图 8：探索性子集实验中逐缺陷配对的块覆盖率差值。每条条形是该模型完成的一个缺陷，并与同一缺陷上的 Mini-SWE GPT-5.2-Codex 比较。正值条形表示探索性模型在该缺陷上优于基线。这些运行不在主排行榜中，因为已完成子集并不一致。

图 9：子集实验按证据类别划分的配对块覆盖率差值。每个单元格在同一已完成缺陷子集和同一类别上，将某个模型与 Mini-SWE GPT-5.2-Codex 比较。GPT-5.4 面板使用 120 个缺陷的共享评估集；其余面板为探索性子集实验。单元格文字给出 GPT-5.2$\rightarrow$模型的绝对块覆盖率、以百分点计的配对差值，以及缺陷数量。部分单元格计数很小，因此该图是描述性的，而不是排行榜比较。

图 10：共享集上的探索性比较。左列使用所有部分探索性行与 Mini-SWE GPT-5.2-Codex 都完成了的 35 个缺陷。右列去掉约束最强的 Mini-SWE Qwen3.6 Max 运行，得到 55 个共享缺陷。底行表明，即便在同一缺陷集上评估，若干较新模型仍需要多得多的 token。

表 17 表明，若干探索性模型在它们自己完成的子集上达到或超过 GPT-5.2-Codex 基线，但 token 用量往往高得多。图 8 给出逐缺陷的配对差值，图 9 则按证据类别拆开同一配对比较。最后，图 10 在共同的共享子集上比较模型：所有部分探索性行都完成的 35 个缺陷，以及去掉约束最强的 Mini-SWE Qwen3.6 Max 运行之后的 55 个缺陷集合。这些结果支持主论文的决定：主排行榜使用共同的 120 缺陷队列，且每种配置有三次有效的已评分尝试；而不一致的子集实验则作为探索性证据，而不是主要基准结果。

附录 G 评估器有效性与污染分析

这些研究检验定位指标是否捕捉到有用的诊断信息，以及公开问题的暴露能否解释这些结果。

G.1 评估器验证

#### 评分盲审。

我们审核 20 份因块覆盖率为零而选出的 GPT-5.4 诊断，定性评估期间隐藏分数。该评估把「诊断是否重建了失效机制」与「它是否把责任放在被标注的代码位置」区分开来。表 18 给出完整的结果分解。四份诊断重建了因果链，但指出了另一个同样合理的干预点。例如，有一份诊断把空指针失效的责任放在某个具体的 Op.check 实现上，而被接受的定位则在更宽的 processRequest 路径中。其余 16 份诊断的假设不正确，或因果解释不完整。

表 18：对 20 份零块覆盖 GPT-5.4 诊断的评分盲审。

因此，合理的替代定位并不能解释大多数零分输出：20 份中有 16 份不正确或因果上不完整。块覆盖率衡量的是对被标注因果实现的恢复，而不是每一个合理的干预点或修复点；那四份替代诊断表明这一区分在何处要紧。因为该审核只抽样零分输出，这些比例描述的是该样本，而不是全基准的假阴性率。

#### 全基准假阴性估计。

我们从全部 17 种配置中块覆盖不完整的 3,293 次尝试里，按分层随机抽样估计该比率：抽取 100 次，其中 69 次为零覆盖、31 次为部分覆盖，与两个层的比例一致。样本包含 193 个被遗漏的金标准块。两名 AI 审阅者独立判断每一个被遗漏的块：Claude Opus 5.5 与 GPT-6 Astra（分别通过 Claude Code 与 Codex CLI 运行），二者均为高推理强度，对修复前源码仅有只读访问，且不能访问网络。每名审阅者收到问题报告、金标准块、作为真值的历史修复以及该诊断，但看不到诊断分数，也不知道产出该诊断的模型。被遗漏的块在下列情形下算假阴性：诊断以偏移后的坐标点名了同一段代码，或者点了一个本身就是缺陷的不同位置——只改该位置就能阻止所报告的失效，且它不是调用方、症状现场或防御性检查。只有两名审阅者一致时，我们才计为假阴性。

审阅者在 85% 的被遗漏块上意见一致（Cohen 的 $\kappa=0.47$）。按各层被遗漏块的数量加权后，被遗漏金标准块中有 8.8% 为假阴性，若把它们计入，块覆盖率将提高 5.0 个百分点（表 19）。在 17 个假阴性块中，有 10 个以不同坐标点名了金标准代码，主要是因为金标准块是对照与任务快照不同的修订版本标注的；我们将在下一版本中修正这些标签。另外 7 个是替代位置。任一审阅者单独判断都会给出更高比率，因此要求一致同意给出的是保守估计。

表 19：全基准评估器假阴性，由 100 次块覆盖不完整的抽样尝试估计（193 个被遗漏的金标准块）。方括号内为 95% 分层自助法区间；第一行是所报告的估计。

#### 诊断辅助修复：设计。

我们从 GPT-5.4 诊断评估中选出 20 个缺陷：一个有可用 100% 覆盖诊断的十缺陷高覆盖集合，以及一个有可用 0% 覆盖诊断的十缺陷低覆盖集合。其中六个被抽中的缺陷同时具有来自同一模型与同一框架的高覆盖诊断和低覆盖诊断。这些混合案例支持缺陷内比较，包含三个条件：不提供诊断、提供低覆盖诊断、提供高覆盖诊断。对其余案例，我们比较无诊断与可用诊断条件。每个条件对每个缺陷做三次修复尝试。在这六个缺陷的比较中，修复模型、代码库、框架、工具与预算保持固定；变化的是所提供的诊断。

一位作者对照原始问题解决方案与 PR 检查每个生成的补丁。金标准文件触及表示补丁修改了参考修复应当落在的文件；金标准块触及表示它修改了被标注的因果区域。已生成补丁报告是否生成了补丁。

表 20：在两个十缺陷集合上的诊断辅助修复（每行 30 次尝试）。补丁生成率与触及率为百分数；成本是每次修复尝试的平均 API 成本，单位为美元。

表 21：六个混合案例上的缺陷内修复比较，每个缺陷每个条件三次尝试。触及率为百分数，并附原始计数。

#### 修复结果。

在六个混合案例上，把低覆盖诊断换成高覆盖诊断，使金标准文件触及提高 27.8 个百分点，金标准块触及提高 50.0 个百分点（表 21）。相对无诊断，高覆盖诊断使金标准块触及提高 38.9 个百分点，同时使平均模型调用减少 22.7%，API 成本降低 33.7%。两个十缺陷集合呈现出相似模式（表 20）。在高覆盖集合上，无辅助的智能体已在 56.7% 的尝试中触及金标准块，因此诊断主要减少搜索代价：金标准块触及升至 60.0%，而成本从 $1.44 降至 $1.02。在低覆盖集合上，没有诊断好过一份糟糕的诊断：金标准块触及从 6.7% 降到 0%。

这是一次小规模试点，而不是对端到端补丁正确性的精确估计。尽管如此，受控的缺陷内比较提供了证据：块覆盖率更高的诊断能更可靠、更高效地把下游修复引向因果代码。

G.2 污染分析

#### 直接答案检索与泄漏防护。

我们的奖励黑客检查针对一条具体捷径：不去根据所提供的事故证据和修复前代码诊断失效，而是检索历史修复。早期实验在没有泄漏防护的情况下运行。随后的轨迹检查发现，智能体在搜索并取回未来的修复提交。工作区路径还暴露了原始问题 ID，从而给了智能体一个查找键。因此我们删除了任务快照之后的提交，并匿名化了工作区目录名。

该防护扫描可见推理、工具输入和工具输出，查找本应向智能体隐藏的原始问题 ID。匹配包括完整问题键或其数字部分，例如 git log | grep ZooKeeper-2845 与 git log | grep 2845。我们将该检查应用于已记录轨迹，包括早期实验，丢弃被标记的尝试，并重新运行，直到每个缺陷都有三次干净的尝试。残留命中还会促使我们审核已准备的工作区，以去除暴露的标识符或修复信息。表 22 把受影响轨迹与各通道中的匹配事件分开报告；单条轨迹可能包含许多次匹配。

表 22：删除未来提交之前与之后的泄漏防护结果。报告分母为 360 次尝试（$120$ 个缺陷 $\times$ $3$ 次尝试）。括号内为被标记的百分比；最后三列统计匹配事件数。

删除未来提交大幅降低了检测到的泄漏：GPT-5.4 被标记的尝试从 102/360（28.3%）降到 4/360（1.1%）。残留命中说明，为何在清理工作区之后仍然需要轨迹检查。

#### 隐式记忆。

标识符匹配检测的是答案检索的显式痕迹，但模型也可能在不提及 ID 的情况下回忆起某个缺陷。公开已久的缺陷仍然可能很难：在 ZooKeeper-2845 中，失败的运行聚焦于报告所暗示的法定人数子系统，而错过了 ZooKeeperServer.java 中的因果代码（附录 E）。我们通过问题年龄相关性与闭卷诊断探测，更广泛地考察这一问题。

#### 问题年龄与公开讨论。

在全部 120 个问题中，GPT-5.4 的块覆盖率与问题年龄的 Pearson $r=-0.002$、Spearman $\rho=-0.032$，与当前问题评论数的 $r=-0.052$、$\rho=-0.048$。在 13 种 Mini-SWE 配置中，与问题年龄的相关范围是 $-0.081$ 到 $0.087$（Pearson），以及 $-0.125$ 到 $0.058$（Spearman；表 23）。更老或讨论更多的问题，在诊断上并非系统性更容易。GPT-5.4 的覆盖率与解决时长负相关（在去掉各系统均值并控制问题年龄之后 $r=-0.269$），这更符合「困难缺陷需要更长时间才能解决」，而不是「更多公开暴露使它们更容易」。

表 23：13 种 Mini-SWE 配置中，问题年龄与缺陷级块覆盖率的相关。$r^{2}$ 值为百分数。

#### 闭卷探测：设计。

我们在不提供代码库访问、工具、Git 历史或互联网的条件下评估 GPT-5.4。在 120 份基准报告中，我们排除 54 份直接包含精确金标准文件名或函数名的报告，剩下 66 个缺陷。先在每个缺陷内对三次尝试取平均，再跨缺陷取平均。我们比较三种提示变体：带问题 ID 的原始报告（可识别）、涂去问题 ID 的报告（匿名），以及只有项目与问题 ID、没有报告（仅 ID）。表 24 中有代码库辅助的参照使用同样的 66 个缺陷。没有源码访问时，模型不会给出源码行范围，因此闭卷的行覆盖率与块覆盖率为零；我们在文件覆盖率与函数覆盖率上比较各变体。

表 24：66 个缺陷上的 GPT-5.4 污染探测（每种闭卷变体 198 次尝试）。所有条目均为平均覆盖率百分数。

#### 闭卷结果与解释。

有代码库辅助的覆盖率高于每一种闭卷变体。在这些探测中，提供问题 ID 并不能提高函数覆盖率：可识别报告为 17.3%，匿名报告为 21.4%。仅 ID 的提示在全部四种粒度上覆盖率均为零。另一项从报告反推 ID 的探测，精确目标标识符的恢复数为 0/360。与之相对，有代码库辅助的函数覆盖率达到 45.5%，块覆盖率达到 56.9%。这一差距支持把代码库探索视为诊断的重要组成部分：仅凭报告文本和问题身份，恢复不了同样的因果代码细节。

在没有代码库访问时仍非零的文件／函数覆盖率，可能反映对项目结构的了解或报告中的线索，包括在去掉精确金标准文件名和函数名之后仍然保留的类名与子系统名。例如，对 LocalHealthMonitor、InitProducerId 或 QuorumCnxManager.Listener 的指称，会约束合理的代码区域。

综合来看，轨迹审核识别并去除了直接的答案检索捷径，而年龄分析与闭卷探测则检验公开的问题暴露是否会轻易转化为准确诊断。结果支持为识别因果代码而探索代码库的重要性。它们并未排除全部预训练暴露或隐式记忆。

NeurIPS 论文核对清单

1. 1. 主张
2. 问题：摘要与引言中提出的主要主张是否准确反映了论文的贡献与范围？
3. 回答：[是]
4. 理由：摘要与第 1 节陈述了论文范围：一个面向分布式系统诊断的基准、块级根因标签，以及对当前智能体的实证评估。
5. 指南：• 回答 [不适用] 表示摘要与引言并不包含论文中提出的主张。• 摘要和／或引言应当清楚陈述所提出的主张，包括论文做出的贡献以及重要假设与局限。对本问题回答 [否] 或 [不适用]，审稿人不会给予好评。• 所提出的主张应当与理论及实验结果相符，并反映这些结果预期能在多大程度上推广到其他设定。• 可以把愿景性目标作为动机，只要明确这些目标并非本论文已经达成。
6. 2. 局限性
7. 问题：论文是否讨论了作者所做工作的局限性？
8. 回答：[是]
9. 理由：第 A.6 节与第 D.1 节讨论了基准选择、标签敏感性、较小的类别样本，以及缺陷级重抽样背后的假设。第 G.1 节与第 G.2 节描述了人工审核与修复试点的范围、基于标识符的泄漏检测，以及记忆探测的限度。
10. 指南：• 回答 [不适用] 表示论文没有局限性，而回答 [否] 表示论文有局限性，但论文中并未讨论。• 鼓励作者在论文中单设「局限性」一节。• 论文应当指出任何强假设，以及当这些假设被违反时结果有多稳健（例如独立性假设、无噪声设定、模型设定良好、渐近近似只在局部成立）。作者应当反思这些假设在实践中可能如何被违反，以及这意味着什么。• 作者应当反思所提出主张的范围，例如该方法是否只在少数数据集上或少数次运行中测试过。一般而言，实证结果往往依赖隐含假设，这些假设应当被说清楚。• 作者应当反思影响该方法性能的因素。例如，人脸识别算法在图像分辨率低或拍摄光线暗时可能表现很差。或者，语音转文字系统也许不能可靠地为在线讲座提供隐藏式字幕，因为它处理不了专业术语。• 作者应当讨论所提出算法的计算效率，以及它们如何随数据集规模伸缩。• 若适用，作者应当讨论其方法在处理隐私与公平问题时可能存在的局限。• 作者也许担心，对局限性的完全坦诚会被审稿人当作拒稿理由，但更糟的结果可能是审稿人发现了论文并未承认的局限。作者应当运用自己的最佳判断，并认识到，有利于透明的个人行动，在形成维护社区诚信的规范方面起着重要作用。审稿人将受到专门指示，不要因对局限性的诚实而施以惩罚。

译注：原文作 “how robust the the results are”，多写了一个 the。

11. 3. 理论假设与证明
12. 问题：对每一项理论结果，论文是否给出了全部假设以及完整（且正确）的证明？
13. 回答：[不适用]
14. 理由：论文不呈现理论结果或证明。
15. 指南：• 回答 [不适用] 表示论文不包含理论结果。• 论文中的全部定理、公式与证明都应当编号并交叉引用。• 全部假设都应当在任何定理的陈述中清楚写出或加以引用。• 证明既可以出现在正文中，也可以出现在补充材料中；若出现在补充材料中，鼓励作者提供简短的证明概要以建立直觉。• 反过来，正文核心中给出的任何非正式证明，都应当由附录或补充材料中的形式证明加以补充。• 证明所依赖的定理与引理应当被妥善引用。
16. 4. 实验结果的可复现性
17. 问题：无论是否提供代码与数据，论文是否充分披露了复现其主要实验结果所需的全部信息，以至于这些信息会影响到论文的主要主张和／或结论？
18. 回答：[是]
19. 理由：第 3 节、第 4 节与第 C 节规定了任务输入、标签、模型与框架版本、推理强度、提示摘录以及评分指标。第 D.3 节、第 D.1 节与第 D.2 节规定了尝试选择、聚合、自助法设置、配对比较以及系统排除。
20. 指南：• 回答 [不适用] 表示论文不包含实验。• 若论文包含实验，对本问题回答 [否] 不会得到审稿人的好评：使论文可复现很重要，无论是否提供代码与数据。• 若贡献是数据集和／或模型，作者应当描述为使结果可复现或可核验而采取的步骤。• 视贡献而定，可复现性可以用多种方式实现。例如，若贡献是一种新架构，充分描述该架构也许就够了；若贡献是某个具体模型及其实证评估，则也许有必要让他人能用同一数据集复现该模型，或者提供对该模型的访问。一般而言，发布代码与数据常常是实现这一点的一种好办法，但也可以通过详细的结果复现说明、对托管模型的访问（例如大语言模型的情形）、发布模型检查点，或其他与所做研究相称的手段来提供可复现性。• 虽然 NeurIPS 并不要求发布代码，但会议要求所有投稿都提供某种合理的可复现途径，这可能取决于贡献的性质。例如（a）若贡献主要是一种新算法，论文应当说明如何复现该算法。（b）若贡献主要是一种新的模型架构，论文应当清楚、完整地描述该架构。（c）若贡献是一个新模型（例如大语言模型），则要么应当有办法访问该模型以复现结果，要么应当有办法复现该模型（例如借助开源数据集，或给出如何构造该数据集的说明）。（d）我们认识到，在某些情况下可复现性可能很难做到，此时欢迎作者描述他们为可复现性所提供的特定方式。对闭源模型而言，对模型的访问也许在某种程度上受限（例如仅限注册用户），但其他研究者应当有某种途径来复现或核验结果。
21. 5. 数据与代码的开放获取
22. 问题：论文是否按补充材料中的描述，开放获取数据与代码，并提供足够说明以忠实复现主要实验结果？
23. 回答：[是]
24. 理由：基准、评估器与智能体运行器发布于 https://github.com/OrderLab/distdebug-bench，全部 6,120 次已评分尝试的轨迹发布于 https://huggingface.co/datasets/OrderLab/distdebug-bench-traces，并附有从这些轨迹重建表 1 以及图 2 与图 3 的脚本；第 3 节描述了所发布的数据格式，第 4 节描述了评估协议。
25. 指南：• 回答 [不适用] 表示论文不包含需要代码的实验。• 更多细节请见 NeurIPS 代码与数据投稿指南（https://neurips.cc/public/guides/CodeSubmissionPolicy）。• 虽然我们鼓励发布代码与数据，但我们理解这也许做不到，因此 [否] 是可以接受的回答。不能仅仅因为没有包含代码就拒稿，除非代码对贡献至关重要（例如一个新的开源基准）。• 说明应当包含复现结果所需运行的准确命令与环境。更多细节见 NeurIPS 代码与数据投稿指南（https://neurips.cc/public/guides/CodeSubmissionPolicy）。• 作者应当提供数据访问与准备的说明，包括如何访问原始数据、预处理数据、中间数据与生成数据等。• 作者应当提供脚本，以复现新提出方法与基线的全部实验结果。若只有一部分实验可复现，他们应当说明脚本省略了哪些以及原因。• 投稿时，为保持匿名，作者应当发布匿名版本（若适用）。• 建议在补充材料（附于论文之后）中尽可能提供信息，但也允许给出指向数据与代码的 URL。
26. 6. 实验设置与细节
27. 问题：论文是否说明了理解结果所必需的全部训练与测试细节（例如数据划分、超参数、它们是如何选定的、优化器类型）？
28. 回答：[是]
29. 理由：第 4 节、第 C 节与第 D.3 节给出了所评估的配置、任务提示、120 缺陷队列以及三次尝试的选择协议。附录 F 与附录 G 规定了子集评估、修复试点与污染探测各自的队列和条件。
30. 指南：• 回答 [不适用] 表示论文不包含实验。• 实验设置应当在论文核心部分呈现到足以领会结果并理解其含义的详细程度。• 完整细节可以随代码提供，也可以放在附录或补充材料中。
31. 7. 实验的统计显著性
32. 问题：论文是否适当地、正确地报告了误差线，或提供了有关实验统计显著性的其他适当信息？
33. 回答：[是]
34. 理由：第 D.1 节定义了 95% 缺陷自助法区间，包括 10,000 次重抽样、种子 2026、独立性假设，以及针对模型差异的配对重抽样；表 9 与表 10 报告了结果。图 3 与图 D.2 给出类别计数与区间以及系统敏感性结果，第 4 节则单独报告了缺陷内变异。
35. 指南：• 回答 [不适用] 表示论文不包含实验。• 若结果附有误差线、置信区间或统计显著性检验，至少对于支撑论文主要主张的实验如此，作者就应当回答 [是]。• 应当清楚说明误差线所捕捉的变异因素（例如训练／测试划分、初始化、某个参数的随机抽取，或在给定实验条件下的整体运行）。• 应当解释计算误差线的方法（闭式公式、调用库函数、自助法等）。• 应当给出所做假设（例如误差呈正态分布）。• 应当明确误差线是标准差还是均值的标准误。• 可以报告 1 倍标准差的误差线，但应当加以说明。若尚未验证误差的正态性假设，作者最好报告 2 倍标准差的误差线，而不是声称自己有 96% 置信区间。• 对于非对称分布，作者应当小心，不要在表格或图中展示对称误差线，以免得出超出范围的结果（例如负的错误率）。• 若在表格或图中报告了误差线，作者应当在正文中解释它们是如何计算的，并在正文中引用相应的图或表。
36. 8. 实验计算资源
37. 问题：对每一项实验，论文是否提供了复现实验所需计算机资源（计算工作节点类型、内存、执行时间）的充分信息？
38. 回答：[是]
39. 理由：主要计算资源是托管模型的 API 推理；第 4 节与第 1 节标明了模型／框架配置，并报告了每次诊断的 API 调用与 token。附录 F 与附录 G.1 报告了子集评估的 token 用量以及修复试点的 API 成本。
40. 指南：• 回答 [不适用] 表示论文不包含实验。• 论文应当指出计算工作节点的类型，是 CPU 还是 GPU、内部集群还是云服务提供商，并包括相关的内存与存储。• 论文应当提供每一次单独实验运行所需的计算量，并估计总计算量。• 论文应当披露整个研究项目所需的计算是否多于论文中报告的实验（例如未进入论文的初步实验或失败实验）。
41. 9. 伦理准则
42. 问题：论文中开展的研究是否在每一方面都符合 NeurIPS 伦理准则 https://neurips.cc/public/EthicsGuidelines？
43. 回答：[是]
44. 理由：本工作在公开的开源问题报告与代码库上评估智能体；人类参与包括作者标注、诊断评估与补丁检查（第 A.5 节与第 G.1 节）。它不招募人类参与者，也不发布新模型。
45. 指南：• 回答 [不适用] 表示作者没有审阅 NeurIPS 伦理准则。• 若作者回答 [否]，他们应当解释需要偏离伦理准则的特殊情形。• 作者应当确保保持匿名（例如，若因其司法辖区的法律或法规而有特殊考量）。
46. 10. 更广泛的影响
47. 问题：论文是否同时讨论了所做工作潜在的正面社会影响与负面社会影响？
48. 回答：[是]
49. 理由：第 1 节以更好地诊断代价高昂的生产失效为动机，并讨论了修复如何可能压住症状、同时留下未解决的根因。第 4 节与第 E 节考察不正确的诊断和误导性的验证信号，并主张在依据智能体的诊断采取行动之前加强检查。
50. 指南：• 回答 [不适用] 表示所做工作没有社会影响。• 若作者回答 [不适用] 或 [否]，他们应当解释为何其工作没有社会影响，或为何论文不讨论社会影响。• 负面社会影响的例子包括潜在的恶意或非预期用途（例如虚假信息、生成虚假档案、监控）、公平性考量（例如部署可能做出不公平地影响特定群体之决策的技术）、隐私考量以及安全考量。• 会议预期许多论文将是基础研究，并不绑定于特定应用，更不必说部署。然而，若存在通向任何负面应用的直接路径，作者应当指出来。例如，指出生成模型质量的改进可能被用来生成用于虚假信息的 Deepfakes，是正当的。另一方面，不必指出一种用于优化神经网络的通用算法可能让人更快地训练出生成 Deepfakes 的模型。• 作者应当考虑：当技术按预期使用且运行正确时可能产生的危害，当技术按预期使用但给出不正确结果时可能产生的危害，以及技术被（有意或无意）误用之后产生的危害。• 若存在负面社会影响，作者也可以讨论可能的缓解策略（例如模型的门控发布、在提供攻击的同时提供防御、监测误用的机制、监测系统如何随时间从反馈中学习的机制、提高机器学习的效率与可及性）。
51. 11. 安全保障
52. 问题：对于具有高误用风险的数据或模型（例如预训练语言模型、图像生成器或抓取得到的数据集），论文是否描述了为负责任发布而已经到位的安全保障？
53. 回答：[不适用]
54. 理由：论文不发布新模型或抓取得到的个人数据集。该基准基于公开、固定的软件事故与源代码产物。
55. 指南：• 回答 [不适用] 表示论文不构成此类风险。• 具有高误用或两用风险的已发布模型，应当带有必要的安全保障，以便对模型的使用加以控制，例如要求用户遵守使用指南或访问限制才能使用模型，或实施安全过滤器。• 从互联网抓取的数据集可能带来安全风险。作者应当描述他们如何避免发布不安全图像。• 我们认识到，提供有效的安全保障具有挑战性，许多论文并不需要这一点，但我们鼓励作者将其考虑在内，并尽最大诚意努力。
56. 12. 既有资产的许可
57. 问题：论文所使用资产（例如代码、数据、模型）的创建者或原始所有者是否得到了适当署名，许可与使用条款是否被明确提及并得到适当尊重？
58. 回答：[是]
59. 理由：论文引用了用于比较的主要既有基准、数据集、框架和模型家族。最终的产物发布为每一个底层开源项目和基准资产包含了明确的许可元数据。
60. 指南：• 回答 [不适用] 表示论文不使用既有资产。• 作者应当引用产出该代码包或数据集的原始论文。• 作者应当说明使用的是该资产的哪一版本，并在可能时给出 URL。• 应当为每一项资产写明许可名称（例如 CC-BY 4.0）。• 对于从特定来源（例如网站）抓取的数据，应当提供该来源的版权与服务条款。• 若发布资产，应当在包中提供许可、版权信息与使用条款。对常见数据集，paperswithcode.com/datasets 为部分数据集整理了许可。他们的许可指南可以帮助确定数据集的许可。• 对于被重新打包的既有数据集，应当同时提供原始许可以及派生资产的许可（若许可已改变）。• 若这些信息无法在线获得，鼓励作者联系资产的创建者。
61. 13. 新资产
62. 问题：论文引入的新资产是否有良好文档，且文档是否与资产一并提供？
63. 回答：[是]
64. 理由：第 3 节、第 A 节与第 C 节记录了基准的输入、文件布局、标签、筛选过程与输出约定。第 A.5 节与第 A.6 节提供了标注一致性结果，以及所筛选数据的范围与局限。
65. 指南：• 回答 [不适用] 表示论文不发布新资产。• 研究者应当通过结构化模板，把数据集／代码／模型的细节作为投稿的一部分加以说明。这包括训练、许可、局限性等方面的细节。• 论文应当讨论是否以及如何获得了其资产被使用之人的同意。• 投稿时，请记得将资产匿名化（若适用）。可以创建匿名 URL，或附上匿名压缩包。
66. 14. 众包与人类受试者研究
67. 问题：对于众包实验和人类受试者研究，论文是否包含给予参与者的说明全文以及屏幕截图（若适用），以及报酬细节（若有）？
68. 回答：[不适用]
69. 理由：论文不涉及众包或招募的人类参与者。人类工作包括基准标注，以及对模型诊断与补丁的评估（第 A.5 节与第 G.1 节）。
70. 指南：• 回答 [不适用] 表示论文既不涉及众包，也不涉及人类受试者研究。• 把这些信息放在补充材料中是可以的；但若论文的主要贡献涉及人类受试者，则应当在正文中尽可能详细地包含这些信息。• 根据 NeurIPS 伦理准则，参与数据收集、筛选或其他劳动的工作者，其报酬至少应当达到数据收集者所在国家的最低工资。
71. 15. 针对人类受试者研究的机构审查委员会（IRB）批准或等效审批
72. 问题：论文是否描述了研究参与者可能承受的风险、这些风险是否向受试者披露，以及是否取得了机构审查委员会（IRB）批准（或基于你所在国家或机构要求的等效批准／审查）？
73. 回答：[不适用]
74. 理由：本研究评估软件智能体与公开的软件事故；它不收集参与者数据，也不在人类受试者上做实验。标注与诊断审核评估的是软件产物和模型输出。
75. 指南：• 回答 [不适用] 表示论文既不涉及众包，也不涉及人类受试者研究。• 视开展研究所在的国家而定，任何人类受试者研究都可能需要 IRB 批准（或等效审批）。若已获得 IRB 批准，应当在论文中明确说明。• 我们认识到，相关程序在不同机构与地点之间可能差异很大，我们期望作者遵守 NeurIPS 伦理准则及其所在机构的指南。• 对于初次投稿，不要包含任何会破坏匿名的信息（若适用），例如开展审查的机构。
76. 16. 大语言模型使用声明
77. 问题：若大语言模型是本研究核心方法中重要的、原创的或非标准的组成部分，论文是否描述了其用法？请注意，若大语言模型仅用于写作、编辑或排版，并且并不影响研究的核心方法、科学严谨性或原创性，则不需要声明。
78. 回答：[是]
79. 理由：第 4 节与第 G 节描述了基于大语言模型的诊断评估、修复试点和闭卷探测。附录 B 记录了单独的大语言模型辅助收集实验；所发布的金标准标签仍由人工筛选。
80. 指南：• 回答 [不适用] 表示本研究的核心方法开发并不把大语言模型用作任何重要的、原创的或非标准的组成部分。• 关于应当或不应当描述什么，请参阅 NeurIPS 手册中的大语言模型政策。