ScarfBench企业级Java框架迁移AI智能体基准测试

企业应用现代化，AI到底能帮上多少忙？

企业应用现代化，这事儿说大不大，说小不小，但真要动起手来，绝对是软件工程里最烧钱、最费劲的活儿之一。团队们费尽心思把应用从一个框架迁移到另一个框架，图的无非是更好的可维护性、更强的云原生能力、更高的开发效率，以及能顺手用上那些时髦的新功能。

最近，编程智能体（Coding Agents）的进展让不少人兴奋起来，觉得AI辅助现代化这事儿终于有了盼头。但问题来了：

AI智能体到底能不能靠谱地完成企业级应用的现代化改造？

现有的软件工程基准测试，在Bug修复和代码生成上确实进步神速，但框架迁移完全是另一回事。这事儿不光要翻译代码，还得保证行为不变、能适配构建系统、处理好运行时依赖——难度上了不止一个台阶。

为了摸清这个底，我们搞了个叫ScarfBench（全称Self-Contained Application Refactoring Benchmark）的开放基准测试，专门用来评估AI智能体在跨框架迁移任务上的表现，目标锁定在Ja va企业级应用。

ScarfBench主要盯着三大Ja va生态圈之间的迁移：

• Spring
• Jakarta EE
• Quarkus

跟那些只拿生成代码跟参考实现做对比的传统基准测试不一样，ScarfBench的评判标准更硬核：迁移后的应用到底能不能编译、能不能部署、行为是不是还跟原来一样。

为什么框架迁移这么难

框架迁移，远远不是替换几个注解那么简单。

举个简单的例子，迁移一个仓库模块，你就得同时改动依赖注入、持久化配置、查询语句还有框架描述符。这些环节里任何一个地方出点小错，整个应用就可能部署不了。

图：Spring → Jakarta 迁移示例

框架迁移的本质是翻译框架语义，而不只是改写源代码。

ScarfBench到底是个什么基准？

ScarfBench提供了一套系统的方法，来评估AI智能体在企业级Ja va框架迁移任务上的表现。

所有迁移后的应用，都必须满足三个硬性标准：

1. 能编译成功。
2. 能正确部署。
3. 能通过行为验证。

这比只看代码能不能跑起来要实在得多，能更真实地反映现代化的质量。

基准数据一览

ScarfBench既包含聚焦的迁移任务，也包含完整的应用迁移。

图：ScarfBench 构建流程

从基于JSR的企业级Ja va分类法出发，专家们通过手动迁移，生成了在Spring、Jakarta EE和Quarkus上的经过验证的实现。

前沿智能体表现如何？

我们拿ScarfBench测试了好几个目前最先进的编程智能体。

结果有点意思：尽管它们在传统软件工程基准测试上表现抢眼，但框架迁移仍然是个硬骨头。不同框架对之间的成功率差异很大，而完整的应用迁移更是难上加难。

图：当前排行榜

来源：scarfbench.info/leaderboard

即便是目前最强的智能体，行为验证通过率也低于10%。这充分说明，能生成可编译的代码，跟能保证应用行为不变，之间还隔着一条鸿沟。

图：编译 → 部署 → 测试 的递进关系

编译成功率明显高于部署成功率，而部署成功率又明显高于行为验证成功率。单看编译成功，会严重高估迁移的质量。

图：按目标框架区分的迁移结果

迁移的难度很大程度上取决于目标框架，其中Jakarta EE的挑战尤其突出。

我们从AI智能体身上学到了什么

除了看成功率，ScarfBench还帮我们搞清楚了智能体在现代化过程中到底是怎么工作的。

智能体能准确判断迁移是否完成吗？

迁移后的应用只有能真正编译和运行，才算有用。

所以我们把智能体自己报告的结果，跟独立的编译验证结果做了对比。

发现：智能体普遍过度自信

Claude Code报告说，30个完整应用中有29个编译成功。

但实际上，只有22个应用真正编译通过了。

而智能体认为失败的那个应用，最终却被验证为编译正确。

这说明，智能体的自我评估不能作为迁移完成的可靠信号。独立的编译和测试验证，仍然必不可少。

智能体是怎么处理应用依赖关系的？

框架迁移很少只影响一个文件或一个层。

配置、服务、数据库、Web组件这些地方的改动，往往会像多米诺骨&牌一样波及整个应用。

发现：迁移是迭代的，而不是线性的

智能体最常访问的层是：

• 配置
• Web
• 数据库
• 服务

常见的状态转移包括：

• 配置 ↔ Web
• 服务 ↔ 数据库

这表明，迁移过程更像是一个反复解决依赖问题的迭代过程，而不是简单的源代码到源代码的转换。

智能体把最多精力花在了哪里？

我们用“重新访问某层的频率”来作为衡量迁移工作量的指标。那些需要反复处理的层，通常涉及调试、依赖解析或框架适配。

发现：配置问题是迁移中最耗时的部分

智能体并没有线性地推进，而是反复回到配置相关的工件上，去解决框架差异和依赖问题。

哪些挑战跟代码转换无关？

不是所有迁移问题都源于源代码。

发现：环境和工具链同样重要

智能体经常在环境问题上栽跟头，比如：

• Docker缓存不一致
• 端口连接问题
• Ma ven包装器和构建工具的问题

这些操作层面的麻烦，往往在源代码迁移本身已经基本完成时，拖慢了验证的进度。

图：失败模式分布

现代化的失败原因遍布构建系统、部署环境、依赖注入、数据库、端点、断言和基础设施等多个环节。

核心结论

框架现代化最大的挑战，不是翻译Ja va代码。

而是管理好配置、基础设施和运行时环境之间那张错综复杂的依赖关系网。

虽然前沿的智能体已经能自动化迁移过程中的大部分工作，但可靠的验证和架构层面的推理能力，仍然是实现成功迁移的关键。

ScarfBench的作用，就是把这些挑战摆到台面上，并提供一个标准化的方式，来衡量我们离真正自动化的应用现代化还有多远。

探索 ScarfBench

ScarfBench被设计成一个开放资源，供研究人员和从业者使用。

你可以找到的资源包括：

• 基准数据集
• 评估基础设施
• 公开排行榜
• 文档
• 开源代码

研究人员可以用它来比较不同智能体的架构和技术。从业者则可以在生产环境中部署现代化解决方案之前，先用ScarfBench来评估一下。

网站

https://scarfbench.info

数据集

https://huggingface.co/datasets/ibm-research/ScarfBench

Space

https://huggingface.co/spaces/ibm-research/ScarfBench

GitHub 仓库

https://github.com/scarfbench/scarfbench

排行榜

https://scarfbench.info/leaderboard

论文

https://arxiv.org/abs/2605.06754

框架迁移，至今仍是AI辅助软件工程领域里最大的未解难题之一。希望ScarfBench能帮助整个社区摸清进展，并加速下一代AI辅助应用现代化的到来。

我们诚邀各位研究人员、从业者和框架社区，来测试你们的智能体，贡献新的迁移场景，一起推动这个领域向前发展。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：ScarfBench企业级Java框架迁移AI智能体基准测试要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题