IBM与Kaggle联合推出Java框架迁移评测榜单

探索ScarfBench排行榜

阅读ScarfBench原始公告

了解IBM与Kaggle的企业AI合作

ScarfBench（自包含应用重构基准测试）是IBM推出的一项开放基准测试，用于评估编码智能体是否能够在保持应用程序正常运行行为的前提下，成功完成企业级Java应用在不同框架间的迁移。该测试涵盖Jakarta EE、Quarkus和Spring之间的迁移场景，通过聚焦型工作负载和完整应用程序两种方式，检验生成的应用程序能否正常构建、启动并保持预期行为。

对企业应用进行现代化改造并不是单一文件的编码任务。在框架之间迁移应用程序，可能需要对依赖注入、持久化、数据库访问、Web端点、构建系统、框架描述文件和部署基础设施进行协同调整。编码智能体生成的迁移方案可能看起来合理，甚至能够通过编译，但该应用程序在部署后或在实际行为测试中仍可能失败。

ScarfBench提出了一个实际问题：智能体能否接手一个陌生的应用程序，将其跨框架迁移，并留下依然能正常运行的软件？

IBM于2026年早些时候推出了ScarfBench，作为评估AI驱动迁移能力的可复现基准测试。如今，IBM与Kaggle正展开合作，使这项评测更易复现、比较，并能随时间推移不断扩展。Kaggle参与了评测设计的咨询工作，独立在其平台上复现并运行了ScarfBench，同时承担了计算资源的赞助，并将在新模型发布后持续维护该基准测试。这次合作使ScarfBench从一份已发布的基准测试，转变为持续更新的智能体化软件现代化进展观测窗口。

此前发布的ScarfBench公告详细介绍了基准测试的设计、经开发者验证的工作负载以及可复现的评测方法。本文将重点介绍最新评测结果揭示的模型与智能体框架组合表现、失败原因，以及该基准测试如何与Kaggle共同演进。

评估模型与框架组合

ScarfBench评估的是一个智能体化系统，而非孤立的语言模型。每项结果反映的是一个模型与一个编码智能体框架的组合，该框架决定了智能体如何与代码仓库及开发环境交互。因此，这些结果应被解读为"模型/框架"组合的结果，而非对底层模型本身的衡量。

在204项迁移任务中，Gemini 4 Argon搭配Antigravity框架在主要的烟雾测试指标上排名第一，得分为75.2%，其次是Claude Opus 5.5搭配Claude Code（70.5%）和Claude Opus 5搭配Claude Code（69.8%）。本次评测共测试了十种模型与框架的组合。

排名 | 模型 | 框架 | 烟雾测试% | 全部通过% | 平均%

1 | Gemini 4 Argon | Antigravity | 75.2 | 71.1 | 85.9

2 | Claude Opus 5.5 | Claude Code | 70.5 | 72.1 | 82.0

3 | Claude Opus 5 | Claude Code | 69.8 | 60.8 | 79.7

4 | GPT-6.1 Sol | Codex | 68.4 | 62.7 | 76.8

5 | Gemini 3.8 Flash | mini-swe | 66.0 | 62.3 | 77.6

6 | GPT-6 Astra | Codex | 65.4 | 61.4 | 75.4

7 | Qwen 3.8 Max | qwen-code | 63.7 | 59.3 | 76.1

8 | Kimi K3 | kimi-code | 61.1 | 50.7 | 71.2

9 | Gemini 3.1 Pro | OpenHands | 39.5 | 35.1 | 50.5

10 | Gemma 4 26B-A4B | mini-swe | 24.5 | 17.6 | 30.8

这三项指标揭示了一个重要的细微差异。作为排行榜的核心指标，烟雾测试得分会给予部分分数，并对更大规模的测试集赋予更高权重。在这项指标上，Gemini 4 Argon + Antigravity组合的表现最强。但Claude Opus 5.5 + Claude Code组合的全部测试通过率最高，达到72.1%，略微领先于Gemini 4 Argon。换句话说，Argon/Antigravity组合在整个基准测试中获得了最多的部分分数，而Opus 5.5/Claude Code组合则将略多的单个迁移任务完全转化为全绿的测试结果。

在敏感性分析中，排名保持稳定。204项迁移任务中有4项任务在所有被评测的模型/框架组合中均未获得任何行为测试得分。排除这4项任务后，各项绝对得分有所提升，但榜首排名未发生变化：Gemini 4 Argon + Antigravity得分79.4%，其次是Claude Opus 5.5 + Claude Code（74.5%）和Claude Opus 5 + Claude Code（73.7%）。这一结果表明，相对排名并非由这一小部分普遍难以完成的任务所主导。

即便是表现最强的组合，仍存在很大的提升空间：整个基准测试中最佳的烟雾测试总分为75.2%，没有任何一种配置能够完全通过超过约四分之三的迁移任务。

最大差异化因素是行为保真度，而非编译能否通过

最明显的结果是"能够构建的代码"与"行为正确的软件"之间的差距。排除4项全零得分的任务后，Claude Opus 5 + Claude Code、Gemini 4 Argon + Antigravity以及Gemini 3.8 Flash + mini-swe均实现了100%的任务编译成功率，GPT-6 Astra + Codex和Kimi K3 + kimi-code分别为99.0%和98.5%，Claude Opus 5.5 + Claude Code和GPT-6.1 Sol + Codex分别为98.0%和98.5%。然而，烟雾测试得分却远低于此。

