ADK Kotlin 1.0:智能体逻辑不必再绕回 Python
Google 发布 Kotlin 版智能体开发套件 1.0,功能上与 Python 版和 Java 版对齐,可用于 Android、JVM 和服务端。几处设计值得留意:工具的描述在编译期由注解生成,不靠运行时反射;敏感工具可以声明为执行前必须人工确认;技能存放在 SKILL.md 里按需加载。端侧推理支持 LiteRT-LM 与仍在测试阶段的 ML Kit。
编辑标为信号级,适合持续跟踪。
本页目录12 节
记录
信号正文
#发布了什么
一个用 Kotlin 写智能体的框架,基于 Kotlin Multiplatform,从服务端到移动设备都能运行。编排、工具调用、持久化、记忆和人在回路的流程都有地道的 Kotlin 接口,开发者不必再为智能体逻辑单独维护一段 Python。Google 的说法是,它的架构不绑定特定的模型后端、会话存储或记忆系统。框架已在 GitHub 上开源。
1.0 新增的能力
- 分层多智能体:父智能体可以把任务委派给子智能体
- 上下文压缩:自动管理上下文并对历史做摘要,减少 token 用量
- 会话管理:智能体的状态可以暂停、序列化、再恢复
- 与 Java 的一等互操作
三处设计
工具描述在编译期生成。工具用 @Tool 和 @Param 注解声明,由 KSP 在编译期生成函数的描述规约,不依赖运行时反射。好处是类型安全,以及移动端的启动速度。
敏感操作可以要求人工确认。在工具声明里设置 requireConfirmation,调用前就必须得到用户明确批准。文中举的例子是发起银行转账。
技能按需加载。程序性知识放在 SKILL.md 文件里,只在用到时才加载进上下文。Google 称之为渐进式披露:智能体能拿到某个领域的操作手册,又不必每次都把整本手册塞进上下文。
端侧与云端
端侧推理支持 LiteRT-LM 和 ML Kit,后者目前仍是测试版功能。云端与混合场景通过 Firebase AI Logic 接入,应用可以在合适的时候本地运行智能体,需要更强能力时再用云端模型。持久化可以直接用 Android 的原生服务:会话存进 Room,可索引的记忆用 AppSearch。
一条来自使用者的建议
InfoQ 引用了一位开发者通讯维护者的看法:先搭一个可恢复的智能体,并打开工具的显式确认,之后再考虑多层级的智能体体系。能不能上生产,更多取决于生命周期能否恢复、工具边界是否确定,而不是智能体的数量。
怎么读这条
这不是一项新能力,是已有能力到达了一个新平台。对移动端团队,它的意义在于智能体可以和应用用同一种语言、同一套构建流程;移动应用随时会被系统挂起,所以暂停后能恢复的会话是必需品,不是锦上添花。
本条依据 InfoQ 的报道写成,InfoQ 中文站的文章译自其英文站。
为什么是现在
为什么重要
#智能体框架此前基本是 Python 的地盘,移动端要用就得跨语言。这一版把人工确认、会话恢复和按需加载这些生产上必需的东西做成了框架的默认能力,而不是留给每个团队自己补。
背景
技术背景
#智能体框架把模型调用、工具执行、状态保存这些重复的部分封装起来。运行时反射是程序在运行时检查自身结构的能力,灵活但慢,在移动端会拖慢启动;在编译期生成同样的信息可以避免这个代价。
关注人群
谁该关注
#下一步
学习路径
#- 先读《人在回路的审查》:哪些操作应当在执行前停下来问人
- 读《长时程智能体的记忆与上下文管理》:上下文压缩在解决什么
- 读本站微软 Agent Framework Harness 那一条:另一家怎样把运行时做成产品
- 列出你的应用里会产生实际后果的工具,逐个决定要不要人工确认
关系网络
在技术网络中的位置
#当前技术与相邻技术、技能和背景知识的连接,点击节点可继续探索。
延伸思考
后续问题
#- 你的智能体被系统挂起之后,能从原来的位置继续吗?
- 哪些工具调用会产生无法撤回的后果?
- 你真的需要多个智能体,还是一个智能体加清楚的工具边界就够了?
发布记录
收录于
#收录这条信号的技术简报,新的在前;最后一行是它那一周的周回顾。标签是它在那一期所在的栏目。
来源参考