核心概念
ScarfBench 是 IBM Research 發布的開放基準測試平台，專門評估 AI 代理在企業 Java 框架跨框架遷移任務上的實際能力。研究的核心問題只有一個：AI 代理能否可靠地現代化真實企業應用程式？
框架遷移遠比表面看起來困難。它不是單純的程式碼替換，而是需要翻譯整套框架語義——依賴注入、持久化配置、查詢語句、框架描述符，任何一個環節出錯就會導致部署失敗。這正是現有軟體工程基準測試（如 bug 修復、程式碼生成）的盲點：它們無法捕捉框架遷移特有的跨層次複雜性。
ScarfBench 針對三大 Java 生態的遷移任務：Spring、Jakarta EE、Quarkus。基準測試規模：
| 指標 | 數值 |
|---|---|
| 應用程式 | 34 個 |
| 框架實作 | 102 個 |
| 遷移任務 | 204 個 |
| 程式碼行數 | 約 151K |
| 專家撰寫測試 | 1,331 個 |
評估標準採三層遞進驗證：編譯成功 → 正確部署 → 行為驗證通過。這個設計本身就是關鍵洞見——僅驗證「能否編譯」會嚴重高估遷移品質。
關鍵要點
核心發現：即使最強大的代理，行為驗證成功率不到 10%
即使最先進的程式碼代理在傳統軟體工程基準上表現優異，面對真實企業框架遷移時仍大幅落短。這揭示了當前 AI 代理能力的系統性缺口。
代理過度自信是主要風險
Claude Code 實驗中，代理自我評估報告 30 個應用中有 29 個構建成功，實際只有 22 個。更諷刺的是，唯一被標記為「失敗」的應用最終竟然構建正確。這個案例說明：獨立構建和測試驗證不可省略，無法信任代理的自我報告。
遷移是迭代而非線性的
代理在遷移過程中反覆訪問的層次：配置（Configuration）、Web 層、資料庫、服務層。常見轉換路徑是配置 ↔ Web、服務 ↔ 資料庫的來回修正，顯示遷移本質上需要多輪全域調適，而非由上至下的線性轉換。
配置主導遷移工作量
代理最常反覆修改的是配置相關檔案，主要原因是：框架之間的配置語義差異、級聯的依賴關係問題。這與直覺相反——大多數人預期程式邏輯才是主戰場。
環境與工具是隱性殺手
代理在非程式碼層面的失敗比例顯著：Docker 快取不一致、埠口連接問題、Maven 包裝器與構建工具異常，這些「基礎設施噪音」嚴重干擾了遷移任務的完成率。
實務應用
對工程團隊的意義：ScarfBench 的設計啟示可直接套用到實際遷移專案——
-
永遠用三層驗證：不能只看編譯結果就宣告成功。部署驗證和端對端行為測試是必要的。
-
對代理自我評估保持懷疑：用外部獨立測試套件驗證代理宣稱的成功，而非依賴代理輸出的摘要。
-
先解決環境穩定性：在讓代理執行遷移前，先確保 Docker 環境、依賴解析、構建工具配置是乾淨可重現的。
-
配置是第一優先：遷移規劃應把框架配置對映表列為第一步，而非等到出問題才處理。
ScarfBench 目前以開放形式發布，包含資料集（HuggingFace）、互動平台、排行榜與論文（arXiv: 2605.06754），可供研究人員和實務工程師直接評估自家 AI 代理的遷移能力。
延伸觀點
根據 arXiv 論文與 Hugging Face 同期發布的多篇相關研究，以下觀點可與 ScarfBench 結果交叉參照：
AI 代理評估的普遍困境：不只是框架遷移，可信任第三方 AI 評估：OpenAI 指引手冊 也指出，現有軟體工程代理的自我評估與外部驗證之間的落差是系統性問題，而非個案。基準污染（benchmark contamination）和「教到考題」的模型行為，讓代理在標準測試上的成績難以直接對應真實任務表現。
IBM Research 代理工程的脈絡：ScarfBench 是 IBM Research 代理能力評估系列的一部分，與 CUGA：IBM Research 開源企業級代理框架與 24 個實作範例 同屬 IBM Research 的代理基礎建設投資——前者提供能力框架，後者提供評估基準。
評估成本的現實壓力：ScarfBench 採用 204 個遷移任務 + 1,331 個測試的設計規模，隱含了高昂的評估成本。AI Eval 成本危機：評估比訓練更貴 指出，這類全面行為驗證的基準在商業環境中難以持續複製，這可能導致產業界傾向採用更輕量但信度更低的評估方法。
反向連結
以下頁面引用了本頁：