把 GitHub Issue 改成聊天口吻，成功率掉一截

本文是论文 Saving SWE-Bench: A Benchmark Mutation Approach for Realistic Agent Evaluation（arXiv:2510.08996）正文第 1 节至第 7 节的中文译文，由智测团队翻译。参考文献未逐条展开。正文保留了遥测规模、11 种沟通模板，以及三个基准在突变前后的成功率、步数和词元用量。

1 引言

人工智能软件工程智能体改变了开发者的工作方式。交互式、基于聊天的智能体，例如 Claude Code 和 VS Code Agent，与传统的全自主智能体不同。GitHub Copilot Agent 这类全自主系统可以独立处理完整的问题规格。交互式智能体则在与开发者的反复、带上下文的对话里，慢慢把问题解出来。评测它们，需要能抓住人与聊天交互细微差别的方法。

当前评测软件工程智能体的基准，尤其是 SWE-Bench Verified，在评估交互式聊天智能体时有根本限制。第一，这些基准由 GitHub Issue 构成。Issue 往往有详细、想得很清楚的问题描述，和集成开发环境聊天里那种简短、非正式的提问差很远。第二，基准公开且被大量研究，导致模型过拟合（Liang 等，2025）：系统在公开基准上表现很好，到非公开基准上并不能以同样方式泛化。

为处理这些限制，作者提出基准突变方法：根据对开发者行为的经验分析，把已有的正式问题描述变成更接近真实的用户提问。做法是利用一个基于集成开发环境的智能体的内部遥测，找出开发者向聊天助手描述缺陷时的常见模式，再用这些模式系统改造基准问题，同时保住本质的技术内容。

贡献有四条。第一，分析开发者的沟通模式，找出刻画真实聊天交互的若干模板，用来建造突变流水线。第二，提出把正式基准问题变成真实初始用户提问的系统方法。作为检验，做出 SWE-Bench Verified-Mutated、Multi-SWE-Bench（TypeScript）-Mutated 和 SWE-Bench C#-Mutated。方法可扩展，几乎能用到任何修缺陷基准上。第三，第一次用开源编码智能体 OpenHands，在原始基准和突变基准上做全面评测，露出显著的性能缺口，说明真实评测场景的重要性。第四，把方法放进官方 SWE-Bench 仓库，并公开所用提示和为 SWE-Bench Verified 生成的突变。实现在 https://github.com/microsoft/SWE-Bench-Mutated-CAIN26 。

发现是：对公开数据集，传统基准把智能体能力高估 20% 到 50%；对 SWE-Bench C# 这类内部基准，缺口收到 10% 到 16%。这说明 SWE-Bench Verified 既有规格写得过满的问题，也有过拟合。既需要反映真实用法的评测，也需要把基准保持私有，以免公开基准上见到的过拟合。第 7 节把高估写成超过 50%。表 1 的相对降幅并不处处超过 50%。下文以表为准，并在结果处标明。

2 背景与相关工作

已有基准用正式的 GitHub Issue 评智能体，并不反映开发者在实践里如何和聊天式编码智能体沟通。这是本文要补的缺口。

2.1 软件工程基准

SWE-bench 把评测从孤立的函数或文件级任务，转到从 GitHub Issue 抽出的真实仓库级问题。任务更复杂：智能体要导航并理解仓库上下文，协调多个文件上的改动，产出能通过已有测试和隐藏测试的补丁。后继的 SWE-Bench Verified 处理质量和污染方面的担心，给出 500 个经人工核验的例子。问题仍在。SWE-Bench+ 揭示了解答泄漏和薄弱测试套件。

SWE-bench 被扩到新领域。SWE-Bench-Multimodal 引入带视觉元素的 JavaScript 任务。Multi-SWE-Bench 面向 7 种语言并提供专家标注。SWE-Poly-Bench 也超出 Python。SWE-Bench-Live 持续更新，覆盖大量仓库，用来对抗过拟合和数据污染。这些基准推进了用编码智能体修功能缺陷，但都依赖正式 GitHub Issue，抓不住开发者在集成开发环境里实际怎么和聊天智能体说话。突变方法把这些正式问题变成更真实的用户提问。

2.2 软件工程智能体

SWE-Agent 提出智能体–计算机接口的设计原则，在 SWE-Bench 上达到 12.5%。OpenHands 是开源平台，智能体像人一样写代码、用命令行、浏览网页。Xia 等人用定位、修复、验证三阶段，不靠复杂智能体架构，能解决 SWE-Bench-Lite 里 32% 的问题。

ReAct 把推理轨迹和任务专用动作交错。Reflexion 用言语反馈做强化，让智能体反思任务反馈。Toolformer 研究语言模型如何通过自我监督学会何时、如何用工具。Gorilla 微调较小的语言模型来用工具，并超过当时的前沿大模型。

