Android的Agent优先时代：构建时vs运行时

本文译自「Android's Agent-First Era: Build-Time vs Runtime」，原文链接medium.com/proandroidd...，由Renaud Mathieu发布于2026年6月8日。

在 Android 中，"Agent"一词现在有两个不同的含义，而且很容易混淆。一个是帮助你编写代码的 AI，另一个是你应用内部为用户提供的 AI。谷歌在同一季度发布了针对这两个方面的工具，这正是有些人容易感到困惑的原因。因此，本文的核心内容集中在以下两点：

_技能 + CLI = 构建时，提升你的效率。

ADK = 运行时环境，你的产品。

为什么现在才推出这些功能？开发模式正在从**"人与 IDE 交互"转向 "人监督智能体"，而谷歌正在公开地为此进行设计。与此同时，像 Gemini Nano**这样的设备端模型已经发展成熟，能够在手机上运行真正的智能体逻辑。因此，谷歌正在双管齐下：一方面提升智能体构建 Android 应用的能力，另一方面简化将智能体集成到应用本身的过程。本文的其余部分将围绕这两个方面展开。

在正式开始之前，先介绍一个有用的细节：构建时部分基于开放标准（agentskills.io），因此它不局限于某个特定的助手；而运行时部分（ADK) 是开源的。这意味着（至少目前如此？）谷歌的竞争优势在于工具和技术，而非厂商锁定。

轴 1：构建时

在你开发过程中与你协同工作的助手。它们会读取你的项目，应用当前的最佳实践，运行迁移，并驱动工具链。最终的回报是提高你的开发效率。这正是 Android 技能 和 Android CLI 的用武之地。

轴 2：运行时

用于构建在你发布的应用程序中运行的助手的框架。最终的回报是为你的用户提供产品功能，通常在设备上私下运行。这是适用于 Kotlin 和 Android 的 ADK （或 JetBrains 的 Koog）。

构建时：辅助构建的代理

Android 技能 是一些小型指令文件（SKILL.md 以及可选资源），用于教授代理一项 Android 最佳实践。代理会读取简短的描述，并在相关时才调用完整的技能，从而保持上下文的清晰。

Android CLI 是一个 android 命令，用于处理 SDK 设置、模拟器、部署、脚手架搭建和文档搜索。其突出特点是能够与正在运行的 Android Studio 通信，以分析文件、查找符号用法并渲染 Compose 预览，从而使代理能够像 IDE 一样查看你的代码。

bash 复制代码

android update         // keep it current
which android          // check it is installed
android init           // set up for agents
android skills list    // see official skills
android skills add --skill edge-to-edge

社区技能 的添加同样简单。一个很好的例子是 Chris Banes 的 Android 技能库 (github.com/chrisbanes/...) 或 Skydove 的 Compose Performance 技能 (github.com/skydoves/co...)

bash 复制代码

npx skills add chrisbanes/skills

用例

最明显的胜利是日常现代化。要求你的代理制作一款边缘到边缘的应用程序，并且凭借正确的技能，它会应用谷歌今天推荐的模式，而不是在培训中学到的陈旧模式。这同样适用于更大、更痛苦的工作：将屏幕从 XML 迁移到 Compose、采用 Navigation 3 或升级到 AGP 9。这些正是代理倾向于即兴发挥和漂移的多步骤任务。一项技能将它们变成可重复的配方，因此无论你在一个屏幕还是五十个屏幕上运行它，结果都是一致的。

绩效工作是社区技能真正发挥作用的地方，因为细微差别比任何模型的训练数据都变化得更快。 Chris Banes 的 repo 就是一个很好的例子。他的"组合-重组-性能"技能引导智能体消除卡顿和不必要的重组，而"组合-状态提升"和"kotlin-流-状态-事件建模"则引导代理走向正确的状态和流模式，而不是模型经常达到的有损默认值。你实际上是在向代理提供多年来调试这些问题的人的判断力。

CLI 涵盖了循环的机械部分。通过单个脚本，代理可以构建新项目、启动模拟器并部署构建，所有这些都无需在 IDE 中单击。而且因为技能只是你控制的文件夹，团队可以将自己的约定（"我们如何在这里做事"规则）打包成共享技能，以便每个开发人员的代理都遵循相同的剧本。

Axis 2，运行时：你在应用程序内发送的代理

ADK 是什么？

代理开发套件 可让你在 Android 应用程序中构建和运行 AI 代理，而不仅仅是作为编码助手。它是一个支持 Kotlin 和 Java 的开源框架，相同的代理代码可以从单个工具调用代理扩展到复杂的多代理系统。你编写的代理代码与标准 ADK Kotlin 指南相同；只有 Gradle 依赖项以及运行时调用它的方式有所不同。

