如果你的團隊正在把一個舊 Java 服務從 Jakarta EE 搬到 Spring 或 Quarkus，最麻煩的通常不是讓 AI 改出一堆檔案。最會拖慢排程的是：它編譯過了，容器卻跑不起來；容器跑起來了，交易流程、JPA 查詢或訊息佇列行為悄悄改變，QA 到後面才發現要回頭重測。
IBM Research 在 2026 年 6 月 30 日透過 Hugging Face 發布 ScarfBench 介紹，把這個風險講得很直接：企業 Java 框架遷移不能只看 coding agent 產出的 diff，也不能相信 agent 自己說「完成」。要先有可重跑的驗收框架，至少同時看 build、deploy 與行為測試，再決定哪些任務能交給 AI 先做草稿，哪些必須由資深工程師拆解與審查。
對平台團隊、架構師和工程主管來說，ScarfBench 的實用價值不在模型排行榜，而在提醒你把「AI 能不能搬 Java 框架」換成一個可驗收的問題：哪些服務、哪些層、哪些測試能證明行為沒有跑掉？
ScarfBench 到底測什麼？
ScarfBench 全名是 Self-Contained Application Refactoring Benchmark。IBM Research 的資料集頁說，它用來評估 AI agents 在 Spring、Jakarta EE 與 Quarkus 之間遷移 enterprise Java 應用時，能不能保留功能、框架慣用寫法與架構完整性。
這和一般「修 bug」或「補功能」benchmark 不同。框架遷移常常牽涉 dependency injection、persistence、query、build 設定、runtime descriptor、container 啟動方式與外部介面。agent 不是把 annotation 換掉就結束；它必須理解來源框架和目標框架的語意差異，還要讓應用在新的 runtime 中真的跑起來。
arXiv 論文摘要列出更完整的規模：ScarfBench 建在 34 個應用上，其中包含 29 個 focused single-layer 應用與 5 個 whole application；這些應用形成 102 個框架變體、約 151K 行程式與測試、1,946 個 source/test files，以及 204 個 directed refactoring tasks。每一題都給 agent 一個可運作的來源應用與目標框架，要求它產生保留行為的目標實作。
這種題型比較接近企業真實痛點。團隊要確認 agent 能不能在一個會被測試、會被部署、會被使用者流程驗證的環境裡，把「看起來會動」變成「真的能交付」。
公開結果提醒：編譯通過離交付還很遠
IBM Research 在 Hugging Face 文章中強調，ScarfBench 要求候選結果 build、deploy，並通過行為測試，而非只比對 reference implementation。這點很重要，因為 Java 框架遷移常常會出現三段式落差：程式碼能編譯，container 不能正常啟動；部署成功，行為測試失敗；行為測試過一部分，但邊界條件與資料層語意已經變形。
ScarfBench 是 benchmark/harness，不是新模型發表。參數規模、模型授權與開源狀態不應主導這次決策；決策主軸應放在任務是否能被重跑、部署是否能被驗證，以及行為是否保留。
論文摘要裡的數字也很保守。研究團隊評估五個 state-of-the-art coding agents，最強者在 focused-layer migrations 的 aggregate test pass 是 15.3%，whole applications 是 12.2%；在 204 個任務中，只有一題達到完整行為等價。Hugging Face 文章另以行為成功率提醒：即使 current agents 在傳統 coding benchmark 表現很好，面對框架遷移仍會明顯卡住。
這些數字不應被解讀成「AI agent 不能用」。更合理的讀法是：agent 可以幫忙產生候選修改、整理依賴與暴露路徑，但它不能取代獨立驗收。尤其在 Jakarta EE 目標遷移、跨 persistence 或 messaging 的服務裡，agent 的自評更不能當成完成證明。
企業先建三層驗收，再談買工具
如果你正在評估 coding agent 能否接手 Java 現代化，第一步請先把自家遷移拆成可測任務，再向供應商追問 ScarfBench 或相近 benchmark 的結果。公開 benchmark 可以提醒你該測哪些環節，但正式決策仍要靠自己的 repo、資料模型、測試成熟度與上線節奏。
| 驗收層 | 要回答的問題 | 企業先做的動作 |
|---|---|---|
| Build | 依賴、plugin、annotation processor、generated code 能否在目標框架下完整編譯？ | 固定 Java / Maven / Gradle 版本，保存 build log，禁止 agent 只改到「本機剛好可過」。 |
| Deploy | 應用能否在 container 或目標 runtime 啟動，健康檢查是否穩定？ | 把 Dockerfile、runtime descriptor、環境變數與 health check 納入任務，不讓 agent 只處理 src 目錄。 |
| Behavior | API、資料層、交易邊界、message flow 是否和來源服務一致？ | 先補 characterization tests，對高風險流程加上輸入輸出範例與資料庫狀態檢查。 |
| Review | agent 是否知道自己失敗在哪裡？人類能否重跑與抽查？ | 保存 trace、命令、錯誤、重試與人工修正，避免只收一份漂亮 summary。 |
表格裡最容易被低估的是 behavior。很多團隊已經有 compile 與單元測試，卻沒有足夠的 characterization tests 來描述舊系統實際行為。這會讓 agent 產生一種假象：它把程式改得像目標框架，測試也沒有紅，但實際的付款、庫存、通知或報表行為沒有被測到。
先用 20 題內部任務試跑
比較安全的起點，是挑 20 到 50 個內部遷移任務做小型 harness。任務不要只選最簡單的 controller，也要放入 persistence、transaction、background job、message listener、batch job 或 framework descriptor。每題都要有來源版本、目標框架、可重跑測試、成功標準與人工抽查紀錄。
第一次試跑的目標是找出分工邊界，暫時不要追求全自動。agent 可能很適合改 boilerplate、產生初版設定、整理 import、替換簡單 API；但遇到 transaction semantic、lazy loading、JMS listener、security filter 或 framework lifecycle 時，工程師要預期它會回頭改很多層，甚至把錯誤藏在「看似完成」的 summary 裡。
內部報告也不要只列成功率。請同步記錄每題花了多少時間、重試幾次、失敗在哪一層、人工修正量、是否需要重寫測試，以及 agent 自評和獨立驗收是否一致。ScarfBench 文章提到 agent self-assessment 不能可靠判斷完成，這點在企業場景更要提早驗證。
如果你已經有 agent 評測流程，可以把 ScarfBench 當成 Java 遷移的專門版本；若還沒有，可以先讀 Agent 評測不能只看分數 和 企業 AI coding agent 評估指南，把 trace、權限、成本與失敗分類納入同一份驗收紀錄。
採購或試用時，該怎麼改問法？
看到供應商宣稱「能自動完成 framework migration」時，請不要只問模型名稱。更好的問法是：能不能在我們的一小組真實服務上跑 build、deploy、behavior tests？能不能輸出可重跑的命令與 trace？如果 agent 判定成功，但 behavior test 失敗，系統會怎麼回報？人工修正後，是否能把錯誤案例留下來，下一輪再測？
這些問題會把採購對話從 demo 轉到工程風險。對 CIO 或工程主管來說，採購重點應是一條能縮短遷移摸索時間、同時保留測試、審查與回滾的交付路徑。agent 如果只能在範例專案裡表現好，卻不能接到你的 build system、container runtime 和測試資料，價值就會停在輔助改稿。
ScarfBench 也提醒團隊不要把低分當成失望結論。公開結果越保守，越能幫你設定試用範圍：先讓 agent 處理低風險層，讓工程師保留架構判斷；把每次成功和失敗都轉成測試資產；等 internal harness 穩定後，再擴大到更完整的服務遷移。
對 Mason 讀者的採用建議
如果你的 Java 現代化還停在盤點階段，先不要急著讓 agent 改整個服務。把三件事補起來：一組代表性遷移任務、可重跑的 build/deploy/behavior 驗收、以及人工抽查 trace 的習慣。這會比直接追最新 coding agent 更快降低風險。
如果已經有成熟測試和容器化流程，可以安排一週試跑：選少量服務或模組，讓 agent 產生候選修改，但不直接合併；由 CI 跑三層驗收，再請資深工程師審失敗 trace。請看失敗是否可理解、修正是否可累積、人工 review 時間是否真的下降，不要只看它一次成功幾題。
如果測試覆蓋不足，ScarfBench 的訊息更明確：先補 characterization tests 和部署驗證。沒有這些護欄，agent 只會把遷移風險包成順眼的 diff。等你能清楚說出「這個服務怎樣才算行為沒變」，AI 才有機會成為 Java 框架遷移的加速器，避免變成新的返工來源。
若還要把這套驗收接進模型選型與採購節奏，可以延伸看 LLM 評估指南 與 AI Coding Agent 成本與 ROI 評估表：前者處理公開分數和自家任務怎麼併用，後者把人工審查、重試與返工成本納入同一張表。