IntelliJ Conf：JetBrains Koog Java原生AI Agent框架实战

文章目录前言Java程序员的Agent焦虑终于有解了认识Koog不是又一个LangChain的Java版环境准备5分钟让项目跑起来实战从Hello World到智能客服第一步定义工具Tool第二步构建Agent第三步运行Agent高级玩法复杂工作流与容错机制函数式策略像写普通Java代码一样编排Agent持久化与故障恢复Agent的存档点历史压缩省下的token都是钱观测性你的Agent在想什么一目了然性能对比原生JVM的优势与现有生态的集成写在最后Java的AI春天来了参考文档无意间发现了一个CSDN大神的人工智能教程忍不住分享一下给大家。很通俗易懂重点是还非常风趣幽默像看小说一样。床送门放这了 http://blog.csdn.net/jiangjunshow前言Java程序员的Agent焦虑终于有解了说实话作为一个写了十几年Java的老码农这两年看着Python圈子里LangChain、AutoGPT玩得飞起心里多少有点不是滋味。每次团队想上AI Agent总有人说“要不单独起个Python服务”——这话听着就像告诉一位老厨师你用了二十年的菜刀不能切新食材得去隔壁借把日式厨刀。这种割裂感干过的都懂。你的核心系统在Java里跑得好好的Spring Boot生态根深蒂固结果为了做个智能客服或者自动化审核非要引入一个Python微服务序列化来序列化去调试还要跨语言。数据在JVM堆内存里躺着Agent却隔着REST API跟你喊话 latency高得离谱不说类型安全更是无从谈起。好在JetBrains终于看不下去了。就在今年3月20号JetBrains官方博客甩出一篇重磅文章《Koog Comes to Java: The Enterprise AI Agent Framework From JetBrains》。没错就是那个做IntelliJ IDEA的JetBrains他们把自己内部用的AI Agent框架Koog正式开放给Java开发者了而且还是原生的、完全兼容Spring Boot的、不需要你写一行Kotlin的纯Java方案。更让人兴奋的是原定于今年3月举行的IntelliJ IDEA Conf 2026虽然改期到了9月但Koog for Java的发布已经让社区炸锅了。这篇文章就带大家 Hands-on 地体验一下看看这个亲儿子框架到底能不能让Java程序员在AI Agent赛道上扬眉吐气。认识Koog不是又一个LangChain的Java版先泼一盆冷水如果你以为Koog就是LangChain的Java翻译版那就大错特错了。JetBrains做这套东西的出发点很实在——他们自己内部有一堆产品需要AI Agent比如JetBrains AI Assistant发现市面上的框架要么不是JVM原生要么企业级功能缺失于是干脆自己造了一个轮子。根据官方文档Koog的核心定位是JVM-native framework for building AI agents。这意味着什么意味着你的Agent直接跑在JVM里和你的业务代码共享堆内存调用你的Service方法不需要HTTP请求类型安全由编译器保证部署也不需要额外维护一个Python环境。几个关键特性值得Java老哥们关注首先原生Spring Boot集成。不是那种理论上可以跑在Spring Boot里的兼容而是真正的Starter依赖、自动配置、Bean注入一条龙。你的Service可以直接被Agent调用不需要包装成REST接口。其次企业级稳定性。Koog内置了故障恢复、Agent状态持久化、历史消息压缩这些生产环境必备的功能。不像某些Demo级框架跑个五轮对话就内存溢出Koog是真的考虑过高并发和长时间运行场景的。最后观测性一流。基于OpenTelemetry的链路追踪对接Langfuse、WB Weave这些主流监控平台。你的Agent每步想了什么、调了哪些工具、花了多少token全都能可视化地展示出来。环境准备5分钟让项目跑起来Koog的环境要求很JavaJDK 17Maven或Gradle任选。个人建议直接用Spring Boot 3.x毕竟JetBrains自家的东西对Spring生态支持最好。Maven依赖配置如下版本号以官方最新为准目前文档显示是0.6.4ai.koog koog-agents-jvm 0.6.4API Key配置方面Koog支持市面上几乎所有主流模型OpenAI、Anthropic、Google、DeepSeek、OpenRouter甚至本地Ollama。建议把Key放在环境变量里别傻乎乎写死在代码里。实战从Hello World到智能客服第一步定义工具ToolAgent的灵魂在于工具调用。Koog在Java里用了注解的方式来定义工具这和Spring的Controller注解一样直观。假设我们在做一个银行客服Agent需要查询余额和转账importai.koog.annotations.Tool;importai.koog.annotations.LLMDescription;publicclassBankingToolsimplementsToolSet{ToolLLMDescription(查询用户账户余额返回整数金额单位美元)publicIntegergetAccountBalance(LLMDescription(用户的唯一标识符)StringuserId){// 这里调用你的Service层returnaccountService.getBalance(userId);}ToolLLMDescription(向指定收款人转账)publicBooleansendMoney(LLMDescription(收款人的唯一标识符)StringrecipientId,LLMDescription(转账金额单位美元)Integeramount){// 实际业务逻辑returntransactionService.transfer(userId,recipientId,amount);}}注意到LLMDescription注解了吗这是给大模型看的使用说明书。Koog会在运行时把这些描述整理成Function Calling的Schema发给LLM让模型知道什么时候该调用哪个方法。第二步构建AgentKoog的Java API采用了Fluent Builder模式链式调用写起来很顺滑importai.koog.core.AIAgent;importai.koog.registry.ToolRegistry;importai.koog.executor.llm.openai.OpenAILLMClient;publicclassBankingAgentConfig{publicAIAgentcreateBankingAgent(){// 配置LLM客户端支持多Provider路由varpromptExecutornewMultiLLMPromptExecutor(newOpenAILLMClient(System.getenv(OPENAI_API_KEY)),newAnthropicLLMClient(System.getenv(ANTHROPIC_API_KEY)));// 构建AgentreturnAIAgent.builder().promptExecutor(promptExecutor).llmModel(OpenAIModels.Chat.GPT5_2)// 可以用最新的GPT-5.2.systemPrompt(你是一位专业的银行客服助手帮助用户查询余额和转账。转账前必须确认用户余额充足。).toolRegistry(ToolRegistry.builder().tools(newBankingTools()).build()).build();}}这里有个很实用的点MultiLLMPromptExecutor支持多模型路由。你可以让GPT-5.2处理复杂推理Claude 3.7处理长文本甚至根据成本自动切换。第三步运行Agent跑起来就一行代码publicstaticvoidmain(String[]args){varagentnewBankingAgentConfig().createBankingAgent();Stringresultagent.run(给我朋友MikeID: mike_1234转100美元前提是我账户里钱够);System.out.println(result);}执行流程是这样的Agent首先调用getAccountBalance检查余额如果足够再调用sendMoney执行转账最后返回自然语言回复。全程在你的JVM里完成没有HTTP往返没有JSON序列化损耗。高级玩法复杂工作流与容错机制函数式策略像写普通Java代码一样编排Agent简单工具调用只是开胃菜Koog真正强大的是它的Strategy策略机制。对于复杂任务你可以用函数式的方式编排工作流就像写普通Java方法一样varfunctionalAgentAIAgent.builder().promptExecutor(promptExecutor).functionalStrategy(customer-support,(ctx,userInput)-{// 第一步识别用户问题类型varproblemctx.subtask(分析用户问题userInput).withOutput(ProblemType.class)// 类型安全的输出.withTools(readOnlyTools)// 只给读权限.run();// 第二步根据问题类型查询知识库varsolutionctx.subtask(基于问题类型查询解决方案problem).withOutput(Solution.class).withTools(knowledgeBaseTools).run();// 第三步如果需要操作权限验证用户身份if(solution.requiresWritePermission()){varverifiedctx.subtask(验证用户是否有权限执行solution.getAction()).withOutput(VerificationResult.class).withTools(authTools).run();if(!verified.isAllowed()){return抱歉您没有权限执行此操作;}}returnsolution;}).build();这种模式的好处是可控性。不像某些黑盒Agent你想知道它每一步在干嘛、给什么工具、输出什么类型全都在代码里一目了然。这对于金融、医疗这些对可解释性要求极高的行业特别重要。持久化与故障恢复Agent的存档点生产环境最怕什么Agent跑到一半服务器挂了或者LLM API超时了。Koog提供了Agent Persistence功能可以在任意节点保存状态下次从断点恢复varpersistentAgentAIAgent.builder().functionalStrategy(with-checkpoint,(ctx,input)-{// 第一步检查用户意图设置检查点ctx.checkpoint(intent-analysis);varintentctx.subtask(分析意图).run();// 第二步执行复杂操作可能失败支持重试ctx.checkpoint(execution-phase);varresultctx.subtask(执行任务).withRetryPolicy(3)// 失败自动重试3次.run();returnresult;}).build();结合Spring Boot的定时任务你甚至可以实现断点续传——用户昨晚下了一个复杂指令Agent处理到一半超时了今天早上下单接着跑不用从头开始。历史压缩省下的token都是钱做Agent的都知道上下文长了以后每次请求都要把历史记录全发给LLMtoken消耗跟流水一样。Koog内置了几种历史压缩策略// 全量压缩把整个对话历史总结成一段话ctx.compressHistory(HistoryCompressionStrategy.WholeHistory());// 分段压缩只压缩最早的20条消息保留近期上下文ctx.compressHistory(HistoryCompressionStrategy.Chunked(20));// 事实提取只保留关键事实如用户叫张三、订单ID是12345ctx.compressHistory(newRetrieveFactsFromHistory());实测下来一个跑了50轮的客服对话压缩后能省60%的token成本响应速度也快了不少。观测性你的Agent在想什么一目了然上线以后最怕什么Agent抽风了你都不知道它哪步想错了。Koog对接了OpenTelemetry配合Langfuse或者WB Weave能看到完整的执行链路varobservableAgentAIAgent.builder().install(OpenTelemetry.Feature,config-{config.addSpanExporter(OtlpGrpcSpanExporter.builder().setEndpoint(http://your-langfuse-instance:4317).build());}).build();在监控面板里你能看到Agent总共执行了多少步每步调用了哪些工具参数是什么每次LLM请求的token消耗和成本哪一步出现了异常异常信息是什么这比在日志里grep ERROR要高效太多了。性能对比原生JVM的优势根据社区的一些测试数据Koog作为原生JVM框架在性能上相比Python方案有显著优势指标Koog (In-Process)Python REST Agent工具调用延迟0.2ms45ms上下文准备4.5ms120ms总延迟4.7ms165ms这个差距主要来自于内存共享。Python方案要把Java对象序列化成JSON通过HTTP发给Python进程Python反序列化后再处理而Koog直接在JVM堆里操作对象省去了序列化和网络往返的开销。对于高频交易、实时风控这些对延迟敏感的场景这100多毫秒的差距可能就是成交和滑点的区别。与现有生态的集成Koog并不是要推翻你的现有架构相反它对Java生态的兼容性做得相当好Spring Boot深度集成你的Service、Repository可以直接作为Tool被Agent调用事务管理、AOP拦截、安全配置全都生效。MCP协议支持Koog实现了Model Context Protocol可以和Anthropic的Claude Desktop、其他支持MCP的Agent互通。你的Java Agent既可以对外提供服务也可以调用其他MCP Server的能力。线程池隔离Java开发者最关心的线程管理Koog允许你为策略执行、LLM请求分别指定不同的ExecutorService避免IO密集型请求阻塞你的业务线程。写在最后Java的AI春天来了说实话写这篇文章的时候我是有点激动的。不是因为Koog有多完美它确实还在快速迭代中GitHub上能看到活跃的开发提交而是因为它代表了一个信号JVM生态在AI时代不再是二等公民。JetBrains把自己内部打磨的框架开源出来还专门为Java开发者设计了一套Fluent API这本身就说明他们看好Java在企业级AI应用中的地位。毕竟全世界还有那么多核心系统跑在Java上让它们为了AI而另起炉灶既不现实也不经济。IntelliJ IDEA Conf 2026改期到9月到时候应该会有更多关于Koog的深度分享和路线图。但就目前的0.6.4版本来看对于想在自己Java项目里引入AI Agent能力的团队Koog已经是一个值得认真考虑的选项了。不用再羡慕Python程序员了。拿起你熟悉的IDEA写几个Tool注解你的Java应用也能拥有自己的AI Agent。毕竟工具只是手段解决问题才是目的。而Koog似乎让Java程序员离这个目标更近了一步。参考文档JetBrains官方博客Koog Comes to JavaKoog官方文档https://docs.koog.aiGitHub仓库https://github.com/JetBrains/koogIntelliJ IDEA Conf 2026官方信息注本文技术细节基于Koog 0.6.4版本框架处于快速迭代期生产环境使用前建议查阅最新官方文档。