Google 发布了 Agent Development Kit（ADK）for Kotlin 1.0。这个版本面向生产环境，覆盖 Kotlin、Android 以及基于 JVM 的服务端应用，并将 Kotlin 版本的能力推进到与 Google ADK for Python 和 Java 对齐的阶段。
更值得关注的是 Android 场景：Agent 不再只能通过远程 API 调用模型，还可以结合设备端 AI，按照任务类型、网络状态和隐私要求选择本地或云端执行路径。这让 Kotlin 既适合编写服务端 Agent，也适合作为 Android AI 应用的统一开发语言。
Kotlin 版本带来了什么变化
ADK for Kotlin 1.0 的重点不是再提供一个只能运行示例的 SDK，而是为生产级 Agent 应用提供统一的开发基础。开发者可以在 Kotlin 生态中组织 Agent、工具调用、模型交互以及工作流逻辑，并将相同的编程语言和工程习惯延伸到不同运行环境。
对于已经使用 Kotlin 的团队，这意味着以下几类代码可以更容易地放在同一个技术体系中：
- Android 客户端中的本地 Agent 和交互逻辑。
- JVM 服务中的远程 Agent、业务工具和 API 集成。
- 负责调度、路由和状态管理的共享 Kotlin 模块。
- 根据设备能力和网络条件选择本地模型或云端模型的混合流程。
“功能对齐”并不等于所有平台的运行条件相同。Android 设备的内存、功耗、模型体积和离线能力，仍然会影响实际架构；服务端则更关注并发、可观测性、密钥管理和成本控制。因此，统一的是开发模型，不是把同一份配置无条件部署到所有地方。
设备端与混合 AI 的工程价值
Android 特有的能力让 Agent 可以把一部分任务留在设备上。例如，简单的文本分类、离线摘要、个人数据预处理或低延迟交互，可以优先交给设备端模型；需要更强推理能力、最新知识或受控工具访问的任务，则可以转发到服务端。
一个实用的路由策略通常会同时考虑四个条件：
- 隐私：原始数据是否允许离开设备。
- 网络：当前是否在线，以及网络延迟是否可接受。
- 资源：设备内存、电量和模型加载成本是否允许本地执行。
- 任务复杂度：任务是否需要云端模型或服务端工具。
这种设计也带来新的边界。设备端模型并不天然更安全，应用仍需保护本地日志、缓存和模型输入；混合调用也可能产生不同的输出质量和延迟。上线前应分别测量本地、云端以及降级路径，而不是只测试网络正常时的主流程。
一个可改造的 Kotlin 路由示例
下面的示例用纯 Kotlin 演示一个最小的本地/云端 Agent 路由器。它不依赖具体 ADK artifact，便于直接运行和理解架构；在真实项目中，可以把 LocalAgent 和 CloudAgent 的实现替换为 ADK Kotlin 的 Agent、模型和工具调用接口。
将代码保存为 Main.kt，使用 Kotlin 编译器运行：
interface Agent {
suspend fun run(input: String): String
}
class LocalAgent : Agent {
override suspend fun run(input: String): String {
return "local-result: ${input.trim()}"
}
}
class CloudAgent : Agent {
override suspend fun run(input: String): String {
return "cloud-result: ${input.trim()}"
}
}
data class RequestContext(
val online: Boolean,
val containsPrivateData: Boolean,
val needsAdvancedReasoning: Boolean
)
class HybridAgent(
private val local: Agent,
private val cloud: Agent
) {
suspend fun run(input: String, context: RequestContext): String {
val mustStayOnDevice = context.containsPrivateData
val shouldUseCloud = context.online && context.needsAdvancedReasoning
return when {
mustStayOnDevice -> local.run(input)
shouldUseCloud -> cloud.run(input)
else -> local.run(input)
}
}
}
// Replace this simple runner with kotlinx.coroutines in an Android or JVM project.
suspend fun main() {
val agent = HybridAgent(LocalAgent(), CloudAgent())
val result = agent.run(
input = "Summarize today's notes",
context = RequestContext(
online = true,
containsPrivateData = false,
needsAdvancedReasoning = true
)
)
println(result)
}
该例子有三个可以直接迁移到 ADK 项目的边界：
Agent表示统一的 Agent 执行接口。RequestContext集中承载隐私、网络和任务复杂度等路由条件。HybridAgent决定何时使用设备端能力，何时调用服务端 Agent。
实际接入时，不要把 API 密钥写入 Android 客户端；云端 Agent 应通过受控服务访问模型和业务工具。对于本地模型，则应在设备能力检测、模型下载、版本升级和失败降级方面增加明确的状态管理。
从 Python 或 Java ADK 迁移时的关注点
Kotlin 达到功能对齐后，团队可以更容易地复用既有 Agent 设计，但迁移仍然不是简单的语法转换。需要重新检查以下内容：
- 协程和并发模型是否与原有 Agent 生命周期匹配。
- Android 生命周期变化是否会中断长时间运行的任务。
- 工具调用失败、网络断开和模型超时是否有可恢复策略。
- 本地和云端模型的输出格式是否经过统一校验。
- 日志中是否意外记录了用户输入、工具参数或敏感上下文。
服务端 Kotlin 项目通常可以把 Agent 封装为 HTTP 接口或后台任务；Android 项目则应把 Agent 调用放在合适的生命周期和线程模型中，并对取消、重试和离线状态做显式处理。统一的 Kotlin 代码风格有助于共享数据模型和策略，但不应掩盖两个运行环境在可靠性与资源约束上的差异。
采用前的检查清单
可以按下面的顺序推进 Kotlin ADK 项目：
- 先选定一个边界清晰的 Agent 任务，例如摘要、分类或受限工具调用。
- 明确哪些输入必须留在设备端，哪些请求允许发送到服务端。
- 为本地、云端和离线降级路径分别记录延迟、成功率和输出质量。
- 将工具权限、网络访问和敏感数据处理从提示词中独立出来管理。
- 确认 Android 端的模型体积、内存占用、电量影响和升级策略。
- 在生产部署前补齐超时、取消、重试、审计日志和人工兜底。
ADK for Kotlin 1.0 的意义，在于让 Kotlin 团队可以用更一致的方式覆盖 Android、JVM 服务和设备端 AI。真正落地时，决定项目质量的仍然是模型路由、工具边界、数据治理和故障处理，而不是单纯把 Agent 类放进应用工程。