TL;DR

本文核心观点：

  1. 单进程基准已饱和，分布式调试是新盲区 — 60 个历史 bug，13 个开源分布式系统，三级难度分区
  2. 模型通过率跨度达 61pp（tier-1），远高于 SWE-bench 的 7pp — 分布式调试暴露的推理维度是单进程基准测不出的
  3. 有限调试上下文整体 +18.1pp，但收益结构不对称 — 弱模型涨通过率，强模型涨效率；上下文喂得不好反而误导
  4. 上下文工程将成为 Agent 中间件下一个核心模块 — 不是无脑塞日志，而是 curation

背景：单进程基准已饱和

LLM-based coding agent 在单进程 SWE 任务上进展迅速，SWE-bench Verified 上前沿模型已聚集在高 70 分位。但分布式系统调试仍是未被充分探索的领域：bug 跨进程、跨节点、跨协议交互，根因很少能仅从源码恢复，暴力探索在非确定性交织态下不可行。

两个空白：

  1. 没有代码修复基准针对分布式系统 bug
  2. 没有对照研究量化外部调试上下文对 agent 成功率的影响

DDBench 填补了这两个空白。

DDBench：60 个历史 bug，三级难度

DDBench 包含 60 个历史 bug，从 13 个开源分布式系统挖掘，分为三个难度层：

  • Tier-1（31 个，最难）：集中协议/恢复和复制/一致性 bug，要求跨进程推理
  • Tier-2（15 个）：居中
  • Tier-3（14 个）：可本地化到单进程的输入触发崩溃

覆盖系统类型：键值存储（22）、共识库（21）、消息系统（10）、服务网格（3）、流处理引擎（3）、存储引擎（1）。

覆盖语言：Go（25）、C++（23）、Java（8）、Erlang（2）、Rust（2）。

双轨对照：症状 only vs 上下文增强

DDBench 每个 case 在两种匹配条件下评估：

  • 症状 only：agent 只接收 bug 症状和代码库，必须通过自身探索获取额外信息
  • 上下文增强：额外接收有界的调试上下文包（日志、traces、运行时状态、目标代码调查笔记）

调试上下文包每个 case 1-3 个 Markdown 文件，中位 321 tokens（最多 1,403）。上下文槽设计为可扩展的：研究者可以用自己的工具输出替换默认包，在相同 case 和相同预言下进行对比。

核心发现一：分布式调试拉开模型差距

在 tier-1 case set 上，10 个模型的通过率跨度达 61pp。配对 bootstrap 测试在 p < 0.05 下区分了 15 个顶级模型对中的 9 对。

对比：在同一批模型上，SWE-bench Verified 只拉开 7pp。这意味着分布式调试锻炼的推理维度与单进程代码修复本质不同。

核心发现二：调试上下文收益结构不对称

有界调试上下文将aggregate通过率从 32.6% 提升到 50.6%（+18.1pp）。

但收益结构不对称：

  • 弱模型：主要涨通过率（GLM 4.7：从 9.7% → 48.4%）
  • 强模型：通过率提升微弱，但成本大幅下降（Opus 4.6：token 消耗降低 69%，完成步数减少 41%）

上下文增强甚至能重排模型排名：上下文增强的 GPT-5.4 匹配 Opus-4.6 的症状 only 通过率，同时减少 60% token 消耗。

核心发现三：上下文需要 curation，否则可能误导

即使忠实的调试上下文有时也会误导强模型——当其观察远离故障时。这揭示了未经 curation 盲目添加信息的隐藏风险。

上下文槽因此成为 agent 工具增强的一等设计轴。

结尾

DDBench 揭示的核心问题是：分布式调试不仅是更难的任务，更是不同种类的推理——跨进程因果、非确定性交织、协议级不变量。基准已饱和的差异不是「谁更高分」，而是「谁在测不同的东西」。调试上下文工程因此不是「多塞日志」，而是「在正确时机给正确信息」——弱模型需要上下文救命，强模型需要上下文省 token。上下文 curation 将成为 Agent 中间件的下一个核心模块。

Published on 2026-08-31

参考链接