分布式系统调试基准：智能体能否定位 120 个真实缺陷

1. 一句话结论

DistDebug-Bench 把「智能体会不会写代码」的考题换成「智能体能不能在真实分布式系统里把故障定位到代码级」：它用 120 个真实缺陷搭出一套基准，并把当前模型的失败归到两个具体原因上——缺少显式推理结构导致的隧道视野，以及工具使用范围不一致带来的结果不确定性。论文发表于 NeurIPS 2026 评测与数据集方向。

2. 方法要点

核心思路不是改模型，而是改考题。已有的软件工程基准大多停留在自包含的 Python 小模块上，做函数级修复或代码合成；分布式系统作为生产软件的主力形态，反而没被单独考察。作者的做法是从 11 个被广泛使用的分布式系统里筛出 120 个高质量真实缺陷，要求智能体在代码层面给出根因诊断，而不是丢一段补丁了事。

关键设计有三点：

• 缺陷多样性：覆盖 5 种编程语言、10 类失败模式。跨语言、跨故障类型的组合，能挡住只在单一语言模式上刷出来的分数。
• 任务收窄到「诊断」：给定故障现象与代码库，输出定位结论。相比补丁合入，定位结论更适合自动判定，也少一些主观争议。
• 轨迹可审计：公开智能体轨迹与排行榜，让「它为什么这么定位」可复查，而不只是一个总分。

从结论反推的两个可干预点，写进伪代码更直观：

def diagnose(bug, repo, tools, budget):
    plan = llm.plan(bug.symptom, repo.layout)        # 先立假设，再动手查
    log = []
    for _ in range(budget):
        act = llm.choose(plan, log, scope=FIXED)     # 固定工具作用域，压制不确定性
        log.append((act, tools.run(act)))
        if llm.enough(log):
            break
    return llm.root_cause(plan, log)                 # 必须落到文件、位置与失败模式

plan 对应论文点名的「显式推理结构」，scope=FIXED 对应「一致的工具体作用域」。换句话说，作者认为分数差距里有相当一部分不是模型能力问题，而是调用方式问题：智能体一旦缺少结构化的假设-验证流程，就会围着最初看到的日志打转；工具范围一次一个样，同一模型跑两次结论就可能不同。

3. 关键数字

原文摘要没有披露各模型的通过率与提升幅度，所以下表只列基准构成与规模；跑分需到论文给出的排行榜页面查看，本文不代填。

这套数字的用法要清楚：120 个缺陷摊到 11 个系统，单系统样本量并不大，它衡量的是「诊断能力是否成立」，不是「通过率有多精确」。真正可比的是同一脚手架下不同模型的相对排序，以及同一模型换脚手架后的波动。

4. 局限与前提

• 规模有限：缺陷总量 120，跨 11 个系统，细分到「语言 × 失败模式」的交叉格子后，单格样本更少，子集结论容易受个别样本影响。
• 故障本身不确定：分布式系统的现象常由时序、网络分区、并发调度共同导致，一次运行未必复现，评测方差需要靠轨迹注释来压。
• 对脚手架敏感：论文把工具使用范围不一致列为不确定性来源，意味着同一模型在不同框架下的分数不能直接横比，换框架就得重测。
• 诊断不等于修复：基准停在定位，补丁是否正确、有无回归风险，不在考察范围内。
• 依赖评测器判定：诊断结论的自动判定边界，直接决定了分数上限。

作者自己承认的不足集中在前两条：现有智能体与真实调试任务之间仍有明显差距，而隧道视野问题在当前模型上反复出现，不是个别案例。

5. 能不能用

开源情况：基准与评测器随论文公开，智能体轨迹与排行榜另有站点入口，链接见原文与下方来源。

复现门槛不在模型，在环境：你要跑起 11 个分布式系统、5 种语言的工具链，还要为每次诊断提供隔离沙箱与可观测数据（日志、指标、调用链）。这套环境的搭建与维护开销，通常高于调用模型的费用。评估自家智能体时，更现实的做法是先挑 1 到 2 个与业务形态接近的系统，跑通「轨迹采集—判定—复现」这条链路，再扩样本。

适用场景：做智能体调试、可观测性、故障根因定位的团队，可以把它当作回归测试集，尤其是想验证「换脚手架会不会掉分」的时候。只做纯代码生成的团队，收益有限。

一句话取舍：把它当诊断能力的体检表值得，当修复能力的评分卡不值得。

参考来源

1. DistDebug-Bench 论文摘要页：https://arxiv.org/abs/2611.03523
2. 论文全文 HTML：https://ar5iv.labs.arxiv.org/html/2611.03523