Android 正在被 AI 重新组织：I/O '26 后工程师的能力栈重排

📰 每日要闻

• Investing.com：BTIG 将 Snowflake 目标价上调至 280 美元，强劲业绩引发看涨信心；RBC Capital 同步上调目标价，看好其 AI 增长前景。

• CNBC：美联储 Goolsbee 表示能源通胀比预期更具持久性，即便油价近期因美伊和谈预期回落，仍显著高于战前水平。

• The Verge：YouTube 推出 AI 自定义视频流功能，用户可通过自然语言描述生成个性化推荐 Feed。

• Android Developers Blog：Google I/O '26 后官方发布《Top AI on Android updates》，全面总结端侧模型、Gemini Nano、AI Edge、ML Kit 演进。

• JetBrains 官方今日发布 Compose Multiplatform 1.12.0-alpha02，同步带出 material3 1.12、navigation 2.10.0-alpha02 多个核心库版本对齐。

先抛一个反常识的观察：Google I/O '26 已经过去两周了，社交媒体上铺天盖地都在讨论 Android 17、Gemini Nano、AppFunctions，但我跟几个一线 Android 团队聊下来，大家最焦虑的其实不是"我要不要立刻升级 minSdk 到 35"，而是另一个更隐蔽的问题——"我现在的技能栈，三年后还值不值钱"。

这个问题不矫情。今年 5 月这一波密集发布，本质上不是"Android 又加了几个 API"，而是 整个 Android 平台正在被 AI 重新组织——设备端、IDE、跨平台、Agent 调用四条线索同时在动，每一条都在重写某一类工程师的位置。我刷完 I/O 17 个 keynote、Compose Multiplatform 1.12 的 release note、Koog 1.0 的发布博客，还有 KotlinConf '26 keynote 之后，越来越觉得：今天写一篇技术分享，最值得讲的不是某个 API 怎么用，而是这四条线索拼起来到底意味着什么。

所以这篇文章不打算给你做"I/O '26 17 大要点速览"——那种文章满网都是，复读没意义。我想做的，是站在 Android 工程师视角，把这四条线索拆开看：哪些今天就能落到代码里、哪些是中长期信号、哪些是我们必须重新审视的能力栈。文章会有点长，但我尽量讲人话。

一、四条线索拼图：先看清整张地图

在拆细节之前，先把这次发布密集期的"地形图"画出来。我把它整理成四条主线，每条主线背后都对应一个 Google/JetBrains 的产品意图：

线索 1 设备端模型 — Gemini Nano + AI Edge + ML Kit 演进，把推理能力推到设备

线索 2 IDE 主战场 — Android Studio Quail RC2/Canary 2，把 AI 编程深度集成到工作流

线索 3 跨平台一等公民 — Compose Multiplatform 1.12 + Koog 1.0，Kotlin 全栈 + AI Agent 闭环

线索 4 Agent 调用入口 — AppFunctions，让你的 App 被 AI Agent 直接调用，而不是被用户打开

这四条线索看起来分散，其实指向同一个事实：Android 不再以"用户主动打开 App"为核心组织逻辑，而是开始围绕"AI 在哪里运行 / AI 谁来写 / AI 跨什么平台运行 / AI 怎么调用应用能力"重新分配权重。每一条线索后面，都对应着一类工程师的技能优先级要被刷新。

二、线索 1：端侧模型——Gemini Nano 的真实可用边界

先泼一盆冷水

Google 官方那篇《Top AI on Android updates》读起来很爽，端侧模型、AI Edge、ML Kit Generative API，一套配齐。但我必须先泼一盆冷水："端侧 AI"不等于"Gemini Nano 跑在你手机上"。这是两件被混为一谈的事，混淆带来的后果就是工程上做错预期。

真实情况是这样的——Gemini Nano 在 2026 年依然只在有限机型上跑（Pixel 9/10 全系、三星 S25 系列、少数旗舰），不是所有 Android 设备都能用。Google 的策略其实是分层的：

L1 系统级 Gemini Nano 仅旗舰机，AICore 系统服务托管，App 通过 ML Kit GenAI API 调用

L2 AI Edge LiteRT App 自带模型（GGUF/TFLite），覆盖更广机型，但要自己处理模型分发

L3 ML Kit 传统能力 人脸、OCR、翻译等成熟模型，几乎全机型可用，能耗最低

L4 云端 Gemini API 兜底方案，能力最强但要联网、有成本、有延迟

写代码的时候，这四层不是替代关系，而是组合关系。我自己最近重构一个图文摘要功能时就走了这个路：旗舰机用 L1 (Gemini Nano) 走 ML Kit GenAI，中端机自带一个小型 LiteRT 模型走 L2，老机型直接走 L4 云端。这种"按设备分层降级"在 2026 年应该成为 Android AI 功能的默认架构思路。

