背景與動機

   現代軟件項目廣泛依賴開源庫以避免重複開發，但庫版本更新常引入破壞性變更，導致代碼兼容性問題。手動適配這些更新需消耗大量開發者時間，且大型代碼庫中開發者易忽視更新警告或鎖定舊版本，長期阻礙功能迭代、性能優化與安全修復。現有自動化方案未被廣泛採用，而 LLM 在代碼生成、程序修復等領域已展現潛力，因此本文提出一種基於 LLM Agents 的框架，用於自動化完成依賴升級並保障代碼兼容性。

1. 代碼遷移的重要性與挑戰

Java 項目現代化（如版本升級）能帶來安全提升、性能優化、架構改進等長期收益，但遷移過程極具挑戰性：

• Java SE 版本迭代會引入二進制、源碼和行為層面的不兼容性；
• 依賴庫演化頻繁，約 1/3 的 Maven 構件發佈包含破壞性變更，且 Java 版本與依賴升級相互綁定（如 Spring Boot 3.0 需基於 JDK 17，而部分舊依賴不支持新 Java 版本）。

2. 現有解決方案的不足

• 傳統規則系統（如 OpenRewrite、jSparrow）：依賴人工編寫的 AST 轉換規則，泛化能力弱，難以應對新型 API 或快速演化的語言特性；
• AI 驅動代理：LLM-based 代理為遷移提供了新可能，但缺乏系統化評估 —— 現有基準要麼未針對代理設計，要麼無法防範 “獎勵黑客”（如代理刪除失敗測試而非修復問題以通過評估），且缺乏高覆蓋率測試集驗證語義一致性。

3. 核心研究缺口

現有基準（如 MigrationBench）未解決：① 缺乏高測試覆蓋率數據集，無法驗證語義保留；② 未防範獎勵黑客；③ 未評估 AI 代理的工具使用能力（如文件操作、構建命令執行）。

因此，提出 FreshBrew 基準，填補 AI 代理在項目級 Java 遷移任務中的評估空白。

第一部分 FreshBrew 基準設計

FreshBrew 的核心目標是提供可靠、防獎勵黑客、貼近真實場景的 AI 代理評估方案，包含兩大核心組件：

1. 高覆蓋率數據集構建

通過自動化多階段篩選流程，從 GitHub 篩選出 228 個符合要求的 Maven 項目，篩選標準如下：

• 初始池：30,000 個高星 Maven Java 倉庫；
• 關鍵篩選步驟：① 能在 JDK 8 構建並通過所有測試；② 在 JDK 17/21 構建失敗（確保遷移必要性）；③ 測試覆蓋率≥50%（支持語義一致性驗證）；④ 採用寬鬆開源許可證。
• 數據集特徵：中位數星數 194，包含 Mockito、SLF4J 等常見依賴，項目提交時間集中於 2018 年後，貼近現代開發場景。

2. 魯棒評估協議

成功遷移需滿足三重條件，杜絕獎勵黑客：

1. 編譯通過（mvn compile成功）；
2. 所有原始測試通過（mvn verify無修改）；
3. 測試覆蓋率保留（相對於 JDK 8 基線下降不超過 5 個百分點）。

• 補充指標：效率（代理交互步驟數）、成本（基於 LLM Token 定價計算）。

三、實驗設計與結果

1. 實驗配置

• 評估任務：將 228 個項目從 JDK 8 遷移至 JDK 17 和 JDK 21；
• 測試對象：7 個主流 LLM（含開源模型如 DeepSeek-V3、企業級模型如 Gemini 2.5 Flash、專業編碼模型如 Arcee AI Coder-Large）+ 規則系統基準 OpenRewrite；
• AI 代理環境：基於 smolagents 框架實現 CodeAct 代理，支持文件操作、Maven 構建、網頁搜索（DuckDuckGo）等工具，最大交互步驟 100，採樣温度 0.2；
• 失敗模式分析：採用 LLM-as-Judge（Gemini 2.5 Pro），將失敗分類為 4 類：Java API 不兼容、依賴管理失敗、構建配置錯誤、代理行為失敗。

2. 核心實驗結果

（1）遷移成功率

關鍵結論：

• Gemini 2.5 Flash 表現最佳，JDK 17 遷移成功率達 52.3%，遠超規則系統；
• JDK 21 遷移難度略高，多數模型成功率小幅下降（如 Gemini 2.5 Flash 從 52.3% 降至 49.8%），但 o3-mini 降幅顯著（27.8%→4.5%）；
• 開源模型整體表現弱於企業級模型，DeepSeek-V3 成功率僅 10.7%。

（2）效率與成本分析

• 步驟數：DeepSeek-V3（中位數 5 步）最簡潔，Gemini 2.5 Flash（中位數 17 步）更傾向探索性操作；
• 成本：DeepSeek-V3 最經濟，GPT-4.1 成本波動最大，Gemini 2.5 Flash 存在高成本長尾案例。

（3）項目複雜度影響

所有模型的成功率隨項目複雜度（依賴數量、代碼行數、測試用例數）增加而下降，驗證了基準對真實場景複雜性的覆蓋能力。

（4）失敗模式分佈

• 開源模型（如 DeepSeek-V3）：70% 以上失敗源於 “代理行為失敗”（如重複操作、幻覺命令）；
• 企業級模型（如 Gemini 2.5 Flash、GPT-4.1）：主要失敗源於 “Java API 不兼容” 和 “依賴管理失敗”，反映其已具備基礎工具使用能力，瓶頸轉向複雜技術問題解決。

第二部分《LLM Agents for Automated Dependency Upgrades》

