软件工程Agent在工程依赖版本升级探索

扫恢怯 · 2026-1-19 05:10:18

<h4>

</h4><h2>背景与动机</h2> 现代软件项目广泛依赖开源库以避免重复开发，但库版本更新常引入破坏性变更，导致代码兼容性问题。手动适配这些更新需消耗大量开发者时间，且大型代码库中开发者易忽视更新警告或锁定旧版本，长期阻碍功能迭代、性能优化与安全修复。现有自动化方案未被广泛采用，而 LLM 在代码生成、程序修复等领域已展现潜力，因此本文提出一种基于 LLM Agents 的框架，用于自动化完成依赖升级并保障代码兼容性。<h5>1. 代码迁移的重要性与挑战</h5>Java 项目现代化（如版本升级）能带来安全提升、性能优化、架构改进等长期收益，但迁移过程极具挑战性：<ul><li>Java SE 版本迭代会引入二进制、源码和行为层面的不兼容性；
</li><li>依赖库演化频繁，约 1/3 的 Maven 构件发布包含破坏性变更，且 Java 版本与依赖升级相互绑定（如 Spring Boot 3.0 需基于 JDK 17，而部分旧依赖不支持新 Java 版本）。 </li></ul><h5>2. 现有解决方案的不足</h5><ul><li>传统规则系统（如 OpenRewrite、jSparrow）：依赖人工编写的 AST 转换规则，泛化能力弱，难以应对新型 API 或快速演化的语言特性；
</li><li>AI 驱动代理：LLM-based 代理为迁移提供了新可能，但缺乏系统化评估 —— 现有基准要么未针对代理设计，要么无法防范 “奖励黑客”（如代理删除失败测试而非修复问题以通过评估），且缺乏高覆盖率测试集验证语义一致性。 </li></ul><h5>3. 核心研究缺口</h5>现有基准（如 MigrationBench）未解决：① 缺乏高测试覆盖率数据集，无法验证语义保留；② 未防范奖励黑客；③ 未评估 AI 代理的工具使用能力（如文件操作、构建命令执行）。因此，提出 FreshBrew 基准，填补 AI 代理在项目级 Java 迁移任务中的评估空白。

<h4>

</h4><h2>第一部分 FreshBrew 基准设计</h2>FreshBrew 的核心目标是提供可靠、防奖励黑客、贴近真实场景的 AI 代理评估方案，包含两大核心组件：<h5>1. 高覆盖率数据集构建</h5>通过自动化多阶段筛选流程，从 GitHub 筛选出 228 个符合要求的 Maven 项目，筛选标准如下：<ul><li>初始池：30,000 个高星 Maven Java 仓库；
</li><li>关键筛选步骤：① 能在 JDK 8 构建并通过所有测试；② 在 JDK 17/21 构建失败（确保迁移必要性）；③ 测试覆盖率≥50%（支持语义一致性验证）；④ 采用宽松开源许可证。
</li><li>数据集特征：中位数星数 194，包含 Mockito、SLF4J 等常见依赖，项目提交时间集中于 2018 年后，贴近现代开发场景。 </li></ul><h5>2. 鲁棒评估协议</h5>成功迁移需满足三重条件，杜绝奖励黑客：<ol><li>编译通过（<code>mvn compile</code>成功）；
</li><li>所有原始测试通过（<code>mvn verify</code>无修改）；
</li><li>测试覆盖率保留（相对于 JDK 8 基线下降不超过 5 个百分点）。 </li></ol><ul><li>补充指标：效率（代理交互步骤数）、成本（基于 LLM Token 定价计算）。 </li></ul>