ML Kit GenAI API：今天就能用的部分

官方这一波最实际的更新，其实是 ML Kit GenAI API 走出 beta，提供了三个稳定的端侧能力：摘要（Summarization）、改写（Rewriting）、回复建议（Reply Suggestion）。这三个 API 都基于 Gemini Nano，但在不支持的设备上会自动 fallback 到云端。最关键的代码长这样：

// build.gradle.kts
implementation("com.google.mlkit:genai-summarization:1.0.0")// 调用代码
val summarizer = Summarization.getClient(
SummarizationOptions.builder()
.setInputType(InputType.LONG_FORM)
.setOutputType(OutputType.THREE_BULLETS)
.build()
)// 1. 检查/下载特性（Nano 模型是按需下载的）
when (summarizer.checkFeatureStatus().await()) {
FeatureStatus.UNAVAILABLE -> useCloudFallback(text)
FeatureStatus.DOWNLOADABLE -> {
summarizer.downloadFeature(progressListener).await()
summarize(summarizer, text)
}
FeatureStatus.AVAILABLE -> summarize(summarizer, text)
}

注意三个细节：

• FeatureStatus 是必须检查的。Nano 模型在第一次使用前不会预装，要走 AICore 的"特性下载"流程，几百 MB 的体积，没 Wi-Fi 直接卡死。

• InputType 和 OutputType 是受限的，不像云端能任意 prompt。这是端侧模型的固有限制：能力被 API 化、参数化。

• 降级逻辑必须自己写。Google 官方没给开箱即用的"自动云端兜底"，这是工程师的责任。

画饼的部分：要谨慎区分

官方在演示里展示的"端侧多模态"、"端侧 Function Calling"、"端侧 Agent 推理"，老实说大部分还在 experimental 阶段。如果你拿这些做生产决策，2026 年大概率会踩坑。我个人的判断是：今年到明年，端侧 AI 的真实战场仍然是"轻量化文本任务 + 传统 ML 能力"，而不是"在手机上跑一个 Agent"。

三、线索 2：IDE 主战场——Android Studio Quail 实测观察

Quail 1 RC2 不只是补全工具

Android Studio Quail 系列从 Canary 一路演进到 RC2，我自己用了快三个月。一句话总结：Quail 不是"在 IDE 里加了个 ChatGPT 侧边栏"，而是 Gemini 把 IDE 当成了 Agent 的运行环境。这两者差异巨大。

举个具体例子。以前 Android Studio 的 AI 补全是"光标位置上下文 → 生成代码"，本质上是个补全引擎。现在 Quail RC2 的 Build Error Fix 长这样：你 Build 失败，IDE 会自动把编译错误 + 涉及的源文件 + 相关的 Gradle 配置 + 历史上类似错误的解决方案一起喂给 Gemini，然后给出一个可以"一键 Apply"的 patch。这个 patch 不是只改一个文件——它可能同时修改 build.gradle、版本目录、和某个被依赖错误影响的 Kotlin 文件。

实测下来，下面几个能力是真的能用的：

• Build Error Fix：Gradle 依赖冲突、KAPT/KSP 错误、ProGuard 规则缺失这类错误，命中率大概 70%。复杂的 Kotlin 编译器错误（比如 inline reified 相关）依然不行。

• Compose Preview Generation：写一个 Composable，按下快捷键自动生成 @Preview 函数和 mock 数据。这个对写 UI 真的省时间。

• Migration Assistant：从 View 迁移到 Compose、从 LiveData 迁移到 StateFlow，AI 给出多步骤迁移方案。这个还挺惊艳，但生成的代码必须人工审。

• Refactor with Intent：选中一段代码，用自然语言说"把这个 callback 改成 Flow"，AI 给出重构 diff。

没那么靠谱的部分

但我也得说点实话——Quail 还远没达到"换掉初级工程师"的水平。它在以下几个场景表现明显不行：

• 跨模块的架构理解：多模块项目中跨模块的依赖关系、API 边界，AI 容易给出"看上去对但实际越权"的代码。

• 性能敏感的代码：要它写一个 RecyclerView Adapter 的优化，它会写出"看起来很 Kotlin"但实际触发不必要重组的代码。

• 项目特有的约定：你团队用的某个内部 framework，AI 不认识。这部分是 Quail 2 Canary 在改进的方向（项目级 context 注入）。

我的建议是：Quail RC2 适合让它做"重复性脚手架"，不要让它做"判断性架构决策"。当你写一个新功能模块的时候，让它生成 Repository、ViewModel、State 类的样板，省时间；但功能逻辑、状态机设计、并发模型，自己来。

