不用再换编辑器了：Android Studio Rabbit 2 稳定版，让 Claude、Codex 住进 IDE 里

10 月 28 日，在 Android Dev Summit 上，谷歌把一件早就预告过的事正式推到了稳定版：Android Studio Rabbit 2 发布，里面的 Bring Your Own Agent（自带智能体，简称 BYOA）也随之转正。这意味着，做 Android 开发的人不再需要在“我习惯的 agent”和“IDE 自带的那套工具”之间二选一——Claude Agent、OpenAI 的 Codex、谷歌自己的 Antigravity，以及另外 40 多个支持开放 Agent Client Protocol（ACP）的编码 agent，现在可以直接装进 Android Studio 里跑。

先把一个容易误读的点说清楚：BYOA 本身不是 10 月 28 日才冒出来的新功能。它在 9 月 24 日就以 Canary 预览的身份出现过。这次的新闻是它进了稳定版。换句话说，谷歌不是在发布一个实验品，而是在告诉所有人：这条路可以当作日常开发的工作方式了。对还在观望的人来说，这个区别很重要——预览版可以试试看，稳定版才值得往团队流程里放。

到底发布了什么

核心变化是 IDE 的态度变了。以前 Android Studio 里的 AI 助手是谷歌自家的，别的 agent 只能待在终端里，隔着一层看你的项目。现在 BYOA 把外部 agent 请进了 IDE 内部：打开 Settings > Tools > AI > Agents，就能从市场里浏览、安装 agent，而且可以同时装好几个，干活时随时切换。你不用为了换一个 agent 就关掉 IDE、另开一个窗口。

更关键的是，装进来的 agent 能拿到 IDE 自己才有的那套理解：项目结构和构建配置、符号解析、Compose Preview 渲染、模拟器、Logcat。谷歌的说法是，agent 因此不只是“读你打开的那个文件”，而是能像一位坐在 IDE 里的同事那样工作：改完界面去跑模拟器，出错了去翻 Logcat，再回来改。这个差别，恰恰是终端里的 agent 最吃亏的地方——它看不到你项目的全貌，验证一步就得多问你一次。

同一批更新里还有几件值得单拎出来的事。第一是 Change Review，一个新的 agent 式代码评审体验：可以从待处理的 agent 改动或者 Git 改动窗口发起评审，IDE 会生成一份潜在问题报告；也可以在 agent 工具窗口里用 /review 命令触发，或者让 AI 带着你一步步看懂一处比较长的改动，再让 agent 去修它发现的问题。谷歌自己也承认，agent 一次改动太多时，人很难看懂它到底干了什么——Change Review 就是冲着这个痛点来的。

第二是 Android Bench 2.0。这是一个评估大模型和 agent 套件在真实 Android 开发任务上表现的榜单，任务是那种工程师要花几天才能做完的活，比如迁移一套界面或者照着设计稿从头做一个应用。评分标准值得注意：看的是做出来的东西是不是真的能用，而不只是能不能编译过，同时还量成本和耗时。对选模型的人来说，这比只看基准分数实在得多。

第三是 Android CLI 的补强，这条线不需要开 IDE 也能用。终端里新增了几条能力：用 android device remote 从谷歌的设备实验室拉一台真实物理设备来测；android preview 可以不启动模拟器、不部署 APK 就渲染 Compose Preview；官方的 Android 插件也已经上架 Claude Code 和 Codex，装法就是一条 marketplace 命令。对习惯在终端里指挥 agent 的人来说，这条线可能比 IDE 里的 BYOA 更先用上。

第四是性能分析那条线。LeakCanary 现在直接集成进了 Android CLI，堆转储在你自己的电脑上分析，而不是在设备上跑，谷歌称用它之后，最强的模型找内存泄漏几乎快了一倍、token 还省了最多四分之一——注意，这是谷歌内部测试的说法，不是独立评测，引用时要带上这个定语。另外，Android Performance Analyzer 的能力也进了 CLI，配合新的 android-profiler 技能，agent 可以抓 trace、分析结果、提修复、验证改动、再量一遍效果，形成一个闭环。还有 android signals 命令，能把生产环境的崩溃、ANR 和内存问题直接拉到终端里给 agent 看。

此外，XML 界面迁移到 Compose 的 Migration Assistant 也来了，不过目前还在 Canary 版：对着 XML 布局点右键选 AI > Migrate to Compose，或者在整个项目上跑，agent 会先和你一起定范围、起草计划，再把布局、视图绑定代码和逻辑转成 Compose 写法，进度时间线会记下来，中途停了也能接着来。谷歌还提到官方 Android 技能已经超过 30 个、覆盖 20 多个领域，包括上架前的 Play 政策检查和 Intent、权限安全审查。这些都不是主角，但拼在一起看，谷歌的意图很清楚：让 agent 从“写代码”扩展到“从生产信号到验证修复”的整条链。

为什么这件事值得认真看

