为什么用JVM写AI Agent？Kotlin与Ktor的工程化实践

1. 为什么我会认真考虑用 JVM 写 AI Agent1.1 一个让我重新思考技术选型的真实场景去年年底我接了一个内部工具项目需求很明确做一个能自动读取工单系统、调用大模型做分类、再把结果写回数据库的 AI Agent。团队里大部分人第一反应是“上 PythonLangChain 一套就完事了”。我一开始也是这么想的毕竟 Python 在 AI 领域的生态确实成熟库多、示例多、上手快。但真正开始做的时候问题一个接一个冒出来。工单系统是 Java 写的数据库连接池、事务管理、定时任务调度全在 Spring 体系里大模型调用需要稳定的 HTTP 客户端和重试机制Agent 要长期驻留后台不能动不动就内存泄漏或者 GC 卡死。用 Python 写当然也能做但意味着我要维护两套运行时、两套依赖管理、两套监控体系部署的时候还得考虑进程间通信。后来我换了个思路既然业务系统已经在 JVM 上了为什么 Agent 不能也跑在 JVM 上Kotlin 写起来不比 Python 啰嗦多少Ktor 做 HTTP 服务端和客户端都很顺手JVM 的线程模型、内存管理、可观测性工具链又足够成熟。于是就有了这个标题——为什么我不用 Web 生态而是用 JVM 来写 AI Agent。这里说的“Web 生态”不是指前端页面而是指以 Python/Node.js 为主的那套快速脚本化、轻量运行时、围绕 Web 框架和异步 IO 构建的 Agent 开发方式。JVM 路线则是以 Kotlin/Java 为核心依托 JVM 的强类型、多线程、成熟监控和长期稳定运行能力来构建 Agent。这篇文章适合谁看如果你正在做 AI Agent 开发尤其是需要和现有企业系统集成、需要长期稳定运行、需要可观测和可调试的场景那我的这些踩坑经验应该对你有用。如果你只是做个 demo 或者一次性脚本Python 确实更快没必要硬上 JVM。但如果你要做的是“从 0 到 1 搭建 AI Agent”并且要上生产那 JVM 这条路值得认真考虑。1.2 JVM 写 Agent 到底解决了什么问题先说最核心的三个问题。第一是运行时稳定性。AI Agent 和普通 Web 服务不一样它往往要长时间运行持续监听消息队列、轮询任务、维护会话状态。Python 的 GIL 和异步模型在这种场景下容易出问题尤其是当你需要同时处理几十个并发请求、每个请求又要调用外部大模型 API 的时候。JVM 的线程池和虚拟线程JDK 21在这块优势明显你可以用很低的成本起大量并发任务而且 GC 行为可预测、可调优。第二是类型安全和可维护性。Agent 的逻辑往往很复杂解析用户输入、构造 prompt、调用模型、解析输出、做工具调用、处理异常、记录日志。Kotlin 的密封类、数据类、协程、空安全这些特性能让这些逻辑写起来清晰很多。尤其是工具调用tool calling这块用密封类定义工具返回结果编译器帮你检查所有分支比 Python 里靠约定和文档靠谱得多。第三是与现有系统的集成成本。大部分企业的核心业务系统都是 Java 写的数据库驱动、消息队列客户端、配置中心、服务发现、链路追踪这些基础设施在 JVM 上都是现成的。Agent 如果跑在 JVM 上可以直接复用这些能力不需要额外搭桥。我之前用 Python 做 Agent 的时候光是接公司内部的配置中心和监控上报就折腾了好几天换成 Kotlin 之后半天就搞定了。当然JVM 路线也不是没有代价。启动慢、内存占用高、生态里 AI 相关的库不如 Python 丰富这些都是事实。但对我来说这些代价换来的是长期运行的稳定性和与现有系统的无缝集成这笔账算得过来。2. 核心细节解析JVM 上写 Agent 的关键技术点2.1 为什么选 Kotlin 而不是 JavaJava 当然也能写 Agent但 Kotlin 在几个地方明显更顺手。首先是协程。Agent 经常需要并发调用多个工具或者多个模型接口Kotlin 的协程写起来比 Java 的 CompletableFuture 简洁太多。比如你要同时查天气、查日历、查数据库然后汇总结果Kotlin 里就是几个async加awaitAllJava 里得写一堆thenCombine。其次是空安全。Agent 处理的外部输入很多是不可控的模型返回的 JSON 可能缺字段工具调用可能返回 null。Kotlin 的类型系统强制你处理这些情况编译期就能发现很多潜在的空指针问题。我之前用 Java 写的时候线上出过好几次 NPE都是模型返回格式不符合预期导致的。第三是数据类。Agent 里到处都是 DTO请求、响应、工具参数、工具结果、会话状态。Kotlin 的data class一行顶 Java 几十行而且自带copy、equals、hashCode做状态更新的时候特别方便。第四是DSL 能力。Kotlin 的 DSL 写 prompt 模板、工具定义、流程编排都很舒服。比如你可以定义一个agent { }块里面用tool { }声明工具用step { }声明步骤读起来就像自然语言。当然如果你团队全是 Java 背景硬上 Kotlin 也有学习成本。但我的经验是有 Java 基础的人学 Kotlin 大概一周就能上手两周就能写出可维护的代码。这个投入是值得的。2.2 Ktor 在 Agent 里的角色Ktor 是我在 JVM 上做 Agent 的首选 HTTP 框架。它有两个用途一是作为 Agent 的服务端对外提供 API二是作为 HTTP 客户端调用大模型接口和外部工具。作为服务端Ktor 很轻启动快配置简单。你可以用几行代码起一个带路由、内容协商、日志、监控的 HTTP 服务。对于 Agent 来说通常不需要太复杂的功能Ktor 刚好够用不会像 Spring Boot 那样带来一堆用不上的自动配置。作为客户端Ktor 的HttpClient支持连接池、超时、重试、日志而且和协程无缝集成。调用大模型 API 的时候你可以直接用client.post发请求用bodyAsText拿响应配合retry和timeout处理网络抖动。我之前用 Java 的 HttpClient 写这些逻辑代码量大概是 Ktor 的三倍。这里有个细节值得说Ktor 的ContentNegotiation插件配合kotlinx.serialization可以自动把 JSON 转成数据类。Agent 处理模型返回的时候这个能力特别有用。你定义一个data class ModelResponse然后call.receiveModelResponse()剩下的交给框架。如果字段对不上会直接抛异常而不是悄悄给你一个 null。2.3 JVM 内存模型对 Agent 的影响JVM 内存模型这块很多人觉得是面试题才用的东西但写 Agent 的时候真的会碰到。Agent 的典型内存分布是这样的堆里放着会话状态、工具缓存、模型响应栈里放着协程的局部变量元空间里放着类定义。如果你用虚拟线程每个虚拟线程的栈是存在堆里的所以堆的压力会更大。我遇到过一个典型问题Agent 长时间运行后老年代越来越大Full GC 越来越频繁。用jmap和jstat查下来发现是会话缓存没有过期策略每个会话的上下文都堆在ConcurrentHashMap里。后来加了基于时间的淘汰和基于大小的限制问题就解决了。另一个坑是大对象。模型返回的 JSON 有时候很大如果你直接把它整个读进内存再解析很容易触发大对象分配直接进老年代。我的做法是用流式解析或者限制单次响应的大小。Ktor 的bodyAsChannel可以让你流式读取响应配合kotlinx.serialization的流式 API能显著降低内存峰值。还有元空间泄漏。如果你在 Agent 里动态生成类比如用反射或者字节码库每次生成都会占用元空间。如果生成逻辑有 bug元空间会一直涨最后 OOM。我一般会限制动态类的数量或者干脆避免在运行时生成类。2.4 工具调用与类型安全Agent 的核心能力之一是工具调用。用户问“今天天气怎么样”Agent 要能识别出需要调用天气工具构造参数执行调用再把结果返回给模型。在 Python 里工具通常用字典或者装饰器定义参数校验靠运行时检查。在 Kotlin 里我可以用密封类定义工具结果sealed class ToolResult { data class Success(val data: String) : ToolResult() data class Failure(val reason: String) : ToolResult() data class NeedMoreInfo(val question: String) : ToolResult() }这样在when表达式里处理结果的时候编译器会强制你覆盖所有分支。如果以后加了新的结果类型所有处理的地方都会编译报错不会漏掉。工具参数也可以用数据类定义配合kotlinx.serialization做校验。比如Serializable data class WeatherParams( val city: String, val date: String? null )模型返回的参数 JSON 反序列化到这个类如果缺了必填字段会直接抛异常而不是等到调用的时候才发现。2.5 可观测性JVM 的隐藏优势Agent 跑在生产环境可观测性太重要了。你需要知道每个请求的耗时、每个工具调用的成功率、模型返回的 token 数、内存和 GC 的情况。JVM 在这块的优势是工具链成熟。Micrometer 做指标Logback 做日志OpenTelemetry 做链路追踪这些都有现成的 Kotlin 支持。你可以用几行代码把 Agent 的关键指标暴露到 Prometheus然后用 Grafana 做面板。我之前用 Python 做 Agent 的时候监控这块要自己搭指标格式、上报方式、采样策略都得自己定。换成 JVM 之后直接用 Micrometer 的Timer、Counter、Gauge配合 Spring Boot Actuator 或者 Ktor 的 Micrometer 插件半天就能把监控搭起来。还有一个细节JVM 的线程 dump 和堆 dump 是标准化的出问题的时候可以直接用jstack和jmap分析。Python 虽然也有类似工具但生态碎片化严重不同版本、不同运行时行为不一致。JVM 在这方面的一致性要好得多。3. 实操过程从零搭建一个 JVM AI Agent3.1 项目结构与依赖选择我的项目结构大概是这样agent-core/ # 核心逻辑会话管理、工具调用、模型接口 agent-tools/ # 工具实现天气、日历、数据库查询 agent-server/ # Ktor 服务端HTTP API、WebSocket agent-monitor/ # 监控指标、日志、追踪依赖方面核心的几个是Kotlin 2.xKtor 3.xserver 和 clientkotlinx.serializationkotlinx.coroutinesMicrometerLogbackHikariCP如果需要数据库模型调用我一般直接走 HTTP不依赖特定的 SDK。因为大模型 API 变化快自己封装一层反而更灵活。Ktor 的HttpClient配合ContentNegotiation就够了。这里有个选型细节为什么不直接用 Spring AI 或者 LangChain4j我的考虑是这些框架抽象层太厚出问题的时候不好排查。而且 Agent 的逻辑往往很定制化框架提供的通用能力不一定贴合需求。自己封装一层代码量不大但可控性强很多。3.2 会话管理与状态存储Agent 的会话管理是核心。每个用户会话需要保存对话历史、当前上下文、工具调用记录、状态标记。我的做法是用一个SessionManager内部用ConcurrentHashMap存活跃会话配合定时任务做过期清理。会话对象本身是不可变的每次更新都生成新对象避免并发问题。data class Session( val id: String, val history: ListMessage, val context: MapString, String, val createdAt: Instant, val lastActiveAt: Instant )存储方面短期会话放内存长期会话落数据库。数据库用 HikariCP 连接池配合 Exposed 或者 JOOQ 做 ORM。如果会话量很大可以考虑 Redis但我的场景下内存加数据库就够了。这里有个坑会话历史不能无限增长。模型有 token 限制历史太长会导致请求失败。我的做法是保留最近 N 轮对话更早的做摘要压缩。摘要用模型生成存成一个特殊的SummaryMessage。3.3 模型调用的封装与重试模型调用这块我封装了一个ModelClient对外暴露suspend fun chat(messages: ListMessage): ModelResponse。内部实现要点用 Ktor 的HttpClient配置连接池和超时请求体用kotlinx.serialization序列化响应解析成数据类失败时根据状态码决定是否重试记录耗时和 token 数重试策略我用的是指数退避初始 1 秒最大 30 秒最多重试 3 次。对于 429限流和 5xx服务端错误重试对于 4xx客户端错误直接失败。suspend fun chat(messages: ListMessage): ModelResponse { return retry(maxAttempts 3, initialDelay 1000, maxDelay 30000) { val response client.post(/v1/chat/completions) { contentType(ContentType.Application.Json) setBody(ChatRequest(messages)) } if (response.status.isSuccess()) { response.bodyModelResponse() } else { throw ModelException(response.status.value) } } }这里有个细节重试的时候要注意幂等性。如果模型调用已经产生了副作用比如扣费重试可能会导致重复扣费。我的做法是在请求里带一个唯一的requestId服务端可以根据这个 ID 做去重。3.4 工具调用的实现与注册工具调用的实现分三步定义工具接口、实现具体工具、注册到 Agent。工具接口interface Tool { val name: String val description: String suspend fun execute(params: JsonObject): ToolResult }具体工具class WeatherTool(private val client: HttpClient) : Tool { override val name get_weather override val description 查询指定城市的天气 override suspend fun execute(params: JsonObject): ToolResult { val city params[city]?.jsonPrimitive?.content ?: return ToolResult.Failure(缺少城市参数) return try { val weather client.get(https://api.weather.com/$city).bodyAsText() ToolResult.Success(weather) } catch (e: Exception) { ToolResult.Failure(查询失败: ${e.message}) } } }注册class ToolRegistry { private val tools mutableMapOfString, Tool() fun register(tool: Tool) { tools[tool.name] tool } fun get(name: String): Tool? tools[name] fun all(): ListTool tools.values.toList() }Agent 在处理用户输入的时候先把工具列表和描述发给模型模型返回要调用的工具和参数Agent 执行工具再把结果发给模型模型生成最终回复。3.5 部署与运行参数调优部署这块我用的是 Docker 加 JVM 参数调优。基础镜像用eclipse-temurin:21-jre启动命令java -XX:UseZGC \ -XX:MaxRAMPercentage75 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/dumps \ -jar agent-server.jar几个关键参数UseZGC低延迟 GC适合 Agent 这种对响应时间敏感的场景MaxRAMPercentage75容器里限制堆大小留 25% 给元空间、栈、直接内存HeapDumpOnOutOfMemoryErrorOOM 的时候自动 dump方便排查如果是 JDK 21还可以开虚拟线程java -XX:UseZGC -Dkotlinx.coroutines.schedulervirtual -jar agent-server.jar虚拟线程对 Agent 这种 IO 密集型的场景提升很明显可以用更少的物理线程支撑更多并发请求。监控方面暴露/metrics端点给 Prometheus关键指标包括请求总数和耗时分布模型调用成功率和延迟工具调用成功率和延迟会话数量和内存占用GC 次数和耗时4. 常见问题与排查技巧实录4.1 JVM 内存泄漏怎么查Agent 跑久了内存涨这是最常见的问题。排查步骤先用jstat -gc pid 1000看 GC 情况。如果老年代持续增长Full GC 后也降不下来基本就是泄漏。用jmap -histo:live pid看对象分布找出数量异常多的类。用jmap -dump:live,formatb,fileheap.hprof piddump 堆然后用 MAT 或者 VisualVM 分析。重点看ConcurrentHashMap、ThreadLocal、缓存类、监听器列表这些容易泄漏的地方。我遇到过的几个典型泄漏会话缓存没有过期策略一直涨线程池的队列没有限制任务堆积日志里打印了大对象导致字符串常量池膨胀动态生成的类没有释放元空间泄漏4.2 模型调用超时和限流怎么处理模型 API 超时和限流是常态必须处理好。超时方面设置合理的连接超时和读取超时。连接超时一般 5 秒读取超时根据模型响应时间定一般 30 到 60 秒。Ktor 里可以这样配install(HttpTimeout) { connectTimeoutMillis 5000 requestTimeoutMillis 60000 socketTimeoutMillis 60000 }限流方面除了重试还要做客户端限流。用Semaphore或者RateLimiter控制并发请求数避免把模型 API 打挂。private val semaphore Semaphore(10) suspend fun chat(messages: ListMessage): ModelResponse { semaphore.withPermit { // 调用模型 } }4.3 工具调用失败怎么降级工具调用失败是常事网络抖动、第三方服务挂了、参数不对都可能失败。降级策略失败时返回明确的错误信息给模型让模型决定怎么回复用户对于关键工具做本地缓存失败时用缓存数据对于非关键工具直接跳过不影响主流程记录失败日志方便后续排查我一般会在ToolResult.Failure里带上失败原因模型看到原因后可以给用户更友好的提示而不是直接说“系统错误”。4.4 常见问题速查表问题可能原因排查方法解决方案内存持续增长缓存无过期、监听器未注销jmap -histo、MAT 分析加过期策略、弱引用Full GC 频繁堆太小、大对象多jstat -gc、GC 日志调大堆、流式处理模型调用超时网络慢、模型响应慢看日志耗时、抓包调超时、加重试工具调用失败第三方服务问题看工具日志降级、缓存启动慢类加载多、依赖重看启动日志用 AppCDS、精简依赖CPU 高死循环、频繁 GCtop、jstack查代码、调 GC4.5 几个我踩过的坑第一个坑是协程泄漏。用GlobalScope.launch启动的协程如果没处理好会一直挂着导致内存泄漏。我的做法是用CoroutineScope配合SupervisorJob在服务关闭的时候统一取消。第二个坑是序列化兼容性。kotlinx.serialization默认对未知字段是忽略的但如果模型返回的字段类型变了比如从 string 变成 number会直接抛异常。我的做法是给关键字段加Serializable(with ...)自定义序列化器做类型兼容。第三个坑是日志太多。Agent 的日志很容易爆炸尤其是调试模式下打印完整请求和响应。我的做法是分级日志生产环境只打关键信息调试信息用采样或者开关控制。第四个坑是时区问题。Agent 处理时间相关的逻辑一定要统一时区。我一般用 UTC 存储展示的时候转本地时区。之前因为时区问题定时任务跑错了时间排查了半天。第五个坑是依赖冲突。JVM 生态里依赖冲突很常见尤其是 Ktor、Kotlin、kotlinx 库之间。我的做法是用 Gradle 的dependencyInsight查冲突然后用resolutionStrategy强制版本。5. 一些个人体会和后续扩展方向用 JVM 写 AI Agent 这段时间最大的感受是技术选型没有绝对的对错只有适不适合。Python 在 AI 领域的优势是事实但 JVM 在工程化、稳定性、可观测性上的优势也是事实。如果你的 Agent 只是做个 demoPython 更快但如果要上生产、要长期运行、要和现有系统集成JVM 值得认真考虑。Kotlin 在这条路线里扮演了关键角色。它既有 JVM 的稳定性又有现代语言的表达力。协程、空安全、数据类、密封类这些特性让 Agent 的代码写起来清晰、改起来放心。后续我打算在这几个方向继续扩展一是把 Agent 的流程编排做成 DSL让非技术人员也能配置二是接入更多的模型提供商做统一的抽象层三是把监控和告警做得更细尤其是模型调用的成本和延迟四是探索虚拟线程在 Agent 里的更多用法看看能不能进一步降低资源消耗。如果你也在做类似的事情欢迎交流。踩过的坑、试过的方案、调过的参数这些才是真正有价值的东西。