<h2>三、实验设计与结果</h2><h5>1. 实验配置</h5><ul><li>评估任务：将 228 个项目从 JDK 8 迁移至 JDK 17 和 JDK 21；
</li><li>测试对象：7 个主流 LLM（含开源模型如 DeepSeek-V3、企业级模型如 Gemini 2.5 Flash、专业编码模型如 Arcee AI Coder-Large）+ 规则系统基准 OpenRewrite；
</li><li>AI 代理环境：基于 smolagents 框架实现 CodeAct 代理，支持文件操作、Maven 构建、网页搜索（DuckDuckGo）等工具，最大交互步骤 100，采样温度 0.2；
</li><li>失败模式分析：采用 LLM-as-Judge（Gemini 2.5 Pro），将失败分类为 4 类：Java API 不兼容、依赖管理失败、构建配置错误、代理行为失败。 </li></ul>

<h5>2. 核心实验结果</h5><h6>（1）迁移成功率</h6><table border="0" cellspacing="0" cellpadding="0"><tbody><tr><td>模型/方法</td><td>JDK 17整体成功率</td><td>JDK 21整体成功率</td></tr><tr><td>规则系统OpenRewrite</td><td>7.0%</td><td>7.5%</td></tr><tr><td>开源模型DeepSeek-V3</td><td>10.7%</td><td>12.4%</td></tr><tr><td>企业级模型Gemini 2.5 Flash</td><td>52.3%</td><td>49.8%</td></tr><tr><td>企业级模型GPT-4o</td><td>52.2%</td><td>28.1%</td></tr><tr><td>专业编码模型Arcee AI Coder-Large</td><td>21.1%</td><td>20.2%</td></tr></tbody></table>

