Android Studio 正式开放 Agent，ACP 让 IDE 能力也跟着过去
这个其实之前聊过了，最直接的变化是 Bring Your Own Agent（BYOA）在 Rabbit 2 进入稳定版 ，它其实 9 月就在 Canary 里就有了，当时我们也聊过了，现在 Android Studio 可以通过开放的 Agent Client Protocol（ACP） 接入 40 多种兼容 Agent，还支持你装几个 Agent 随时切换，入口在 Settings > Tools > AI > Agents，可以使用自己的订阅或者 API Key ：
ACP 可以简单理解成 IDE 和编程 Agent 之间的通用通信接口，然后 Android Studio 负责提供项目结构、符号解析、构建诊断、Logcat、Compose Preview、模拟器等能力，Agent 可以在对话过程里面调用这些。
它跟 MCP 的位置不太一样：ACP 主要解决编辑器怎样和 Agent 对接，MCP 更偏向 Agent 怎样接外部工具。
而且 Google 现在把官方 Android Skills 也放进了 IDE 管理器，直接输入 @ 就能挑选，比如 agp-9-upgrade、android-profiler、r8-analyzer、camerax，目前官方称有 30 多个 Skill，覆盖 20 多类 Android 开发问题，重点补模型对新 API、性能和安全规则不了解的地方：
当然，说不准你多久没开过 Android Studio 了？本来给 Agent 内存就不够，开个 AS 不炸了？
林外 Android Studio 还加了 Agent 改完代码以后谁来审的支持，Change Review 可以从 Agent Changes、待提交的 Git Diff，甚至历史 Commit 发起，支持先找可能的问题，再把分散在多个文件里的相关修改组织成 Walkthrough，让开发者按功能关系看改动，Agent 也能继续处理发现的问题：
当然，前提是你还审代码。
Google 自己的 Android Bench 2.0 就已经把任务做到跨文件迁移、从设计稿创建 App 这种长链路，按 10 月 29 日榜单 Claude Sonnet 5.5（max）配 Claude Code 在 30 个任务上的通过率也只有 40% 。
另一个例子是 XML Views 迁移 Compose，现在右键 XML 可以选 AI > Migrate to Compose，Agent 会先分析布局、关联的 ViewBinding 和控制逻辑，形成迁移计划，随后按步骤执行，进度还能随会话保存，不过这个 Migration Assistant 目前属于 Canary 功能，而且迁移后涉及导航、状态和旧 View 共存的行为：
Android CLI 把真机和 UI 验证搬进终端
有点割裂的是， Android 官方也知道大家不怎么打开 IDE 了，所以另一条线是 Android CLI，它之前已经有安装、运行、读取页面结构和操作 UI 的命令，这次补上的 android preview ：
直接在终端把
@Preview渲染成 PNG，还可以用--component-tree额外导出组件树 JSON，不用启动模拟器，也不用开 Android Studio。
比如 Agent 改完一个 Compose 页面，就能直接取得预览图片和组件结构，再依据任务要求检查布局。
Google 说内部 UI 任务测试里，使用 android preview 的 Agent 完成任务快了 77%，Token 最多减少到原来的三分之一。
真机也被接进了这条链路。android device remote 可以从 Google 的设备实验室预订物理设备，然后把它连接到本机 adb，后续安装、运行、调试的方式就和本地设备接近，android device hub 也提供了独立的设备画面与交互窗口，同时能看本地模拟器和远程真机：
比如你要让 Agent 检查一个登录后的页面，可以先构建安装 App，再通过 android layout 读可访问的 UI 结构，用 android input 点击、输入和滑动，最后截屏验证。
如果只是检查 Compose 的静态布局，就先跑 android preview，省掉启动整台设备的开销，Google 甚至给 Claude Code 和 Codex 发布了官方 Android CLI 插件：
sql
codex plugin marketplace add android/android-cli-plugin
codex plugin add android-cli@android-cli-plugin当然这对 Flutter 也有启发，Flutter 也搞了一套自己的 AI Plugin ，这里 Android 端的 APK 安装、设备操作、截图和系统 Trace 可以借用同一套底层工具。
三、性能分析
Google 这次还展示了一个很完整的例子：
给 Claude Code 一批用户操作流程，让它找出 App 里的内存泄漏，Agent 在不同模拟器上并行执行流程，抓取 Heap Dump 后交给开发机上的 LeakCanary 分析，这样设备端就不用承担完整的堆分析工作，接着沿着对象引用链回到代码修复，最后重新跑流程确认。
也就是同一 Claude Opus 5.5、同一 Prompt、同一批 45 条用户流程、6 台 Android 模拟器，4 万行代码的开源 App，在 Apple M4 Pro 上运行。
- 加入 Android CLI 的一组耗时 45 分 57 秒、350 万 Token
- 没加入的一组是 88 分 17 秒、460 万 Token
也就是差不多快了 1.9 倍、Token 少了 24%。
具体怎么找到泄漏如下，它发现 ConnectivityManager 的内部回调集合持有一个匿名 NetworkCallback，而这个回调又隐式引用了 MainActivity，然后 Activity 已经退出，但系统服务还保存着回调，所以 GC 没办法把 Activity 收掉：
顺着这条引用链，Agent 就可以检查注册 NetworkCallback 的代码，把注销操作补在正确的生命周期位置，然后再次走页面进入、退出的流程，看旧 Activity 是否还会被保留。
除此之外，android signals 也把 Firebase Crashlytics 的线上 Crash、ANR 和内存问题带到了终端，线上 OOM、Android 17 Memory Limiter Kill 的 Heap Dump 还涉及 Crashlytics 提前申请的访问能力，拿到后可以结合 R8 Mapping 还原信息，再用 Perfetto 和代码去定位。
四、编译优化也开始能量化
这一轮 Android 还更新了 Android Performance Analyzer（APA）和 androidx.tracing 2.0，比如以前看 Perfetto 经常只能看到某段工作耗时很长，但下一步还得自己找代码，现在应用 Trace 可以带源文件、行号和参数，协程跨线程的工作也能通过 Flow 关联起来，Agent 可以把慢操作和具体调用点对上。
特别 Compose 1.13 的 Recomposition Tracing 更直接：它把造成重组的 State Read/Write 也写进 Trace，选中一次 State Write 就能看到调用栈，以及它触发了哪段 Composable 重组，比如某个动画状态频繁写入，页面就不断重组，原来只能看到重组次数，现在能继续往回追是谁在写这个值。
这里有个很重要的条件：Recomposition Tracing 比普通 Composition Tracing 开销更高。
R8 又可以从另一个角度解决问题，比如以前 App 体积降不下来，大家都知道要查 ProGuard/R8 的 -keep，但不知道第三方库哪条宽泛规则挡住了最多优化，之前我们也聊过，AGP 9.3 起的 R8 Configuration Analyzer 可以分别计算 shrinking、optimization、obfuscation 的覆盖分数，给 Keep Rule 排出影响程度，还能不用完整打 APK 就生成报告：
ruby
./gradlew :app:analyzeReleaseR8Config
还有个叫 Lightbuild 的实验项目，把传统可执行的 Gradle 配置换成声明式 YAML，并保存预解析依赖，方便 Agent 读取、编辑和查询构建结构，这思路其实挺有意思，不过 Google 明确建议现有和生产项目继续用 Gradle/Kotlin DSL，Lightbuild 现阶段主要适合小型新项目和原型，暂时还是个概念。
整体看下来， Android 也在对齐 AI ， 就是 KMP 反而一直没跟上，JB 在 AI 时代一直在掉队，这次 Android 官方开始把编译、设备、UI 预览、线上异常、Heap 和 Trace 统一变成 Agent 能调用和检查结果的工具接口，整体趋势和 Flutter 一样都是 AI 工具化和 AI 框架化，过去的古法编程，看起来就像是往日繁荣。