安卓开发者大概都有过这种别扭：IDE 里的那个 AI 助手是谷歌自家配的，你想用 Claude 或者 Codex，只能在终端里另开一个窗口，让它靠搜索一点点把项目结构猜回来。猜错一次，改半天。
十月二十八日的 Android Dev Summit 上，谷歌把这道门推开了。Android Studio 的 Rabbit 2 版本支持「Bring Your Own Agent」，通过开放的 Agent Client Protocol，四十多个编程智能体可以直接装进 IDE，包括 Anthropic 的 Claude Agent、OpenAI 的 Codex 和谷歌自己的 Antigravity。装完能同时开几个，随时切换。
这条消息本身不算意外，意外的是谷歌顺手配套的三样东西：一张考卷、一个查作业的、一套命令行接口。三样凑在一起，这件事才从「多支持几个模型」变成了「智能体写的代码开始要验收」。
具体怎么装，装进去能拿到什么
入口在设置里：Settings 下的 Tools、AI、Agents，从内置市场里挑，可以装不止一个。
装进去的智能体拿到的不是一段提示词，而是 Android Studio 已经知道的东西：项目结构和构建配置、符号解析、Compose Preview 渲染、模拟器、Logcat。这一点是关键差别。终端里的智能体要靠搜索文件重建对项目的理解，每换一个任务就重建一次；IDE 里的智能体直接继承这份理解，省掉的是「摸索」这段消耗。
顺带说一个容易漏掉的细节：通过 BYOA 登录 Google Antigravity，能拿到谷歌最新发布的 Gemini 模型，以及 Antigravity 后续下放的新能力。也就是说，用第三方的智能体，并不耽误用谷歌自己的模型。
那张考卷：不只看编译过没过，还看花了多少钱
Android Bench 2.0 是这次发布里我觉得最值得单独讲的一项。
它是一个模型榜单，但测的不是「写一段快排」，而是长周期的真实安卓开发任务，比如把一个应用的界面迁移掉，或者照着一份设计稿从零搭一个新应用。题目按「一个安卓工程师要干几天」的量级设计。
打分方式有三列：功能是否真的能用、花了多少时间、花了多少钱。官方明确说，不看能不能编译通过，看的是跑起来对不对。
这个口径变化比分数本身重要。过去一年大家比的是跑分，跑分高的模型接到真实项目里照样把代码写成一团；加上时间和成本两列之后，一个模型贵而快、另一个便宜而慢，选择才变成一个可以算的题。团队真正在意的是「这个改动值不值这个钱」，而不是某个测试集上多两分。
77% 和「省三倍 token」，先别急着信
发布里最抓眼球的两个数字，都来自谷歌的内部测试。
一是 Android CLI 新增的预览命令，能在终端里渲染 Compose 预览，不用启动 IDE 也不用开模拟器。谷歌说智能体完成界面任务快了 77%，token 消耗最多降到三分之一。
二是把开源的 LeakCanary 接进了命令行和 Profiler，堆转储在电脑上分析而不是在手机上，测试时应用不会卡。谷歌用 Claude Opus 5.5 做了一次对照实验，找内存泄漏并修好的速度快了将近一倍，token 少用了大约四分之一。
这两个数字的测量方法，谷歌没有公开。有媒体追问那 77% 是怎么算出来的，得到的答案并不具体。所以我的建议是：把它当方向，不当承诺。方向是对的——给智能体一套它自己能读懂的接口，总比让它猜要省；具体省多少，得在你的项目上量。
一个替你查作业的，可能才是最实用的
智能体写完代码，真正难受的是评审。一次改动几千行，看完也不知道它到底动了什么。
Change Review 就是冲这个来的。从待审的改动或者 Git 变更窗口发起一次评审，Android Studio 会生成一份潜在问题报告；也可以在智能体窗口里用斜杠命令直接调起来；改动太长，可以让它带着你一步步走读；发现问题，可以让智能体自己回去修。
同一套思路还落在另外两处。Canary 版里的迁移助手，右键任何 XML 布局选 AI 分类下的「迁移到 Compose」，智能体会先跟你确认范围、出方案，再把布局、视图绑定代码和逻辑转成符合习惯的 Compose 写法，进度条会显示跑到哪一步、断了从哪接上。正在测试的 Lightbuild 则把构建配置改成 YAML 声明式，人和智能体都能读能改。
这三件事指向同一个判断：智能体不难用，难的是让它交出的东西可检查。
怎么在自己项目上验一遍
看发布不如自己动手。给一套最小验证：
第一步，挑一件小事。不要一上来迁移整个界面，选一个泄漏排查或者一个小 Compose 改动，半天能收尾的那种。
第二步，同一件事跑两遍。一遍用你现在的终端智能体，一遍装上 Android CLI 插件在 IDE 里跑，记三个数：实际耗时、token 消耗、人工返工次数。第三个数字最容易被忽略，也最能说明问题。
第三步，所有改动过 Change Review 或者过人。这条不是形式主义。有报道提到过一组数字：某次自动化扫描报出约两万九千个潜在开源漏洞，真正被修的只有几百个。找问题比修问题容易得多，智能体的产出如果没有验收环节，堆起来只会更快。
谁该现在装，谁可以先等等
安卓团队、而且已经在给 Claude Code 或 Codex 付费的，值得这周就试：装一个插件，跑一件真实的小事，成本几乎为零，收益是知道自己团队到底适不适合让智能体碰生产代码。安卓这条线的工具选择，可以先看AI编程工具专题，再看老达之前整理的选型对比。
只是偶尔写写 Demo、或者项目还在早期阶段的，可以先放着。BYOA 的价值在「团队已经有固定的智能体工作流」，没有这个前提，多装几个只是多几个窗口。
老达点评
这次发布最容易被误读成「谷歌服软了，不再逼你用 Gemini」。我觉得不是。谷歌让出的是入口，收回来的是标准。
四十多个智能体进得来，但都要走 ACP；模型可以随便换，但比高低的尺子是 Android Bench 2.0，题目是谷歌出的，评分口径也是谷歌定的；改动可以随便写，但要过 Change Review。入口开放、出口收口，这比守着一个自家助手要聪明得多，也更接近智能体真正进工作流的样子。
对比上次 JetBrains 发 Air 时的思路，那次的重点是「编辑器不绑定自家智能体」，是把选择权交出去；这次谷歌多做了两件事：给出可比的榜单，给出可验收的流程。前者解决「选哪个」，后者解决「选完敢不敢用」。真正把智能体推进生产环境的，往往是后面这一半。JetBrains 那次的思路我写过一篇单独的拆解，放在一起看更清楚。
对国内开发者来说还有一层现实：ACP 这类协议一旦成为事实标准，工具链的竞争就从「谁的模型强」转到「谁家的工程接口更懂业务」。这条路上，安卓这套东西值得抄的不是功能列表，是那个「先出考卷再卖工具」的顺序。
至于智能体跑长任务会不会半路断掉、断了能不能接上，这是另一条正在被补的短板，Vercel 那个断点续跑的包和把智能体拆成文件夹的思路都在解决这一头。安卓这次把「可检查」写进了 IDE，算是同一件事的另一半。