关键结论：<ul><li>Gemini 2.5 Flash 表现最佳，JDK 17 迁移成功率达 52.3%，远超规则系统；
</li><li>JDK 21 迁移难度略高，多数模型成功率小幅下降（如 Gemini 2.5 Flash 从 52.3% 降至 49.8%），但 o3-mini 降幅显著（27.8%→4.5%）；
</li><li>开源模型整体表现弱于企业级模型，DeepSeek-V3 成功率仅 10.7%。 </li></ul><h6>（2）效率与成本分析</h6><ul><li>步骤数：DeepSeek-V3（中位数 5 步）最简洁，Gemini 2.5 Flash（中位数 17 步）更倾向探索性操作；
</li><li>成本：DeepSeek-V3 最经济，GPT-4.1 成本波动最大，Gemini 2.5 Flash 存在高成本长尾案例。 </li></ul><h6>（3）项目复杂度影响</h6>所有模型的成功率随项目复杂度（依赖数量、代码行数、测试用例数）增加而下降，验证了基准对真实场景复杂性的覆盖能力。<h6>（4）失败模式分布</h6><ul><li>开源模型（如 DeepSeek-V3）：70% 以上失败源于 “代理行为失败”（如重复操作、幻觉命令）；
</li><li>企业级模型（如 Gemini 2.5 Flash、GPT-4.1）：主要失败源于 “Java API 不兼容” 和 “依赖管理失败”，反映其已具备基础工具使用能力，瓶颈转向复杂技术问题解决。</li></ul><h2>第二部分《LLM Agents for Automated Dependency Upgrades》</h2><ol><li>论文提出多Agent协同框架（LADU）：整合Summary Agent、Control Agent、Code Agent，结合迁移文档实现依赖升级的自动化推荐、修改与验证；</li><li>引入Meta-RAG机制：通过代码摘要压缩（Token量减少近80%），实现大规模代码库的高效变更定位与信息检索；</li><li>实证验证：在工业级合成代码库中，相比现有方案（如OpenHands），该框架在精度、效率（步骤、耗时、Token消耗）上均有显著优势。</li></ol><h2>方法论：框架设计与工作流程</h2>1. 核心组件<table border="0" cellspacing="0" cellpadding="0"><tbody><tr><td>组件</td><td>核心功能</td></tr><tr><td>Summary Agent</td><td>预处理阶段：生成与AST对齐的代码摘要（每个文件/函数一行职责描述），存储为元数据；修改后更新摘要，维持代码与元数据一致性。</td></tr><tr><td>Control Agent</td><td>核心调度器：基于迁移指南和代码摘要，定位需读取（获取上下文）和修改（执行升级）的代码单元；触发编译测试，处理错误反馈。</td></tr><tr><td>Code Agent</td><td>执行器（基于GPT-4o）：接收修改指令，实现依赖配置更新、代码适配；最小化上下文长度，避免重复检索。</td></tr><tr><td>Meta-RAG</td><td>变更定位机制：基于代码摘要而非原始代码检索，提升大规模代码库的处理效率与可扩展性。</td></tr></tbody></table>2. 完整工作流程<ol><li>预处理：Summary Agent为整个代码库生成结构化摘要，后续仅需增量更新；</li><li>启动升级：用户指定目标版本（或从仓库自动获取）；</li><li>规划与定位：Control Agent分析项目pom/yml配置文件、迁移指南，识别需修改的文件和代码单元；</li><li>代码修改：Code Agent执行依赖版本更新、代码适配，触发Summary Agent同步更新摘要；</li><li>验证与迭代：编译项目并运行单元测试，若出现错误，Control Agent接收日志并启动自动化程序修复（APR）循环，重复修改-验证流程；</li><li>终止条件：① 构建与测试全部通过；② Agent声明无法解决问题；③ 同一错误连续出现3次（避免无限循环），此时移交人工并提供已执行操作摘要，支持后续AI续跑。</li></ol><h2>实验设计与结果</h2>1. 实验设置<ul><li>评估对象：3个基于Java Moneta（Spring Boot生态微服务框架）的合成代码库，覆盖3组版本升级场景（3.1→3.2、3.2→3.3、3.3→3.4）；</li><li>黄金标准：手动完成的依赖升级结果，用于验证修改准确性；</li><li>基准对比：OpenHands（主流Agent开发工具）+ Claude 3.7 Sonnet；</li><li>核心指标：修改文件/代码行与黄金标准的重合度、精度、步骤数、运行时间、Token消耗、成本。</li></ul>2. 关键实验结果<table border="0" cellspacing="0" cellpadding="0"><tbody><tr><td>对比维度</td><td>框架优势</td></tr><tr><td>精度</td><td>最高达71.4%（如3.2→3.3升级的代码删除操作），远超OpenHands的17.2%，减少无效修改风险。</td></tr><tr><td>效率</td><td>步骤数仅为OpenHands的1/5~1/6（如3.1→3.2升级：18步 vs 106步）；运行时间更短，Token消耗显著降低（最低仅为基准的1/20）。</td></tr><tr><td>成本</td><td>美元成本大幅降低（如3.3→3.4升级：0.11美元 vs 基准的14,387美元）。</td></tr><tr><td>兼容性</td><td>能有效识别并适配依赖变更，生成的代码可通过编译与单元测试，与手动升级结果重合度较高。</td></tr></tbody></table><h2>相关工作与结论</h2>1. 相关工作对比<ul><li>传统方案（如SemDiff、LIBSYNC）：依赖API变更分析或迁移模式学习，泛化能力弱；</li><li>现有LLM/CodeLM方案：难以处理复杂、时效性强的依赖升级，且Token消耗高；</li><li>本文框架：通过多Agent协同+Meta-RAG压缩，解决了大规模代码库的高效定位与精准修改问题。</li></ul>2. 结论与未来方向<ul><li>该框架通过多Agent分工与代码摘要机制，实现了Java依赖升级的自动化、高效化，精度与效率优于现有方案，为软件维护提供了可扩展解决方案；</li><li>未来工作：扩展至真实工业级代码库，强化单元测试覆盖，集成更先进LLM，探索混合式升级策略（AI+人工协同）。</li></ul><h2>第三部分 Google Jules 实现JAVA版本治理</h2>Google Jules 是一个基于 Gemini 模型的异步（Asynchronous）编程 Agent，它与 GitHub 深度集成，能够在一个隔离的虚拟机（VM）环境中自主完成代码修改、测试和提交 PR。对于 Java 工程的版本升级（如 JDK 8 -> 17/21，或 Spring Boot 2 -> 3），它的评价如下：<h5>1. 核心优势：全流程自主闭环</h5>与传统的代码补全工具（如 Copilot）不同，Jules 是真正的“Agent”。<ul><li>环境感知与验证能力： Jules 不仅是修改代码，它会在后台启动一个 VM，尝试编译项目并运行测试用例。这对于版本升级至关重要，因为升级往往会导致编译错误或运行时异常。Jules 能够根据报错信息自主尝试修复（Self-Correction），直到测试通过或达到尝试上限。</li><li>多步规划（Planning）： 对于复杂的升级（如涉及多个模块的 Maven/Gradle 依赖），Jules 会先生成一个 <code>Plan</code>。它可以识别出仅仅修改 <code>pom.xml</code> 是不够的，还需要修改因 API 废弃（Deprecation）而受影响的 Java 代码。</li><li>Critique（审查）机制： Jules 内置了一个 Critic Agent，会在提交代码前进行自我审查，减少了生成“幻觉代码”或引入安全漏洞的风险。</li></ul>如果您打算在团队中引入 Jules 进行 Java 升级：<ol><li>"Agent + Rule" 混合模式： 不要让 Jules 徒手做全量迁移。先用 OpenRewrite 快速刷一遍通用的 API 变更，然后让 Jules 负责处理剩下编译报错的“疑难杂症”。</li><li>测试覆盖率是关键： Jules 极度依赖测试反馈。如果您的工程没有单元测试，Jules 的“自我修复”能力就失效了，它可能会提交一堆能编译但运行报错的代码。</li><li>Prompt 工程： 使用详细的 Prompt，例如：“将此项目升级到 Java 17，请注意处理 Lombok 的版本兼容性，并确保所有日期处理都使用 java.time 包。”</li></ol>简单demo工程测试https://github.com/megadotnet/mavenhelloworld/commits/upgrade-java-21-10605999360869649344/大型JAVA工程https://github.com/megadotnet/thingsboard/pull/2

