SWE-agent：接口设计如何开启自动化软件工程
上周我读了 SWE-bench 的论文，得出一个简单的结论：原始的 GPT-4 仅能解决 1.96% 的真实 GitHub 问题。本周我想了解后续问题 —— 究竟是什么提升了这个数字？Yang 等人发表的 SWE-agent (NeurIPS 2024) 给出了答案，而这个答案看似平淡无奇：更好的接口。
论文内容
SWE-agent（由普林斯顿大学和斯坦福大学的 John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan 和 Ofir Press 提出）引入了代理-计算机接口 (Agent-Computer Interface, ACI) 的概念。这是一个专门构建的软件层，位于 LLM 和 Linux 环境之间，它不是为人类用户设计的，而是根据语言模型处理信息的方式量身定制的。该研究认为，这种接口的设计，而非底层模型本身，是自主软件工程代理的主要瓶颈。
该系统处理来自 SWE-bench 的 GitHub 问题：阅读问题、导航仓库、定位相关代码、进行编辑并运行测试以验证修复。其核心贡献不是新模型或训练过程，而是一套精心设计的命令原语和反馈格式，用以替代默认的 Linux shell。
核心观点
- 接口性能比原始 shell 高出 10.7 个百分点。 在对 300 个 SWE-bench Lite 实例的消融实验中，SWE-agent 比直接使用裸 Linux shell 的相同代理多解决了 10.7% 的问题。这是论文中影响最大的单一因素。
- 带有 100 行窗口的文件查看器。 ACI 每次显示约 100 行并配合滚动命令，而不是直接
cat整个文件。上下文太少（30 行）会损失 3.7 个百分点；太多（整个文件）会导致模型失去焦点。这个平衡点非常微妙。 - 编辑循环中的 Linter。 每个编辑命令在提交更改前都会运行语法检查器。这防止了模型陷入代码损坏的状态，而这种状态通常很难仅通过自然语言来恢复。
- 极简目录搜索。 ACI 仅返回匹配的文件名列表，而不是带有上下文的
grep -r（这会使模型信息过载）。当模型需要决定下一步查看何处时，少即是多。 - 完整基准测试结果：在 SWE-bench 上配合 GPT-4 Turbo 达到 12.47%。 相比之下，非交互式 RAG 系统为 3.8%，原始 SWE-bench 论文中的简单检索基准为 1.96%。在 HumanEvalFix 上则达到了 87.7%。
- ACI 设计具有通用性。 网络安全变体 (SWE-agent EnIGMA) 将相同的 ACI 理念应用于 CTF 挑战，通过使用维持并发 shell 会话的交互式代理工具，实现了 13.5% 的成功率 —— 是之前系统的三倍。
哪些结论站得住脚，哪些站不住
核心见解 —— “代理的接口设计与提示词工程同样重要” —— 得到了充分支持，我认为这非常有价值。消融实验很真实：作者隔离了各个组件并展示了每个组件的贡献。相比原始 shell 基准 10.7% 的提升是一个干净利落的结果，无法用模型差异来解释。
我不太确信的地方在于基准测试本身。SWE-bench 测试集中的问题在复杂性、模糊性以及基准修补程序的明确程度上差异巨大。问题质量的高度波动意味着 12.47% 这个数字在一定程度上取决于评估集中碰巧包含了哪些问题。作者通过在 SWE-bench Lite（300 个问题）上报告消融结果隐式地注意到了这一点，但该子集内的方差依然很高。
更大的局限性在于范围：SWE-bench 测量的是孤立的单个问题解决能力。没有跨问题的会话记忆，没有对代码库历史的理解，也没有多问题依赖跟踪。SWE-Bench Pro (arXiv:2509.16941, 2025) 后来显示，当问题涉及多个文件的协同更改时，即使是尖端模型的性能也会降至 25% 以下 —— 性能随文件数量增加而剧烈衰减。ACI 虽能辅助解决单个问题，但真正的难题是 SWE-agent 从未被设计去处理的长程、多文件案例。
还有一个我一直在思考的可重复性问题：接口设计选择（100 行窗口、极简搜索输出）是通过在训练/开发集上进行迭代实验发现的。如果没有类似的调优工作，这些选择能否直接转移到新领域并不明朗。这涉及真实的成本投入。
为什么这对金融 AI 很重要
ACI 框架可以直接映射到 Beancount 代理的设计问题上。Beancount 账本虽然不是命令行，但它是模型需要阅读、导航和写入的结构化产物。这些经验可以迁移：
- 一个账本查看器，如果每次显示 20-50 条交易并配有滚动和过滤命令，其表现将优于一次性倾倒 10 年数据的查看器。上下文窗口溢出是相同的失效模式。
- 一个在提交分录前检查复式记账平衡和账户存在性的写入校验器，就是账本领域的“SWE-agent Linter”。如果没有它，产生语法错误分录的代理将无法自行修复。
- 极简搜索至关重要：查询“显示账户 X 在日期 Y 和 Z 之间的所有交易”应该返回一个紧凑、可扫描的列表，而不是带有大量无关上下文的冗长信息。
论文也为 Beancount 回写代理的早期版本设定了务实的预期。在定义明确的 GitHub 问题上实现 12.47% 的解决率，是目前精心设计的单任务代理的天花板。账本回写涉及类似的任务结构 —— 用户意图、结构化文件、要求的输出、校验器 —— 我预期在定义明确的任务上会有类似的成功率，但在涉及多条目、多账户的工作流中会出现明显的性能下降。
延伸阅读
- MemGPT: Towards LLMs as Operating Systems [arXiv:2310.08560] —— SWE-agent 的上 下文管理是被动式的（溢出时截断）；MemGPT 提出了主动分层内存，这对于需要处理多年份 Beancount 账本的代理来说似乎是必要的。
- SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? [arXiv:2509.16941] —— 直接跟进了 SWE-agent 的不足之处；对于设计复杂账本回写的安全性而言，其中关于多文件性能衰减的数据是必读内容。
- Gorilla: Large Language Model Connected with Massive APIs [arXiv:2305.15334] —— 如果说 ACI 关注接口设计，那么 Gorilla 则关注 API 检索；两者结合可以更全面地展示代理应如何可靠地选择和调用工具。
