Google 给 AI Agent 发了第一份官方技能包，只挑 LLM 最不擅长的活儿

仓库： android/skills
语言： Kotlin | 协议： Apache 2.0 | 今日 stars： 163 ↑
标准： Agent Skills 开放标准
兼容： Claude Code、Codex、Gemini、Google Antigravity

一、Google 做了一件反直觉的事

2026 年 10 月，Google 在 GitHub 上线了 android/skills 仓库——这是 Android 团队官方发布的 AI Agent 技能包。

反直觉的地方在于：Google 没有选择"全面覆盖"。

README 里有一句话：

"Skills focus on use cases where LLMs underperform, not where they're already proficient."

翻译过来就是：技能只覆盖 LLM 做不好的场景，不做 LLM 已经擅长的。

大多数 Agent 技能库的策略是"越多越好"——177 个技能、500 个技能、1000 个技能。Google 的策略是"越精越好"——只补短板，不锦上添花。

这个选择背后有一个判断：LLM 的通用能力已经够强了，真正卡脖子的是领域专有知识。

二、什么是 Agent Skills

如果你不熟悉 Agent Skills 标准，这里是一个 30 秒的科普：

Agent Skills 是一个开放标准（agentskills.io），定义了 AI Agent 如何加载和使用领域技能。每个技能是一个 SKILL.md 文件，包含：

• 技能名称和描述
• 何时触发（trigger conditions）
• 具体指令（instructions）
• 示例和反例

技能不是代码——它是结构化的提示词。Agent 读取 SKILL.md 后，在遇到相关任务时自动应用这些指令。

类比：Agent Skills 就像给 AI 装上了"职业资格证书"。一个通用 LLM 可以写代码，但装上"Android R8 混淆分析"技能后，它就能像资深 Android 工程师一样分析混淆规则。

三、Google 选了哪些技能

android/skills 目前提供的技能围绕 Android 开发的痛点：

• R8 Analyzer：R8 是 Android 的代码混淆和压缩工具，配置复杂、报错晦涩。LLM 对 R8 规则的理解通常停留在表面，容易给出似是而非的建议
• 其他正在开发中（仓库目前处于早期阶段）

技能数量不多，但每个都瞄准了 LLM 的认知盲区。R8 是一个很好的例子——它的规则文件（proguard-rules.pro）有自己的 DSL，报错信息指向不明确，Stack Overflow 上的回答经常过时。通用 LLM 在这个领域的表现比新手开发者好不了多少。

Google 的判断是：与其让 LLM 在所有 Android 开发任务上都"还行"，不如让它在几个关键任务上"很行"。

四、安装与使用

安装

# 安装单个技能
android skills add r8-analyzer --project=.

# 安装所有技能
android skills add --all

在不同 Agent 中使用

自动激活

技能安装后不需要手动调用。当 Agent 遇到与技能相关的任务时（比如你问"R8 混淆后这个类为什么被移除了"），技能会自动激活，Agent 的回答会自动应用技能中的领域知识和验证步骤。

这个设计很关键。如果需要用户手动 /invoke r8-analyzer，大多数人会忘记。自动激活让技能变成"隐式知识"而非"显式工具"。

五、为什么是 Google，为什么是现在

Google 发布 android/skills 的时机值得注意。2026 年 10 月，Agent Skills 标准已经被多个项目采用（K-Dense-AI 的 177 个科学技能、Anthropic 的 Claude Code 插件目录、Cursor 的插件生态）。Google 不是第一个，但它是第一个大型平台方以官方身份发布技能包。

这意味着什么？

1. 平台方开始认真对待 Agent 生态

以前，Agent 技能大多是社区或第三方公司做的。Google 以 Android 团队官方身份发布，说明平台方开始把"Agent 支持"当作一等公民——和"开发者文档""SDK""命令行工具"同级。

2. 领域专有知识的价值被重新定价

通用 LLM 的能力在 2026 年已经很强了。但"很强"不等于"够用"。在 Android R8 混淆、iOS 代码签名、Kubernetes 网络策略这些领域，LLM 的表现仍然不可靠。Google 的技能包是对这种不可靠的官方回应：不是让 LLM 变得更聪明，而是给 LLM 装上领域知识。

3. 开放标准 vs 封闭生态

Google 选择遵循 agentskills.io 开放标准，而不是搞一个 "Google Agent Skills" 私有标准。这意味着这些技能可以在 Claude Code、Codex、Gemini 等任何兼容 Agent 上使用。这是一个重要的信号——Google 在 Agent 生态上选择了开放而非封闭。

六、设计哲学的对比

把 android/skills 和其他 Agent 技能项目放在一起看，能看到两种截然不同的哲学：

两种策略都有道理。Google 作为平台方，知道 Android 开发者最常卡在哪里，所以精准打击。K-Dense 作为第三方，需要覆盖足够多的领域才能吸引用户。

这就像百科全书和专业手册的区别——百科全书追求广度，专业手册追求深度。在 Agent 技能领域，两种形态会长期共存。

七、局限与展望

当前局限

1. 技能数量少：目前只有少量技能，覆盖面有限
2. 不接受社区贡献：README 明确说 "Public contributions are not accepted at this time"。这意味着技能更新节奏取决于 Google 内部团队
3. Android 专属：技能只覆盖 Android 开发，不覆盖 Flutter、KMP 等跨平台框架

未来方向

Google 的这个仓库是一个信号。如果 Google Android 团队认真维护，我们可以预期：

• 技能数量会逐步增加，覆盖 Android 开发的更多痛点（Jetpack Compose 性能优化、Gradle 构建调试、Android Studio 卡顿排查）
• 其他 Google 团队可能跟进（Firebase skills、Google Cloud skills、TensorFlow skills）
• 平台方发布的技能可能成为该领域的"标准答案"，社区技能在相同领域会面临竞争压力

八、更大的图景：领域知识作为基础设施

android/skills 的出现指向一个趋势：领域知识正在从"人类脑中的经验"变成"Agent 可加载的基础设施"。

以前，一个 Android 开发者需要 3-5 年才能熟练处理 R8 混淆问题。这个知识存在于 Stack Overflow 答案、博客文章、同事的脑子里，传递效率低。

现在，Google 把这些知识结构化成 SKILL.md，任何 Agent 加载后就能像资深工程师一样处理 R8 问题。知识的传递成本从"3 年经验"变成了"一条命令安装"。

这不是"AI 取代开发者"——而是"领域知识变成可编程资产"。开发者仍然需要判断力来决定何时使用 R8、为什么使用 R8，但"如何正确配置 R8 规则"这个执行层面的知识，已经可以被 Agent 接管。

当每个领域都有这样的技能包时，跨领域工作的门槛会大幅降低。一个前端开发者可以临时处理 Android 的 R8 问题，一个数据科学家可以临时处理 Kubernetes 的网络策略——只要 Agent 装上了正确的技能。

领域知识正在从"护城河"变成"插件"。 这对领域专家是坏消息，对跨界工作者是好消息。

九、如何开始

# 克隆仓库
git clone https://github.com/android/skills.git

# 或直接在 Claude Code 中安装
/plugin install android-skills

# 或在 Android 项目中安装单个技能
android skills add r8-analyzer --project=.

技能是 Apache 2.0 协议，可以自由使用和修改。但当前不接受社区贡献——如果你想贡献 Android 技能，需要等待 Google 开放贡献通道。

核心洞察： Google 没有试图让 LLM 擅长所有事，而是让 LLM 在关键场景上从"还行"变成"很行"。这是正确的策略——补短板比锦上添花更有价值。当领域知识变成可加载的技能包，跨领域工作的门槛会大幅降低。