炉 VI · 回火CH 25进度 25/26

疆域：KMP、Swift Export 与用 Kotlin 写 Agent

你的 Kotlin 技能现在能覆盖多大地盘？这一章画一张地图 —— 但我要先立一条规矩：本章的每一项，我都会告诉你「该跟」还是「该等」。因为「Kotlin 能做 X」和「你应该用 Kotlin 做 X」是两个问题，而技术博客通常只回答前一个。你是个要交付产品的工程师，不是收集技能徽章的人。

KMPCompose MultiplatformSwift ExportKoog

KMP：共享逻辑，不是共享 UI

Kotlin Multiplatform 最容易被误解的一点：它不是「一次编写，到处运行」。它的主张要克制得多，也现实得多：

◆ 锭 · KMP 的真正主张

共享那些「本来就和平台无关」的东西 —— 网络请求、数据模型、业务规则、状态机、校验逻辑、数据库访问、错误处理。

把 UI 留给各自的平台（或者用 Compose Multiplatform，但那是另一个决定，不是必选项）。

换句话说：你在前面 24 章里学的一切 —— sealed 状态建模、协程、Flow、错误建模 —— 几乎全部是可共享的。而它们恰恰是一个 App 里最难写对、最不该写两遍的部分。

KMP 的采用率在过去一年翻了一番（KotlinConf 26 数据），而生态已经补齐了：Ktor（网络）、SQLDelight / Room（数据库）、kotlinx.serialization、kotlinx.coroutines、DataStore —— 你 Android 上那套工具，大部分已经是跨平台的了。

判断：

  • ✓ 该跟，如果你的公司同时有 Android 和 iOS 团队，而且两边在重复实现同一套业务逻辑（同样的 bug 修两遍、同样的接口对接两遍）。这是 KMP 的甜蜜点，收益是实打实的。
  • ⚠ 该等，如果你只做 Android。KMP 会给你的构建增加复杂度，而收益是零。「以后可能要做 iOS」不是理由 —— 那天真来了再说，业务逻辑本来就该是分层的、可迁移的。

Compose Multiplatform：一个独立的决定

用 Compose 写 iOS / 桌面 / Web 的 UI。iOS 和桌面已经稳定，Web 目前在 Beta。

它是和 KMP 分开的一个决定：你完全可以用 KMP 共享逻辑，而 iOS 侧照常用 SwiftUI 写 UI —— 事实上这也是目前最稳妥的组合。

判断：如果你的 iOS 团队不想放弃 SwiftUI（大概率），别硬推 Compose Multiplatform —— 那会变成一场政治斗争而不是技术选型。它更适合：内部工具、没有专职 iOS 团队的小团队、或者以 Android 为主的产品想「顺便有个 iOS 版」。

Swift Export：iOS 侧终于能好好用你的代码了

KMP 一直有个尴尬：Kotlin 代码导出给 iOS 时，要先经过 Objective-C 这一层 —— 于是 Swift 侧看到的是一堆 KotlinInt、KotlinArray，泛型丢失，suspend 函数变成回调，用起来非常别扭。

Swift Export（2026 年进入 Alpha）直接生成 Swift API，跳过 ObjC：

// Kotlin 侧
suspend fun loadUser(id: String): User
fun userFlow(): Flow<User>
let user = try await loadUser(id: "42")     // suspend → Swift 原生 async/await

for await user in userFlow() {              // Flow → Swift 的 AsyncSequence
    print(user)
}

这是 KMP 体验的关键一块拼图。「iOS 同事觉得 KMP 的代码难用」这个 KMP 推广路上最大的阻力，正在被拆掉。

判断：Alpha 阶段，别用在生产。但如果你正在评估 KMP —— 它是「未来一两年 KMP 会变得好用得多」的最强信号。

Koog：用 Kotlin 写 AI Agent

2026 年绕不开的话题。Koog（JetBrains 出品，1.0 已稳定）让你用 Kotlin 构建 AI Agent：

