aider 在 SWE Bench 主榜取得 18.9%：交互式代码编辑与自动化评测方法的完整剖析

本文基于 aider 官方仓库中的评测博文（aider/website/_posts/2024-06-02-main-swe-bench.md），完整还原 aider 在 SWE Bench 主榜上以 18.9%（pass@1、无提示）取得当时 SOTA 的具体方法：双模型两轮回避式评测流程、"plausibly correct" 判定标准、验收测试的隔离机制，以及评测流程中实际使用的 --yes、--test-cmd 等命令行参数在仓库源码中的落地实现。读完本文，你可以理解一次"像开发者一样使用 aider 解决 GitHub issue"的自动化评测是如何构建的，并能在自己仓库中复现相应的命令行配置。

核心成绩：18.9% 的主榜 SOTA

aider 在 SWE Bench 主榜上取得 18.9% 的成绩，构成一项 SOTA 结果。当时榜单上最高的公开条目是 Amazon Q Developer Agent 的 13.8%，另一份被广泛引用的公开结果是 Devin 报告的 13.9%（后两者均出自其各自的技术报告与官方榜单，本文仓库仅作为评测文章记录这些数据）。

需要强调的评测口径：

• 所有成绩均为 pass@1：agent 内部可以多次尝试，但最终只挑选、返回唯一一个候选解，只有这个候选解参与验收测试并计入分数；
• 未使用 SWE Bench 提供的 hints_text；
• 评测样本与 Devin 评测相同：随机抽取的 570 个 SWE Bench 问题，便于与已有公开结果直接对比。

这一结果建立在 aider 此前在更易的 SWE Bench Lite 上取得 SOTA 的基础上（见仓库内的另一篇博文 SWE Bench Lite 结果）。

设计哲学：交互式工具，而非 Agentic Agent

博文中最值得注意的论点是：aider 达到这一成绩，主要依赖其既有的三个方向的能力，而不是某种大规模 agentic 编排：

1. 静态代码分析：通过 repo map 等机制为模型提供代码库结构上下文；
2. 可靠的 LLM 代码编辑：结构化的编辑格式与落盘校验；
3. 务实的 UX：自动修复 lint 与测试错误：编辑后自动跑 lint、跑测试，把失败信息喂回模型迭代修复。

aider 刻意保持"agentic 行为"窄而有限，以规避三个代价：长延迟、高 token 成本、用户需要反复 review 错误方案。博文中还明确说明，评测时 aider 不使用 RAG、向量检索、外部工具，也不给 LLM 联网搜索或单方面执行代码的权限。

定位上，aider 首先是一个"工程师在真实代码库中用聊天界面完成真实工作的交互式工具"：用户提出变更，实时看到代码编辑；模型可以顺带修 lint/测试错误，但用户始终保有完整的交互控制权，可以随时把误解拉回正轨，避免时间与 token 的浪费。

从源码结构看，这一"交互可控"的定位贯穿实现：aider/coders/base_coder.py 中的编辑落盘、lint 修复、测试回喂循环是核心路径，而不是一个自主规划执行器。

评测方法：两轮尝试与"plausibly correct"判定

评测流程如下（与 Lite 评测相同思路，为控制主榜成本将总尝试次数限制为两次）：

1. 第一轮：在每个问题的 git 仓库中启动 aider + GPT-4o，把问题描述作为"用户"的第一条聊天消息提交。此后 aider 按正常运行，但所有建议一律自动接受，无需用户确认。
2. plausibly correct 判定：使用一个简单 harness 检查 aider 产出的代码是否"貌似正确"——即 aider 报告自己成功编辑了仓库，没有引入语法错误，也没有破坏任何既有测试。若不满足，则重试。
3. 第二轮：若第一轮无貌似正确的解，harness 从零启动 aider + Claude 3 Opus 再试一次。
4. 兜底：两轮都没有貌似正确的解时，harness 选择"最貌似正确"的那个——即编辑/lint/测试问题最少的解。

一个关键的公平性约束：

aider 与评测 harness 在整个过程中只能看到每个问题仓库中"既有"的测试。 被扣出的"验收测试"（held-out acceptance tests）只在评测结束后，用于统计哪些问题被正确解决，全程对 aider 不可见、不可运行。