最小代理是一个具有名称、指令、模型和一组工具的"LlmAgent"。工具是用"@Tool"注释的普通 Kotlin 函数，你可以从协程运行代理，收集其响应作为事件来驱动你的 UI。以下是从 Google 的 HelloTimeAgent 快速入门中删减的要点：

kotlin 复制代码

class TimeService {
    @Tool
    fun getCurrentTime(
        @Param("City to get the time for") city: String
    ): Map<String, String> = mapOf("city" to city, "time" to "10:30am")
}
val rootAgent = LlmAgent(
    name = "hello_time_agent",
    description = "Tells the current time in a city.",
    model = Gemini(name = "gemini-flash-latest", apiKey = /* from your backend, never hard-coded */),
    instruction = Instruction("Tell the time in a city using the getCurrentTime tool."),
    tools = TimeService().generatedTools(),
)

引人注目的是，在设备上运行所需的更改很少：将 Gemini(...) 模型替换为 ML Kit 支持的 GenaiPrompt（GenaiPrompt.create(generativeModel, name = "gemini-nano")），并且相同的代理现在可以离线运行。然后，你可以使用"InMemoryRunner"从协程驱动它，收集事件来更新你的 UI。

移动角度：在设备上使用 Gemini Nano

这就是 ADK 在手机上变得有趣的部分，而不仅仅是另一个代理 SDK。 Android 工件可以通过 ML Kit GenAI API 使用 Gemini Nano 在设备上运行推理，因此代理可以在没有网络访问的情况下运行并将数据保留在设备上。你甚至可以混合两者：云 Gemini 模型作为协调器，设备上模型处理隐私敏感的子任务。

需要向读者提出的一个重要警告：切勿将 API 密钥嵌入到已发布的应用程序中。对于云模型，调用应通过你自己的后端或 Firebase AI Logic，以便密钥永远不会在客户端代码中公开。

ADK 并不孤单：Koog

将 Kotlin 中的运行时代理视为 Google 垄断是一种误导。 JetBrains 推出了直接竞争对手 Koog，这是一个使用 Kotlin 和 Java 编写的 AI 代理开源框架，涵盖相同的构建块：工具、工作流程、持久性、内存和可观察性。同样的问题，不同的哲学。 ADK 将你带入 Google 生态系统，如果你押注于设备上的 Gemini Nano，它会大放异彩，而 Koog 与模型无关，倾向于 Kotlin Multiplatform 和 OpenTelemetry 可观测性，并通过 LiteRT 在 Android 上运行本地模型。今天实际的决定因素是成熟度：Koog 已达到稳定的 1.0，并提供一年的 API 稳定性保证，而 ADK Android 神器仍处于早期阶段。对于生产 Kotlin 后端，这种保证是一个具体的论据。

值得注意的是，JetBrains 也在 Axis 1 上发挥作用，拥有自己的 Skill Manager 和技能存储库，因此两家供应商都在同时推进这两个方面。

它为什么会发展，又将走向何方？

退后一步，两个轴都指向同一个方向。人工智能辅助已经从自动完成转向可以设置、构建、测试并越来越多地作为产品一部分运行的代理。使这两种飞跃成为可能的不是更智能的模型，而是更好的基础和更好的管道：编码代理的当前项目上下文和应用程序内的干净的设备上运行时。

开放标准、开源选择对两者都很重要。通过不将开发人员锁定在单个助手或运行时，Google 为社区扩展事物留下了空间，而社区存储库是构建时生态系统已经超出 Google 自身能力的早期证据。在运行时方面，设备内推理悄然改变了"人工智能功能"的含义，因为它不再需要往返服务器。

它倾向于哪里？

在轴 1 上，针对拥有更多开发人员一直推迟的升级和迁移跑步机的代理。在 Axis 2 上，代理功能将成为应用程序的正常部分而不是新奇事物，并将保护隐私的设备上模型作为敏感工作的默认设置。目前诚实的评估：所有这些都是可选的。如果你已经与代理合作、高度自动化或想要应用内人工智能，那么它确实非常有用；否则很容易跳过。

但这种选择往往会很快成为标准。

要点

要保留的一种心理模型：技能和CLI 使你更快地构建应用程序； ADK 允许你将代理放入应用程序中。生命周期的不同末端，相同的代理优先浪潮。

如果你的工作流程中代理较多或 CI 较多，请立即关注轴 1。如果你的路线图上有应用内或设备上的 AI 功能，请立即关注 Axis 2。否则，请同时关注两者。一个很好的第一个实验：在一个副项目上使用一项官方技能加上"chrisbanes/skills"运行"android init"，并单独连接 ADK Kotlin 快速入门以感受运行时方面。

来源

欢迎搜索并关注 公众号「稀有猿诉」 获取更多的优质文章！

保护原创，请勿转载！