ScarfBench：企业Java框架迁移的AI Agent基准测试
ScarfBench: Benchmarking AI Agents for Enterprise Java Framework Migration
IBM Research 发布 ScarfBench（Self-Contained Application Refactoring Benchmark），一个用于评估 AI agent 在企业 Java 框架迁移任务上的开放 benchmark。ScarfBench 包含 34 个应用、102 个框架实现、204 个迁移任务、约 151K 行代码和 1,331 个专家测试，覆盖 Spring、Jakarta EE 和 Quarkus 三大生态。评估显示，即使最强 agent 的行为成功率低于 10%，且 agent 自我评估不可靠，迁移难点在于配置、依赖和运行时环境而非代码翻译。
](https://huggingface.co/rpavuluri)
企业应用现代化是组织所承担的最大、最昂贵的软件工程活动之一。团队跨框架迁移应用，以提升可维护性、云就绪性、开发者生产力，并获取对现代能力的访问。
编码 agent 的最新进展引发了人们对 AI 辅助现代化的兴奋。但一个重要问题仍然存在：
AI agent 能否可靠地实现真实世界企业应用的现代化？
现有的软件工程 benchmark 在 bug 修复和代码生成方面展示了令人瞩目的进展，但框架迁移提出了一个根本不同的挑战。成功不仅需要翻译代码，还需要保持行为、适配构建系统以及处理运行时依赖。
为填补这一空白，我们推出了 ScarfBench（Self-Contained Application Refactoring Benchmark，自包含应用重构基准），这是一个用于评估 AI agent 在企业 Java 中执行跨框架迁移任务的开放 benchmark。
ScarfBench 专注于三大 Java 生态系统的迁移：
- Spring
- Jakarta EE
- Quarkus
与将生成代码与参考实现进行比较的传统 benchmark 不同，ScarfBench 评估迁移后的应用是否实际构建、部署并保持行为。
为什么迁移很难
框架迁移远不止替换注解那么简单。
一个简单的仓库迁移可能需要修改依赖注入、持久化配置、查询和框架描述符。这些环节中的任何小错误都可能导致部署失败。
图：Spring → Jakarta 迁移示例
框架迁移需要翻译框架语义，而不仅仅是源代码。
介绍 ScarfBench
ScarfBench 提供了一种系统化的方法来评估 AI agent 在企业 Java 框架迁移任务上的表现。
应用需要满足以下条件：
- 成功构建。
- 正确部署。
- 通过行为验证。
这提供了对现代化质量更真实的衡量。
Benchmark 概览
| 指标 | 数值 |
|---|---|
| 应用数 | 34 |
| 框架实现数 | 102 |
| 迁移任务数 | 204 |
| 代码行数 | ~151K |
| 源文件和测试文件数 | ~2,000 |
| 专家编写的测试数 | 1,331 |
ScarfBench 包含聚焦的迁移任务和全应用迁移。
图：ScarfBench 构建流水线
从基于 JSR 的企业 Java 分类法出发，专家迁移在 Spring、Jakarta EE 和 Quarkus 上创建了经过验证的实现。
前沿 agent 表现如何？
我们在 ScarfBench 上评估了多个最先进的编码 agent。
尽管在传统软件工程 benchmark 上表现强劲，框架迁移仍然困难。不同框架对之间的成功率差异很大，全应用迁移尤其具有挑战性。
图：当前排行榜
即使是最强的当前 agent，其行为成功率也低于 10%，这说明了生成可编译代码与保持应用行为之间的差距。
图：编译 → 部署 → 测试进展
编译成功率始终高于部署成功率，而部署成功率又高于行为成功率。仅凭构建成功会显著高估迁移质量。
图：按目标框架划分的迁移结果
迁移难度在很大程度上取决于目标框架，其中 Jakarta EE 尤其具有挑战性。
我们从 AI agent 进行 Java 现代化中学到了什么
除了衡量成功率，ScarfBench 还帮助我们理解 agent 在现代化过程中的行为。
agent 能否可靠地判断迁移何时完成？
迁移后的应用只有在实际构建并运行时才有用。
因此，我们将 agent 报告的结果与独立的构建验证进行了比较。
发现：agent 过于自信
Claude Code 报告称，30 个全应用中有 29 个构建成功。
但实际上只有 22 个应用成功构建。
与此同时，被 agent 归类为失败的那一个应用最终却正确构建了。
这表明 agent 的自我评估不应被视为迁移完成的可靠信号。
独立的构建和测试验证仍然至关重要。
agent 如何处理应用依赖？
框架迁移很少只影响单个文件或层。
配置、服务、数据库和 Web 组件中的更改通常会级联到整个应用。
发现：迁移是迭代的而非线性的
最常被访问的层是：
- 配置
- Web
- 数据库
- 服务
常见的转换包括：
- 配置 ↔ Web
- 服务 ↔ 数据库
这表明迁移是一个迭代的依赖解析过程，而不是简单的源到源转换。
agent 将大部分精力花在哪里？
我们使用层重访频率作为迁移工作量的代理指标。需要重复访问的层通常涉及调试、依赖解析或框架适配。
发现：配置主导了迁移工作量
agent 并非线性推进，而是在解决框架差异和依赖问题时反复回到与配置相关的工件。
哪些挑战与代码转换无关？
并非每个迁移问题都源于源代码。
发现：环境和工具很重要
agent 经常与环境问题作斗争，包括：
- Docker 缓存不一致
- 端口连接问题
- Maven wrapper 和构建工具问题
即使源代码迁移本身基本完成，这些操作性问题也常常会延迟验证。
图：失败模式分布
现代化失败涉及构建系统、部署环境、依赖注入、数据库、端点、断言和基础设施。
关键要点
框架现代化中最大的挑战不是翻译 Java 代码。
而是管理跨配置、基础设施和运行时环境的依赖网络。
虽然前沿 agent 可以自动化迁移过程中的大部分工作，但可靠的验证和架构推理对于取得成功结果仍然至关重要。
ScarfBench 有助于揭示这些挑战，并提供了一种标准化的方法来衡量向真正自主的应用现代化迈进的进展。
探索 ScarfBench
ScarfBench 被设计为面向研究人员和实践者的开放资源。
资源包括：
- Benchmark 数据集
- 评估基础设施
- 公开排行榜
- 文档
- 开源代码
研究人员可以比较 agent 架构和技术。实践者可以在将现代化解决方案部署到生产环境之前，使用 ScarfBench 对其进行评估。
网站
数据集
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 辅助应用现代化。
我们邀请研究人员、实践者和框架社区评估他们的 agent、贡献新的迁移场景，并帮助推动技术前沿的发展。