devgo.cn如果你在做AI编程助手或者Agent开发，一定遇到过这个尴尬：短任务上模型表现惊艳，一放到真实项目里就崩。因为真实开发不是改一行代码，而是升级依赖、迁移框架、从零搭模块——这类活一个工程师可能要干好几天甚至一周。而过去几乎所有评测基准都只测单步修改，拿几个断言糊弄过去。Google刚发布的Android Bench 2.0就是为了填这个坑，它第一次用“长程任务”来考AI，还改了评分方式，从纯二分法变成了连续打分。
先回顾一下Android Bench是什么。这是Google几个月前推出的一个基准框架，专门评估AI模型和Agent在Android开发任务上的表现，覆盖权限、导航、连接等常见场景，并强制要求遵守Android最佳实践。原本的评测方式很传统：给模型一个仓库，让它做一个小改动，然后跑一组预定义的测试用例来判断通过还是失败。但这种方式跟真实工程差太远——真实开发里，任务往往横跨多个文件、多个模块，需要理解既有架构，还得处理没有文档的边界情况。
Android Bench 2.0的核心变化有三个。第一是引入了长程任务（Long-Horizon Tasks，LHT）。这类任务复杂度极高，Google的说法是“一个工程师要花好几天甚至一周才能完成”。具体包括升级依赖、添加新功能、从零构建应用，或者把一个跨平台应用移植到Android。这些任务天然要求模型具备规划、拆解和长程推理的能力，而不是单次调用就能搞定。第二是引入Agentic评测——让Agent（也就是能自主调用工具、迭代执行的AI系统）来跑这些任务，而不是直接让模型输出最终代码。Google说先支持对应模型厂商自带Agent，比如Gemini、GPT这类。第三是评分方式改了，从原来的“过/不过”变成了连续评分。
为什么连续评分重要？原来一个复杂任务只要有一个边界断言失败，哪怕其他几十个需求都满足了，整体就判零分。这太苛刻，也不公平——真实场景里，部分完成也有价值。现在评分基于完成率，通过功能完整性、视觉保真度、是否避免回归等多个因素加权计算，对偏离评测指令或结构约束的行为再额外扣分。这样最终结果能更细粒度地反映能力水平。比如Google给出的数据：目前榜单上最高分是Claude Opus 5.5，LHT通过率32%，紧随其后的是GPT 6 Astra，28%。这个数字看着不高，但考虑到任务难度，已经说明当前最强模型也只能完成约三分之一的长程任务，距离可用还有很大差距。
更值得琢磨的是Google在结果里发现的规律。他们总结说，AI写新代码比重构现有代码做得好。原因不难理解：重构和迁移要求理解代码库的架构复杂度，而模型在训练中见过的模式大多是“干净”的新项目任务。反过来，AI在处理一些“成熟、确定性的转换”时表现很好——哪怕代码库很大，只要规则明确，比如把Java转成Kotlin、把Retrofit换成Ktor、引入ViewModel层，这类机械性操作模型能完成得不错。但一旦任务需要运行时验证（比如依赖注入图缺失），涉及破坏性的框架变更，或者遇到未发布的库（知识空白），模型就明显吃力。最典型的是跨平台应用移植到Android，最强模型也只有80%完成率，Google称之为“依然开放的挑战”。
这组观察给开发者的直接启示是：在给AI编排任务时，要分清它的“舒适区”和“雷区”。机械性的、规则明确的转换可以放心交给AI；涉及架构理解、运行时验证、需要探索未知库的任务，人必须全程把关。这也侧面反映了评测本身的价值——不是看谁厉害，而是帮我们识别哪些环节还不行。Android Bench 2.0的仪表盘已经更新，收录了Gemini 3.8 Flash、OpenAI GPT-6、Claude Opus 5.5等最新模型，所有结果公开可查。
最后留个坑提醒：这类长程评测目前还没有覆盖到业务逻辑里的隐含约束，比如性能开销、隐私合规，所以即便模型通过率高，生产环境依然需要严格的code review和测试。但至少，现在我们有了一把能量“长任务完成度”的尺子，这比过去只看单点正确率靠谱多了。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/news/2026/10/android-bench-2/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global