val agent = AIAgent(
    executor = simpleOpenAIExecutor(apiKey),   // 或者接 Anthropic 等
    systemPrompt = "你是一个订单助手",
    toolRegistry = ToolRegistry {
        tool(::searchOrders)                   // 普通的 Kotlin 函数，直接注册成工具
        tool(::refund)
    }
)

val answer = agent.run("帮我查一下上周的订单")   // suspend 函数

为什么 Kotlin 适合干这个？看看一个 Agent 框架真正需要什么：异步 + 流式输出（协程和 Flow，第 14—18 章）、结构化的工具定义（类型安全的函数签名 + 反射/KSP）、状态机与重试（sealed + 结构化并发）、DSL（第 11 章）。

这些恰好是你前面二十四章学的全部东西。—— 这一点值得停下来体会：Agent 编排的本质是「一堆异步的、可能失败的、需要取消和重试的工具调用」，而这正是 Kotlin 协程最擅长的领域。

判断：如果你要在后端或Android 端做 AI 功能，Koog 是一个不用切语言的选项 —— 你的协程、Flow、错误建模技能全部可以直接复用。（想深入 Agent 本身的原理，本站有一本姊妹作 《我，Agent》。）

AI 已经进了你的 IDE

2026 年的 Android 开发现场，工具链已经变了：Junie（JetBrains 的编码 Agent）有了专门的 Android 支持，Claude 已经原生集成进 IntelliJ 和 Android Studio。

与其争论「AI 会不会取代程序员」，不如问一个更有用的问题：AI 让哪些技能升值了？

◆ 锭 · AI 时代，这本书教的东西反而更值钱

AI 很擅长写出能跑的代码。它不擅长的是：

  • 判断这段代码对不对。AI 会毫不犹豫地给你一个用 runCatching 包住 suspend 调用的「防御性写法」（第 15 章：它吞掉取消信号）—— 因为网上一半的代码都是这么写的。你能不能看出来？
  • 建模。「这个状态该用 sealed 还是 boolean 堆」「这个错误该是异常还是返回值」—— 这些决定 AI 会跟着你的暗示走，而暗示是你给的。
  • 知道代价。AI 会给你一个能跑的 collectLatest，但不会告诉你它可能留下半截的副作用。

「说得清」的价值，在 AI 时代反而上升了 —— 因为写代码的成本正在归零，而审查和判断的成本没有。这就是为什么第 1 章那十道题重要。

一张地图，一句总结

疆域状态该跟还是该等
KMP（共享业务逻辑）成熟，采用率翻倍有 iOS 团队 → 跟。纯 Android → 不必
Compose MultiplatformiOS/桌面稳定，Web Beta⚠ 独立决定。iOS 团队爱 SwiftUI 就别硬推
Swift ExportAlpha⚠ 别上生产，但它是 KMP 未来的强信号
Koog（AI Agent）1.0 稳定✓ 要做 AI 功能就跟 —— 协程技能直接复用
Kotlin/Wasm还在快速演进⚠ 观望。除非你有明确的 Web 场景
后端 Kotlin（Ktor / Spring）成熟✓ 想扩展到全栈，这是最短的路 —— 语言不用换，协程照旧
✚ 动手锻打

1. 不管你要不要做 KMP，都做这件事：检查你的 domain 层有没有依赖 Android 框架（android.* 的 import、Context、LiveData）。如果没有 —— 恭喜，它已经是可共享的了。如果有，那是个分层问题，和 KMP 无关，本来就该修。

2. 用 Ktor 写一个五十行的后端服务（一个 GET /users）。你会发现你什么新东西都不用学 —— 协程、序列化、错误处理全是同一套。这是「Kotlin 全栈」最直观的一次体验。

3. 如果你对 AI 开发有兴趣：用 Koog 搭一个能调用两个工具的最小 Agent。把你的协程和 Flow 知识用上，看看它有多自然。

4. 下次让 AI 帮你写协程代码时，专门检查三件事：有没有 runCatching 吞取消？async 有没有裸奔？collectAsState 有没有带 Lifecycle？—— 这是你现在能做而它做不好的事。

最后一章：出炉。回到第 1 章那十道题，交一份代码审查清单，然后给一个不讨喜但诚实的答案 —— 有些时候，你确实还该写 Java。