四、线索 3：跨平台与 Kotlin 全栈——CMP 1.12 + Koog 1.0 的组合拳

版本号同步比版本号本身更重要

Compose Multiplatform 1.12.0-alpha02 今天（5/28）刚发布，但比版本号本身更值得关注的是它带出的这一长串同步版本：

📦 compose-multiplatform 1.12.0-alpha02 ←今日

📦 material3 1.12 — 与 Jetpack Compose 主线对齐

📦 adaptive 1.3.0-beta02 — 大屏自适应

📦 navigation 2.10.0-alpha02 — 跨平台路由统一

这个"版本同步"看起来是工程细节，背后却是JetBrains 把 CMP 当成"一等公民"对齐 Jetpack Compose 节奏的明确信号。在过去，CMP 永远比 Android 的 Compose 慢半拍——你 Android 项目用了某个新 API，跨平台版本里还没有。这种"二等待遇"在工程上是劝退点。1.12 之后，这个 gap 在缩小。

配合 KotlinConf '26 keynote 给的路线图（Kotlin 15 周年的节点，重点投入 Compose Multiplatform / AI Agent / 多平台），CMP 这条线在 2026-2027 是一个真实的卡位选择。

CMP 真要追上 Flutter 了吗？

这个问题我跟同事们争论过很多次。结论是：追平不是目标，"互补"才是真实定位。我整理了一个对比表（基于 ProAndroidDev 那篇 5/27 的对比文章 + 我自己的实战体感）：

真实的取舍是：如果你的团队主力是 Android 工程师，且需要快速覆盖 iOS，CMP 1.12 是 2026 年值得重新评估的选项。但如果你的产品定位高视觉一致性、且团队没有 Kotlin 偏好，Flutter 仍然是更稳的选择。这个判断没有银弹。

Koog 1.0：Android 工程师写 Agent 不用切 Python 了

JetBrains 5/27 发布的 Koog 1.0 是另一个被低估的事件。简单说，它是个 Kotlin 原生的 AI Agent 框架，对标 LangChain/LlamaIndex，但本身就是 Multiplatform 的——能在 JVM、Android、iOS、Native 都跑。

// Koog 1.0 最小可用 Agent 示例
val agent = AIAgent(
promptExecutor = simpleOpenAIExecutor("sk-..."),
systemPrompt = "你是一个帮助用户搜索本地文件的 Agent",
llmModel = OpenAIModels.Gpt4o,
toolRegistry = ToolRegistry {
tool(SearchFilesTool)
tool(ReadFileTool)
}
)// 在 Android 主界面里直接调用
viewModelScope.launch {
val result = agent.runAndGetResult("找一下我上周写的关于支付重构的笔记")
_state.update { it.copy(answer = result) }
}

这个意义在于：过去要在 Android 项目里实现一个 Agent 功能，要么走云端（让 Python 服务做编排），要么自己用 OkHttp 拼 HTTP 请求。Koog 1.0 把 Agent 编排、tool calling、persistence、observability 这些工业级能力直接做进了 Kotlin SDK。配合 CMP，理论上可以做到一份 Agent 代码同时跑在 Android 和 iOS。

我自己最近用 Koog 改写了一个内部工具的 Agent 编排层（之前是 LangChain Python），主要观察：

• Tool 注册比 LangChain 干净很多，没有那么多 prompt template 魔法。

• Persistence 模块（把 Agent 中间状态持久化）API 设计得偏工程，比 LangGraph 更"程序员友好"。

• Observability 集成 OpenTelemetry，这点超过我预期。

• 但生态还小——没什么 community tools，几个主流模型 provider 是齐的，但小厂商模型要自己适配。

五、线索 4：AppFunctions——Android 分发逻辑的"安静革命"

这才是 I/O '26 最被低估的发布

如果让我从这次 I/O '26 挑一个"3 年后回头看最重要的发布"，我选 AppFunctions。不是 Gemini Nano，不是 Quail，是 AppFunctions。

原因很简单：AppFunctions 改的不是某个 API，而是"用户怎么使用 App 的根本范式"。过去用户用 App 是"打开 → 找功能 → 操作"。AppFunctions 让 AI Agent 直接以结构化方式调用 App 暴露的能力——用户跟 Gemini 说"帮我点份外卖"，Gemini 通过 AppFunctions 找到美团/饿了么的相关 Function，参数化调用，App 可能根本不会被打开到前台。

这个范式跟 iOS 的 App Intents 是同一类东西，但 Android 的实现更接近"操作系统级 RPC"——任何能调用 AppFunctions API 的 Agent（Gemini、第三方 Agent）都能调你的 App。声明一个 AppFunction 的最小代码：

