以前测试 AI 写代码，常见做法是给它一个函数，再跑几条单元测试。现在 Agent 已经开始从空目录写整套后端。问题也随之变了：我们怎么知道这套东西真的能用？
拿一个推送服务来说。Alice 创建了一个应用，Bob 不该看到它。Alice 删除应用后，里面的消息也该一起消失。系统拒绝一次错误请求后，数据库不能悄悄多出一条脏数据。每条规则单看都不复杂。可同一组接口换个人、换个操作顺序，正确答案就会变。第一版测试很难把所有情况都想到。
BackendForge 想解决的就是这个问题。研究者先写了 7,250 项测试，再让 Agent 专门寻找这套测试漏掉了什么，最后补进 640 项。测试数量只多了 +8.8%，同一批 GPT-5.5 代码却从 31/56 个任务全通过，降到 16/56。
这批代码没有改变，变的是评分用的题库。BackendForge 带来的启发也在这里：当 AI 开始写整套应用，benchmark 不能只把题目变大。出题方式也要从一次写完的笔试，变成一场会继续追问的面试。
HumanEval 测的是一个函数。模型读一段需求，写出几十行代码，然后跑单元测试。
SWE-bench 把模型放进真实代码仓库。它要读 issue、找到相关文件，再提交一个修复补丁。FEA-Bench 测得更大：Agent 不只修 bug，还要实现一个跨越多个文件的新功能。
现在，评测对象又变成了整套 App。模型要自己处理数据库、接口、登录和权限，最后交出一个能启动、能接收请求的系统。BackendForge 就属于这一代 benchmark。
任务每变大一级，测试也会多一层难度。一个函数通常调用一次就能判断对错。整套服务要连续做完一串动作，才能知道哪里出了问题。
完整应用的 benchmark 已经有不少。BaxBench 让模型生成后端，同时检查功能和安全问题。AppForge 测安卓应用，会把成品装进模拟器，真的点开界面操作。Vibe Code Bench 测网页应用，再让浏览器 Agent 按照用户流程一步步验收。
这些 benchmark 已经在测整套产品。BackendForge 多做的一步，是让题库在发布前继续找漏。
它收录了 56 个后端任务，一共有 2,345 个 API 操作。模型生成代码后，研究者把服务装进 Docker，再用真实 HTTP 请求测试。整套评测一共发出了 24,798 次请求。
这些请求会串在一起。第一次请求创建数据，第二次换成另一个用户读取，第三次再删除，最后检查数据库里还剩下什么。前面 Alice 和 Bob 那类规则，只有这样才能测出来。
原来的 7,250 项测试已经会检查这些跨越多次请求的规则。类似思路也不是新发明，微软的 RESTler 很早就在自动尝试不同的 API 调用顺序。BackendForge 的变化，是让测试在构建 benchmark 时主动寻找自己的遗漏。
BackendForge 先准备一套参考服务。你可以把它理解成标准答案。然后，三个 Agent 围着它反复出题、检查和修正。
第一个 Agent 负责出题，论文里叫 Test Agent。它根据需求文档和 OpenAPI 设计新测试。如果参考服务能通过，这道题没有发现新问题，直接丢掉。如果参考服务失败，它可能抓到了第一版题库漏掉的规则。
第二个 Agent 负责检查新题有没有需求依据，论文里叫 Review Agent。它一共否决了 113 个站不住脚的候选。最后，Code Agent 修好参考服务，再把新旧测试全部跑一遍。全部通过后，新题才会进入正式题库。
论文把这个循环叫作 co-evolution，也就是测试和参考服务一起改进。最终新增的 640 项测试都从具体问题出发：
可以把以前的评测想成笔试。每个 task 的题目提前写好，代码交上来以后，照着固定答案打分。BackendForge 在出题阶段多加了一位面试官：它先看这个 task 的参考服务错在哪里，再沿着那个错误继续问。
共同演化把测试从 7,250 项增加到 7,890 项。新增 640 项，只占 +8.8%。它们数量不多，却都是先发现真实失败、再核对需求、最后通过回归测试留下来的。
BackendForge 的计分方式很严格：一个任务里的测试必须全部通过。哪怕只错一项，整个任务也算失败。
一共 56 个任务。用最初的题库评分时，GPT-5.5 生成的服务有 31 个任务全部通过。换成加固后的题库，只剩 16 个。换句话说，原来通过的任务里，只有 51.6% 还能通过。
Claude Opus 4.7 的变化更大：原来通过 33 个任务，加固题库后只剩 10 个。
模型没有重新生成代码，也没有突然变弱。同一份代码换了一套更会找问题的测试，结果就变了。第一版题库漏掉的一些问题，足以让整个任务从通过变成失败。
论文说作者计划公开完整评测材料，但截至本文核对时，公开渠道还找不到这套资源。外界暂时无法逐项检查新增的 640 项测试，所以不应把这里的改判幅度直接套到所有整套应用评测上。
BackendForge 按每个 repo 或 task 定制追问。Gotify 的参考服务在哪里出错，测试 Agent 就沿着 Gotify 的问题追问；换成另一个 task，它会从那个服务暴露的问题继续问。因此，不同 task 最后补进题库的问题可以不同。它不会针对每个参评模型临时换题。
但题库定稿以后，面试就结束了。同一个 task 的最终测试会被冻结。GPT-5.5、Claude Opus 4.7 或其他模型来做这个 task，面对的都是同一套题。这样既能针对每个项目的具体问题继续追问，又不会为了某个 candidate 临时换题。
所以 BackendForge 仍然保留了笔试。区别只在于：试卷定稿之前，先按每个 task 的实际回答做一轮面试式追问。定稿之后，所有模型再用同一张试卷比较成绩。
以后评测整套应用，可以把这轮追问变成发布前的必做步骤。先让 Agent 对着参考服务找漏，再由人检查新题有没有需求依据。检查完，冻结一个统一版本。公开题库负责长期比较，定期更新的隐藏题目继续寻找新漏洞。
从一个函数到一套完整应用，AI 接到的任务一直在变大。BackendForge 让评测也学会了追问。标准试卷仍然要有，只是在定稿之前，应该先让它经历一场面试。