这套从 Amper 演进而来的 Kotlin Toolchain从 0.13 开始官方正式建议大部分新的 Kotlin Multiplatform 项目优先采用 Kotlin Toolchain用project.yaml、module.yaml声明项目和模块统一执行环境准备、构建、测试、运行和发布。比如以前 KMP 的痛点一般是 Android SDK、JDK、Xcode、模拟器、Gradle 插件和各平台配置需要团队分别维护这里 Toolchain 开始把这些繁琐环节收进同一个构建入口0.13 还补上了 Apple 依赖导入和 Native 迭代效率等关键支持。一、KMP 构建终于有了更统一的入口这次 0.13 主要增加了几个能力Swift Package Manager 依赖怎么进入 Kotlin/Native 编译链Native 缓存省了哪部分编译统一 CLI 和工程描述怎样让 AI Agent 更少试错因为在传统的 KMP 项目里面开发者经常要同时理解 Gradle、Android 工具链与 Xcode遇到依赖或者 SDK 缺失的时候还需要判断错误来自哪一层但是现在 Toolchain 的思路比较直接用 YAML 描述目标平台、模块、依赖和构建选项然后通过自身的任务执行和环境管理机制完成后面的步骤而且开发团队也能把项目自带的kotlin包装脚本纳入版本控制让开发机与 CI 采用约定好的 Toolchain 版本。比如 0.13 的kotlin new就把项目类型和目标平台变成两个交互式选择它和之前已经有的kotlin init用的同一套新初始化体验区别在于kotlin new是这个版本的 CLI 增强引导这里支持选择 Compose Multiplatform、JVM、KMP Library、Ktor、Spring Boot 等模板然后再配合 Android、iOS、Desktop、Web 和 Server 再按项目需要组合 这个版本还修了一个体验问题以前 Toolchain 在执行kotlin build或者kotlin run时能够自动准备 Android SDK但是开发者先用 IDE 打开项目SDK 缺失还是会导致同步失败所以现在项目导入 IDE 时也能触发 SDK 自动配置而且 iOS 方面还增加了 Xcode 初始化状态检查、Simulator Runtime 自动下载以及模拟器自动创建。这里的工程收益很直接新项目、CI 和不同开发机器使用统一的工程描述环境准备过程也更加可预测。不过这种便利并不代表 iOS 构建已经摆脱 macOS、Xcode 的要求。另外 0.13 还加入了 Swift Package Manager 依赖支持支持有 Apple 目标平台的模块直接声明 Swift Package比如现在希望在 iOS App 的 Kotlin 代码里用 Firebase Analytics可以配置product: ios/app ​ dependencies: - swiftPackage: repository: https://github.com/firebase/firebase-ios-sdk.git version: 12.17.0 products: [FirebaseAnalytics]之后可以在 Kotlin 代码中使用类似下面的导入import swiftPMImport.app.FIRAnalytics import swiftPMImport.app.FIRApp在 SwiftPMImportTask.kt 的实现里面其实就是 Toolchain 用生成的 SwiftPM/Xcode 工程调用xcodebuild然后拿到实际构建参数然后找到 Clang Module、提取链接选项然后交给 Kotlin/Native 的 cinterop 生成可调用的绑定。也就是原本需要开发者手动协调的 SwiftPM、Xcode、Clang 和 Kotlin/Native 构建步骤现在统一集成到了一个构建链。不过支持 SwiftPM 不是说 Kotlin/Native 就能直接调用任意纯 Swift API目前导入的还是 Objective-C 可见的接口// /path/to/CryptoKitWrapper/Sources/CryptoKitWrapper/CryptoKitWrapper.swift // CryptoKit is a system library with Swift APIs that are not accessible to Objective-C import CryptoKit import Foundation ​ objc public class CryptoKitWrapper: NSObject { objc public static func sha256(data: NSData) - NSString { return SHA256.hash(data: data).map { String(format: %02x, $0) }.joined() as NSString } }另外发布链也同步完善了比如你开发的是一个依赖 SwiftPM 的 KMP Library发布时会带上-swiftpm-metadata.json这样消费端才能知道应该获取哪些 Swift Package这个格式在这里沿用了 Kotlin Gradle Plugin 的相关约定这部分增量主要都集中在 Toolchain 的依赖解析、cinterop、链接和发布集成上。依赖本地 Swift Package 的 Library 只能发布到mavenLocal因为本地包的绝对路径不能在其他开发者机器上可靠复现所以 Toolchain 会阻止发布到共享 Maven 仓库。另外现在Native 缓存终于接进来了做过 KMP iOS 开发的应该都有印象有时只是改了共享模块中的一小段 Kotlin 代码重新运行 iOS App 会需要等比较长的编译和链接过程这个也是 Shopify 从 RN 转原生的时候提了为什么不选 KMP 的原因之一。因为 Kotlin/Native 编译存在不同阶段项目代码会先生成.klib然后编译器还要把代码和依赖处理成最终 Native 二进制传统情况下后一个阶段会反复处理大量已经没有变化的依赖。然后 0.13 通过 KTC-5422 把 Kotlin/Native 已有的 Compiler Caches 接入到了 Toolchain 构建流程比如源码 NativeCompilerCaches.kt 里面可以看到几个关键参数-Xauto-cache-from... -Xenable-incremental-compilation -Xic-cache-dir...这里分成两类缓存外部依赖可以编译成可跨构建、跨项目复用的机器级缓存项目自己的代码用每文件级增量缓存配合NativeLinkTask.kt保留和重用缓存目录下一次只修改一个 Kotlin 文件的时候Native 链接阶段有机会复用大部分已有结果。这套设计继承了 Kotlin/Native 已经有的编译器缓存机制属于 Toolchain 这次真正完成的工程接入。最后 JetBrains 还把 Kotlin Toolchain 和 AI Agent 结合起来提供了官方的 Kotlin Agent Skills可以告诉 Agent 怎么识别 Toolchain 工程、使用正确的 CLI、生成模块配置还有避开已有 Gradle 项目。在官方的一组测试里面JetBrains 让 Claude Sonnet 5 用 Claude Code 创建同时支持 Android、iOS 的 Kotlin Toolchain 工程每组运行十次两组环境和任务相同区别在于有没有 Toolchain Skill 指标无 Skill有 Skill平均 Reward0.63331.0000平均工具调用299平均总 Token976,117405,176平均端到端时间15分21秒15分30秒整体Token 消耗下降 58%工具调用也明显减少。所以后面KMP 大概率基本都是一个 kotlin 命令Gradle 是真的退役了。