不只是"IDE 里加个 AI"
如果只是在 Android Studio 里再塞一个 Copilot 式的 AI 助手,那不值得专门写一篇文章。
Google 这次做的事更有意思------他们专门为 Agent 重建了一套工具链,包含三个独立组件:Android CLI 、Android Skills 、Android Knowledge Base。
这背后有一个清晰的技术判断:未来相当一部分 Android 开发任务,会由 Agent 直接执行,而不是由人坐在 IDE 前一行一行地写代码。如果工具链不为这个场景专门设计,Agent 拿着现有的工具(分散的 adb 命令、复杂的 Gradle DSL、不统一的 SDK 管理接口)去干活,就像让一个工厂机器人用给人类手工设计的工具------能用,但效率极低。
这篇文章把三个组件逐一拆开来看,搞清楚每个组件解决的是什么本质问题。
问题根源:Agent 用现有工具有多痛?
在聊解决方案之前,先想想 Agent 用传统 Android 工具到底哪里不顺。
一个典型场景:让 Agent 帮你初始化一个新项目,配置好开发环境,跑起来看看效果。听起来简单,但 Agent 需要依次搞清楚:
- SDK 装了哪些版本?缺什么?用
sdkmanager查,但输出格式不统一 - 项目模板从哪来?Android Studio 模板 wizard 是 GUI,没有命令行接口
- 模拟器怎么创建?
avdmanager命令参数多且不直观 - 怎么跑起来?
./gradlew还是adb install?环境不同答案不同
每一步 Agent 都要试探性地执行命令、解析输出、判断状态------大量 Token 花在了"猜测当前环境状态"上,而不是真正的开发工作。
Google 的实验数据印证了这一点:使用传统工具集时,环境配置和项目创建消耗的 LLM Token 中,超过 70% 是浪费的------不是浪费在写代码上,而是浪费在和工具的低效对话上。
Android CLI:给 Agent 的标准化接口
Android CLI 是这套工具链的基础层,本质是重新设计了 Android SDK 的命令行接口,以 Agent 的使用方式作为第一优先级。
五个核心命令
bash
# SDK 管理:按需下载特定组件,保持环境精简
android sdk install
# 项目创建:从官方模板生成项目,自动应用推荐架构
android create
# 设备管理:创建和管理虚拟设备
android emulator
# 应用部署:自动化构建与部署
android run
# 版本更新:获取最新功能与修复
android update
看起来很简单,但每个命令背后的设计逻辑值得细说。
android create 解决的不只是"帮你生成文件",而是确保生成的项目结构符合当前推荐架构------对 Agent 来说,这意味着后续所有操作都有一个可预期的项目布局,不需要花 Token 去探测"这个项目是什么结构"。
android sdk install 的关键词是"按需"。传统工具倾向于一次性装很多东西,Agent 工作流更需要精确控制------只装这个任务需要的组件,减少不确定性。
android run 把"构建→打包→安装→启动"这个多步流程封装成一个命令,避免 Agent 在中间步骤出错时的混乱。
性能数据
根据 Google 内部实验:
- LLM Token 使用量减少 70%+(相比传统工具集)
- 核心开发任务完成速度提升 3 倍
这两个数字的来源是同一个根本原因:减少了 Agent 的"猜测成本"。命令接口越标准化、输出越可预期,Agent 花在试探和解析上的 Token 就越少。
安装方式
bash
# macOS ARM64
curl -fsSL https://dl.google.com/android/cli/latest/darwin_arm64/install.sh | bash
其他平台安装包:d.android.com/tools/agent...
Android Skills:把最佳实践装进可调用的模块
Android CLI 解决了"怎么跟工具交互"的问题,但还有另一个问题没解决:Agent 怎么知道 Android 开发的最佳实践?
官方文档是给人看的------概念性的、描述性的,适合人类学习,但 Agent 执行复杂工作流时需要的是精确的、可操作的步骤化指令。Android Skills 就是填补这个空白的。
Skills 是什么
Skills 是 Markdown 格式的指令文件(SKILL.md),把特定开发任务的最佳实践封装成可被 Agent 直接调用的模块。格式遵循 Agent Skills 开放标准,不绑定特定 Agent------Gemini、Claude Code、Codex 都可以用。
每个 Skill 的文件结构:
bash
.skills/
└── skill-name/
├── SKILL.md # 必须
├── scripts/ # 可选:Python、Bash 等执行脚本
├── references/ # 可选:技术文档、API 参考
└── assets/ # 可选:模板、Schema、示意图
SKILL.md 的格式:
yaml
---
name: edge-to-edge # 最多 64 字符,小写字母、数字、连字符
description: |
帮助将 Android 应用 UI 迁移至 edge-to-edge(无边框全屏)模式,
包含 WindowInsets 处理和系统栏适配。
当用户需要实现全屏 UI 或适配刘海屏、导航栏时触发。
metadata:
author: android
version: "1.0"
---
# Edge-to-Edge 实现指南
## 什么情况下需要这个 Skill
...
## 步骤
...
几个关键约束值得注意:
description最多 1024 字符------这是 Agent 判断是否触发该 Skill 的"搜索索引",要写得既精准又包含足够多的触发关键词- 正文建议 10,000~20,000 字符(约 2,500~5,000 Token)------太短信息不够,太长则在不需要的场景里浪费 Token
- 超出范围的详细内容移到
references/目录,按需加载
初始发布的 5 个官方 Skills
| Skill 名称 | 解决的问题 |
|---|---|
navigation-3-setup |
Navigation 3 框架的配置与迁移 |
edge-to-edge |
无边框全屏 UI 实现与系统栏适配 |
agp-9-migration |
Android Gradle Plugin 9 升级指南 |
xml-to-compose |
从 XML 布局迁移至 Jetpack Compose |
r8-config-analysis |
R8 代码压缩配置分析与优化 |
这 5 个 Skill 的选择有一定规律:都是"有明确最佳实践但人工执行容易出错"的任务,恰好是 Agent 最能发挥价值的场景。
三种使用方式
方式一:通过 Android CLI 安装
bash
# 查看可用 Skills
android skills list
# 安装指定 Skill
android skills add --skill edge-to-edge
# 一次安装全部
android skills add --all
方式二:Agent 自动触发
当用户的 Prompt 与 Skill 的 description 匹配时,Agent 自动加载对应 Skill。比如用户说"帮我把 UI 改成全屏无边框",Agent 会自动找到并应用 edge-to-edge Skill,而不需要用户知道这个 Skill 的存在。
方式三:Android Studio 手动调用
在 Studio 的 AI 对话窗口输入 @edge-to-edge,直接激活对应 Skill。
Android Knowledge Base:解决 LLM 知识过期问题
即使 CLI 和 Skills 都配置好了,还有一个根本性的问题没解决:LLM 的训练数据是有截止日期的。
Android 生态更新很快------新版 API、废弃的用法、架构最佳实践的演变------这些变化发生在 LLM 训练数据截止日期之后,模型完全不知道。Agent 用过期知识给你写代码,比用错工具更难排查。
Android Knowledge Base 是专门的实时知识数据源,通过 android docs 命令访问:
bash
# 搜索权威文档
android docs search "WindowInsets edge-to-edge"
# 获取特定 API 的最新文档
android docs get "WindowCompat"
整合的四大数据源:
- Android 开发者官方文档 --- API 参考、架构指南、最佳实践
- Firebase 文档 --- 后端服务集成
- Google Developers 文档 --- 广泛的 Google 平台集成
- Kotlin 官方文档 --- 语言特性与标准库
从 RAG 的角度理解这个组件:它让 Agent 在回答 Android 开发问题时,不再单靠 LLM 的内置知识,而是检索最新权威文档作为 Ground Truth,然后基于这些信息生成回答。答案的时效性和准确性都有了可靠保障。
该组件也已集成至 Android Studio------在 Studio 的 AI 功能中,Agent 会自动调用 Knowledge Base 来增强回答质量。
工作流:CLI 起步,Studio 深化
这套工具链的设计是"分工"而非"替代",两个入口各有适用场景:
arduino
快速原型阶段
Agent + Android CLI + Skills
↓ 数秒内搭起项目骨架
↓ 安装 Skills,让 Agent 按最佳实践实现功能
↓ android run 直接跑起来验证
↓
精细开发阶段
Android Studio
↓ 可视化布局编辑器
↓ 断点调试与性能剖析
↓ Agent Mode + Planning Mode
↓ 多平台适配(折叠屏、Wear OS、Android Auto、TV)
CLI 阶段生成的项目可以直接在 Studio 里打开,没有迁移成本。对于很多重复性的开发任务(初始化项目、执行架构迁移、配置构建系统),完全可以在 CLI + Agent 阶段就搞定,Studio 只用于需要视觉化工具和深度调试的部分。
这意味着什么
三个值得关注的判断:
判断一:移动开发的 Agent 工作流正式被官方认可
Google 为 Agent 专门设计工具链,不是实验性的------这是在宣告他们认为这个工作方式已经成熟到可以提供官方支持的程度。这比任何市场预测都更有说服力。
判断二:Skills 的开放标准意味着可迁移性
Android Skills 遵循 agentskills.io 开放标准------同样的 Skill 格式,换一个支持该标准的 Agent(Claude Code、Codex、Gemini CLI)都可以用。这是刻意避免厂商锁定的设计,也预示着这个标准可能被其他平台(iOS?Web?)效仿。
判断三:Agent 选择权回归开发者
官方文档明确写着:这套工具"支持你选择任何 Agent"。这和过去的思路不同------以前是"用我的 IDE、用我的 AI",现在是"用任何 Agent,只要能用我的工具链"。这个开放姿态,本身就是一种市场判断:Agent 市场未来会是多元的,锁定 Agent 得不偿失。
快速开始
bash
# 1. 安装 Android CLI(macOS ARM64)
curl -fsSL https://dl.google.com/android/cli/latest/darwin_arm64/install.sh | bash
# 2. 验证安装
android --version
# 3. 安装全部官方 Skills
android skills add --all
# 4. 查看已安装 Skills
android skills list
# 5. 创建第一个项目
android create --template compose-app --name MyApp
# 6. 运行项目
android run
其他平台安装包:d.android.com/tools/agent...
参考资料
- Android CLI 与 Agent 工具官方文档
- Android Skills 指南
- Android Skills GitHub 仓库
- Agent Skills 开放标准
- Google 官方博客:Build Android Apps 3x Faster