ScarfBench:Agent 能搬得動企業級 Java 嗎?

TL;DR

• 應用活得比框架久:企業 Java 應用累積了數十年的 institutional knowledge——商業規則、資料語意、workflow、整合。遷移必須換掉底層技術棧,同時保住應用行為,而後者才是難的部分。
• 難在框架把行為藏起來了:Java 框架用 proxy、reflection、interceptor 把 runtime 行為包在 API 後面,程式碼本身根本沒有記錄這些。所以 Spring 與 Jakarta 之間不存在一對一對應;遷移後看起來 build 得過、跑得動,卻可能藏著只在部署時才浮現的 silent failure。
• ScarfBench = Self-Contained Application Refactoring Benchmark,由 IBM 的領域專家手工把每個應用跨 Spring / Quarkus / Jakarta 轉寫,並為每個應用手寫行為測試——從 curl 煙霧測試到 Playwright 的瀏覽器點擊驗證。
• 最關鍵的結果:agent 讓程式編譯與部署成功的能力很強,但遷移後只有 2–14% 行為完全一致。compilation 是個 weak signal,它給了「agent 很會遷移」的假象。
• 遷移方向是不對稱的:Spring→Quarkus 與 Jakarta→Spring 是完全不同的難題;資料強烈顯示有些框架特別難遷入,有些特別難遷出。

重點整理

為什麼企業 Java 遷移值得做,也值得測(約 02:36–02:37)

Rahul Krishna 是 IBM Research 的資深研究科學家。(這場開頭投影片出了問題,他中途改用自己的筆電接續,約 02:35–02:36 有一段空白。)

用 Java 寫的企業應用至今仍然關鍵。這些 legacy 應用當初寫在某個框架上,而應用本身往往活得比框架還久。現代化之所以重要,是因為新框架帶來受支援的 runtime、更好的安全性、更好的部署形態等等。

但真正的關鍵洞見在於:部署中的應用裡沉澱了數十年的 institutional knowledge——商業規則、資料語意、workflow、整合關係。因此:遷移必須替換底層技術棧,同時保住應用的行為。

為什麼這件事很難:行為不在程式碼裡(約 02:37)

Legacy Java 應用所依賴的框架,用 API 把 runtime 行為藏了起來——各種 proxy、reflection、interceptor。程式碼本身並沒有捕捉到這些行為,是框架自己在處理。

後果是:Spring 寫的應用與 Jakarta 寫的應用之間,並不存在一對一的等價關係。 當你遷移這些應用,它看起來 build 得正確、跑得正確,但可能存在只有在部署時才會顯現的 silent failure。

典型企業 Java 應用的結構(約 02:38–02:39)

大型應用通常分層,每層處理一個特定關注點:presentation layer(透過瀏覽器或手機呈現)一路往下到 data access layer(資料庫讀寫),再加上把它們串起來的 cross-cutting concern(組態、安全性等)。

難點在於:大量行為與商業邏輯藏在框架與其 API 之後,而每個框架都有自己的怪癖——dependency injection、annotation 等等,決定了商業邏輯以什麼形式被嵌入。你去程式碼裡翻,可能一個都找不到。

而且雖然這些層在「關注點」上是分開的,部署後的應用是所有層同時互相交互——這才是問題真正棘手的原因。

ScarfBench 的設計(約 02:39–02:40)

ScarfBench = Self-Contained Application Refactoring Benchmark,目標有兩個:

1. 檢驗 agent 在跨框架遷移與現代化應用上到底有多有效。
2. 在這個過程中透過理解 agent 的 trajectory,建立一份「field manual」——關於如何為一般性的現代化任務打造 agentic 解決方案。

benchmark 分兩組:

• Focused applications:針對單一層的自足應用。
• Whole applications:把各層組合成一個完整的商業 use case。

IBM 的做法是:讓大量領域專家(SME)手工把每個應用跨 Spring、Quarkus、Jakarta 轉寫。表格每一列是一個應用,而一個遷移單位就是「某個應用從某框架到另一框架」。

這樣設計同樣有兩個目的:

1. 每種遷移都有自己的怪癖,而且是不對稱的——Spring→Quarkus 和 Jakarta→Spring 是非常不同的兩件事。
2. 看 agent 處理各個獨立層的能耐——agent 可能很擅長轉換 presentation layer,卻在 integration 或 dependency injection 層上卡住。

Whole application 的部分,同一個應用同時收錄 monolith 與等價的 microservice 部署兩種形態,一樣由 SME 手工跨所有框架轉寫。

規模(講者現場口述):約 38 個應用,展開成 114 個變體,directed transformation 合計約 228 個。(論文公布的數字略有不同,見「待確認」。)

真正的分野:手寫的行為測試(約 02:41–02:42)

他強調 benchmark 的關鍵差異在於 handwritten test cases。在遷移每個應用時,開發者為「這個應用部署後應該表現出的行為」撰寫測試。範圍涵蓋:

• HTTP 檢查:例如一個 curl 煙霧測試,確認目標框架下部署的應用開放了相同的 HTTP / HTTPS 埠——本質是 health check。
• 煙霧測試也涵蓋:messaging 是否正常、資料庫的 update / commit / rollback 行為是否符合預期。
• JSP 頁面層級:確認部署後的應用瀏覽器點擊動作正確、資料正確傳遞。
• Playwright 測試:對於有瀏覽器端點的應用,確保遷移後應用上的使用者操作與來源應用看起來完全一致。

結果:編譯得過,行為卻沒保住(約 02:42–02:43)

他們評估了大量 coding agent(更多結果、失敗模式的分類與 agent 建構建議都在論文裡)。現場的重點結論:

Agent 非常擅長把應用遷移到「能編譯、能部署」的狀態,但在「保住目標應用的行為」上並不好。

具體數字:遷移後只有 2–14% 的案例行為與來源應用完全一致。

他點出的方法論教訓:compilation 本身是一個 weak signal——它給了我們「agent 很會遷移」的錯誤指示,但行為根本沒被保住。

此外,資料流向也強烈顯示:有些框架特別難「遷入」,有些框架特別難「遷出」。agent 從一個應用遷到另一個應用的過程中,存在內在的複雜度與不對稱性。

金句

"The applications themselves often outlive the frameworks."(約 02:36)

企業現代化問題的一句話定義。

"If we go hunting for it in the code, we may not find any of these."(約 02:38)

商業邏輯藏在框架的 annotation 與 dependency injection 裡——這正是純看程式碼的 agent 會失手的地方。

"Compilation itself was a weak signal … that gave us a false indication that the agents are really good at migration, but the behavior was not preserved."(約 02:42)

整場最重要的方法論警告。