谷歌把AI编程考试改成“开卷长跑”：Android Bench 2.0想测点真本事

用AI写一段代码并不难，难的是让它在一个真实项目里连续工作几天，改依赖、加功能、修回归，最后还能交付。谷歌最近发布的Android Bench 2.0，就是冲着这个差距来的。

一分钟速览

• Android Bench 2.0引入长周期任务（LHT），单任务可能需要工程师花费数天甚至一周完成。
• 新增基于智能体的评估机制，首批采用来自各模型提供商的智能体。
• 评分从“通过/失败”的二元判断，改为连续评分，更能反映复杂任务中的部分完成度。
• 任务类型包括升级依赖、添加新功能、从零构建应用，以及把跨平台应用移植到Android。

旧基准测试，考的是“片段能力”

初版Android Bench主要评估模型在常见开发任务上的表现，关注权限、导航、网络连通性等Android最佳实践。这类测试很像单元测验：给定一个小问题，看模型能不能写出正确代码。它能区分模型的基础能力，却很难回答一个更重要的问题：如果把一个真实项目交给AI智能体，它能不能独立完成？

真实开发不是单轮问答。它需要理解现有代码库、制定计划、修改多个文件、运行测试、处理失败、再迭代。过程中会遇到依赖冲突、API变更、编译错误和回归问题。这些能力，靠短任务很难测出来。

长周期任务，把“项目制”搬进基准

Android Bench 2.0的第一批长周期任务，覆盖了工程师日常工作中最耗时的几类事情：升级依赖项、添加新功能、从零开始构建应用、把跨平台应用转换为Android应用。这些任务的共同点是，没有唯一正确的答案，只有“能不能交付”和“交付得好不好”。

这也解释了为什么评分要从二元转向连续。一个复杂任务可能完成了80%，但因为最后一个测试没通过而被判失败；另一个任务只完成了50%，却因为代码质量高、可维护性好而更有价值。连续评分可以捕捉这些差异，让基准更接近真实工程的评价方式。

智能体评估，难在“怎么算完成”

基于智能体的评估，是这次更新的另一个重点。传统测试由人类写好断言，跑一遍就知道对错；智能体评估则要让模型自己规划、执行、验证，甚至判断任务是否完成。这就带来了新的难题：如果智能体“自认为”完成了，但实际结果不符合要求，算不算通过？

谷歌的做法是，首批采用来自相应模型提供商的智能体，再结合任务本身的验收标准来评分。这种方式更贴近真实使用场景，但也增加了评估的复杂性：不同智能体的工具调用能力、上下文管理策略不同，结果可能受到框架而非模型本身的影响。

基准测试的军备竞赛

过去一年，AI编程基准经历了快速迭代。从单文件代码生成，到仓库级修复，再到长周期任务，测试的颗粒度越来越大。原因很简单：模型在短任务上的分数已经很高，继续加题很难拉开差距；只有把任务变长、变复杂，才能暴露规划、记忆和纠错能力的差异。

但基准测试也有自己的风险。任务一旦公开，就可能被训练数据污染；评估环境一旦复杂，复现成本就会上升；智能体评估还涉及工具、网络和运行时长，结果可能不稳定。谷歌强调连续评分和智能体评估，方向是对的，但能否成为行业通用的标准，还要看后续的透明度与可复现性。

对开发者意味着什么

对普通开发者来说，Android Bench 2.0的价值不在于“哪个模型排第一”，而在于它定义了AI编程的新评价维度：能不能处理长任务、能不能在真实代码库里工作、能不能交付可维护的结果。选型时，与其只看代码补全的准确率，不如看模型在长周期任务中的完成度和稳定性。

对模型厂商来说，这是一次更严格的考试。短任务靠记忆和模式匹配就能拿高分，长任务则要求真正的规划、工具使用和自我纠错。未来的编程智能体，竞争焦点会从“写得多快”转向“能不能独立把一个项目做完”。这才是AI编程从演示走向生产的关键一步。