Rabbit 2 接入 40+ AI 智能体：Android 开发工作流的变化

过去使用 AI 生成 Android 代码时，开发者往往要反复“搬运”：让模型生成代码，回到 Android Studio 编译、运行，再把 Logcat、项目结构和构建错误重新整理到对话中。模型能看到代码，却未必理解代码所在的应用、模块和运行环境。

Rabbit 2 的关键变化，是让编程 Agent 直接接入 IDE，并获得项目结构、符号解析、构建诊断、Logcat、Compose Preview 和模拟器等能力。它已稳定支持 Bring Your Own Agent，也就是 BYOA，目前可通过 ACP 接入 40 多个兼容 Agent。这里的“40+”指可通过 ACP 接入的兼容 Agent 范围，不是 Android Studio 预装了 40 个模型，也不代表这些 Agent 可以同时运行。

“40+ AI Agent”是内置还是可接入？

答案是“可以接入”，而不是“已经内置”。Rabbit 2 在 Android Dev Summit 2026 上把 BYOA 带入稳定版，公开资料列出的兼容 Agent 包括 Claude Agent、OpenAI Codex 和 Google Antigravity 等。

开发者可以在 Settings > Tools > AI > Agents 中安装兼容 Agent，使用自己的订阅或 API Key，并按任务切换不同工具。 现有资料使用的是“ACP 兼容”这一口径，因此不能把“40+”进一步理解为一份由 Google 逐个认证的 Agent 榜单。

这组数字的实际意义是：Rabbit 2 没有试图规定开发者必须使用哪个模型，而是把接入边界从特定产品扩展到了开放协议。对团队而言，这意味着可以根据代码库规模、任务类型、成本和已有订阅选择工具，而不必围绕单一模型重做工作流。

Gemini、Agent Mode、BYOA、ACP 与 MCP 如何分工？

Gemini 与 Agent Mode 关注的是 IDE 内的任务执行方式：开发者可以与模型对话，让它完成代码修改、调试或分析。BYOA 关注的是接入方式——开发者可以把符合要求的外部编程 Agent 安装进 Android Studio。BYOA 在现有 Agent 能力之外增加了一条外部接入路径，并未取代 Gemini。

ACP，即 Agent Client Protocol，负责 IDE 与编程 Agent 之间的通信。它让不同 Agent 可以通过统一方式获得 Android Studio 提供的能力，而不必分别针对每个 Agent 开发一套集成。MCP 位于更外层，主要解决 Agent 如何连接外部工具和数据源。简单说，ACP 关注“Agent 怎样进入 IDE”，MCP 关注“Agent 怎样在 IDE 外调用工具”。

BYOA 带来的变化是增加模型与供应商的选择权。Rabbit 2 允许安装多个 Agent 并根据任务切换，但“支持多个”和“同时执行多个”仍然是两件事。

“接入多个 Agent”等于“同时跑多个 Agent”吗？

Quail 2 的 Agent Mode 已经支持多个 AI 对话并行运行，开发者可以分别处理界面重构、构建规则修复或文档生成；同时，Agent Mode 也支持 Gemini 之外的多种模型。 Rabbit 2 这次稳定化的重点，则是 BYOA，以及 40 多个 ACP 兼容 Agent 的安装和切换能力。

因此，“40+”描述的是可接入的 Agent 范围，而不是并发数量，更不是系统会同时启动 40 个 Agent。并行会话解决的是多任务调度问题，BYOA 解决的是工具可选择性，两者可以同时存在，但不能混为一谈。

实际使用时，先安装几个互补的 Agent 已经足够。例如，可以用一个 Agent 负责日常代码修改，用另一个专门处理构建或性能问题，再用一个用于独立审查。是否有必要增加更多工具，应由任务覆盖情况决定，而不是安装数量。

接入后，Agent 能拿到哪些项目上下文？

Rabbit 2 的一项关键变化，是让 IDE 能力成为 Agent 可以调用的上下文。

接入后的 Agent 可以使用项目结构理解、符号解析、构建诊断、Logcat、Jetpack Compose 界面预览和模拟器。这意味着 Agent 不只接收开发者粘贴的代码片段，还能把代码与具体模块、界面和运行诊断联系起来。

这能减少原有工作流中的上下文损耗。以前，开发者可能先生成代码，再手动补充依赖版本、相关类、错误日志和预览结果；现在，这些信息可以通过 IDE 提供给 Agent。它尤其适合处理跨文件修改、Compose 界面调整和构建错误，因为这些问题往往不是靠单段代码就能判断的。

不过，获得 IDE 上下文不等于可以跳过验证。Agent 能读取 Logcat，不代表它总能正确解释日志；能打开模拟器，也不代表生成的交互符合产品需求。更完整的上下文主要能减少信息搬运和上下文漂移，而不是替代测试。

官方 Skills 能补齐哪些 Android 专属知识？

通用模型可以生成 Java 或 Kotlin 代码，却未必持续掌握最新 Android API、性能规则和安全要求。Rabbit 2 同期加入的官方 Android Skills，用于补充这类 Android 专属知识。

Google 官方称，IDE 的 Skills 管理器已经提供 30 多个 Skills，覆盖 20 多类 Android 开发问题。开发者输入 @ 即可选择，其中包括 agp-9-upgrade、android-profiler、r8-analyzer 和 camerax 等。

ACP 与 Skills 解决的不是同一层问题：ACP 提供通信接口，Skills 提供与具体任务匹配的知识和指导。前者决定 Agent 能否顺利进入开发环境，后者决定它在升级、性能分析、混淆规则或 CameraX 等任务中能补充多少 Android 专项信息。

