Google ADK for Kotlin 1.0：Kotlin 也能写生产级 AI Agent 了
写 AI Agent，很多人第一反应是 Python。Kotlin / Android / JVM 这边，官方脚手架也补齐了。
写 AI Agent，很多人第一反应是 Python。
文档多，示例多，框架也多。
Java 这边，也有一套官方路线。
但是，如果你日常写的是 Kotlin----尤其是做 Android，或者 JVM 服务端----你会发现另一件事：
模型调用可以做，真正把 Agent 做成可上线的东西，仍然很散。
工具怎么定义？多轮对话上下文怎么压？敏感操作怎么让人确认？进程杀掉以后，会话怎么恢复？
这些事，往往要自己拼好几套库。
2026 年 9 月 9 日，Google Developers Blog 发了一篇文章。
作者是 Developer Advocate Guillaume Laforge。
标题很直接：Announcing ADK for Kotlin 1.0。
ADK 全称是 Agent Development Kit。
Kotlin 版到了 1.0，正式 GA。
它到底解决什么问题？
简单说，ADK for Kotlin 想给 Kotlin / Java / Android 开发者，一套惯用、轻量、可组合的 Agent 开发工具。
0.1.0 时期，目标就已经摆在那里。
1.0 的变化，是把这套东西推到了生产可用。
核心是 Kotlin Multiplatform（KMP）。
它对具体模型后端、会话存储、记忆系统保持无关。
你可以在本地跑，也可以接云端。
官方还强调一点：它不只给 Android。
服务端 Kotlin 开发者，同样可以用惯用 Kotlin 写法，做企业侧 Agent 和智能应用。
换句话说，同一套核心，覆盖 JVM 服务端和 Android 端上场景。
跟 Python / Java 版对齐了什么？
很多人会问：Kotlin 版是不是功能缩水版？
官方的说法是：与 ADK Python、ADK Java 的 1.0 Core 功能对齐。
具体包括这些能力：
1、层级多代理。可以把任务拆给专门的子 Agent，再串起来。
2、上下文压缩与多轮对话。历史太长时，用摘要把上下文压回 Token 上限以内。
3、人在回路（HITL）与确认流。敏感动作可以先暂停，等人确认，再继续执行。
4、长跑工具，以及基于注解的工具。用 Kotlin 写工具，自动生成 schema。
5、会话可恢复。进行中的交互可以暂停、序列化，之后再恢复。
6、Java 互操作。现有 Java 应用可以直接调用 ADK Kotlin Agent。
7、企业平台集成。对接 Vertex AI 的 session、RAG memory、memory bank 等服务（例如 VertexAiSessionService、VertexAiRagMemoryService、VertexAiMemoryBankService）。
这些能力听起来抽象，落到工程里其实都是硬需求。
没有多代理，复杂流程只能塞进一个巨大 prompt。
没有上下文压缩，长对话很快会撞 Token 墙。
没有确认流，转账、删数据这类动作就很危险。
没有会话恢复，App 被系统杀掉，Agent 状态也就丢了。
所以，1.0 对齐的不是名词清单，而是生产环境里绕不开的那些缺口。
工具：注解 + 编译期生成
Agent 要能做事，就得有工具。
ADK for Kotlin 的做法，很 Kotlin。
你用普通 Kotlin 类写服务，再给方法加上 @Tool 和 @Param。
构建时，靠 KSP（Kotlin Symbol Processing）在编译期生成函数调用定义。
官方特别强调三点：
类型安全的 schema；
支持 suspend 函数；
零运行时反射。
这很重要。
很多动态 schema 方案，依赖运行时反射。
手机端和严格的服务端环境，反射成本、体积、启动时间都不划算。
编译期生成，等于把"告诉模型这个工具长什么样"这件事，提前做完。
官方示例里，有一个数据库故障排查 Agent。
工具包括：拉服务指标、查最近部署、通知值班频道。
例如 getServiceMetrics 可以是 suspend 函数；notifyOnCall 则是普通函数。
构建完成后，KSP 会生成类似 InfrastructureDiagnosticsService().generatedTools() 的扩展。
你把生成好的工具列表交给 Agent，不用手写一长串 JSON schema。
对开发者来说，工具定义更像普通业务代码，而不是另一套 DSL。
Skills：把 SOP 从代码里拆出来
光有工具还不够。
真实线上排障，往往还有标准作业流程（SOP）。
先看哪些指标，再对照最近发布，再读安全规则，最后才通知人。
这些流程如果全写进 system prompt，又长又难维护。
ADK 引入了 Skills。
机制是 SkillToolset，配合 SKILL.md，做 progressive disclosure（渐进披露）。
什么叫渐进披露？
大白话就是：先告诉模型有哪些技能可用；真正需要时再加载完整 SOP；附属资源（比如规则文件）也只在必要时读取。
这样可以少占 Token。
官方示例把数据库故障排查 SOP 放在 src/main/resources/skills/database-incident-triage/SKILL.md。
文件头用 front matter 写清名称、描述、允许使用的工具。
正文则是分步清单：先查遥测，再关联部署，再读 mitigation 规则，最后通知频道。
Agent 配置时，一边挂编译期生成的 tools，一边挂 SkillToolset。
工具负责"能做什么"；Skills 负责"按什么流程做"。
分工清楚以后，代码和文档各管一块，后面改 SOP 也不必大改工具实现。
一个官方示例在干什么？
官方用 InMemoryRunner 跑了一个事故分诊演示。
模型字段里写的是 gemini-3.8-flash。
这只是演示代码里的模型名，不是本文要介绍的新模型发布。
流程大致是：
收到数据库延迟告警；
发现并加载对应 skill；
调用 getServiceMetrics，看到连接池接近打满；
再调用 fetchRecentDeployments，把根因落到最近一次部署；
最后通知 #production-alerts，并给出回滚建议。
它展示的不是"模型有多聪明"，而是 Agent 框架怎么把工具、技能、事件循环串成可运行闭环。
对开发者更有用的，其实是这套闭环能不能复制到自己的业务里。
Android：端上、混合、可持久化
服务端示例讲完，官方又回到移动端。
现代手机 AI，一边要云端推理能力，一边要端上隐私、速度和离线可靠。
ADK for Kotlin 1.0 给 Android 做了模块化扩展，贴近常见 Android 架构组件。
素材和博文里点到的能力，大致是这些：
LiteRT-LM：端上本地模型路径。
ML Kit（beta）：端上能力扩展。
Firebase AI Logic：混合云工作流，例如经由 Firebase 调用云端模型。
Room：会话持久化，进程重启后聊天历史还在。
AppSearch：端上全文索引记忆。
文件 artifact：生成的对账单、回执等，落到应用私有文件存储。
官方还有一个金融助手示例。
Agent 通过 Firebase AI 接模型（演示里同样写了 gemini-3.8-flash）。
转账工具用 @Tool(requireConfirmation = true) 标成需要明确批准。
Runner 配置里：
RoomSessionService 管会话；
AppSearchMemoryService 管记忆；
FileArtifactService 管产物文件。
执行时是两轮：
第一轮，用户请求转账，Agent 发出确认请求并暂停；
第二轮，用户在 UI 里确认，Agent 再真正执行 transferFunds。
官方也写明：这个例子只做演示，不满足真实合规要求。
但工程含义很清楚。
敏感动作默认不自动落地；状态要能活过进程死亡；记忆和文件要走 Android 现成组件。
这比"在 App 里塞一个聊天框"更接近可上线产品。
怎么引入依赖？
入门很直接。
在模块的 build.gradle.kts 里加入：
dependencies {
// ADK Kotlin Core + KSP
implementation("com.google.adk:google-adk-kotlin-core:1.0.0")
ksp("com.google.adk:google-adk-kotlin-processor:1.0.0")
// 可选 Android 扩展
implementation("com.google.adk:google-adk-kotlin-mlkit-android:1.0.0-beta")
implementation("com.google.adk:google-adk-kotlin-litertlm:1.0.0")
implementation("com.google.adk:google-adk-kotlin-firebase-android:1.0.0")
}核心是 google-adk-kotlin-core:1.0.0，再配同版本 KSP processor。
Android 扩展按需加：ML Kit、LiteRT-LM、Firebase。
文档入口是 adk.dev。
代码仓库是 github.com/google/adk-kotlin。
官方还提供模块架构说明、Android Agent 指南、示例集，以及 Java 互操作示例。
如果你已有 Java 代码库，也不必推倒重来，可以直接互调。
哪些人值得看？
我觉得，至少三类人可以打开文档试一下。
第一类，是已经在写 Kotlin 服务端的人。
你们不一定要迁到 Python，也能用惯用语法搭多代理、工具、会话恢复。
第二类，是 Android 开发者。
如果产品需要端上推理、云端推理，或者两者混合，同时还要 Room / AppSearch 这类本地持久化，ADK 把拼图收拢了。
第三类，是已有 Java Agent 资产、想逐步引入 Kotlin 的团队。
官方把 Java 互操作当成一等能力，而不是事后补丁。
反过来，如果你主要做快速实验、脚本原型，Python ADK 可能仍然更顺手。
工具选语言，最终还是看团队日常写什么，以及要上线到哪里。
小结
Google ADK for Kotlin 1.0 已经 GA。
它用 KMP 核心对齐 ADK Python / Java 1.0 的多代理、上下文压缩、HITL、注解工具、会话恢复、Java 互操作和 Vertex AI 相关服务。
工具侧靠 @Tool / @Param + KSP 编译期生成 schema，支持 suspend，不做运行时反射。
Skills 侧靠 SkillToolset 与 SKILL.md，按需加载流程和资源。
Android 侧补上 LiteRT-LM、ML Kit（beta）、Firebase AI Logic，以及 Room、AppSearch、文件 artifact。
依赖从 com.google.adk:google-adk-kotlin-core:1.0.0 起步，文档看 adk.dev，代码看 google/adk-kotlin。
如果你一直觉得"Agent 框架都是 Python 的事"，这篇文章至少说明一件事：
Kotlin 这边，官方也把生产级脚手架补齐了。
值不值得换，不必先争论生态高低。
打开仓库，把官方事故分诊或金融助手示例跑通，比看十篇趋势稿更有用。
（完）