过去两年，几乎所有 AI Agent 教程都有一个共同点：默认使用 Python。

无论是 LangChain、AutoGen、CrewAI，还是各种 RAG、Workflow 框架，开发者几乎都会先安装 Python，再配置一堆依赖，然后开始搭建自己的 Agent。

但对于 Android 开发者来说，这种开发方式一直存在一个问题。

App 用 Kotlin 写，后端 Agent 用 Python 写，接口通过 HTTP 通信，看起来很合理，却意味着项目被迫维护两套语言、两套工程和两套部署环境。

很多团队都遇到过类似情况：Android 工程师不会 Python，AI 工程师不了解 Android，任何一个功能改动，都需要客户端、后端和 AI 三方协作，开发效率越来越低。

KotlinConf 2026 后，这种局面开始发生变化。

JetBrains 推出的 Koog，第一次让 Kotlin 拥有了完整构建 AI Agent 的能力。

对于 Kotlin 开发者而言，这意味着 AI Agent 不再必须依赖 Python，一个从 Android 到后端再到 AI 的统一技术栈开始成为现实。

为什么 Python 不一定是最佳选择？

Python 的生态确实成熟，但企业开发真正关心的不只是模型调用，而是工程维护。

一个典型的 AI 项目通常包含客户端、业务服务、数据库以及 Agent 工作流。如果 Agent 单独使用 Python，就需要维护两套项目结构。

Android（Kotlin）

        │

HTTP API

        │

Python Agent

        │

LLM / RAG / MCP

这种架构没有问题，却增加了语言切换、接口维护和部署成本。

如果团队本身就是 Kotlin 技术栈，这种成本会更加明显。

Koog 带来了什么？

Koog 并不是简单封装几个大模型 API，而是希望把 AI Agent 当作 Kotlin 的一等公民。

开发者可以直接在 Kotlin 中定义模型、Prompt、工具调用以及 Agent 工作流，而不需要额外维护一个 Python 服务。

整个架构可以变成：

Android

     │

Shared(KMP)

     │

Koog Agent

     │

LLM

     │

MCP / RAG

如果项目本身已经采用 KMP，那么 Android、Desktop、甚至 iOS 都可以共享 Agent 相关代码。

真正共享的不只是网络请求，而是整个 AI 能力。

KMP 的价值开始发生变化

很多人认为 KMP 的核心价值是"一套代码，多端运行"。

但在 AI 时代，更重要的是：

共享 AI 业务逻辑。

例如：

• Prompt 构建
• Memory 管理
• MCP Client
• RAG 检索
• Tool Calling
• Agent Workflow

这些模块几乎都与平台无关。

过去它们大多写在 Python。

现在，它们可以直接成为 Shared Module。

对于 Android、Desktop 和 iOS 而言，它们共享的是同一个 AI 大脑，而不是简单的工具类。

一个 Kotlin 全栈 AI 项目是什么样？

未来，一个 AI 项目的目录可能像这样：

shared
├── ai
│   ├── agent
│   ├── memory
│   ├── rag
│   ├── workflow
│   ├── prompt
│   └── mcp
├── data
├── network
└── domain

androidApp

desktopApp

iosApp

Android 负责界面。

iOS 负责交互。

Shared Module 负责整个 Agent。

这样的分工，比传统的"客户端 + Python 服务"更加统一。

Android 开发者最大的机会

过去几年，Android 开发者一直面临技术边界的问题。

不会后端。

不会 Python。

不会 AI。

于是很多人认为进入 AI 领域必须重新学习一套新的技术栈。

Koog 出现后，这条路径可能发生变化。

如果整个 AI Agent 都可以使用 Kotlin 编写，那么 Android 工程师可以直接利用已有经验进入 AI 应用开发，而不必完全转向 Python。

这也是 KotlinConf 2026 最值得关注的变化之一。

它不是又发布了一个 SDK，而是试图让 Kotlin 从移动开发语言，成长为 AI 全栈开发语言。

Kotlin 会取代 Python 吗？

答案当然是否定的。

Python 在 AI 研究、模型训练和算法生态中的优势短时间内不会改变。

但在应用开发层面，企业更关心的是工程效率、团队协作和维护成本。

如果一个团队已经全面采用 Kotlin，那么继续引入 Python，并不一定是成本最低的方案。

Koog 的意义就在于，让 Kotlin 开发者拥有新的选择。

未来很可能形成这样的分工：

Python 负责模型。

Kotlin 负责应用。

而 AI Agent，则成为连接两者的新桥梁。

写在最后

AI Agent 正在成为下一代应用的核心能力，而 Kotlin 的角色也正在发生变化。

过去它是 Android 开发语言，现在它正在尝试覆盖客户端、服务端以及 AI Agent。

对于 Android 开发者来说，与其问"KMP 会不会取代 Flutter"，不如开始思考另一个问题：

当 AI 成为每个应用的基础能力时，你是否还需要维护一套独立的 Python Agent 服务？

Koog 给出的答案是：也许不用了。