对团队而言，Skills 的价值还在于统一实践入口。与其要求每位开发者分别向模型解释项目采用的版本、检查规则和推荐流程，不如把相关指导放进 IDE。模型输出仍可能出错，但至少输入侧的信息来源更加一致。

Agent 改完代码，谁来检查和继续修复？

代码生成速度提高之后，代码审查会成为瓶颈。Rabbit 2 新增的 Change Review，用于审查代码修改。

开发者可以从 Agent Changes、待提交的 Git Diff 或历史 Commit 发起审查。系统会先生成潜在问题报告，再把分散在多个文件中的相关修改组织成 Walkthrough，便于按照功能关系查看变更。规模较大的代码修改还可以通过 /review 命令交给 Agent 检查；发现问题后，可继续让 Agent 修复。

这套机制解决的是“修改规模大于人工逐行检查耐心”的问题，但它不能被当作免检证明。潜在问题报告本质上仍是辅助信号，Walkthrough 也只是重新组织变更视图，最终仍要由开发者判断改动是否符合业务要求、测试是否充分。

更合理的工作方式是让 Agent 完成修改和第一轮自审，再由人检查高风险部分，随后通过模拟器或真机验证。Change Review 让这条闭环更顺畅，但没有消除代码审查本身。

Android Bench 2.0 能怎样帮助选择模型与 Agent？

Agent 数量变多之后，新的问题是如何判断哪个模型与 Agent 组合更适合 Android 开发。Android Bench 2.0 正是为这一问题设计的。

它使用真实 Android 开发任务评估不同模型与 Agent 组合，例如根据设计稿构建应用、迁移界面。除了检查代码能否编译，它还会验证最终功能是否正常，并衡量完成任务所需的时间和成本。

这比单纯比较代码生成片段更接近实际开发，因为一个 Agent 即使能快速产出可编译代码，也可能在跨文件迁移、组件状态或功能完整性上失败。耗时和成本则进一步影响它在日常工作中的可行性。

但基准结果不应被当作绝对排名。测试任务无法覆盖每个项目的业务规则、遗留代码和发布约束，更稳妥的做法是把 Android Bench 当作初筛，再用自己的代码库和真实任务做第二轮验证。

真实设备测试如何进入终端、脚本和 CI？

Android CLI 将 Android 开发能力扩展到终端、自动化脚本和持续集成流水线，Agent 因此不必始终运行在完整的 Android Studio 中。

其中，android device remote 可以从谷歌设备实验室申请真实 Android 设备，用于安装和测试应用；Android Device Hub 则提供统一界面，用于管理本地设备、远程设备和模拟器。 开发者还可以通过相关命令获取界面预览、UI 截图和组件树导出，再交给 Agent 分析。

android device remote
android preview

模拟器适合覆盖大量常规场景，但真实设备上的硬件差异、系统行为和厂商实现仍可能暴露模拟环境无法复现的问题。把真实设备纳入 Agent 工作流，意味着问题发现、修改和验证可以继续沿同一条链路推进，而不是等应用进入人工测试阶段后重新交接。

对 CI 而言，这提供了接入真实设备测试的基础能力，但不意味着测试可以完全无人值守。设备申请、任务稳定性、失败重试和结果判断，仍然需要设计可靠的自动化流程。

性能、崩溃分析与构建优化也进入 Agent 链路了吗？

部分能力已经进入，部分则仍属于同一工具链中的配套更新。

Quail 2 已将 LeakCanary 的堆分析集成到 IDE，把分析任务从资源受限的测试手机转移到桌面端。Google 称，这种方式可使泄漏追踪最高提速五倍，并让测试应用在设备上保持更流畅的运行。 App Quality Insights 也已与 Android Studio 集成，Agent 可以综合堆栈信息、设备数据和源代码分析崩溃原因，提出分步骤的修复建议。

同一阶段的开发工具还引入了 Firebase Crashlytics 集成、R8 配置分析和声明式 Lightbuild 实验项目，分别覆盖崩溃诊断、混淆规则理解与构建优化。 这些能力补充了 Agent 在构建、运行和质量诊断方面的信息。

但自动建议仍不是自动验收。崩溃根因分析、内存泄漏定位和 R8 调整都需要开发者审查修改，并在真实环境中重新验证。Agent 可以缩短诊断路径，但发布责任仍由开发者承担。

普通开发者应该先安装全部 40+ 个 Agent 吗？

没有必要。更稳妥的起点，是选择一个与日常任务匹配的 Agent，先跑通“任务修改—IDE 诊断—Change Review—模拟器或真机验证”的闭环，再根据 Android Bench 和实际项目结果决定是否增加或更换组合。

例如，日常以 Compose 和业务功能开发为主，可以先选择一个能稳定读取项目结构和 Compose Preview 的 Agent；如果团队经常处理升级或构建问题，再补充对应 Skills 或专业工具。只有当现有 Agent 无法覆盖某类任务时，再评估新的接入对象。

这种做法比一次装满所有 Agent 更容易建立使用习惯，也能避免把“模型更多”误当成“流程更高效”。评估接入效果时，应关注每一步输出是否可诊断、修改是否可审查、结果是否可重复验证。

Rabbit 2 正在把项目理解、界面预览、日志、审查、评测和真机验证串成 Agent 可调用的开发闭环。接下来，拉开差距的会是闭环的可靠性，而不是 Agent 数量。

封面图：Android Studio Chipmunk running on macOS，作者 Software:，CC BY-SA 4.0，来自 Wikimedia Commons