Resolving Java Code Repository Issues with iSWE Agent

本文提出了专注于 Java 语言的 iSWE Agent，该代理结合了基于规则的静态分析与大模型技术，通过定位和编辑两个子代理实现了在 Java 代码库问题修复上的最先进性能。

要点

这篇论文介绍了一个名为 iSWE Agent 的新系统，它的核心任务是自动帮程序员修 Bug 或写新功能。

为了让你更容易理解，我们可以把软件开发想象成管理一座巨大的、错综复杂的“代码城市”。

1. 背景：为什么需要 iSWE？

• 现状：以前，大家主要用 AI 助手来修Python（一种比较灵活、像脚本一样的语言）写的代码。这就像 AI 助手非常擅长在“乐高积木”搭建的简易房子里找问题。
• 问题：但是，世界上很多重要的企业软件（比如银行系统、大型后台）是用 Java 写的。Java 更像是一座结构严谨、规则森严的“摩天大楼”。之前的 AI 助手虽然也能进大楼，但因为不懂大楼的复杂结构和严格规则，经常修不好，甚至把楼修塌了。
• 目标：这篇论文就是要造一个专门懂 Java 大楼结构的超级维修工。

2. iSWE 是怎么工作的？（双特工模式）

iSWE 不像以前的 AI 那样“一个人包揽所有事”，它把任务拆成了两个特工，像是一个侦探和一个工匠的完美配合：

🕵️‍♂️ 特工一：定位员 (Localization Agent) —— “侦探”

• 任务：当收到一份“故障报告”（比如“大楼三楼的电梯按钮按了没反应”）时，侦探的任务是找到问题到底出在哪。
• 绝招：它手里拿着Java 专用的“透视眼”工具（基于静态分析技术）。
  • 普通的 AI 可能只能看表面，像盲人摸象。
  • 侦探能直接看到大楼的蓝图、电路图和承重墙。它能迅速分析出：“哦，问题不在按钮本身，而是连接按钮和电梯控制室的两根电线（两个文件）接错了，而且这两根电线在两个不同的楼层。”
• 特点：它只看不动手（读工具），确保不会在找问题的时候把大楼弄坏。

🔨 特工二：编辑员 (Editing Agent) —— “工匠”

• 任务：拿到侦探给出的“精确维修点”后，工匠负责动手修改代码。
• 绝招：它使用一种安全的“手术刀”工具。
  • 它不会像以前的 AI 那样随意乱写代码（比如直接运行一段脚本，可能把整个系统搞崩）。
  • 它是在一个**隔离的“透明玻璃房”（沙盒容器）**里进行修补。它先试着在玻璃房里把线接好，然后让编译器（大楼的质检员）检查：“这样接对吗？符合建筑规范吗？”
  • 只有当质检员说“完美”时，它才把修改正式应用到主大楼里。

3. 为什么它比以前的厉害？（核心创新）

以前的 AI 修 Java 代码，就像让一个只会修乐高的人去修摩天大楼，他只能凭感觉乱猜，或者试图用通用的工具（比如命令行）去硬撬，效率低且危险。

iSWE 的厉害之处在于：

1. 懂行：它不是通用的，而是专门为 Java 定制的。它知道 Java 的“建筑规范”（类型系统、面向对象），所以它用的工具是专门针对 Java 设计的“透视眼”和“手术刀”。
2. 安全：它大部分时间都在“只读”模式下工作，只有在最后修补时才在隔离区操作，绝不会意外把大楼拆了。
3. 省钱：因为它更聪明，不需要像其他 AI 那样反复试错（比如问 100 次“这里对吗？”），它往往几次就能搞定。论文数据显示，它比竞争对手省了 2 到 3 倍的“咨询费”（API 调用成本）。

4. 成果如何？

研究人员在两个著名的“代码维修考试”（Multi-SWE-bench 和 SWE-PolyBench）的 Java 部分进行了测试。

• 成绩：iSWE 在 Java 修 Bug 的排行榜上名列前茅，甚至拿到了第一。
• 性价比：它不仅修得好，而且花得少。用同样的 AI 大模型，iSWE 能修好更多的 Bug，但花费的钱却只有别人的一半甚至更少。

总结

简单来说，iSWE 就是一个给 Java 代码大楼量身定制的“智能维修团队”。它不再盲目地乱猜，而是先派懂结构的侦探精准定位，再派守规矩的工匠在安全区修补。

