07. SWE-agent：把真实 GitHub Issue 变成 Agent 的任务

SWE-bench：来自真实代码库的 benchmark

HumanEval、MBPP 这些 benchmark 的题目是为测试而构造的，和真实软件开发有距离。

SWE-bench（Jimenez et al., 2023）从 12 个 Python 开源库（包括 Django、Flask、Scikit-learn、Sympy 等）收集了 2294 个真实 GitHub Issue，每个 Issue 对应一个 pull request（人类开发者提交的实际修复）。

评测任务是：给 Agent 看 Issue 描述（有时附带复现步骤），让它在代码库里找到问题、修改代码，使得原 PR 的测试用例能够通过。

这个设定的难点在于：

• 代码库规模大：Django 有几十万行代码，Agent 需要快速定位相关文件
• Issue 描述模糊：用户报 bug 通常不会精确指出哪一行出了问题
• 测试是隐藏的：Agent 只知道"修好之后测试应该过"，不知道测试具体测什么
• 修复可能涉及多个文件：真实 bug 通常不是改一行那么简单

早期 LLM（GPT-4）直接作用于该任务的 pass rate 只有 1.7%，说明能通过代码生成 benchmark 和能修复真实 bug 是两件不同的事情。

SWE-agent：为软件工程任务设计的 Agent

SWE-agent（Yang et al., 2024）是 Princeton 团队专门为 SWE-bench 设计的 Agent 系统，核心是 Agent-Computer Interface（ACI） 的概念。

ACI：为 LLM 重新设计的工具接口

程序员调试时用的工具——VS Code、命令行、grep、git blame——是为人类操作设计的。对 LLM 来说，一个 cat 命令输出几千行，大部分是噪音，直接使用效率很低。

SWE-agent 重新设计了这套接口，针对 LLM 的能力和限制：

传统工具        → ACI 改造后
────────────────────────────────────────
cat file        → view file（带行号，可指定范围）
grep            → search_file / search_dir（语义更清晰）
vim / nano      → edit（精确行号操作，自动缩进）
无              → scroll_up / scroll_down（滚动浏览长文件）
无              → open file（记住当前打开的文件和位置）

关键设计原则：

1. 每次动作的信息量适中，不返回几千行，也不返回一行
2. 状态显式保存：Agent 总是知道"当前在哪个文件的第几行"
3. 编辑操作精确：指定行号范围替换，不是全文重写

典型的 SWE-agent 工作流

[读取 Issue]
"Django 的 QuerySet.filter() 在某种条件下返回错误结果"

[定位代码]
search_dir("QuerySet filter", "./django/db/models/")
→ 找到 django/db/models/query.py

[浏览相关代码]
view("django/db/models/query.py", 890, 950)
→ 看到 filter() 的实现

[理解上下文]
view("django/db/models/sql/query.py", 200, 280)
→ 追踪 SQL 构建逻辑

[定位 bug]
search_file("add_filter", "django/db/models/sql/query.py")
→ 发现边界条件处理有误

[修改代码]
edit("django/db/models/sql/query.py", 245, 248,
     "        if not isinstance(value, (list, tuple)):\n            value = [value]")

[验证修改]
python -m pytest tests/queryset_tests.py -k "test_filter"
→ 查看测试输出

整个过程类似程序员的调试流程，每一步的信息量都控制在 LLM 能有效处理的范围内。

ACI 设计对结果的影响

SWE-agent 论文里有一个消融实验，用相同的 LLM（GPT-4），只改变工具接口：

同样的 LLM，同样的任务，工具接口的设计使通过率相差约 6 倍。这说明 Agent 的表现不只取决于 LLM 本身，工具和接口的设计同样重要。

SWE-bench 上各系统的进展

两年内从 1.7% 到超过 70%，模型能力提升和 Agent 设计优化共同驱动了这个变化。

需要注意的是，SWE-bench Verified 是 SWE-bench 的精简子集，过滤了质量不高的 Issue，比原版更容易一些。

对 Agent 系统设计的几点参考

工具要为 Agent 设计，而不是直接沿用人类的工具

给 Agent 一个完整的 bash shell，并不比给它几个信息量适中的专用工具效果更好。

上下文管理是实际挑战

大型代码库的内容远超 LLM 的上下文窗口。SWE-agent 的浏览工具设计本质上是在帮 Agent 管理"现在在看哪里"这个状态，避免上下文被无关内容占满。

Agent 需要显式的位置状态

人类用编辑器时有文件树、当前文件标签、光标位置这些视觉线索。Agent 需要在 prompt 里保持等价的状态信息，否则容易在大代码库里迷失方向。

后续发展

SWE-agent 的 ACI 思想之后被多个系统采用：

• Devin（Cognition AI）：商业化的软件工程 Agent，内置浏览器、终端、代码编辑器
• OpenHands（前身 OpenDevin）：开源实现，结合了 CodeAct 和 SWE-agent 的思路
• GitHub Copilot Workspace：在 GitHub 原生环境里的代码修复功能

这些系统都在处理同一个问题：怎样让 Agent 在真实软件工程环境里有实际用处。工具接口设计、上下文管理、人机协作边界，是绕不开的几个方面。