过去一年，AI 编程工具的竞争大多发生在“模型谁更强”上。但 Android Studio 这次的动作指向另一个战场：谁离开发者的真实工作环境更近。一个只能读文件、改文件的 agent，和一个能跑模拟器、读 Logcat、查生产崩溃的 agent，干的根本不是同一种活。前者给你一段看起来对的代码，后者有机会把“改完、跑通、验证”这三步自己走完。谷歌赌的就是后者更有价值。

这里还有一层平台意味。谷歌没有把 Android Studio 做成只推自家 Gemini 的店面，而是把 Claude 和 Codex 请了进来。这在几年前是很难想象的：平台方通常会把自家助手放在最顺手的位置，把别人的工具挡在门外。现在谷歌反过来了——它承认开发者已经有了自己付费的 agent，与其逼他们换，不如把 IDE 做成一个能容纳所有 agent 的地方。对谷歌来说，IDE 的位置比某一个助手的位置更重要；对开发者来说，选择权回到了自己手里。

对国内的 Android 开发者和独立开发者而言，还有一个现实意义：很多人做的是跨端或者副业项目，时间本来就碎。如果 agent 能在 IDE 里直接把“改界面—跑模拟器—看日志—再改”这个循环跑起来，省下的不只是几次切换窗口，而是每次切换都会丢掉的上下文。以前你得自己把报错贴给终端里的 agent，现在 agent 自己就能看到报错。这一步看起来小，但它是“ vibe coding 能不能真的交付一个可用的 Android 应用”的关键一步。

对 vibe coding 开发者具体意味着什么

如果你正在用 AI 做 Android 应用，或者打算做一个，可以按下面这个顺序试。第一步，先升级到 Rabbit 2，把你已经在用的 agent 装进 IDE：Settings > Tools > AI > Agents 里装好、登录你自己的订阅。注意，BYOA 不是免费送 agent——你用的是你自己的订阅和额度，谷歌自带的 agent 仍然免费可用，但外部 agent 的账单归各家服务商。先把这个账算清楚，再谈效率。

第二步，别一上来就让 agent 大改。先给它一个小任务做“体检”：比如让它解释某个界面是怎么管理状态的，涉及哪些文件，改之前先提方案不改代码。看它对项目结构的理解准不准，再决定给它多大的权限。这个体检花不了十分钟，但能帮你避开“agent 自信满满地改错地方”的常见坑。

第三步，把验证交给 agent，但把验收留在自己手里。具体做法是：让 agent 改完之后自己跑模拟器、读 Logcat，并且用 Change Review 走一遍它自己的改动；你最后只看三件事——行为变了什么、为什么这么改、怎么验证是对的。如果这三件事你讲不清楚，就别合并。这条规矩对 AI 生成的改动尤其重要，因为代码量越大，人越容易“看着像对的就放过去”。

第四步，如果你习惯终端工作流，别忽略 Android CLI 那条线。android preview 不用起模拟器就能看 Compose 界面，对反复调界面的场景很划算；android signals 能把线上崩溃直接喂给 agent，修线上 bug 时比“把堆栈贴来贴去”省事得多。这两条命令都不需要你换 IDE，适合先小规模试。

第五步，选模型时别只看广告。Android Bench 2.0 的思路值得借鉴：找一个你自己的真实任务，比如“把这个列表页从 XML 迁到 Compose”或者“修掉这个内存泄漏”，让候选的 agent 各跑一遍，量三样东西——能不能跑起来、花了多少 token、花了多长时间。榜单是参考，你自己的任务才是标准。

风险与还没定下来的地方

有几件事现在还不能下结论。第一，agent 拿到 IDE 的深层能力之后，权限边界怎么划？谷歌在 Canary 时期的说法是，细粒度权限可以让 agent 自己处理常规工作、在风险操作前停下来等你批准，但具体到你的项目里，哪些操作算“常规”、哪些算“风险”，还得你自己在实践中划线。特别是 agent 能跑模拟器、执行命令的情况下，别默认它什么都不会碰坏。

第二，谷歌内部测试的那些数字——预览快 77%、token 省 3 倍、找泄漏快一倍——都是厂商自己的测试，不是第三方复现的结果。机制上说得通（不起模拟器当然更快），但落到你的项目上能省多少，得自己量。别拿着厂商数字去跟老板或者客户承诺工期。

第三，BYOA 的生态还处在“数量先行”的阶段：40 多个 agent 都能装进来，不等于每个都同样好用。不同 agent 对 ACP 的实现深度、能调用的 IDE 工具范围、出错时的表现都会有差别。建议先锁定一个主力 agent 用熟，再把第二个当作对照组，而不是一次装十个轮着试。

第四，Migration Assistant 还在 Canary，Lightbuild 这类构建新尝试也还是早期预览，生产项目别急着上。稳定版的 BYOA 和 CLI 插件可以先用，Canary 里的东西适合拿一个不重要的分支去试。

再拆细一点：IDE 里与终端里的两条线怎么分工

这次发布最容易让人犯迷糊的地方，是它同时给了两条线：一条是 IDE 里的 BYOA，一条是不开 IDE 也能用的 Android CLI。两条线用的都是同一套 Android 能力，但适合的人和场景不一样，分不清就会出现“装了一堆工具、每样都只用一半”的情况。