现有框架在公开基准上能力强，但报告的表现未必能转到用户沟通方式很不同的真实设置。在原始基准和突变基准上同时评测，是第一次系统评估：面对真实用户提问而不是正式 GitHub Issue 时，智能体表现如何变化。

2.3 开发者行为与聊天助手

Ziegler 等人测量 GitHub Copilot 对生产率的影响。Imai 研究与 Copilot 结对编程相对于人与人结对的效果。Scholl 和 Kiesler 研究新手如何用 ChatGPT 做编程练习。McNutt 等人考察 Jupyter 笔记本里代码助手的潜力，以及交互环境的设计。Li 等人分析开发者使用 ChatGPT 的特点，发现他们倾向于短的、聚焦任务的聊天。本文在这些研究上，第一次专门全面分析开发者如何向这些系统描述缺陷，并把开发者行为研究直接接到基准设计上。

2.4 数据污染与基于突变的基准

公开基准普遍有数据污染。LiveCodeBench 和 SWE-Bench-Live 用持续更新来减轻静态基准的污染。DyVal 用有向无环图动态生成评测集。LLMEval-3 从专有的研究生级题库里为每次评测动态抽样。DyCodeEval 在污染风险下生成多样问题集。Zhu 等人的推理时去污染，检测并改写泄漏样本，而不改变题目难度。

本文的突变与这些防污染方法互补，但针对的是另一个问题：开发者在 GitHub Issue 里的沟通，和在聊天智能体里的沟通之间的缺口。先前工作主要靠持续更新或动态生成来防止过拟合。本文把已有基准改到更接近真实用法。结果里公开基准和私有基准的性能差，说明这也有助于对抗过拟合，并更能评估智能体在真实条件下的表现。

3 方法

3.1 遥测分析与模式提取

为理解开发者实际如何和基于聊天的软件工程智能体沟通，作者分析了一个广泛使用的聊天智能体工具的内部使用遥测。这构成突变方法的基础：找出用聊天智能体修缺陷时，真实用户交互的不同模式。文中没有公开这个工具的产品名。

3.1.1 数据收集与标注

从大约 6,000 名不同用户在一周内发给聊天智能体的请求里，随机抽 10,000 条用户提问。目标是修缺陷，所以先把提问按用户意图分类。

分类分两阶段，用大模型，并有人工核验。第一阶段，给模型大约 500 条提问，让它产出 5 到 10 个高层类别，例如修缺陷、软件测试、代码搜索。得到的十类是：缺陷修复与错误解决；代码重构与质量改进；软件测试；文档与技术写作；功能开发与增强；构建、部署与持续集成；代码导航、搜索与分析；DevOps 与基础设施；项目搭建与配置；用户界面与体验设计。图 4 的示例标签写法略有出入，例如把接口集成与数据处理、配置与依赖管理单独列出。第二阶段，把每条提问分到最合适的一类。

图 3 是分布。最大的几类是代码搜索与分析、功能实现，以及修缺陷。修缺陷与错误解决约占全部提问的 14%。

图 4 给每类一个例子。修缺陷的例子是一段很长的命令和 C++ 运行时错误，用户只问错误发生在哪里。重构的例子是不要用 HashMap，改用带 Average 和 Max 的结构体，避免每个 pod 上的动态内存分配。测试的例子是请对照 client.go 的改动，检查 client_test.go 并增改测试。

图 5 比较不同基准的问题陈述词数和真实用户提问。遥测提问简短得多。用户提问大约 10 到 30 个词，SWE-Bench 这类基准的问题通常超过 100 个词。

3.1.2 理解修缺陷的用户提问

图 6 比较基准和真实聊天提问里，有用缺陷报告元素出现的频率。用大模型判断文本是否包含：文件路径、复现代码、错误堆栈、测试用例、环境信息、期望行为相对实际行为。聊天用户更多用错误堆栈和文件路径。GitHub Issue 则还包含复现代码、期望行为、环境细节等。这些在用户提问里大体缺失。聊天用户偏好更有针对性的信息，而不是像 Issue 那样一上来就给穷尽细节。

再用大模型从修缺陷提问里抽模板，得到 11 种：

1. 只贴错误或堆栈。用户贴上错误信息、调用栈、崩溃报告或测试失败日志，几乎不另加解释。
2. 直接说「修这个」。用「fix this」「fix the error」这类很短的话，没有详细解释。
3. 贴上错误并要求解释。贴堆栈，并请帮助理解、诊断或分析根因。
4. 最小修改请求。简短给出错误、命令或警告，直接要更正、期望语法或最小代码改动。
5. 指定行或函数。请修某一个函数、行号、文件，或一块很窄的代码。
6. 期望行为相对实际行为。说清应该发生什么、实际发生了什么，问为什么不一致或怎么消除差别。
7. 贴上代码再提问。贴一段代码，再加澄清问题，或问哪里错了、怎么修。
8. 不贴代码，只要调试。只用文字或很少的日志描述缺陷，请诊断或给建议。
9. 贴测试或持续集成失败。贴测试输出，常常来自持续集成，问为什么失败或怎么修。
10. 要求分析或分诊。请对缺陷或事故做分诊、诊断或深挖，有时只给编号或工单，常常不贴技术细节。
11. 引用文档或外部 Issue。指向外部问题跟踪、文档或规格，请分析或修复。

