AI Agent 做代码演示很容易：改一个函数、补一个测试、生成一段样板代码。但企业里的 Java 框架迁移不是这种玩具任务。它通常意味着跨模块理解、依赖升级、注解替换、配置重写、测试修复，以及对运行时行为的谨慎验证。标题里的 ScarfBench 指向的正是这个更硬的问题：如何用企业 Java 框架迁移来评测 AI Agent。
为什么框架迁移适合做 Agent 基准测试
企业 Java 项目迁移有几个天然难点，非常适合暴露 Agent 的真实能力边界。
一是改动分散。一次迁移可能同时碰到 pom.xml、Spring 配置、控制器、过滤器、测试、CI 脚本和部署配置。Agent 不能只会“局部补全”，它必须能沿着依赖和错误信息追踪。
二是正确性不只靠编译。比如从旧框架版本迁移到新版本，代码能编译并不代表请求路径、事务边界、安全配置、JSON 序列化行为都保持一致。
三是迁移任务有明确目标，但路径不唯一。一个成熟 Agent 应该能制定计划、分阶段修改、运行测试、根据失败日志迭代，而不是一次性生成一大坨代码。
所以，类似 ScarfBench 这样的基准测试如果围绕企业 Java 框架迁移设计，重点就不该只是“模型会不会写 Java”，而是“Agent 能不能像靠谱工程师一样完成迁移闭环”。
一个好的迁移 Benchmark 应该测什么
如果把企业 Java 框架迁移拆成可评估任务，至少应覆盖下面几类能力。
| 能力 | 迁移场景中的表现 |
|---|---|
| 代码库理解 | 找到入口、依赖、配置和测试位置 |
| 变更规划 | 区分必须改、顺手改、不能碰的内容 |
| API 替换 | 将旧框架 API 替换成新框架等价写法 |
| 构建修复 | 根据 Maven/Gradle 错误定位依赖冲突 |
| 测试驱动迭代 | 运行测试、阅读失败、继续修复 |
| 行为保持 | 尽量保持 HTTP 契约、配置语义和业务逻辑不变 |
这里最容易被低估的是“行为保持”。很多 Agent 能把项目从红色编译错误改到绿色，但会偷偷改变默认值、异常码或认证路径。对企业迁移来说，这类变化比编译错误更危险。
可以这样实践：做一个迷你 Java 迁移评测任务
下面是一个可改造的最小评测脚本思路：准备一个含旧写法的 Spring Boot 项目，让 Agent 完成迁移，然后用测试判断它是否真的保持了接口行为。这里不声称这是 ScarfBench 的实现，只是一个可以在团队内部落地的小型实践。
假设项目结构如下：
migration-bench/
pom.xml
src/main/java/com/example/demo/HelloController.java
src/test/java/com/example/demo/HelloControllerTest.java
可以准备一个测试文件，要求迁移后仍然通过：
package com.example.demo;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.test.web.servlet.MockMvc;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
@WebMvcTest(HelloController.class)
class HelloControllerTest {
@Autowired
private MockMvc mockMvc;
@Test
void keepsHttpContractAfterMigration() throws Exception {
mockMvc.perform(get("/hello").param("name", "ScarfBench"))
.andExpect(status().isOk())
.andExpect(content().string("Hello, ScarfBench"));
}
}
控制器可以故意放入需要迁移或整理的旧式代码风格，例如让 Agent 将其改成当前团队约定的写法：
package com.example.demo;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class HelloController {
@RequestMapping("/hello")
public String hello(@RequestParam(defaultValue = "World") String name) {
return "Hello, " + name;
}
}
运行验证命令：
mvn test
给 Agent 的任务可以写得更接近企业迁移：
你正在迁移一个 Java Web 项目。请在不改变 HTTP 行为的前提下：
1. 将控制器改成团队当前推荐的显式注解写法。
2. 保持 /hello?name=ScarfBench 返回 Hello, ScarfBench。
3. 运行测试，根据失败信息继续修复。
4. 不要修改与迁移无关的业务逻辑。
这个例子很小，但它包含了评测 Agent 的关键形状：给定旧代码、提出迁移目标、保留行为测试、允许迭代修复。
评分不能只看“最后能不能跑”
企业场景里的 Agent 评测，建议把结果拆成几层。
- 构建通过率：项目是否能成功编译和运行测试。
- 行为保持率：关键接口、配置、数据处理是否保持一致。
- 改动最小性：是否避免了无关重构和大面积格式化。
- 诊断质量：失败时是否能根据日志做出合理下一步。
- 可审查性：提交是否集中、解释是否清楚、风险是否标出。
这比单一分数更有用。一个 Agent 如果能跑通测试但重写半个项目，在企业迁移中未必值得信任。另一个 Agent 虽然需要多轮迭代，但每次修改都小而准，反而更像能进入真实工作流的工具。
落地建议：先让 Agent 做“窄迁移”
团队如果想用类似 ScarfBench 的思路评估 Agent，不必一开始就拿核心系统开刀。更稳妥的路径是：
- 选择一个边界清楚的模块，例如只迁移 Web 层注解或测试框架。
- 准备迁移前后的行为测试，尤其是 HTTP 契约和异常场景。
- 限制 Agent 的改动范围，要求它解释每类变更。
- 记录失败日志、修复轮次和人工介入点。
- 把“少改、可审查、能回滚”作为评分项，而不只是追求一次成功。
AI Agent 在企业 Java 迁移中的价值，不是替代所有工程判断，而是承担可验证、可回滚、可审查的一段迁移工作。ScarfBench 这类基准测试的意义，也正在于把 Agent 从代码生成器拉回工程现场：它要面对旧代码、构建系统、测试失败和真实约束。