IDE 这条线适合的，是每天大部分时间本来就泡在 Android Studio 里的人。它的好处是上下文最完整：agent 能看到项目结构、构建状态、符号关系，还能直接调模拟器和 Logcat。坏处是，它把你绑在 IDE 里——如果你习惯在终端里同时管好几个项目、或者喜欢用脚本把流程串起来，IDE 里的 agent 反而会显得笨重。对这类人，CLI 那条线更对味：命令可以写进脚本、放进 CI、半夜跑定时任务，不用开着一个图形界面等它。

一个实用的分工是：日常开发、调界面、修当下这个 bug，走 IDE；批量验证、线上问题排查、跨项目重复执行的活，走 CLI。比如你要把十几个界面的 Compose 预览逐个过一遍，用 android preview 在终端里循环跑，比在 IDE 里一个个点开要快；你要修一个线上崩溃，用 android signals 把生产信号拉到终端里给 agent，agent 能在同一个地方查崩溃、改代码、跑测试。但如果你正在一个新界面上反复抠细节，IDE 里的 agent 能一边看预览一边改，循环更短。

Change Review 的位置也值得单独讲一句。它不是传统意义上的“跑个 lint 就完事”的检查，而是一次带讲解的评审：先生成问题报告，再用 AI 引导你看懂长改动，最后让 agent 去修。这个顺序很重要。很多人用 AI 评审时犯的错，是直接让它“修掉所有问题”，结果修出来的东西自己也没看懂。正确的顺序是先看懂、再决定修哪些、最后才让 agent 动手。Change Review 的设计恰好把这个顺序固定下来了：报告在前、讲解在中、修复在后。如果你把它当成一键修复工具用，就浪费了它最有价值的那一步。

Android Bench 2.0 也值得多说两句。它的任务设计有一个细节：任务是工程师要花几天才能做完的活，而不是几分钟就能跑完的小测试。这意味着它量的是“能不能把一个真实任务从头做到尾”，而不是“能不能答对一道题”。对选型的人来说，这个区别很大：很多模型在小任务上分数很好看，一到多文件、多步骤、需要反复验证的长任务就掉链子。如果你要自己搭评估，照着这个思路来：别用玩具任务，用你项目里真实存在、且你已经知道正确答案的任务。

给不同人的试用清单

如果你是一个人做副业 Android 应用，试用清单可以很短：升级 Rabbit 2，装好你已经在付费的那个 agent，做一次前面说的十分钟体检，然后只开 Change Review 这一项新能力。别急着把 CLI、Bench、迁移助手全套都接上。副业项目最缺的是时间，全套接上反而会把时间花在配工具上。等 IDE 里这条线跑顺了一个月，再按需加 CLI 的一两个命令。

如果你带一个小团队，清单要多两项。第一项是定权限：哪些操作 agent 可以自己做，哪些必须等人批准，先写下来再开给全员。特别是能执行命令、能跑模拟器的能力，别默认所有人、所有项目都一个标准。第二项是定验收：PR 里 AI 改动的部分，必须附上“行为变了什么、为什么这么改、怎么验证”三句话，缺一句就打回。这条规矩写进团队的 PR 模板里，比口头提醒管用得多。

如果你是刚学 Android 开发的新手，这次发布对你反而要更谨慎。agent 能直接在 IDE 里跑，意味着你更容易“还没学会，就先依赖”。建议的用法是反过来的：先让 agent 讲、再让 agent 做。让它解释某个界面的状态管理、让它带着你走一遍 Change Review 的报告，等你能自己讲清楚这段代码在干什么，再放手让它改。新手最需要的是理解，不是产出速度；理解跟不上，产出越快，欠的债越多。

还有一个容易被忽略的细节：自带订阅到底意味着什么。BYOA 的意思是你把自己在 Claude、Codex 或者其他服务商那里的订阅带进来，在 Android Studio 里用，而不是谷歌替你买单。好处是选择权在你手里，坏处是账单会变得分散：IDE 里用的额度、各家 agent 自己的额度、还有可能产生的额外调用，都要分开算。团队试用时，建议先让一两个人跑两周，把“每个任务实际花了多少 token、多少钱”记下来，再决定要不要全员铺开。没有这两周的实测数据，任何关于“效率提升”的说法都只是推测。

一句话总结试用节奏：先升级、先体检、先开评审，再按需加终端命令；权限与验收规则先写下来，再给全员开。工具越是强大，前面这几步就越不能省。

补充一点：升级之前先看一眼你项目的 Gradle 与 AGP 版本是否在 Rabbit 2 的支持范围内，旧项目直接升级 IDE 有可能先遇到构建插件的兼容问题。先在分支上升级、跑通一次完整构建，再切到主分支，这个顺序能省掉很多返工。

最后说一句判断：Android Studio 这次不是在比谁的模型更聪明，而是在比谁的工作台更完整。对 vibe coding 的人来说，这其实是个好消息——工具越是贴近真实的开发流程，你用自然语言指挥 agent 做出来的东西，就越接近一个真正能跑、能修、能上架的应用。但前提始终没变：验证的那一步，不能外包给 agent 自己。