SWE-agent 是普林斯顿和斯坦福研究者做的开源软件工程智能体：把一个 GitHub issue 丢给它，它就在沙箱里读代码、定位问题、改文件、跑测试，最后交上一份能直接合并的修复补丁。

issue 堆到明年，修的人还是只有一个？

开源项目和小团队都有同一个尴尬：待修的 issue 越攒越多，能腾出手的人始终就那么几个。市面上的 AI 编码工具大多停在"帮你补全眼前这几行"，写得快一点，但不会替你把一个 bug 从头跟到尾。SWE-agent 走的是另一条路：把整件事交出去。

不是补全代码，而是把一次修复走完

给它一个 GitHub issue 地址，它会克隆对应仓库、读描述，在代码库里翻找相关文件、理解问题、动手修改，再跑一遍测试确认没有弄坏别的地方，最后产出补丁，可以直接当作 Pull Request 提交。整个过程在隔离环境里完成，不需要人在旁边逐个确认。

这套流程 2024 年第一次亮相：在 SWE-bench 这个由真实 GitHub issue 构成的评测集上，它解出了 12.29% 的问题，平均一次只要 93 秒——第一次有开源方案做出两位数成绩，也让"AI 能不能真的修 bug"从口头讨论变成了可测量的题目。此后随着模型迭代，1.0 版本又多次刷新了开源方案在这类评测上的最好成绩。

重点不是模型，而是给它一套合手的工具

让普通对话模型去翻一个真实仓库，多半是迷路：文件太多、上下文塞不下、格式一错就前功尽弃。SWE-agent 论文里最核心的贡献叫 ACI（智能体-计算机接口）——不是把裸终端丢给模型，而是为"读代码、改代码"这件事重新设计一套命令。

细节都做得很具体：文件查看器每轮只显示约一百行，正好落在模型看得准的范围；编辑命令会先跑一遍语法检查，代码不合法就不让这次修改生效；整目录检索只列出命中的文件名，不多塞上下文；命令没有输出时也会明确回一句"执行成功但没有输出"。看着琐碎，正是这些设计让模型在长任务里不容易崩掉——论文也验证过，没有调好的 ACI，同样的模型表现会差一大截。

模型随你换，配置只要一个文件

它不绑定任何一家模型厂商，主流闭源模型和本地开源模型都能接，模型与参数都写在一个 YAML 文件里，换模型改一行就行，不用动代码。这让它特别适合做"同一个任务、不同模型谁更强"的横向评测。

隔离交给 Docker，每次执行都在沙箱里，不会碰坏你的机器；要一次处理几十上百个 issue 时可以开批量并行；跑完还会留下完整的轨迹，每一步读了什么文件、搜了什么、改了什么都能回溯，官方还提供在线查看器，连每一步花了多少钱、耗了多少 token 都标得清楚。

修 bug 只是起点

同一套框架还能干别的：团队用它去打网络安全方向的 CTF 挑战赛，在相关榜单上拿到过领先成绩；竞技编程题，以及任何能描述成"在一个环境里连续操作直到完成"的任务，都可以接上去跑。项目全程开源，代码可审计、可改、可复刻，这也是它在学术圈被反复引用的原因。

它现在的位置，说清楚

2025 年 7 月，同一个团队开源了更轻量的 mini-swe-agent：核心约一百行 Python，去掉全部自定义工具、只保留 bash，在 SWE-bench 验证集上依然能解出约 65% 的问题。团队现在的建议是多数新用户直接用 mini；SWE-agent 则转入维护模式，重心不再放在新功能上。

它值得用的场景也随之清晰了：需要高度可配置的工具链、想试验不同的历史处理策略，或者想研究"一个好的智能体界面该怎么设计"——功能更完整的 SWE-agent 仍然是更合适的那个。它是研究基础设施，不是包装好的成品软件。

截至 2026 年 9 月，它的开源仓库已经积累了两万多个 star 和两千多次 fork，配套的 SWE-bench 评测集也成了这个方向绕不开的公共标尺。

如果你手里堆着一批描述清楚的 issue，或者想弄明白一个能真正动手改代码的智能体是怎么搭起来的，SWE-agent 值得跑一次：把 issue 交给它，它在沙箱里读完代码、改完文件、跑完测试，把补丁交回你手上。