这篇论文告诉我们：在解决复杂的企业级软件问题时，“懂行”的专用工具 + 严谨的流程，比单纯依赖“大力出奇迹”的通用大模型更有效、更安全、也更省钱。这为未来企业软件的自动化开发迈出了重要的一步。

技术摘要

iSWE Agent：面向 Java 代码仓库的自动化问题修复系统技术总结

1. 研究背景与问题定义 (Problem)

核心问题：
虽然基于大语言模型（LLM）和智能体（Agent）的自动化代码问题修复（Issue Resolution）在 Python 领域取得了显著进展（如 SWE-bench），但在Java等企业级编程语言上的研究相对匮乏。现有的模型和工具大多针对 Python 优化，而 Java 在语法、类型系统（强静态类型）和面向对象特性上与 Python 存在显著差异，导致直接迁移现有方案效果不佳。

具体挑战：

1. 语言差异：Java 是编译型语言，拥有严格的静态类型系统，许多错误在编译阶段即可发现，传统的 Python 风格 Linter 无法有效捕捉 Java 的深层代码问题。
2. 多文件编辑：Java 的面向对象特性导致功能往往分散在多个文件中，修复一个 Issue 通常涉及跨文件的修改，这比 Python 的单文件修改更具挑战性。
3. 工具依赖：现有的通用 Agent 往往依赖沙箱运行任意代码（如 Bash），这带来了安全风险、资源开销（时间、内存）以及复杂的迭代循环。
4. 缺乏专用工具：缺乏针对 Java 静态分析和代码转换的高级专用工具，导致 Agent 难以利用领域知识。

目标：
构建一个专门针对 Java 代码仓库的自动化问题修复系统（iSWE），通过结合基于规则的工具与模型驱动的智能体，实现高效、安全且准确的问题定位与代码修复。

---

2. 方法论 (Methodology)

iSWE 采用双智能体（Two-Agent）流水线架构，将问题分解为“定位（Localization）”和“编辑（Editing）”两个子任务。两个智能体均基于 ReAct（Reasoning + Acting）范式，但使用了专为 Java 设计的专用工具。

2.1 系统架构

系统由两个主要子智能体组成，通过结构化的中间数据（JSON）进行交互：

1. 定位智能体 (Localization Agent)：

   • 输入：问题描述 ($d_{issue}$) 和旧代码 ($c_{old}$)。
   • 任务：识别需要修改的代码位置（文件、类、方法）。
   • 工具：使用只读的基于规则的工具，基于静态分析库（CLDK 和 Tree-Sitter）。
     • 节点查询工具：获取文件、类、方法、符号信息。
     • 边查询工具：获取继承层级、函数调用者、调用链。
   • 输出：结构化的 JSON，包含建议修改的代码位置范围（Span）和初步的修改思路。
   • 特点：完全在用户空间运行，无需沙箱，无副作用。

2. 编辑智能体 (Editing Agent)：

   • 输入：定位智能体输出的代码位置集合、问题描述及初步思路。
   • 任务：生成具体的代码修改补丁 ($c_{new}$)。
   • 工具：使用**搜索 - 替换（Search-Replace）**工具，格式类似版本控制中的合并冲突（Merge-Conflict）。
   • 验证流程：
     1. 格式检查：检查搜索块是否匹配。
     2. 轻量级 Lint：运行无副作用的 Java Linter。
     3. 编译检查：仅在上述检查通过后，在容器化环境中启动 Java 编译器进行编译验证，确保依赖版本正确且无副作用。
   • 输出：符合 Unidiff 格式的最终补丁。

2.2 关键技术特性

• 语言感知工具 (Language-Aware Tools)：不同于通用的 Bash 命令，iSWE 的工具直接利用 Java 的 AST（抽象语法树）和语义信息，提供丰富的上下文，减少 LLM 的猜测。
• 声明式提示工程 (PDL)：使用 PDL (Prompt Description Language) 编写提示模板，使逻辑更清晰，便于管理上下文和数据流。
• 模型无关性 (Model-Agnostic)：系统不硬编码特定的 LLM，支持从开源模型（如 DeepSeek, Llama）到前沿闭源模型（如 Claude）的灵活切换。
• 安全性：绝大多数操作（包括定位和大部分编辑检查）是只读的，仅在必要时（编译检查）使用容器沙箱，极大降低了风险。

