iSWE-Agent（智能体） for Java 在 GitHub issue 解决任务中占据了排行榜前两名。第一个条目使用前沿模型的单次运行，第二个条目使用开放模型的推理扩展。
就像汽车机械师的天赋最好花在修理发动机上，而不是整天修补漏气的轮胎，软件工程师的价值在于他们创造性的问题解决能力。不幸的是，工作日很容易被调试、编码和文档编写所吞噬。IBM Research 的一款新智能体 AI 工具旨在分担软件工程师工作中较为单调的部分，而两个新版本正引领潮流。
IBM 的软件工程（iSWE）-Agent for Java 目前在 Multi-SWE-Bench 的 Java 类别中占据第一和第二名。一个条目基于前沿模型 Claude 4.5 Sonnet，位居排行榜榜首，另一个基于开源模型，位列第二。这些 iSWE 智能体在基准测试中分别解决了 33% 和 31% 的 Java issue。
iSWE-Agent 使用两种输入：Java 或 Python 代码库，以及一个 issue，如错误报告或功能请求。有了这两种输入，它会生成一个补丁，目的是解决该 issue。“大多数 GitHub issue 是错误报告，有些是功能请求，iSWE 对两者遵循相同的基本工作流程，”IBM Research 首席研究科学家兼经理 Martin Hirzel 说。
为什么选择 Java？
虽然该团队过去的工作集中在 Python 上，但这个新版本是为 Java 构建的。原因有两方面。一个原因纯粹是实际的：IBM 有许多 Java 客户，更广泛地说，有一个庞大的 Java 开发者社区，对他们来说，智能体 AI 工具可以省去很多麻烦。
另一个更科学的原因是，其他所有人都专注于 Python，以至于现有的 SWE 智能体对 Python 过拟合。“Python 的 issue 解决排行榜有点饱和，而且越来越多的证据表明，最新的前沿模型基本上被训练中看到这些基准数据所污染，”Hirzel 说。换句话说，这些工具正在学习在基准测试中表现出色，但尚不清楚这种性能如何延伸到它们真正设计用于的实际任务。这一趋势的不幸结果是降低了社区对 Python SWE 智能体基准有效性的信心。
此外，对性能更好的 Java SWE 智能体存在未满足的需求。Python 排行榜上充满了在 issue 解决方面得分在 70% 到 80% 准确率范围内的智能体，而 Java 排行榜上的许多智能体得分在 20% 到 30% 之间。还有增长空间，而且这似乎是一项更具挑战性的任务。
开发 iSWE 智能体
iSWE-Agent 是 IBM 首个完全内部编写、基于 IBM 原生开源技术（PDL）构建的专有多智能体 SWE 系统，以减轻长期维护方面的顾虑。IBM Research 高级研究工程师、iSWE-Agent 项目负责人兼架构师 Jatin Ganhotra 表示，iSWE-Agent 与其他领先 SWE 智能体的不同之处在于其架构创新和其他编码智能体中没有的专门 Java 感知工具。与需要不受限制的 shell 访问权限的流行 SWE 智能体不同，iSWE-Agent 使用更安全的工具，这些工具大多为只读，基于 IBM 的开源程序分析工具包 CodeLLM DevKit（CLDK）。
为了填补 SWE 智能体领域的空白，研究人员采取了两种方法。其中一种是将专有 iSWE-Agent 与前沿模型 Claude 4.5 Sonnet 一起使用。其核心是，iSWE-Agent 通过两个专门组件工作：一个精确定位代码中需要更改的位置及原因，另一个应用这些编辑。iSWE-Agent 不依赖 shell 命令或简单文本替换等传统方法，而是采取更智能的路径。它使用定制构建的工具来理解代码结构并应用编辑，然后在最终确定之前检查准确性。这种方法提高了可靠性，并使系统能够处理跨多个文件的更复杂更改。
结果体现在数字上。基于前沿模型 Claude 4.5 Sonnet 构建的 iSWE-Agent 实现了 33% 的解决成功率，位居前沿模型类别——以及 Java 排行榜——榜首。
第二个实验使用了开放模型。iSWE-OpenModels 通过一种称为推理扩展（inference scaling）的技术达到了有竞争力的性能。推理扩展可以采取多种形式，但本质上它是一种在推理时增加更多计算能力的方法。一种方法是生成多个不同的输出，然后对这些输出进行评分和排序以提高性能。iSWE-OpenModels 的大部分创新都涉及打磨用于选择提交哪个输出的模型。“通过精心设计选择组件，我们获得了非常好的性能，”IBM 杰出研究科学家 David Kung 说。
开放模型的推理扩展之所以可行，是因为较小的模型托管成本更低，而且由于它们是开源的，可以在本地托管，而不必支付前沿模型提供商的 API（应用程序编程接口） 费用。对于关注隐私或受行业法规约束的 IBM 客户而言，采用开放模型使得在本地进行推理扩展成为可能。
在团队将两个 Java iSWE 参赛作品提交到 Multi-SWE-Bench 排行榜之前，榜首由一个使用 Gemini 2.5 Pro 的作品占据，其在解决 Java 问题方面的得分为 28.9%。相比之下，另一个使用前沿模型 Claude 3.7 Sonnet 的提交得分为 23.4% 的准确率。“排行榜上使用开源模型的最佳提交使用的是 DeepSeek-R1，得分为 22.7%，”Kung 说。
为了超越这些数字，Kung 和同事使用了推理扩展。为此，他们对同一问题多次运行推理。“我们这样做的原因是，通过对智能体进行重复采样，我们增加了其中一个解决方案正确的概率，”Kung 说。
获得好的结果取决于从智能体产生的候选中选出最佳结果。这就是团队“验证器”（Verifier）组件的用武之地。在这个阶段，一个评分 LLM（大语言模型）——在本例中，团队构建了一个微调版的 Qwen-2.5-Coder-32B——为每个提议的补丁分配分数，并选出最好的五个。
“我们推理扩展流程的最后一步基于 LLM-as-a-judge，它会查看这五个候选并选出唯一一个，”Kung 说。在锦标赛式的选择中，候选补丁的不同组合被相互比较，在这个过程中，最终的优胜者脱颖而出。通过这种方式，iSWE-OpenModels 智能体以 31% 的解决率超越了所有使用开放模型的提交——达到了与由前沿模型驱动的 SWE 智能体相当的性能。
而事实上，IBM Research 的模型在两个类别中都取得了领先。
团队计划在现有发现的基础上开发新版本，他们希望这些版本能在基准测试中获得更高的分数，目标是用 AI 解决开发者的 Java 任务，就像今天用 AI 解决 Python 任务一样。他们还计划将软件工程智能体与事件分析集成，以主动修复由软件变更和缺陷引起的事件。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文来源：IBM Research Blog
原文作者：Peter Hess；如有侵权，请联系管理员删除。
