企业应用现代化，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框架迁移任务上的表现。
所有迁移后的应用，都必须满足三个硬性标准：
- 能编译成功。
- 能正确部署。
- 能通过行为验证。
这比只看代码能不能跑起来要实在得多，能更真实地反映现代化的质量。
基准数据一览
| 指标 | 数值 |
|---|---|
| 应用数量 | 34 |
| 框架实现数量 | 102 |
| 迁移任务数量 | 204 |
| 代码行数 | 约151K |
| 源文件和测试文件 | 约2,000 |
| 专家编写的测试用例 | 1,331 |
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辅助应用现代化的到来。
我们诚邀各位研究人员、从业者和框架社区，来测试你们的智能体，贡献新的迁移场景，一起推动这个领域向前发展。