1. 論文提出多Agent協同框架（LADU）：整合Summary Agent、Control Agent、Code Agent，結合遷移文檔實現依賴升級的自動化推薦、修改與驗證；
2. 引入Meta-RAG機制：通過代碼摘要壓縮（Token量減少近80%），實現大規模代碼庫的高效變更定位與信息檢索；
3. 實證驗證：在工業級合成代碼庫中，相比現有方案（如OpenHands），該框架在精度、效率（步驟、耗時、Token消耗）上均有顯著優勢。

方法論：框架設計與工作流程

1. 核心組件

2. 完整工作流程

1. 預處理：Summary Agent為整個代碼庫生成結構化摘要，後續僅需增量更新；
2. 啓動升級：用户指定目標版本（或從倉庫自動獲取）；
3. 規劃與定位：Control Agent分析項目pom/yml配置文件、遷移指南，識別需修改的文件和代碼單元；
4. 代碼修改：Code Agent執行依賴版本更新、代碼適配，觸發Summary Agent同步更新摘要；
5. 驗證與迭代：編譯項目並運行單元測試，若出現錯誤，Control Agent接收日誌並啓動自動化程序修復（APR）循環，重複修改-驗證流程；
6. 終止條件：① 構建與測試全部通過；② Agent聲明無法解決問題；③ 同一錯誤連續出現3次（避免無限循環），此時移交人工並提供已執行操作摘要，支持後續AI續跑。

實驗設計與結果

1. 實驗設置

• 評估對象：3個基於Java Moneta（Spring Boot生態微服務框架）的合成代碼庫，覆蓋3組版本升級場景（3.1→3.2、3.2→3.3、3.3→3.4）；
• 黃金標準：手動完成的依賴升級結果，用於驗證修改準確性；
• 基準對比：OpenHands（主流Agent開發工具）+ Claude 3.7 Sonnet；
• 核心指標：修改文件/代碼行與黃金標準的重合度、精度、步驟數、運行時間、Token消耗、成本。

2. 關鍵實驗結果

相關工作與結論

1. 相關工作對比

• 傳統方案（如SemDiff、LIBSYNC）：依賴API變更分析或遷移模式學習，泛化能力弱；
• 現有LLM/CodeLM方案：難以處理複雜、時效性強的依賴升級，且Token消耗高；
• 本文框架：通過多Agent協同+Meta-RAG壓縮，解決了大規模代碼庫的高效定位與精準修改問題。

2. 結論與未來方向

• 該框架通過多Agent分工與代碼摘要機制，實現了Java依賴升級的自動化、高效化，精度與效率優於現有方案，為軟件維護提供了可擴展解決方案；
• 未來工作：擴展至真實工業級代碼庫，強化單元測試覆蓋，集成更先進LLM，探索混合式升級策略（AI+人工協同）。

第三部分 Google Jules 實現JAVA版本治理

Google Jules 是一個基於 Gemini 模型的異步（Asynchronous）編程 Agent，它與 GitHub 深度集成，能夠在一個隔離的虛擬機（VM）環境中自主完成代碼修改、測試和提交 PR。對於 Java 工程的版本升級（如 JDK 8 -> 17/21，或 Spring Boot 2 -> 3），它的評價如下：

1. 核心優勢：全流程自主閉環

與傳統的代碼補全工具（如 Copilot）不同，Jules 是真正的“Agent”。

• 環境感知與驗證能力： Jules 不僅是修改代碼，它會在後台啓動一個 VM，嘗試編譯項目並運行測試用例。這對於版本升級至關重要，因為升級往往會導致編譯錯誤或運行時異常。Jules 能夠根據報錯信息自主嘗試修復（Self-Correction），直到測試通過或達到嘗試上限。

• 多步規劃（Planning）： 對於複雜的升級（如涉及多個模塊的 Maven/Gradle 依賴），Jules 會先生成一個 Plan。它可以識別出僅僅修改 pom.xml 是不夠的，還需要修改因 API 廢棄（Deprecation）而受影響的 Java 代碼。

• Critique（審查）機制： Jules 內置了一個 Critic Agent，會在提交代碼前進行自我審查，減少了生成“幻覺代碼”或引入安全漏洞的風險。

如果您打算在團隊中引入 Jules 進行 Java 升級：

1. "Agent + Rule" 混合模式： 不要讓 Jules 徒手做全量遷移。先用 OpenRewrite 快速刷一遍通用的 API 變更，然後讓 Jules 負責處理剩下編譯報錯的“疑難雜症”。

2. 測試覆蓋率是關鍵： Jules 極度依賴測試反饋。如果您的工程沒有單元測試，Jules 的“自我修復”能力就失效了，它可能會提交一堆能編譯但運行報錯的代碼。

3. Prompt 工程： 使用詳細的 Prompt，例如：“將此項目升級到 Java 17，請注意處理 Lombok 的版本兼容性，並確保所有日期處理都使用 java.time 包。”

簡單demo工程測試

https://github.com/megadotnet/mavenhelloworld/commits/upgrade-java-21-10605999360869649344/

大型JAVA工程

https://github.com/megadotnet/thingsboard/pull/2

Java 版本升級治理專家提示詞

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.

進度彙報

JAVA治理職位 很快在今年內即將消失。 某金融領域銀行還有有這個職位，需要人工編寫升級評估報告，與各個Team進行溝通JAVA版本升級。是不是會演變為 JDK version migration expert agent與communcation agent, report agent的形態。

結論：為構建可信賴的AI代碼現代化工具奠定基礎

   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生成評估，實現低風險自動化升級。