在这十种配置中，可解决任务的编译成功率跨度约为25个百分点，但多数配置的表现聚集在高位，十种配置中有八种编译成功率达到97%或以上；而烟雾测试表现的跨度则超过50个百分点。在成功部署的应用程序中，领先的几种配置的全部测试通过率大致聚集在63%至76%之间；Kimi K3 + kimi-code降至53%，Gemini 3.1 Pro + OpenHands降至42%，Gemma 4 26B-A4B + mini-swe降至26%。在本次评测中，保持行为一致性远比让迁移后的应用程序通过编译更能体现区分度。

智能体配置的失败原因

在745次被分类的失败运行中，535次（约72%）属于运行时行为失败：应用程序成功构建、往往也能成功启动，但未能通过行为验证。这一类别包括304次内容或断言不匹配，以及210次路由丢失/404错误；另有21次为明确的HTTP 500/405错误。编译或打包失败约占20%（152次），启动或依赖注入崩溃约占8%（58次）。

路由丢失与HTTP语义问题：在concurrency-taskcreator-quarkus-to-jakarta任务中，Claude Opus 5 + Claude Code得分0/6，原因是/taskinfo返回了"文件未找到"，且一项预期返回HTTP 405的测试失败。在address-book-jakarta-to-quarkus任务中，GPT-6 Astra + Codex得分2/10，原因是列表页和创建页均返回HTTP 404。

源框架配置遗留到目标框架：在cargotracker-jakarta-to-spring任务中，Gemini 3.8 Flash + mini-swe在Spring Boot目标应用中保留了JSF/JoinFaces的配置，导致在创建facesContext bean时启动失败。

打包方式与目标运行环境不兼容：在cart-spring-to-jakarta任务中，GPT-6 Astra + Codex因迁移后留下的打包类型不受目标Liberty运行环境支持，而导致部署失败。

这些失败案例说明了为何ScarfBench的验证不止于编译层面：在本次评测被分类的失败案例中，近四分之三出现在运行时阶段。

智能体效率揭示不同的运行特征

在经过四项任务敏感性排除后剩余的200项任务中，Claude Opus 5 + Claude Code所用的中位数轮次最少，为32轮。GPT-6.1 Sol + Codex为36轮，Gemma 4 26B-A4B + mini-swe为40轮，Gemini 4 Argon + Antigravity为42轮，GPT-6 Astra + Codex为45轮，Kimi K3 + kimi-code为47轮，Qwen 3.8 Max + qwen-code和Gemini 3.1 Pro + OpenHands均为53轮，Claude Opus 5.5 + Claude Code为64轮，Gemini 3.8 Flash + mini-swe为79轮。

在可获取框架报告成本数据的范围内（即Claude Code、Codex、mini-swe和kimi-code框架；Antigravity、qwen-code和OpenHands框架未提供单次运行成本数据），各配置呈现出不同的成本特征：

模型/框架 | 中位数轮次 | 成功运行轮次 | 单次成功运行成本 | 每项已解决任务成本

Claude Opus 5 / Claude Code | 32 | 30 | .76 | .83

Claude Opus 5.5 / Claude Code | 64 | 60 | .98 | .10

GPT-6.1 Sol / Codex | 36 | 34 | {zhiding_content_info_26}.64 | .25

GPT-6 Astra / Codex | 45 | 44 | .55 | .65

Gemini 3.8 Flash / mini-swe | 79 | 74 | {zhiding_content_info_26}.73 | .59

Kimi K3 / kimi-code | 47 | 44 | .27 | .21

IBM与Kaggle正在打造持续更新的ScarfBench排行榜

最新的ScarfBench评测也是IBM与Kaggle深化合作的起点。两个团队发挥各自优势：IBM围绕企业级Java现代化改造开发了ScarfBench，而Kaggle则带来了独立的评测基础设施以及长期的排行榜维护能力。这次合作旨在使该基准测试能够在其原始开发环境之外实现可复现，并随着新的模型与智能体配置不断发布而持续发挥价值。

此次合作包含三个具体部分。首先，Kaggle就基准测试与评测方案的严谨设计与IBM进行了咨询协作。其次，Kaggle在其平台上独立复现并运行了该评测，并承担了相关计算资源的赞助。第三，Kaggle将对该基准测试进行长期维护，并在新模型发布后持续加入测试。ScarfBench排行榜将公开展示这些结果。目前尚未开放公众模型提交功能，但该功能已列入未来规划。

目前已获得的认知

ScarfBench的构建基于一个严格的前提：要让编码智能体真正有意义地参与企业现代化改造，就必须以企业最终关心的结果——可正常运行的软件——作为评测标准。

最新的评测进一步印证了这一前提。领先的配置几乎能够编译通过敏感性测试集中的所有任务，但编译成功掩盖了一个更难的问题。路由会消失，HTTP行为会发生变化，源框架的配置会遗留到迁移后的系统中，应用程序会在启动过程中失败，业务行为也会与预期系统出现偏差。

"能够构建的代码"与"真正能用的软件"之间的这一差距，正是ScarfBench最具信息价值的部分。随着新的模型/框架组合不断出现，一个持续维护的基准测试可以揭示：进步究竟来自更优的代码生成改动、更有效的调试与迭代能力、更高效的工具使用，还是这些能力的综合提升。

订阅我们的Future Forward新闻通讯，及时了解最新研究动态

订阅我们的新闻通讯