每种模板代表一种不同的问题沟通方式，技术细节、上下文和期望的智能体回应程度都不同。

3.2 突变方法

图 9 是流水线。在模板分析之上，把正式基准问题变成符合真实用法的提问。

3.2.1 突变算法

用大模型做突变。输入有三样：已有基准里的问题描述、修好该问题的代码补丁，以及第 3.1.2 节从遥测抽出的沟通模板。模型要对适用的模板尽量多地改写，每种适用模板产出一条变体。提示强调用户往往写得短、不完整，还常有错别字。跳过明显不适用的模板。把补丁信息放进提示，是为了能真实地提到用户常写进提问里的具体文件、函数和行号。

每个基准问题会生成多条可能的用户提问，代表不同沟通方式。每个问题随机选一条变体，组成最终的突变基准，既有多样性，评测又保持一致。

3.2.2 SWE-Bench 上的一个例子

图 10 是 SWE-Bench Verified 里 astropy__astropy-7336 的突变。原 Issue 像一份表单：摘要、复现文件、调用栈、在 Fedora 27 上用 Python 3.6.3 和 astropy 2.0.2 测过、变通办法，以及可能的修复。缺陷是 units.quantity_input 装饰器用在构造器上，返回类型标成 None 时，None 没有 to 属性，抛出 AttributeError。突变结果只保留调用栈，对应模板「只贴错误或堆栈」。突变后的实例叫 astropy__astropy-7336-mutated。

3.2.3 把突变提问和遥测放在一起看

图 12 用 OpenAI 的 text-embedding-3-large 嵌入，再用主成分分析降到三维。蓝色是遥测提问，红色是 SWE-Bench C#，绿色是 SWE-Bench C#-Mutated。原始基准和遥测几乎是两团分开的云。突变后的云与遥测重叠得多。这说明突变把基准提问的分布推向了更真实的用户提问。

4 实验设置

4.1 基准

突变三个修缺陷基准。

SWE-Bench Verified：500 个经人工核验的修缺陷问题，来自流行 Python 仓库。每题有基于 GitHub Issue 的问题陈述、仓库上下文和地面真值补丁。突变后称为 SWE-Bench Verified-Mutated。

SWE-Bench C#：组织内部的基准，150 个来自 GitHub 上 C# 仓库的修缺陷问题，难度不同，含 Issue、仓库上下文和开发者补丁。突变后称为 SWE-Bench C#-Mutated。

Multi-SWE-Bench 的 TypeScript 子集：因全量太大，只用 224 个例子。突变后称为 Multi-SWE-Bench（TypeScript）-Mutated。

对每个基准套用突变提示，为每条问题陈述生成多个突变，再随机挑一个。

4.2 智能体与模型

评测用开源智能体 OpenHands，修缺陷任务用它的默认提示。C# 基准只把措辞里的 Python 改成 C#。三个常用模型：GPT-4.1、Claude Sonnet 3.7、Claude Sonnet 4。

每次运行最多 100 步，然后用与未突变基线相同的测试框架判定成功。所有例子在隔离的 Docker 容器里跑。

4.3 指标

成功率：智能体产出的修复能通过该基准隐藏测试的任务百分比。平均词元：每任务的输入和输出词元。平均步数：智能体可以在 100 步用完前结束，报告完成一题的平均步数。更高的成功率往往伴随更长的运行和更高的计算或金钱成本。用户要在质量和成本之间平衡，所以两类指标都看。

表 1 是 OpenHands 在三个基准的基线变体和突变变体上的成功率、步数和词元。Change 是相对变化，不是绝对百分点。

SWE-Bench Verified：

SWE-Bench C#：

Multi-SWE-Bench（TypeScript）：

5 结果

5.1 对成功率的影响

SWE-Bench Verified。把正式 GitHub Issue 变成真实用户提问后，所有智能体–模型组合都明显变差。相对成功率下降 20% 到 40%。表上是 23.2% 到 36.5%，与这一段一致。引言写的 20% 到 50% 比这一段宽。结论写成超过 50%，只和 TypeScript 上 Sonnet 4 的 −53.8% 对得上，不能概括全部。现有基准显著高估修缺陷能力。各模型都掉，说明缺口不只是某个模型的局限，而是问题呈现方式，以及智能体对真实场景的适应。GPT-4.1 掉得更多，可能因为它更需要 GitHub Issue 里那种上下文，或者已经过拟合。