这一点直接决定了该成绩的可信度：它不是"看过答案"的成绩。

命令行视角：评测等价于 aider --yes --test-cmd pytest

博文指出，整个评测过程"与开发者用 aider 解决一个 GitHub issue 的方式相同"，具体对应三条操作：

• 在仓库里启动 aider --yes --test-cmd pytest——告诉 aider 自动接受每个建议，并用 pytest 跑测试；
• 在聊天中粘贴 GitHub issue 的 URL 或文本，aider 会拉取 URL 内容并尝试解决 issue；
• 若产出未通过 lint/测试，开发者可以 用 git 回退改动，换 aider --opus 再试。

这些参数在当前仓库中都有明确实现：

• --test-cmd：定义于 aider/args.py，help 为 "Specify command to run tests"，默认空列表。它会被传入 coder（见 aider/main.py 中 test_cmd=args.test_cmd），并写入系统提示的平台信息段落——在 aider/coders/base_coder.py 中，若开启了 --auto-test，提示会说明"用户的 pre-commit 会运行该测试命令"，否则说明"用户偏好该测试命令"，从而让模型知晓可用的验证手段。
• 自动接受确认：博文写作时使用的 --yes，在当前仓库中已更名为 --yes-always（定义于 aider/args.py，help 为 "Always say yes to every confirmation"）。根据 aider/website/HISTORY.md 的记录，命令行上仍可缩写为 --yes，因此 aider --yes --test-cmd pytest 这一写法至今有效。
• 测试执行的落点：/test 命令最终调用 aider/commands.py 的 cmd_test，当未显式传参时回退到 self.coder.test_cmd；实际执行走 cmd_run，仅在命令非零退出时才把输出追加进聊天（见 aider/commands.py 的 add_on_nonzero_exit 分支），失败输出会以用户/助手消息对的形式喂回模型，驱动下一轮修复。
• 相关开关：--auto-lint 默认开启（aider/args.py），--auto-test 默认关闭（aider/args.py）。评测 harness 在自动接受的前提下，把 lint/测试结果作为"是否 plausibly correct"的信号。

此外仓库还提供了非交互入口：--test 标志表示"运行测试、修复发现的问题后退出"（aider/args.py），配合 aider/main.py 中在 --test 且无 --test-cmd 时报错 "No --test-cmd provided."（aider/main.py）的逻辑，构成脚本化调用场景。

结果明细：GPT-4o 与 Opus 的分工

先给出一个重要事实：aider + GPT-4o 单独做一次尝试就取得了 17.0%，本身已是 SOTA；主结果是在此基础上叠加 Opus 补救轮得到的 18.9%。

下表完整继承自原文档，拆解 570 个问题中各轮"提出的解"（proposed solutions）与最终被验证正确的 108 个解的来源。"提出的解"要么是一个 plausibly correct 的解（编辑、lint、测试均无遗留错误），要么是两轮中"最貌似正确"的解（编辑/lint/测试错误最少）：

轮次	模型	提出的解	占提出解比例	正确解决的解	占正确解比例	对主榜分数的贡献
1	aider + GPT-4o	419	73.5%	87	80.6%	15.3%
2	aider + Opus	151	26.5%	21	19.4%	3.7%
合计		570	100%	108	100%	18.9%

可以看到 GPT-4o 贡献了绝大多数正确解（87/108），Opus 轮作为低成本补救贡献了 21 个。注意"对主榜分数的贡献"一列（15.3% + 3.7%）与"GPT-4o 单独评测的 17.0%"之间的差异，这正是下一节要解释的。

"貌似不正确但实际正确"的解，与分数非单调性

plausible 的判定只是 aider 自己报告"编辑完成、lint 修复、测试通过"，但一个解不 plausible 并不意味着它不能通过验收测试。博文列出了几种典型原因：

