Aider 的 SWE Bench Lite 评测全解析26.3% pass1 背后的仓库地图与可靠代码编辑基于 Qwen3-Coder 仓库源码拆解【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder本篇文章以 2024-05-22-swe-bench-lite.md 为核心骨架结合仓库内完整保留的 Aider 源码qwencoder-eval/instruct/aider/aider/与基准测试工具qwencoder-eval/instruct/aider/benchmark/系统拆解 Aider 在 SWE Bench Lite 上取得 26.3% pass1unhinted成绩的评测方法论、核心技术路径与工程实现帮助读者理解如何用交互式结对编程工具而非重 agentic 框架在真实代码库上解决 GitHub Issue并掌握仓库地图、静态检查、测试驱动修复等可直接复用的实战能力。一、评测背景与核心结果2024 年 5 月 22 日发布的结果显示Aider 在 SWE Bench Lite 基准上取得了26.3%的成绩成为当时该榜单的新 SOTA。此前榜单最高记录为 Amazon Q Developer Agent 的20.3%。需要特别强调的评测口径这也是该成绩可复现、可比较的前提所有结果均为 pass1 结果即每个问题只提交一个候选补丁model_patch参与验收测试内部多次尝试只用于挑选这一个候选全程未使用 SWE Bench 的hints_text官方榜单只接受不带 hint 的 pass1 结果对比图表在 5/30 做过修正改为对等的 pass1、unhinted 数据。在这一口径下文章还报告了两个重要子结果仅用 Aider GPT-4o 单跑即可达到25.0%本身已与当时 SOTA 持平Aider GPT-4o 与 Opus 交替后达到26.3%。这些数字是文档发布当时的记录且全部建立在基准测试 harness 与 Aider 只能访问每个问题仓库中已有的测试这一前提下held-out 的验收测试仅在评分阶段使用。二、交互式而非 AgenticAider 的设计哲学Aider 取得该成绩并非依靠更强的 agent 行为恰恰相反它刻意保持了相当有限且克制的 agentic 行为以避免长延迟、高 token 成本以及用户反复审查错误方案的开销。从源码结构可以印证这一设计取向aider 主目录 中的核心模块是args.py参数解析、coders/对话编码器、repomap.py仓库地图、linter.py静态检查、repo.pygit 集成等——它首先是一个供工程师在真实代码库中通过聊天界面完成实际工作的交互式工具而不是一个自主决策的 agent 框架。该评测发布时 Aider 并未使用 RAG、向量检索、工具调用也不允许 LLM 联网搜索或单方面执行代码。它的工作方式是用户在聊天界面提出修改请求用户实时看到代码编辑被执行Aider 提供额外辅助修复 lint / 测试错误用户始终处于完整的交互控制中可以随时把误解拉回正轨避免浪费时间和 token。这也是 Aider 在基准测试外被设计为交互使用的原因——任何 AI agent 在无人监督下运行于真实代码库都是不明智或至少是低效的。三、基准测试方法harness 如何驱动 Aider3.1 运行方式在评测中Aider 在每个问题的 git 仓库内被启动问题陈述作为开场聊天消息提交。之后 Aider 正常运行仅做了以下修改Aider 的建议始终被接受无需用户批准一个简单的 harness 用于在 Aider 产出非合理正确plausibly correct代码时重试该问题若未找到合理方案harness 会从头重启 Aider 再次尝试在 GPT-4o 与 Opus 之间交替六次尝试后仍无合理方案则选择编辑/lint/测试问题最少的方案。合理正确plausibly correct的定义是Aider 报告它已成功编辑仓库且没有引入语法错误、没有破坏任何预先存在的测试。3.2 与真实开发流程的对应关系评测过程与开发者用 Aider 解决 GitHub Issue 的方式高度一致用如下命令启动 Aider表示接受所有建议、并用 pytest 跑测试aider --yes --test-cmd pytest把 GitHub Issue 的 URL 或文本粘贴进聊天即可开始若 Aider 产出的代码不能通过 lint 与测试开发者可以回退更改后用另一个 LLM 重试——Aider 与 git 深度集成随时可以轻松回退不理想的 AI 改动。这一点在仓库参数解析中可以得到印证args.py 中定义了--yes、--test-cmd指定运行测试的命令、--auto-lint修改后自动 lint默认 True、--auto-test修改后自动测试默认 False、--test运行测试并修复发现的问题等参数与评测描述一一对应。四、结果数据两次模型的逐轮尝试分解4.1 按尝试轮次分解300 个问题harness 按固定顺序交替运行总是先用 GPT-4o再与 Opus 交替直到每个问题找到合理方案。下表完整列出 300 个问题中按尝试轮次找到的合理方案以及最终被验收测试确认正确解决了 Issue 的数量AttemptAgent合理方案数占合理方案比例正确解决数占正确解决比例SWE Bench Lite 得分1Aider with GPT-4o20869.3%6177.2%20.3%2Aider with Opus4916.3%1012.7%3.3%3Aider with GPT-4o206.7%33.8%1.0%4Aider with Opus93.0%22.5%0.7%5Aider with GPT-4o113.7%22.5%0.7%6Aider with Opus31.0%11.3%0.3%总计300100%79100%26.3%值得注意的观察点仅第一次尝试Aider GPT-4o就解决了 20.3% 的问题与当时官方榜单第一的 Amazon Q Developer Agent 持平包含第二次尝试后得分为 23.6%前两次尝试获得了约75% 的合理方案与约90% 的正确解决方案存在一条长尾两个模型持续在后续尝试中找到方案甚至有一个问题是在该问题的第六次最后一次尝试中才被正确解决。4.2 按模型拆分若仅按模型拆分方案可看到 Aider GPT-4o 优于 Opus——但这不是公平的直接对比因为 GPT-4o 总是先手抢先拿到了所有最容易的问题Opus 只见到 GPT-4o 首次尝试未找到合理方案的问题Agent合理方案数正确解决数合理方案中正确解决的比例Aider with GPT-4o2396627.6%Aider with Opus611321.3%总计3007926.3%五、核心能力一仓库地图Repository Map而非 RAG解决 SWE Bench 问题的关键第一步是判断仓库的哪些部分相关、需要编辑哪些文件。多数编码 agent 使用 RAG、向量检索或给 LLM 提供交互式探索代码库的工具。Aider 的替代方案是 仓库地图通过代码 AST抽象语法树与调用图的静态分析生成整个代码库紧凑而强大的摘要地图会随着对话状态持续定制只展示与当前聊天相关的仓库上下文其实现方式是对代码调用图做图优化。5.1 源码实现证据从 repomap.py 可以看到基于 tree-sitter 对每个文件抽取 tagsget_tags_raw见 repomap.py#L202区分def定义与ref引用get_ranked_tags见 repomap.py#L278使用networkx.MultiDiGraph构建符号定义-引用图并借助PageRank 个性化personalization让图排序向当前聊天文件中涉及的符号、用户提到的文件与标识符倾斜生成的 ranked tags 再被组织成层级树to_tree见 repomap.py#L595按预算 token 数量裁剪后作为地图上下文注入仓库地图结果缓存在.aider.tags.cache.v{N}TAGS_CACHE_DIR见 repomap.py#L32大仓库的首次扫描较慢但只发生一次。5.2 工作流LLM 提名文件用户确认入聊当用户请求修改代码时LLM 可以借助仓库地图决定编辑哪些文件并直接返回普通文本解释。Aider 注意到 LLM 提到仓库中的文件名时会询问用户是否加入聊天加入后 LLM 才能看到该文件全文并编辑它。原文给出了一个典型会话#### Please add a new /factorial/N endpoint. To add a new /factorial/N endpoint, the most likely file that needs to be edited is app.py. Please add app.py to the chat so I can proceed with the changes. app.py Add these files to the chat? yes这一自然流畅的交互流程在 SWE Bench 问题上表现良好Aider 在 70.3% 的基准任务中正确识别出了应编辑的文件。该统计是利用每个任务关联的 gold patch人类开发者写的参考补丁在评测过程之外计算的——Aider 在求解时完全看不到 gold patch 或其包含的文件名。六、核心能力二可靠的代码编辑Reliable Code Editing选定文件后下一步自然是从源码层面把问题修好。Aider 在保证 LLM 不仅能写代码、更能可靠地编辑代码上投入了大量工作拥有一系列提示策略与代码编辑后端edit 格式这些能力通过 benchmark 目录 中的代码编辑基准持续打磨该目录基于 Exercism 练习构造端到端评测见 benchmark/README.md仓库地图在此同样发挥作用确保 LLM 能看到整个仓库相关的类、函数与变量使新增代码尊重项目既有 API 与约定即使如此仍存在 LLM 未遵守编辑指令system prompt 中的编辑格式约束而无法干净完成编辑的情况。此时 Aider 完成时会返回一个编辑结果状态editing outcome指示是否成功应用了全部编辑——基准 harness 正是把它作为判断合理方案的标准之一。七、核心能力三Lint 与自动修复合理方案的另一关键标准是通过基础 lint无语法错误或其它致命错误。Aider 在每次 LLM 编辑后都会 lint 代码并提供自动修复。7.1 tree-sitter 内置 linter源码层面linter.py 实现了完整链路内置基于 tree-sitter 的 linterfrom tree_sitter_languages import get_parser支持大多数主流语言basic_lint见 linter.py#L195用 tree-sitter 查找语法错误并结合 AST 展示带上下文tree context的错误Python 场景还叠加compile检查与 flake8py_lint见 linter.py#L112lint 结果通过tree_context以新颖的格式回传给 LLM——用 AST 展示每个错误相关的代码上下文帮助 LLM 理解问题并做出正确修改。7.2 错误反馈会话示例app.py:23:36: F821 undefined name num app.py: ...⋮... 6│class LongNum: ...⋮... 19│ def expound(self, threshold): 20│ number self.basis 21│ while number threshold: 22│ number * self.factor 23█ return num 24│ 25│ ...⋮... Attempt to fix lint errors? yes在基准测试中这些 lint 修复建议总是被接受。完成后 Aider 报告 lint outcome指示是否产出了无未解决 lint 错误的代码harness 同样以该状态作为合理方案的判定标准之一。八、核心能力四测试与修复合理方案的最后一个标准是所有测试通过。Aider 可配置仓库的测试运行命令并自动尝试修复测试失败。Python 项目的典型启动方式aider --test-cmd pytest评测中Aider 被配置为运行每个问题仓库中已存在的测试。SWE Bench 问题来自拥有大量现有测试套件的开源项目因此Aider 若破坏了任何既有测试、或新建的测试未通过测试环节都会失败。与编辑、lint 一样Aider 会报告 testing outcome指示完成时是否还有未通过的测试harness 以此作为合理方案的判定标准。需要再次澄清Aider 无法运行、甚至无法看到被 hold out 的验收测试——那些测试只在评分阶段、在 Aider 与 harness 之外运行。九、寻找合理方案Plausible Solution的完整流程每次 Aider 执行都会报告编辑、lint、测试三个环节的结果每个环节可能成功或存在未解决问题。harness 据此判定若 Aider 返回已编辑仓库且无未解决的编辑/lint/测试错误则该方案为合理方案其改动被记录为 SWE Bench 的model_patch留待验收测试评估若非合理则从头重启 Aider再次求解同一问题GPT-4o 与 Opus 交替各三次共六次尝试一旦找到合理方案立即接受进入下一个实例若仓库本身在 Aider 编辑前就存在 lint/测试错误无论由谁引入六次尝试后仍可能找不到合理方案。六次全失败时harness 选择最佳可用方案作为model_patch——忽略测试结果按以下优先级排序优先选择编辑完成且 lint 成功的方案其次编辑至少部分成功且 lint 成功再次编辑成功最后编辑至少部分成功。十、计算基准得分79/300 26.3%harness 为全部 300 个 SWE Bench Lite 实例产出了合理方案并保存为model_patch。随后使用独立的评测脚本用**完整测试套件含 held-out 验收测试**逐个测试这些方案验收测试前Aider 对测试文件所做的任何编辑都会被丢弃确保使用正确、未修改的测试套件评测脚本将候选方案与人类开发的 gold patch的测试结果对比匹配即视为正确解决这些验收测试只在 Aider 与 harness 之外运行且仅用于计算正确解决数求解过程中从未运行、使用甚至可见。最终300 个实例中正确解决 79 个即 26.3%。十一、pass1 口径与结果可比性说明文中所有 Aider 结果都是 pass1、且未使用hints_text的结果。Aider agent内部虽然会做多次尝试但只挑选并返回一个候选方案且只有这一个候选被验收测试评估并计入得分——因此是严格的 pass1。与之相对的是 passNN1对同一问题做 N 次尝试并把 N 个方案全部交给验收测试任一通过即算成功。两者不可直接比较。文档发布时图中对比的其他 pass1、unhinted 结果数据以原文报告为准仅作当时横向参照Agentpass1 得分unhintedAmazon Q Developer Agent (v20240430-dev)20.3%AutoCodeRover19.0%SWE-Agent GPT-418.0%OpenDevin16.7%SWE-Agent Opus11.7%原文也说明了图表在 5/30 的两次修正AutoCodeRover 改用其平均 pass1 结果此前展示的是不可比较的 pass3OpenDevin 改用未使用 hints 的最佳结果此前展示的是带 hint 的结果。十二、仓库中的复现与可视化工具虽然运行 SWE Bench Lite 的专用 harness 是独立于本仓库的外部工程但本仓库保留了可辅助理解与复现评测生态的配套工具benchmark/README.mdAider 自身的代码编辑基准测试 harness使用说明——基于 Exercism 练习做端到端评估不仅测 LLM 编码能力还测其编辑既有代码与格式化编辑的能力建议在 docker 容器内运行以避免执行未经人工审查的 LLM 代码核心参数包括--model、--edit-format推荐从whole起步、--threads可并行跑多个练习、--num-tests、--keywords类似pytest -k过滤、--tries以及用--stats生成 yaml 格式统计报告含pass_rate_1、pass_rate_2、edit_format、commit_hash等字段benchmark/swe_bench.pySWE Bench 结果绘图脚本输入文本数据文件即可输出柱状图is_lite lite in fname自动区分 SWE Bench Lite 与完整 SWE BenchAider 的条柱以高亮色区分Lite 版为绿色并标注每个模型对应的实例数与 pass1 百分比仓库中另有 tally_output.txt 与 tally_results.txt可看到基准运行的汇总输出样例。十三、总结Aider 在 SWE Bench Lite 上的 26.3% pass1unhinted成绩是一套非 agentic技术路线的有力证明仓库地图AST 调用图 PageRank 个性化解决编辑哪里、可靠的代码编辑后端解决怎么改、tree-sitter lint 与测试驱动修复解决改得对不对而交互式 UX 保证用户始终掌握方向盘。对于希望在自己的代码库中复现用 AI 结对解决 GitHub Issue的团队Aider 提供的启示是先把定位相关代码与可靠落盘编辑这两个基础设施做好往往比堆叠更多自主 agent 能力更高效、更省 token、也更可控。【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