// 用注解声明一个可被 Agent 调用的功能
@AppFunction(
description = "在用户的笔记应用里创建一条新笔记"
)
suspend fun createNote(
@AppFunctionParam("笔记标题") title: String,
@AppFunctionParam("笔记正文") body: String,
@AppFunctionParam("标签，可选") tags: List<String> = emptyList()
): NoteCreatedResult {
val note = noteRepository.create(title, body, tags)
return NoteCreatedResult(noteId = note.id, deeplink = note.deeplink)
}

注意几个关键点：

• Function 用注解声明，编译期生成 schema，不需要运行时反射。这跟 App Actions 时代靠 XML 配置完全不同。

• 参数描述会作为 LLM 的 context——所以"description"这个字段写得好坏直接决定 Agent 调用的准确性。这是新的"SEO"。

• 返回值结构化——AI 需要能把结果再喂回 LLM，所以 result type 必须是可序列化的。

• 权限控制走系统级 prompt，用户在第一次被 Agent 调用某个 Function 时会看到授权弹窗。

为什么说这是分发逻辑变化

想想看：如果 Gemini 是用户的主入口，App 的能力被 AppFunction 化暴露给 Agent，那么用户压根不打开你的 App，也能用你的功能。这意味着两个连锁反应：

• "App 拉新"模型崩塌一半。用户不打开 App = 没广告位、没推送窗口、没活跃用户数。流量逻辑彻底变。

• "AppFunction 优先级"成为新的产品资产。同样是订外卖，用户问 Gemini 时会调谁的 AppFunction？这是新的卡位战。

这是 AppActions 当年没解决的问题——AppActions 时代 Google Assistant 的入口太弱，开发者没动力适配。AppFunctions 时代 Gemini 是核心入口，开发者只要不想被竞争对手抢走入口，就必须接入。这是结构性变化，不是可选项。

六、Android 工程师 2026 年的能力栈应该怎么调

回到开头那个问题——"我现在的技能栈，三年后还值不值钱"。我把这次发布密集期看下来的判断梳理成一张图（这是我个人观点，仅供参考）：

📈 升值的能力 • Compose（含 Multiplatform）— 跨平台带来更大杠杆 • 端侧 ML 工程（模型分发/量化/降级架构）— 替代不了的硬技能 • AI 集成与 prompt 工程 — Koog/AppFunctions 都需要 • 系统集成深度（Permissions/Background/IPC）— Agent 时代更重要

⚖️ 维持稳定的能力 • Kotlin 协程/Flow — 仍是基础 • 性能优化（启动/渲染/内存）— 用户体验底线 • 测试工程 — AI 生成代码反而更需要严格测试

📉 边际递减的能力 • 纯 XML View 体系 — 新项目几乎不用 • 重复性 boilerplate — Quail 越来越能写 • 单平台特定知识 — CMP 模糊了边界

不要误会——"边际递减"不等于"立刻没用"。XML View 在 2026 年依然是大量存量项目的现实，性能优化的第一性原理永远有效。我说的是边际增长率：你今年再投入 100 小时学 XML View 的奇技淫巧，回报远不如花 50 小时把 AppFunctions 吃透。

七、收尾：变化中的不变

写到这里，可能有读者会觉得"信息量好大，我有点焦虑"。我想说的最后一句话其实是：不要被这次发布密集期搞得太焦虑，但也不能假装没发生。

我做 Android 这么些年，看过 Material 1 → Material You、AsyncTask → Coroutine、View → Compose 这些历次重构。每一次都有人喊"Android 要变天了"，每一次最后留下来的是那些既能跟上新范式、又对底层原理有手感的工程师。

这次也一样。AI on Android 这套东西，三年后大概率不是今天 I/O '26 描绘的样子——某些线索会爆发（我赌 AppFunctions），某些会折戟，某些会被新东西替代。但你今年花时间去理解"端侧推理的真实边界"、"Agent 调用 App 的协议设计"、"Kotlin 全栈在 AI 时代的位置"，这些理解不会浪费。具体的 API 会换，思考方式会留下来。

至于今天能动手做的事，我给三个具体建议：

• 找一个老项目里的"摘要 / 改写 / 回复建议"场景，用 ML Kit GenAI API 改造一遍，体感"端侧 AI 的真实约束"。

• 给你的 App 至少定义 3 个有意义的 AppFunction。即使现在 Agent 调用量还小，这是分发资产的提前布局。

• 用 Koog 1.0 搭一个最小 Agent，跑在 Android 上感受一下"在客户端做 LLM 编排"是什么体验。

这三件事加起来不会超过两个周末，但能让你对"被 AI 重新组织的 Android"建立第一手认知。技术分享文章看十篇，不如自己 hello world 一遍。

如果这篇文章对你有帮助，欢迎点赞、在看、转发给身边的 Android 同行。我们下篇见。