稀有猿诉

十年磨一剑，历炼出锋芒，说话千百句，不如码二行。

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

本文译自「Android’s Agent-First Era: Build-Time vs Runtime」，原文链接https://medium.com/proandroiddev/androids-agent-first-era-build-time-vs-runtime-9f66db6d8eed，由Renaud Mathieu发布于2026年6月8日。

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

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

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

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

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

轴 1：构建时

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

构建时：辅助构建的代理

ADK 是什么？

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13

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 和技能存储库，因此两家供应商都在同时推进这两个方面。

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

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

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

来源

Comments