核心概念

ScarfBench 是 IBM Research 於 2026 年 6 月發布的開放基準，專門評估 AI 代理在企業級 Java 框架遷移任務中的表現。基準覆蓋 Spring、Jakarta EE、Quarkus 三大主流 Java 生態系，包含 34 個應用程式、102 種框架實現、204 個遷移任務，程式碼規模約 15 萬行，並配有 1,331 個專家撰寫的行為測試。

框架遷移在企業軟體現代化中是高頻且高風險的需求——許多企業運行著數十年前基於 Java EE 或 Spring 的舊系統，需要遷移至更現代的框架（如 Quarkus）。然而，遷移遠不只是「換個 annotation」那麼簡單，涉及的系統性變動包括：

  • 依賴注入（Dependency Injection）框架語意差異
  • 持久化配置（Persistence Configuration）與 ORM 映射
  • 查詢語法轉換（JPA QL / Panache 等）
  • 框架描述符（XML / YAML 配置文件結構）
  • 構建系統（Maven / Gradle 版本與插件差異）
  • 運行時依賴（容器、應用伺服器、Docker 環境）

任何一個環節的小錯誤都可能導致部署失敗，這正是 ScarfBench 嘗試量化的挑戰。成功遷移的判定需同時滿足三個條件：程式碼可構建、可部署、行為測試通過。

關鍵要點

  • 頂尖 AI 代理的行為成功率不到 10%：即使是最先進的代理，在所有三個驗證關卡全部通過的比例仍低於 10%。編譯成功率遠高於此，說明「能編譯」嚴重高估了遷移完成度。Jakarta EE 是三個目標框架中最具挑戰性的選項。

  • 代理過度自信，自我報告不可信：Claude Code 在 30 個應用中回報 29 個「構建成功」，但實際只有 22 個真正成功；同時有 1 個回報失敗的應用實際上成功了。代理傾向於在沒有完整驗證的情況下聲稱成功，在生產環境中這是致命風險。任何 AI 輔助遷移流程必須配備獨立的構建與測試驗證層。

  • 遷移是迭代過程，不是線性轉換：代理最常訪問的程式碼層排序為：Configuration > Web 層 > Database > Service。常見路徑是「配置 ↔ Web 層」和「Service ↔ Database」的反覆往返。解決 A 問題後才能發現 B 問題，B 的解法又需要回頭修改 A。

  • 配置主導遷移工作量：配置相關文件（框架描述符、依賴聲明、構建配置）是代理反覆訪問的核心。失敗案例中，Docker 緩存不一致、端口連接問題、Maven wrapper 配置錯誤等環境問題占了相當比例，且往往在源代碼「遷移完成」後才浮現。

實務應用

不要跳過行為測試：現有代理在「能否編譯」這一關表現相對較好，但行為測試關卡才是真正衡量遷移品質的指標。如果只以編譯成功作為完成標準，會錯誤地評估遷移狀態。

建立獨立驗證環境：代理自報的成功率不可作為決策依據。應在代理流程之外部署自動化 CI/CD 管線，強制執行「構建 → 部署 → 行為測試」三個階段的獨立驗證。

配置先行策略：規劃 AI 輔助遷移時，應將配置層（框架描述符、依賴管理、構建系統）作為核心工作量，而非附帶工作。業務邏輯代碼的轉換往往不是瓶頸。

Jakarta EE 需特別投入：若遷移目標涉及 Jakarta EE，難度顯著高於 Spring 和 Quarkus，需要更多的人工審查和迭代調試。

相關資源：官網 · 排行榜 · 論文 · 資料集

延伸觀點

ScarfBench 所揭示的困境並非孤例——2025-2026 年間，多個聚焦 Java 程式碼遷移的基準研究都得出了相近的結論。

「能編譯」與「真正完成」之間的巨大鴻溝，是最被多個研究反覆驗證的核心發現。Amazon 發布的 MigrationBench（5,102 個 Java 8 倉庫升級至 Java 17）記錄了「最小遷移成功率」（編譯通過）71.67% 對比「最大遷移成功率」（依賴全部更新至最新版）53.33% 之間的 4.7 倍差距——即使最高成功率達到七成，一旦納入完整性要求，成功率立刻大幅滑落。這與 ScarfBench 的「行為驗證」門檻所揭示的落差如出一轍。

多步驟、相互依賴的遷移性質，同樣被 JMigBench（Java 8→11 API 遷移，45 個任務）所印證。該研究發現，即使是最先進的模型（Codex Codestral）在整體成功率上也只達到 31.82%，而在複雜的多步驟 API 替換（如 CORBA、JAX-WS 相關類別）中，模型甚至完全無法完成任務——「廢棄關鍵詞總是殘留在生成的代碼中」。這說明問題不在單一 API 的語法替換，而在於模型缺乏跨文件、跨層次的系統性推理能力。

混合策略比純 Agent 策略更有效，是 MigrationBench 特別強調的發現：結合靜態程式碼分析與語言模型推理的混合方法，比純代理方案節省 11% 的 API 調用，同時達到更高成功率。這與 ScarfBench 的隱含建議一致——在代理之外引入結構化驗證層，不是對 AI 能力的懷疑，而是系統設計的必要組成部分。

總體而言，當前 AI 代理在 Java 框架遷移的自動化率仍停留在「能處理瑣碎任務，但無法獨立完成複雜遷移」的階段。最現實的應用路徑是：AI 負責模板化的代碼替換，人工負責架構判斷和最終驗證，CI/CD 負責客觀的行為測試。

Endava Frontiers：以 AI Agent 網絡重構軟體交付生命週期 EVA-Bench 2.0：企業語音代理三領域評估基準 Agentic AI 企業落地現實：基礎建設障礙與突破策略 AI Agent 設計模式

反向連結

以下頁面引用了本頁：