SWE-bench：语言模型能否解决真实的 GitHub 问题？
CodeAct 论文提出了一个引人注目的观点，即 Python 是 LLM 智能体的正确动作格式。但选择正确的动作格式只是问题的一半——你还必须证明智能体能够处理现实世界的任务复杂性，而不仅仅是人工筛选的基准测试。SWE-bench (arXiv:2310.06770) 由普林斯顿大学的 Carlos Jimenez、John Yang、Alexander Wettig、Shunyu Yao、Kexin Pei、Ofir Press 和 Karthik Narasimhan 发表并于 ICLR 2024 展示，正是这篇论文迫使该领域直接面对这一差距。
论文内容
“SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” 构建了一个包含 2,294 个任务实例的基准测试，这些实例提取自 12 个热门 Python 仓库（astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy 和 xarray）中实际合并的拉取请求。每个实例向模型提供代码库快照和 GitHub 问题描述；模型必须生成一个补丁，使一组指定 的、先前失败的测试通过，且不破坏现有测试。该基准测试通过挖掘约 90,000 个 PR 构建，筛选出那些既解决了关联问题又添加了新测试的 PR，然后验证基于执行的通过/失败转换。这种严谨的构建方式避免了典型基准测试中真值模糊或容易作弊的问题。
核心观点
- Claude 2 作为发布时表现最好的模型，在使用 BM25 稀疏检索（即模型必须自行寻找相关文件的现实部署设置）时仅解决了 1.96% 的问题。
- 在“先知检索”（Oracle retrieval）设置下（即直接向模型提供所需的文件），Claude 2 的解决率提高到 4.80%，这证实了瓶颈部分在于检索，但主要是编辑问题：即使拥有完美的上下文，成功率仍低于 5%。
- GPT-4 在使用 BM25 检索时解决了 0.00% 的问题（出于预算考虑仅在 25% 的子集上进行了评估），在先知检索下解决了 1.74%。对于 Claude 2 来说，从先知检索到 BM25 的降幅是剧烈的；而对于 GPT-4 来说则是全军覆没。
- 生成的补丁在系统性上过短：Claude 2 成功的补丁平均为 19.6 行，而人类编写的黄金补丁平均为 74.5 行。模型倾向于寻找简单的局部修复；而人类则会编写全面的跨文件解决方案。
- 更多的上下文反而有害。BM25 在 50k token 下比 13k token 检索到了更多的先知文件，但解决率往往反而下降。这里记录了一个真实的失败模式——“丢失在中间”（lost in the middle）效应，即模型会忽略埋藏在长上下文中间的相关证据。
- SWE-Llama 13b 在先知检索的上下文上进行了微调，在先知设置下达到了 4.00%，但在 BM25 设置下仅为 0.70%。在完美上下文上进行训练会产生脆弱的智能体，一旦检索环境变得现实，它们就会崩溃。
哪些结论依然成立，哪些已经过时
该基准测试的构建非常严谨。基于执行的评估（测试实际运行、通过或失败）是代码编辑任务的正确基准真相。它是客观的、可自动化的，且难以作弊。要求“失败到通过”的转换（而不仅仅是成功应用补丁）的决定尤为重要：它防止了像空操作或删除代码这种琐碎但“正确”的补丁。
这些结果经受住了时间的考验。SWE-bench 于 2023 年 10 月发布，并迅速成为编程智能体事实上的评估标准。最初 1.96% 的基准线具有真实的参考价值，而非刻意挑选。由相关团队在 2024 年发表的 SWE-agent 通过重新设计智能体-计算机接口，将解决率提高到了 12.47%——这一 6 倍的提升本身就证实了原始基准线还有多大的提升空间。
这篇论文没有处理好的两件事：首先，该基准测试仅限 Python。这是实际操作的需要，但也带来了过度拟合 Python 惯例的真实风险。其次，论文仅提出了检索增强生成（RAG）基准线，并明确将基于智能体的方法留给未来的研究。这种延后在 2023 年是恰当的，但意味着论文本身没有提供关于哪些智能体架构有所帮助的信号。
“先知”设置也比看起来要弱。提供完美的文件上下文并不能解决这些文件内部的代码定位问题，也无助于关于模块间交互的多文件推理。Claude 2 在先知设置下仅 4.8% 的成功率意味着即使上下文中有正确的 文件，模型在 95% 的时间里仍然失败。问题主要不在于检索。
为什么这对金融 AI 很重要
Beancount 是一个托管在 GitHub 上的 Python 项目。Beancount 的回写智能体（write-back agent）在本质上就是一个需要通过 SWE-bench 式任务的智能体：给定一个账本文件和一条指令（“添加这笔交易”、“修复此余额差异”），生成一个能够通过 bean-check 且不破坏现有断言的修改。
检索失败与账本定位问题直接类比。当用户说“修复第三季度办公用品的超支”时，智能体必须首先在一个可能包含数千行的文件中找到相关分录——这正是 BM25 在 40–50% 的 SWE-bench 实例中失败的文件定位任务。 “丢失在中间”的性能退化同样适用于长的 .beancount 文件，其中较早日期的分录同样容易被忽略。
补丁长度的不对称性是一个实用的警告。模型打补丁过于狭隘。在会计领域，这表现为修复了一个分录却遗漏了对冲分录，或者更新了支出行却让累计余额变得过时。生产环境中的 Beancount 智能体需要一个验证层——bean-check、余额断言或显式的对账流程——强制智能体看到其修改的全局后果，而不仅仅是局部的合理性。
先知检索与 BM25 之间的差距也提醒我们，检索质量与智能体质量是不可分割的。一个无法可靠识别哪些账户或文件与用户问题相关的智能体，在尝试编辑之前，就会在账本导航步骤失败。
延伸阅读
- SWE-agent (arXiv:2405.15793, NeurIPS 2024) — 直接的后续研究；通过重新设计智能体-计算机接口，将解决率从 1.96% 提升到 12.47%。其文件导航和代码搜索的设计原则可直接应用于 Beancount 智能体工具的开发。
- Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — 剥离了智能体的复杂性，展示了一个没有复杂脚手架的简单“定位 + 修复”流水线也可以具有竞争力；这是对重接口方法的一个有用的补充视角。
- MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — 通过分层内存管理正面解决长上下文问题；对于必须在跨越多年的 Beancount 账本上进行推理的智能体直接相关。