SWE-Bench C#。内部 C# 基准上，突变的影响小得多。绝对百分点下降大约 2 到 5 个，SWE-Bench Verified 上是大约 13 到 16 个。可能的原因：模型或智能体过拟合了 SWE-Bench Verified 这类流行基准；或者 C# 上的起点本来就不高。Python 仓库比 C# 多，训练数据更多。智能体也可能过拟合 Python，因为它们是对着 SWE-Bench 这类 Python 基准建的。

TypeScript。三个模型在描述被突变后都下降，相对降幅都超过 C#。Sonnet 4 掉得最大，而且在未突变的基线上也比另外两个模型差。

5.2 对步数和词元的影响

SWE-Bench Verified。步数上升。这符合预期：Issue 里的许多细节被拿掉后，智能体要斟酌更久，或先搜索相关代码。词元用量却下降。按步数上升，本应期望词元也上升。作者认为这是因为可处理的细节变少，轨迹里每一步没那么啰嗦。三个基准上，Claude Sonnet 4 都比另外两个模型更啰嗦、步数更多，倾向于把问题纠缠得更久。

SWE-Bench C#。步数上升没有 Verified 那么剧烈，这可能又是过拟合的痕迹。Sonnet 4 的步数增加最多，其次是 Sonnet 3.7。GPT-4.1 的步数略降。这个模型上智能体表现也更低，步数下降未必是好事。与 Verified 不同，Claude 模型的词元上升，GPT 大致持平。问题规格不足，模型要推理更多，步数和词元都上去。Sonnet 4 在 C# 上每条实例的词元几乎是 Python 基准的两倍，另外两个模型没有类似上升。这可能是语言上的不均衡，或只是过拟合某个基准。

TypeScript。突变后三个模型的步数都上升。和成功率一样，Sonnet 4 的步数和词元上升最剧烈。无论突变与否，Sonnet 4 用尽最大步数的实例大约是 Sonnet 3.7 的 3 倍，说明 Sonnet 4 修 TypeScript 缺陷总体上更吃力。和 C# 类似，Sonnet 4 在 TypeScript 上比在 SWE-Bench Verified 上消耗多得多的词元和步数。GPT-4.1 相对其他基准也用更多步数和词元。

6 局限

语言与任务覆盖。主要是 Python、C# 和 TypeScript。所考察的基准只覆盖修缺陷。遥测里修缺陷不到全部提问的 15%。方法对功能实现、重构、软件测试等其他任务是否有效，还没探索。

智能体覆盖。只评了一个开源智能体 OpenHands。它是研究用的前沿智能体之一，但其他智能体在突变基准上可能有不同模式。评测框架是单轮交互，没有计入真实聊天里用户用后续对话补充澄清和上下文。

模板提取与对大模型分析的依赖。模板对这份数据和用法可能够用，但开发者对界面不同的其他编码智能体，沟通方式可能不同，作者没有那些遥测。领域专用的沟通模式可能不在样本里。尽管有人工核验，基于大模型的分类、抽模板和应用仍可能因模型和提示设计带入系统偏差。

突变后的问题有效性。突变想模仿真实用户行为，但可能无意丢掉问题陈述里必要的技术信息，并改变难度。方法假设突变后问题仍然有效。对改过的问题，除了原来的开发者修复，可能还有多种合法解，从而不公平地惩罚那些对规格不足的问题给出合理解决的智能体。

评测方法和测试框架没变。问题陈述改成了真实提问，评测框架仍然刚性。理想情况是有一套更能抓住人–智能体交互、更接近用户对回答是否满意的指标。

尽管有这些局限，这项工作为聊天式编码智能体的修缺陷能力建立了一种更真实的评测，并给出可接到已有和新基准上的可扩展框架。

7 结论

现有修缺陷基准，例如 SWE-Bench Verified 和 Multi-SWE-Bench，系统性地高估智能体能力。原因是严重依赖正式的 GitHub Issue 描述，再加上语言不均衡和过拟合。结论把高估写成相对基线超过 50%。表 1 里，SWE-Bench Verified 的相对下降是 23.2% 到 36.5%，C# 是 10.7% 到 16.8%，只有 TypeScript 上的 Sonnet 4 达到 53.8%。通过真实开发者与聊天智能体的交互，抽出用户如何向聊天描述缺陷的模板，本文把 GitHub Issue 式的问题变成更真实的聊天式提问。经验结果说明，这会露出智能体和评测方法上的显著缺口，也说明真实评测场景的重要性，以及基准过拟合的风险。作者主张采用基于突变的智能体评测，并用私有基准，以更好反映开发者的实际用法，同时避开过拟合。未来工作应把方法扩到其他软件工程任务和领域，并进一步抓住多轮人–智能体协作的细微差别。