• 既有失败的测试：仓库在 aider 介入前就有失败的测试。aider 可能没修它们，但验收测试只关心"测试的通过/失败模式是否与人类金补丁（gold patch）一致"——只要某个测试在金补丁下同样失败，它的失败就是允许的；
• 既有的 lint 问题：如果遗留的 lint 问题落在测试覆盖不到的代码路径上，就不会影响验收结果；
• 编辑报错：当 LLM 未按系统提示中的编辑格式给出编辑、aider 无法落盘时会报告编辑错误。此时模型可能已经"跑偏"，要求了冗余或无关的编辑，但这类未落盘的编辑未必是致命的。

由此引出一个反直觉的统计现象：GPT-4o 在双模型合表里只占 15.3%，但单独跑一轮 GPT-4o 却能得 17.0%。原因是：允许 Opus 在 GPT-4o 之后补救时，Opus 可能产生一些"不正确但更 plausible"的解，它们在"挑最貌似正确者"的规则下挤掉（eclipse）了 GPT-4o 那些"不 plausible 但实际正确"的解。

结论由此推出：

增加尝试次数不保证单调提升解决数量。 新解可能解决新问题，也可能挤掉丢弃先前"不 plausible 但正确"的解。幸运的是，净效果通常是提升或至少持平——在这两次（主榜与 Lite）评测的所有尝试中都是如此。

分数的最终计算方式

评测 harness 对 570 个问题各产出一个"提出的解"后，由独立的评估脚本完成最终计分：

1. 对每个解运行完整测试套件，包括扣出的验收测试；
2. 丢弃 aider 对测试文件的任何修改，确保验收测试使用的是正确的、未被改动的测试套件（防止"改测试凑结果"）;
3. 将该解的测试结果与人类金补丁的测试结果逐一对比：通过/失败模式一致，即判定该问题被正确解决；
4. 验收测试只在 aider 与 harness 之外运行，只用于事后统计；在 aider 尝试解决问题的全程中，它们从未被运行、使用或暴露。

最终结果：aider 正确解决了 570 个实例中的 108 个，即 18.9%。

博文致谢部分还提到，Albert Örwall 将 SWE Bench 评测脚本容器化（Docker 化），使验收测试跑得更快、更容易、更可靠——这是该结果能在有限成本内完成的工程基础。

pass@1 口径与参考基线

最后明确计分口径，避免与 pass@N 混淆：

• 文中所有成绩为 pass@1 且无 hints_text；
• agent 内部可以多次尝试，但最终只挑选一个候选解参与验收测试并计入分数；
• 对比之下，pass@N（N>1）是 N 次尝试、N 个解全部评测，任一通过即算成功。

原文档给出的同口径（pass@1、无 hints）公开参考结果：

系统	成绩	评测规模
Devin（认知 AI 技术报告）	13.9%	570 个实例
Amazon Q Developer Agent（官方榜单）	13.8%	2,294 个实例
SWE-Agent + GPT-4（官方榜单）	12.5%	2,294 个实例
AutoCodeRover	10.6%	2,294 个实例
SWE-Agent + Opus（官方榜单）	10.5%	2,294 个实例

其中 AutoCodeRover 的 10.6% 取其论文 Table 2 中 ACR-avg 的平均 pass@1 值（其 GitHub 页面展示的是未明确标注的 pass@3 结果），以保证同口径可比。

可继续深入的仓库入口

• 评测方法原始文章：aider/website/_posts/2024-06-02-main-swe-bench.md，Lite 版本方法：aider/website/_posts/2024-05-22-swe-bench-lite.md
• 命令行参数定义：aider/args.py（--test-cmd、--auto-test、--auto-lint、--yes-always、--test）
• 测试命令执行与失败回喂：aider/commands.py
• 系统提示中 lint/test 命令注入：aider/coders/base_coder.py
• 参数到 coder 的装配：aider/main.py
• git 回退操作文档：aider/website/docs/git.md

需要说明的适用前提：本文成绩与流程对应 2024 年 6 月的评测设定（GPT-4o + Claude 3 Opus、570 个抽样实例、两轮尝试）。仓库后续版本中部分参数已更名（如 --yes → --yes-always，命令行仍可缩写为 --yes），若要在当前版本复现类似流程，建议以 aider/website/docs/config/options.md 中的参数说明为准。