---

3. 主要贡献 (Key Contributions)

1. 首个 Java 专用问题修复智能体：提出了 iSWE，这是第一个专门针对 Java 代码仓库设计的问题修复 Agent，填补了该领域的空白。
2. 验证了“语言感知工具”的有效性：证明了结合基于规则的静态分析工具与 LLM，可以显著提升在特定语言（Java）上的问题修复能力，优于纯代码生成的通用方案。
3. 广泛的基准测试与评估：在两个主要 Java 基准测试（Multi-SWE-bench 和 SWE-PolyBench）上进行了详尽的实验，提供了关于 Java 问题修复的深入洞察（如不同复杂度、不同工具集的表现）。
4. 成本与性能的双重优化：展示了在保持甚至提升修复率的同时，显著降低了 LLM 推理成本（相比其他领先 Agent 低 2-3 倍）。

---

4. 实验结果 (Results)

实验在 Multi-SWE-bench (Java) 和 SWE-PolyBench (Java) 两个基准上进行。

4.1 修复率 (Resolution Rate)

• 前沿模型表现：使用 Claude-4.5-Sonnet 时，iSWE 在 Multi-SWE-bench 上达到 43% 的修复率，在 SWE-PolyBench 上达到 55% 的修复率，均处于或接近排行榜首位。
• 开源模型表现：即使使用 DeepSeek-V3-2 等开源模型，也能取得 21.8% (Multi-SWE) 和 18.1% (SWE-Poly) 的修复率，证明了系统的通用性。
• 对比优势：在 Multi-SWE-bench 上，使用相同模型（Claude-3.7-Sonnet），iSWE 的修复率（32%）高于其他提交（如 MSWE-agent 的 23.4%），且成本更低。

4.2 成本效率 (Cost Efficiency)

• 显著降低成本：iSWE 的推理成本比使用相同 LLM 的其他领先 Agent 低 2 到 3 倍。
  • 例如在 Multi-SWE-bench 上，iSWE (Claude-4.5-Sonnet) 平均成本为 $1.86/实例，而 InfCode (GPT-5.2) 高达 $4.78/实例。
• 原因分析：
  • 专用工具减少了 LLM 的推理轮数（Turns）。
  • 工具输出更精准，减少了无效 Token 的生成。
  • 大部分操作无需启动昂贵的沙箱环境。

4.3 定位与编辑精度

• 定位精度：文件级召回率（Recall）通常在 60% 以上，节点级（类/方法）召回率约为 30-40%。
• 相关性：定位的准确性与最终修复率高度正相关，表明精准定位是成功修复的关键。
• 工具调用：实验显示，使用 iSWE 的高级 Java 工具比使用 Bash 或通用工具（如 SWE-Agent 的工具集）能减少约 30-40% 的 Token 消耗和推理轮数。

4.4 复杂度分析

• 难度分级：随着问题难度从“简单”到“困难”，修复率下降，成本上升，这是符合预期的。
• 修改类型：仅修改函数（Function Only）的修复率最高（约 60%），涉及混合修改（Mixed，跨文件/类）的修复率最低（约 13-24%），突显了多文件编辑的挑战。

---

5. 意义与展望 (Significance)

1. 推动企业级软件开发：Java 是许多大型企业系统的核心语言。iSWE 的成功证明了将 AI 智能体应用于企业级语言是可行的，且能通过专用工具获得比通用方案更好的效果。
2. 范式转变：从“纯代码生成”转向“规则辅助 + 模型生成”的混合模式。通过引入静态分析工具，弥补了 LLM 在理解复杂代码结构和类型系统方面的不足，同时避免了沙箱带来的开销。
3. 成本效益：为大规模自动化代码维护提供了经济可行的方案，使得在资源受限的场景下使用 AI 辅助开发成为可能。
4. 未来方向：
   • 引入测试反馈（Test Feedback）和动态执行来进一步提升修复率。
   • 探索推理扩展（Inference Scaling）技术。
   • 将类似的方法论扩展到其他企业级语言（如 C#, C++）。

总结：iSWE 通过精心设计的 Java 专用工具链和双智能体架构，成功解决了 Java 代码问题修复中的定位难、多文件编辑复杂及安全性问题，在保持高修复率的同时大幅降低了成本，为自动化软件工程在企业级语言中的应用树立了新的标杆。