SWE-agent 教程：浏览代码仓库并尝试修复 GitHub 问题

我介绍 SWE-agent，这是 Princeton 团队围绕智能体计算机界面设计的编程智能体项目。它的目标是为语言模型提供处理 GitHub 问题的工具：检查仓库、尝试复现问题、编辑文件并提出修复。这些是项目希望提供的能力，并不承诺每个问题都能解决。

项目展示的 SWE-bench 图表报告，使用 GPT-4 的 SWE-agent 解决了 12.29% 的问题，Devin 的结果为 13.84%。图表脚注说明 Devin 的结果只在 SWE-bench 测试集的 25% 上评估。这些由项目展示的历史结果评估范围不同，因此仅凭图表无法确定普遍适用的正面排名。

项目展示了智能体读取问题、复现涉及转换为 R 的问题、搜索相关文件并编辑可能的源文件。我对这种逐步交互印象深刻，因为模型必须在仓库中找到有用的部分，而不是在一个提示中接收整个代码库。

团队将结果部分归因于为语言模型设计的命令和反馈。我将大型仓库中寻找相关上下文的挑战与 Aider 等工具进行比较，我说 Aider 使用 Universal Ctags。问题在于如何提供足够有用的代码，同时不让模型信息过载。

项目介绍了一个代码检查器：如果编辑引入语法错误，就会阻止该编辑继续。自定义文件查看器每次显示约 100 行，并提供滚动和文件内搜索命令。我怀疑代码片段是否总能提供足够上下文，但作者报告认为这一界面很有用。

另一个目录搜索命令会返回简洁的匹配结果；没有输出的命令则会收到明确的成功信息。我把这一套工具看作智能体的小型定制开发环境。这些界面选择由项目介绍；视频没有通过独立实验分别测量每项选择的效果。

在 2024 年的配置过程中，我先准备 Docker 和 Miniconda，在终端克隆仓库，根据环境文件创建项目的 Conda 环境并激活，然后运行设置脚本构建 Docker 镜像。这些是当时版本展示的步骤，后续版本可能不同。

尽管起初我称赞了打包好的配置，但在 Apple Silicon Mac 上，我无法解决一个与 Miniconda 有关的 Docker 错误。我转而使用 Lightning，并说明它没有赞助视频，随后在那里完成镜像构建。切换环境是我在演示中采用的变通方法，并不能证明错误的确切原因。

我在项目目录中创建密钥配置文件，并配置 GitHub token 和本次测试使用的 OpenAI 密钥。界面还列出了其他可选供应商密钥。这套配置针对演示的版本；凭据和供应商设置取决于实际环境。

我指定模型、配置文件和 SWE-agent 自身仓库中的一个问题 URL 来运行智能体。这个问题涉及缺失的 `base_commit` 记录。智能体初始化环境，开始阅读问题和仓库文件。

智能体识别出报告的键错误，并使用内置查看命令浏览一个很长的文件。它滚动经过多个位置后找到相关方法，随后提出编辑并注意到一个重复设置。我觉得这一过程很有趣，但运行过程和提出的补丁并不能证明解决方案有效。

运行在超过配置的 2 美元成本上限后停止。我看到智能体作出修改的迹象，但没有完成验证来证明提出的修复解决了问题。项目的汇总基准分数不能解读为这个具体问题被修复的精确概率。

我注意到成本上限可以配置，并说希望使用本地模型来避免同样的托管 API 费用。当时我没有找到直接的本地模型选项，并推测未来版本可能让这件事更容易。本地推理仍然存在硬件和运营成本。

另一段演示来自一位自我介绍为 Carlos 的作者，他使用 SWE-bench 中一个 SymPy 问题，涉及 `Matrix.col_insert` 的异常输出。他把问题发送给智能体，然后讲解同一示例此前的一次运行。

Carlos 展示智能体根据问题创建复现脚本，并确认异常行为。智能体搜索仓库、打开矩阵实现，并确定插入函数是值得调查的位置。

智能体发现索引问题，应用编辑并重新运行复现脚本。Carlos 说输出现在符合预期。智能体删除临时复现文件，并提交建议的代码差异以进行基准评估。

Carlos 报告，提交的补丁通过了此前失败的测试，也没有破坏 SWE-bench 评估中展示的现有测试。这是作者选择的单个演示，与我中断的运行不同，也不能保证未来的问题都能解决。