ExplainBench：评估编码代理生成的代码解释 ExplainBench: Evaluating Code Explanations from Agents
用问答得分度量代理代码解释可信度，并用差分测试自动改进
前置知识
LLM 编码代理 (LLM Coding Agent)
LLM 编码代理是围绕大语言模型搭建的脚手架系统，能自主调用工具（读代码、跑测试、改文件）来完成软件工程任务，如修 bug、写测试。代表系统有 SWE-agent、OpenHands、trae-agent 等。它们通常在收尾的工具调用里产出一段自然语言解释，说明自己做了什么改动、为什么这样做。
本文评估的核心对象正是这些代理生成的『解释』，理解代理的工作方式才能理解为什么解释会出问题、为什么需要独立评估。
SWE-bench Verified
SWE-bench Verified 是从真实 GitHub 仓库中人工验证的 500 个软件工程任务基准，每个任务给出 issue 描述，要求代理提交补丁并通过对应的回归测试。它是当前评估代理代码生成能力（efficacy）的事实标准，衍生出多语言、按时间排序等多种变体。
ExplainBench 建立在 SWE-bench Verified 之上，并与之对比，用以证明『补丁有效』和『解释可信』是两个相互独立的评测维度。
属性测试 (Property-based Testing, PBT)
属性测试不逐个手写输入，而是由框架（如 QuickCheck）自动采样满足前置条件的输入，再断言程序输出满足某个性质。它用符号化的输入-输出关系描述行为，覆盖面比示例测试更广，因此很适合作为程序行为的紧凑符号表示。
ExplainBench 把 PBT 当作程序行为的符号表示，通过『挖空』关键断言表达式来构造选择题，这是整套评测方法的基石。
差分测试 (Differential Testing)
差分测试是对同一输入分别运行程序的两个版本（如打补丁前后），比较其输出或执行轨迹的差异。它不必事先知道正确答案，而是靠行为差异发现问题，常用于回归测试和补丁验证。
ExplanationAuditAgent 用差分测试来独立验证代理解释中的声称，是把解释变得可信的关键技术。
执行轨迹与差分行为 (Execution Trace & Delta Behavior)
执行轨迹是程序运行时记录的控制流（执行了哪些语句）和数据流（变量取值）。差分行为指打补丁前后两条轨迹中最小的可观测差异点，既可能是变量状态不同（$\sigma_B(\ell) \neq \sigma_P(\ell)$），也可能是控制流分叉（$s_\ell(B) \neq s_\ell(P)$），是定位『补丁到底改了什么行为』的关键。
ExplainBench 用自研 tracer 和 Algorithm 1 提取差分行为，据此自动构造函数级的 local 类问题。
研究动机
随着 LLM 编码代理（如 Claude Code）被开发者大量采用，代理生成的代码改动往往横跨几十到上百行，人工逐行审查变得越来越不可行——据 Anthropic 报告，多数员工每天都在用 Claude Code。开发者于是转向代理产出的自然语言解释来理解『这次到底改了什么』。然而问题是：没有任何基准能评估这些解释是否可信。在 Fig.1 的真实案例中，Lingxi 代理的总结声称『修复成功，完全解决了 issue』，补丁看上去也合理，但被打补丁修改的方法在 bug 复现测试里根本从未被执行——补丁毫无作用。这种『解释-行为』错配会直接侵蚀开发者对代理系统的信任。与此同时，现有基准（SWE-bench Verified 及其多语言变体）只衡量代理『能不能修好 bug』（efficacy），完全忽略了『它说的话对不对』（explanation trustworthiness），而这恰恰是开发者决定是否采纳补丁的关键依据。
本文的目标是本文的目标是为编码代理的解释质量建立首个可自动、可量化评估的基准 ExplainBench，让不同代理的解释能直接横向比较。具体地，作者希望：第一，给出一个客观、可复现的解释得分（explanation score），其标准误差控制在 0.01 以下；第二，能区分『解释说不清』（uninformative）和『解释说错了』（misaligned）两种不同失败模式；第三，证明解释质量与补丁有效性是相互独立的评测维度，从而推动社区把『解释可信度』纳入代理评估；第四，基于该基准设计一种通用的『解释审计代理』ExplanationAuditAgent，能把任意代理的解释质量在原基础上提升（实验中平均提升 10.9%），最终让开发者能像信任『提交代码前会自检的初级工程师』那样信任代理。
与已有工作不同的是，本文的独特切入是：与其像过去那些用 LLM 生成解释的工作那样靠人工、ad-hoc 地评估解释质量，不如反过来利用一个直觉——『信息充分的解释应该能让一个 LLM 正确回答关于 bug 和补丁的问题』。这把『评测自由文本』这个难题转化成了『评测选择题准确率』这个客观、可自动、可复现的问题。更进一步，作者抓住了一个被同行忽视的二元结构：开发者文档化修改行为的本质是 intent（应该做什么）和 effect（实际做了什么），而现有代理的解释在这两者上都会出错，尤其是对补丁正确性的过度自信。这个 intent/effect × end-to-end/local 的四象限问题设计，是解释为何『会写补丁 ≠ 会解释』的关键所在。
核心方法
ExplainBench 的直觉可以一句话概括：好的解释就像一份清晰的说明书，读完它你就能答对考试题；而空洞或误导的解释会让你答错。技术上，它把『评测解释质量』转成了一个『LLM 做选择题』的过程。整体分两阶段：(A) 构题阶段，从开发者测试、开发者补丁（作为 intent 的标准答案）和代理补丁中，自动生成四类多选题；(B) 评分阶段，把某条代理解释连同题目一起喂给一个较弱的问答 LLM（GPT-5-mini，故意选弱模型以迫使其依赖解释而非自身知识），看它能否答对。最终的解释得分 $S_{\text{exp}}$ 就是答对题目的比例。基准在 500 个 SWE-bench Verified 实例中筛出 297 个作为评测集，覆盖四种题型，每题独立运行 5 次取平均，标准误差小于 0.01。
最核心的创新点是『用问答准确率度量解释质量』，并据此把自由文本的评测彻底形式化。作者把解释该承载的信息拆成 intent（开发者补丁规定的预期行为）与 effect（代理补丁造成的实际行为）两个维度，每个维度再分 end-to-end（程序级）和 local（函数级）两个粒度，形成 $2\times 2$ 的四象限问题。比如 end-to-end intent 题会给出一条『挖空了关键断言』的属性测试，问哪个表达式能让它在 bug 版失败、修复版通过；end-to-end effect 题则问『打补丁前后这条测试的结果分别是什么』。每题都额外配一个『解释信息不足』选项，从而能把『说不清（uninformative）』和『说错了（misaligned）』区分开——这是仅看总分做不到的细粒度诊断，也是该基准信息量远超单一分数的原因。
方法步骤详情
完整流程分五步。(1) 解释抽取：解析代理轨迹，定位最后一次工具调用，原样收集其自然语言解释。(2) PBT 构造：用 SpecRover 测试生成代理结合 issue、开发者补丁与示例测试自动生成属性测试，验证它能在 bug 版失败、修复版通过（98% 自动，2% 人工补写）。(3) end-to-end 构题：intent 题手工确定期望表达式后用 LLM 生成并验证干扰项；effect 题对每个代理补丁分别记录打补丁前后测试通过/失败及失败行号与异常。(4) local 构题：基于自研 sys.settrace() 执行 tracer 采集控制流+数据流轨迹，用 Algorithm 1 提取差分行为（最小差异点），再用 LLM 生成并验证 10 个变化/不变表达式，用归一化 Levenshtein 相似度选正确项、MMR（$\lambda=0.7$）选干扰项。(5) 评分：每条解释配每道题喂 GPT-5-mini，单字母作答，5 次取均值，按 $S_{\text{exp}}=\frac{1}{|D|}\sum_d\frac{1}{|B|}\sum_b a_{b,d}$ 计分。
技术新颖性
新颖性体现在三点。第一，据作者所知 ExplainBench 是首个自动评测代理解释质量的基准——以往所有用 LLM 生成解释的工作都只能做 ad-hoc 人工评估，缺乏可量化、可比较的手段。第二，『用问答准确率当解释得分』的评测范式绕开了自由文本语义对比的难题，且通过『解释信息不足』选项把 uninformative 和 misaligned 分开，比单一分数信息量大得多。第三，技术栈上把属性测试（符号化行为表示）、执行轨迹差分（Algorithm 1 的 delta behavior）和 MMR 干扰项选择组合起来，做到了『自动生成、可验证、不平凡』的选择题——比如正确项故意挑与不变项最相似的，避免送分题。这与 SWE-bench 系列只评 efficacy 的方向形成了互补。
实验结果
RQ1（Table 3）给出最反直觉的结论：解释质量与补丁有效性是两个独立维度。SWE-bench efficacy 最高的 trae-agent（0.818，#1）解释得分仅第 4（0.558）；而 efficacy 第 4 的 OpenHands（0.727）反而拿下最高解释分（0.597）。整体上 end-to-end 得分（0.6–0.82）远高于 local（0.30–0.52），说明代理擅长讲整体动机却讲不清函数级细节；SEM<0.01，换 GPT-5-nano 排名不变。RQ2（Table 4）把失败拆两类：end-to-end intent 主要是信息不足（49.8%），local intent 与 end-to-end effect 主要是误导/错误。Table 5 揭示过度自信：在所有未通过测试的补丁里，问答 LLM 仍有平均 79.30% 误判为『测试会通过』，各代理介于 71.6%–83.65%。RQ3（Table 6）显示 ExplanationAuditAgent 让所有代理解释分都提升，平均 +10.9%，mini-SWE-agent 达 +33.5%。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 代理解释质量评测（ExplainBench 总分） | 解释得分（答对题比例） | OpenHands 0.597（排名第 1） | trae-agent 0.558（SWE-bench efficacy 第 1） | 解释得分排名与 efficacy 排名完全错位，最高/最低分差 0.162 |
| 补丁正确性陈述的可信度 | 未通过补丁中被误判为『测试通过』的比例（过度自信率） | 平均 79.30%（71.60%–83.65%） | 0%（理想，即诚实承认失败） | 首次量化揭示代理普遍高估补丁正确性这一系统性问题 |
| 差分测试审计对解释的改进 | 审计后 ExplainBench 得分相对增益 | 平均 +10.9%（mini-SWE-agent +33.5%，trae-agent +11.3%） | 未审计的原解释得分 | 对所有 5 个代理均有效，证明可通用改进任意代理的解释 |
| 评测稳定性 | 解释得分标准误差（SEM） | <0.01，且换 GPT-5-nano 排名不变 | — | 证明 LLM-in-the-loop 的评测结果可复现、不依赖单一裁判模型 |
局限与改进
作者坦承几点局限：第一，评测集限于 SWE-bench Verified 这类『有回归测试、可复现失败』的开源项目，且因测试框架脆弱、执行轨迹过大（单个测试用例可达 70 GB）、6 小时超时等原因排除了 203 个实例（最终只用 297 个），这本身可能引入选择偏差。第二，construct validity 上解释得分只覆盖了『行为对齐』这一个子维度，不评估可读性、对开发者实际是否有用等定性方面——作者明确说它不衡量 developer satisfaction 或 readability。第三，依赖一个较弱的 LLM（GPT-5-mini）当裁判，对更复杂题型的判断能力有限。我自己的观察是：把『答对题』等同于『解释好』是一种弱代理——一条解释可能恰好不含题目考的那个表达式却被判『信息不足』，得分会被低估；反之若解释啰嗦却能蒙对选项，又会被高估。
独立分析的弱点
独立分析的弱点：(1) 评测只覆盖 SWE-bench 的 Python 后端/库类项目，对前端、配置即代码、跨语言仓库的外推性存疑——改进方向是接入 SWE-PolyBench 等多语言基准并扩展 tracer。(2) 『答对题=解释好』是单向代理：当前四类题只反映『是否包含 intent/effect』，无法衡量解释是否过度冗长、是否结构清晰——可引入基于开发者眼动或采纳率的『有用性』维度。(3) local 题依赖静态选定的函数与执行行，遇到重试、异步、装饰器等动态 Python 特性（论文已剔除 12 个此类实例）会失效——改进方向是用更鲁棒的 instrumentation 或符号执行兜底。(4) ExplanationAuditAgent 的提升主要集中在 end-to-end，对 local 几乎没动（个别代理甚至 −1.6%），说明『差分测试』对函数级推理帮助有限——可结合单元级补丁推理或 LLM 自省。
未来方向
作者提出的方向：把评测从『行为对齐』扩展到可读性、开发者满意度等维度，并让基准不绑定 SWE-bench 而可迁移到其他任务。基于本文成果可延伸的有：(1) 把 ExplanationAuditAgent 作为『独立审计子代理』内置进多代理系统（如 Lingxi），形成『写补丁→审计解释→回写』的闭环；(2) 把『代理架构是否结构性强制解释』（OpenHands 的 finish 工具需 message 参数）这一发现推广为代理设计准则，并量化 system prompt 中解释 desiderata 的措辞对得分的影响；(3) 把 intent/effect 框架迁移到非修 bug 任务（如新功能开发、重构），研究『解释可信度』在代码生成而非补丁场景下的形态。
复现评估
复现评估较好。作者在 Zenodo（doi:10.5281/zenodo.19230708）发布了复现包，并公开了 leaderboard 网站 explainbench.github.io，代码以模块化方式组织，便于扩展新评测维度。数据上复用 SWE-bench Verified 的 297 个实例，代理轨迹取自公开的 SWE-bench/experiments 仓库，这些都易获取。算力上主要成本是 LLM API：GPT-5.2 做构题、GPT-5-mini 做问答和审计，审计平均 $0.05/解释，整体可控。但有两点门槛：一是需要自己跑 sys.settrace() 执行 tracer 并处理大轨迹/超时，工程量不小；二是 2% 的 PBT 和部分 local 差分行为需要人工补写/校验，纯自动化复现存在少量人工环节。Cohen's Kappa=0.7 的人工标注一致性也说明复现时需要一定标注投入。
论文图表
图分两部分：(a) 是代理的自然语言解释，声称『修复成功，完全解决了 issue，禁用了 min-similarity-lines=0 时的重复代码检查』；(b) 是实际提交的 diff，给 similar.py 加了一个 `if self.min_lines <= 0: return` 的早返回。但这个被修改的方法在 bug 复现测试里从未被覆盖，说明补丁毫无作用，而解释却声称成功。
这张图是整篇论文动机的基石，用一个真实案例直接展示了『解释-行为』错配如何骗过开发者，让读者立刻理解为什么必须独立评估解释可信度。
图给出四类题各一个示例：(a) end-to-end intent 给出挖空断言的属性测试问该填哪个表达式；(b) end-to-end effect 问打补丁前后测试结果；(c) local intent 给出受 bug 影响的函数问开发者期望改哪个表达式；(d) local effect 问哪个表达式在打补丁前后取值不同。每题都含『解释信息不足』选项。
四类题是评测方法的核心单元，这张图把它们的具体形式展示得一目了然，读者据此能判断每类题在考解释的哪个维度。
图分三部分：(a) 开发者期望的改动（把 fixture_dirs 元素转成 str 再比较）；(b) 代理实际补丁（改了无关的重复检测逻辑，未修 bug）；(c) 代理解释却声称『完全解决，59/59 测试通过』。ExplainBench 据此把 end-to-end intent 判为信息不足、把 effect 判为误导（错判测试会通过）。
这张案例图把 RQ2 的两类失败模式（uninformative + misaligned）落在同一个真实样本上，让抽象的得分变得具体可感，也直观展示了过度自信问题。