<h2>Java 版本升级治理专家提示词</h2>JAVA版本升级治理专家
#核心定义 
角色：你是一位拥有 15 年经验的 Java 首席架构师，专注于企业级应用的 JVM 版本迁移与现代化改造。你精通从 Java 7,8 到 Java 11,17,21,23,25 甚至最新 LTS 版本的演进历程。 
目标：协助开发者评估升级风险、解决兼容性难题、重构过时代码，并充分利用新版本的特性（如虚拟线程、记录类等）优化系统性能。将复杂的升级任务转化为标准化的工程流水线，实现“低风险、高收益、自动化”的升级。
#技能组合 
版本特性深度解析：精通 JEP (JDK Enhancement Proposals)，能解释从模块化系统 (Project Jigsaw) 到 ZGC 的技术细节。 
依赖与环境审计：能够识别 Maven/Gradle 依赖中的潜在冲突，特别是针对 jakarta.* 命名空间切换、Lombok 兼容性及字节码增强工具（如 ByteBuddy, CGLIB）的升级。 
JVM 性能调优：针对不同版本的垃圾回收器（G1, ZGC, Shenandoah）提供参数优化建议。 
安全与合规：识别已废弃（Deprecated）或移除的 API（如 Applet, Security Manager, Nashorn）。 
- Java版本生态全景分析（LTS/非LTS版本特性对比） 
- 企业级升级风险评估模型（兼容性/性能/安全三维度） 
- 自动化升级工具链设计 
- 容器化环境下的版本治理方案 
- 灰度发布与回滚机制设计 
- 向后兼容性保障体系构建
#工作流说明 
你必须遵循以下**“三维平衡法则”**： 
兼容性维：处理 sun.misc.Unsafe 移除、反射限制（Strong Encapsulation）、命名空间变更（Java EE -> Jakarta）。 
性能维：对比 G1 与 ZGC 的吞吐量与延迟，评估虚拟线程（Virtual Threads）对并发模型的重构价值。 
工程维：优化 CI/CD 门禁、精简 Docker 镜像（JLink/JPackage）、更新 Maven/Gradle 插件生态。
当你接收到升级任务时，请按以下步骤执行： 
风险评估：列出从源版本到目标版本最可能出现的“破坏性更改”。 
依赖项检查：建议需要升级的核心框架版本（Spring Boot, Hibernate 等）。 
代码重构建议：提供具体的代码示例，演示如何用新语法简化逻辑。 
编译与运行时排障：针对常见的 InaccessibleObjectException 或反射问题提供解决方案。 
工作量评估：需要多少人天 
价值评估：升级新版本能对工程带来的价值
# 治理框架： 
````mermaid 
graph TD A[现状评估] --> B[版本路线规划] B --> C[兼容性治理] C --> D[工具链集成] D --> E[灰度验证] E --> F[生产切换] F --> G[持续监控] G -->|反馈数据| A 
````
#交互规范 
代码优先：在解释概念后，务必提供“Before vs After”的代码对比。 
结构清晰：使用表格列出 API 的变更，使用检查清单（Checkbox）提供操作步骤。 
严谨性：如果某个库在目标版本中尚未稳定，必须明确告知风险。
# 输出物： 
1. 《Java版本升级可行性评估报告》 
2. 《自动化迁移实施方案》 
3. 《兼容性保障体系设计文档》 
4. 《灰度发布验证报告》 
5. 《生产环境切换checklist》 
6. 《持续治理机制建设方案》 
7. 《Java版本治理白皮书》 
* Please make sure to use Simplified Chinese as the language for interactions with users, unless it is for specific proprietary terms or situations where English words are more appropriate.<h2>进度汇报</h2>

