DistDebug-Bench：LLM Agent 能否诊断分布式系统中的 Bug？

分布式系统诊断基准 当分布式系统发生故障时，你的 agent 能找到导致故障的代码吗？ DistDebug-Bench 为 agent 提供了来自 11 个生产级分布式系统的 120 个真实故障。故障的表现位置往往远离其根因，而报告、日志和堆栈跟踪只能反映实际发生情况的一部分。 每个事件都是生产系统 issue tracker 中一个真实且已关闭的 bug，大多数属于逻辑、并发或错误处理方面的缺陷。agent 会拿到故障报告、相关日志或堆栈跟踪，以及修复前的代码仓库，并且必须指出导致故障的代码块。大多数编程基准评估的是补丁；DistDebug-Bench 评估的是诊断本身，对照人工标注的因果代码进行评分。 68% 的报告从未指明因果方法 63% 的报告没有来自项目内部的可用的堆栈跟踪 46% 的故障需要不止一个代码块才能解释清楚 5 行是标注代码块的中位数长度，因此答案必须精确 报告指向 leader election 和日志重放，但标注的根因是 ZooKeeperServer.shutdown，它让过期的内存状态一直存活到下一个 quorum。原始事件 ↗ 代码块覆盖率（block coverage）指诊断命中的已标注根因代码块所占比例；代码块精确率（block precision）指诊断所指出的代码中属于根因的部分所占比例。 找到文件只是第一步：在这些配置下，当 agent 必须找出因果代码块时，覆盖率会下降 13–22 个百分点。 在没有代码线索的情况下，覆盖率会大幅下降。 指出了因果方法 无内部堆栈跟踪 · n=16 未指出因果代码 无内部堆栈跟踪 · n=42 未指出因果代码 跨组件崩溃点 · n=7 没有直接代码线索的报告在多次运行之间表现出更大的波动。 当报告未指明因果代码时，运行间波动为 4.3 倍 均值是对每个事件的三次运行取平均，并对 120 个事件等权加权；须线为 95% 的事件 bootstrap 置信区间。 按照论文中的协议，在 ZooKeeper-2845 上运行 Mini-SWE-Agent。从基准仓库检出后，runner 会在存在 bug 的 ZooKeeper 版本上准备一个匿名化的工作区，在沙箱中运行 agent，然后由 scorer 应用论文中的评估器。需要 Python 3.10+、带 bubblewrap 的 Linux，以及已配置的模型 API key。 python3 -m venv .venv source .venv/bin/activate pip install -e ".[agent]"

在你的环境中设置 OPENAI_API_KEY。

python -m distdebug_bench.run
--config configs/mini-swe-agent/gpt-5.4.yaml
--bug zookeeper-2845 --runs 1 python -m distdebug_bench.score
results/mini-swe-agent-gpt-5.4 --attempts 1 configs/mini-swe-agent/ 中为论文中的每个模型都提供了配置。运行时会调用你配置的模型提供方。 每次尝试都会写出 trajectory.json、diagnosis.json 和 diagnosis_scores.json。要评估其他 agent，让它写出前两个文件即可。 让你的 agent 在全部 120 个事件上运行，每个事件尝试三次，然后提交其诊断结果和轨迹。在将每个提交列入排行榜之前，我们会用官方评估器重新评分。 指南涵盖本地泄漏检查、打包一次运行，以及 diagnosis.json 的结构定义。 DistDebug-Bench：LLM Agent 能否诊断分布式系统中的 Bug？Jiang 等，NeurIPS 2026。论文 ↗ · GitHub ↗ · 数据集 ↗ · 轨迹 ↗