KMP 用于 AI 智能体：在 4 个平台上的经验

Kotlin 多平台开发 AI 智能体：优势、劣势与发布陷阱

用 Kotlin 多平台（KMP）开发两个应用，历时六个月，揭示了关键洞见：Android、iOS、Web、桌面和后端代码复用。共享智能体代码集成 koog、mcp-sdk 和 cactus 等库，支持本地模型。亲身实践凸显了强大的 JVM 生态与平台特定障碍间的平衡。

KMP 的核心优势

KMP 将智能体业务逻辑集中管理，大幅减少重复代码。JVM 生态提供丰富的 LLM 供应商 SDK，而 Compose 多平台支持热重载，简化 UI 开发。Android 原生构建利用 Skia 支持 iOS，尽管桌面依赖 JAR 包装。

主要优势：

• 在 4+ 目标平台复用通用代码。
• 丰富的 JVM 生态支持智能体和模型。
• Kotlin 稳定，向后兼容性强。
• Compose UI 问题少。

明显的局限性

多平台支持要求使用 expect/actual 处理平台特定代码。桌面应用因 JVM 和 Swing 依赖而体积庞大，Web 仍处于 beta 阶段，存在库 bug 和 SEO 问题。iOS 调试体验基础，Swift 互操作落后于 JVM。桌面 UI 常显得不协调。

隐蔽的开发挑战

macOS 发布构建耗时数周：两个应用 ID（JRE 和应用）、三个签名密钥、应用商店和 DMG 的独立配置（每次公证 15+ 分钟）。原生库加剧复杂性——签名前资源打包到 JAR、ProGuard 排除项、Catalina 兼容（用户占比 63%）。TestFlight 需要 JDK 18+，另需 aarch64/x86_64 独立构建。

典型发布步骤：

• 为商店和直分生成密钥。
• 将原生资源嵌入 JAR。
• 处理 ProGuard 混淆。
• 公证与调试（5+ 次迭代）。
• 在旧版 macOS 测试。

KMP 资深专家稀缺：就业市场偏好单平台开发者。平台特定任务（如 iOS 政府证书 vs. Android）需深厚专长。LLM 在边缘案例中表现不佳。

库冲突与过度工程

Alpha 级库如 kotlinx-datetime 引发版本冲突：koog 自 9 月起拉取不兼容依赖。Web 缺少 Dispatchers.IO，导致共享代码分支。Android/桌面/后端卸载 JVM 逻辑增加编译时间，还重复反射代码。

明智选择：

• JVM 共享代码：反射适配妥协。
• 日志：平衡 logback 与合理默认。
• 测试：模拟 Android 上下文，桌面加速。

Xcode 加剧痛苦：启动慢、自动补全卡顿、随机崩溃。只有 6.1% 的 Stack Overflow 2025 开发者愿意忍受。

无框架构建 AI 智能体

放弃 langchain4j（臃肿、过时）和 koog（alpha 级、多余依赖如 simpleOpenAIExecutor）。自定义实现：节点图带过渡回调、分类、RAG、错误处理。优势：完全控制、最少依赖、无 OpenTelemetry 冗余。

智能体图可视化调试，手动构建状态机持久化提升韧性。测试针对共享代码，使用平台模拟。

测试智能体代码

测试在 iOS/Android 上运行，模拟上下文。桌面加速 CI。问题：编译慢、平台相关 Dispatchers。最佳实践：JVM 单元测试 + 平台特定集成测试。

关键要点：

• macOS 发布需数周处理密钥、公证、ProGuard。
• Alpha 库版本冲突（如 kotlinx-datetime）破坏构建。
• 自定义智能体优于框架，适合小众 LLM（如 GigaChat）。
• KMP 资深人才稀缺，平台技能必备。
• Xcode 是 iOS 开发的瓶颈。

总体评价：KMP 适合带 JVM 后端的 AI 智能体，但发布和 iOS/Web 需专业技能。

— Editorial Team