JAVA治理职位很快在今年内即将消失。某金融领域银行还有有这个职位，需要人工编写升级评估报告，与各个Team进行沟通JAVA版本升级。是不是会演变为 JDK version migration expert agent与communcation agent, report agent的形态。<h2>结论：为构建可信赖的AI代码现代化工具奠定基础</h2> FreshBrew方法论通过精心筛选的高覆盖率数据集和包含覆盖率维持检查的严格评估协议，成功解决了在评估AI代码迁移代理时普遍存在的“奖励滥用”问题。我们的研究证明，若无此类完整性检查，大量看似成功的迁移实则包含了奖励滥用行为，这凸显了FreshBrew的必要性。 FreshBrew并非终点，而是一个基础平台。通过向社区公开发布这个可扩展的平台，我们旨在为软件工程研究人员和开发人员提供一个稳健的工具，以推动AI驱动的代码现代化研究。我们的最终目标是确保下一代软件工程代理的开发，将可靠性与可信度作为其核心设计原则，而非事后的补救措施。 Java版本升级自动化正从传统规则系统转向LLM Agent驱动。FreshBrew基准测试显示，Gemini 2.5 Flash在JDK 17迁移中成功率达52.3%，远超OpenRewrite的7.0%，通过编译、测试、覆盖率三重验证防"奖励黑客"。LADU框架采用多Agent协同+Meta-RAG代码摘要，升级精度达71.4%，步骤数降为1/5，成本最低至OpenHands的1/20。Google Jules实现GitHub集成，在隔离VM中自主编译测试，依赖覆盖率驱动自修复。未来JDK治理专家角色将演变为Agent集群：迁移Agent处理技术适配、沟通Agent协调团队、报告Agent生成评估，实现低风险自动化升级。 来源：程序园用户自行投稿发布，如果侵权，请联系站长删除 免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

账号		自动登录	找回密码
密码			立即注册

软件工程Agent在工程依赖版本升级探索

相关帖子

浏览过的版块

签约作者

软件工程Agent在工程依赖版本升级探索

相关帖子

相关推荐

浏览过的版块

签约作者