去年有个朋友跑来找我说他们公司想上AI功能但后端全是Java几十个微服务、上百万行代码总不能为了接一个大模型API就把技术栈推到重来。这个场景我太熟了。过去一年里几乎每隔一段时间就会碰到类似的询问Java到底能不能玩转大模型答案当然是能而且比很多人想象的更稳、更成熟。这篇文章就围绕“Java接入大模型”这件事把思路、框架选型和落地细节掰开揉碎聊一遍覆盖从最小可运行的对话原型到生产级配置的全过程给正在观望的Java后端工程师和架构师一条清晰的参考路径。先说清楚这篇文章要解决什么问题第一让你理解Java接入大模型有哪些路线可选各自适合什么场景第二把当前主流的Java侧大模型框架生态讲明白知道它们之间有什么区别、怎么选第三给出可以直接照抄的接入流程包括普通HTTP调用、Spring AI、LangChain4j、函数调用和RAG第四整理我实际踩过的坑和排查方法。不管你之前接触过多少AI开发这篇文章都会尽量用大白话把里面的门道讲清楚。1. 先想清楚Java接入大模型的整体思路与方案选型1.1 你到底需要接的是什么很多人一上来就问“我想接入大模型”但真正的需求千差万别。我习惯把接入需求分成几个阶梯每个阶梯的技术复杂度完全不一样。最低阶梯是“纯文本问答”给一句Prompt返回一段文本。这类需求直接调HTTP接口就够了不引入任何框架。第二阶梯是“流式对话”像ChatGPT那样一个字一个字蹦出来。需要处理流式响应对HTTP客户端编排和超时控制有要求。第三阶梯是“结构化输出”让模型返回JSON、表格、固定格式的文本需要做提示词工程和输出校验甚至在代码里做二次解析。第四阶梯是“函数调用”模型在回答过程中调用你定义的Java方法比如查库存、下单、查天气。这是目前企业落地最实用的一层。第五阶梯是“RAG检索增强生成”把私有知识库向量化先检索再生成解决模型不知道你内部业务的问题。把这几个阶梯画出来你就会发现根本不需要一上来就上重型框架。如果是第一个阶梯裸调HTTP反而是最可控的方案到了第四、第五阶梯再考虑框架带来的结构化能力才划算。这个判断会在后面反复影响选型所以第一步一定要想清楚。1.2 三条主流路线横向对比在当前Java生态里接入大模型基本只有三条路线没有太多花样路线代表方案优点缺点适合场景裸调HTTPJava标准库HttpClient Jackson依赖最少完全可控调试直观流式、函数调用、上下文管理全都要自己写轻量接入、定制需求极强、不想绑定框架Spring AISpring官方风格集成自动配置 Starter与Spring Boot体系无缝融合学习成本低部分高级特性如复杂RAG还在快速演进存量Spring项目快速上线AI能力LangChain4j面向Java的LLM编排框架概念对齐LangChain功能全面Chain/Memory/Tool/RAG都有成熟封装概念较多上手需要一段时间消化需要复杂链路编排的Java项目这三条路线不互斥。很多团队从裸调HTTP起步验证了可行性之后再在核心模块引入Spring AI或LangChain4j来承接复杂链路。我个人的建议是公司有强Spring背景默认看Spring AI要上复杂Agent/多轮路由/多工具编排LangChain4j更稳只做一两个固定场景裸调HTTP最省事。1.3 Java生态为什么“迟到”但恰好不晚大模型爆发初期主流工具链几乎都围绕Python构建Java社区显得安静。这不是Java不行而是AI研发和算法团队习惯用Python第一波工具天然长在Python生态里。但真正到了企业生产环境问题就变了。Java的存量优势极强。大多数银行、电商、制造企业的业务系统都是Java用户体系、订单系统、权限系统跑在Java上。大模型要真正产生业务价值绝不是孤立聊个天而是要读取订单、调库存、联动工单系统。这时候Java接入大模型不是在“造轮子”而是在“搭桥”——把大语言模型的能力桥接到现有业务系统里。这正是Java生态后来居上的核心逻辑Python侧重模型实验和算法Java侧重系统工程和可靠交付。当大模型从Demo走向生产Java的稳定运行时、成熟线程模型、完善的监控体系反而成了加分项。所以与其说Java“迟到”不如说它等到了最需要它的阶段。这个视角在选型时非常重要你选框架不是为了追新而是为了在现有系统里稳妥地把AI能力用起来。2. 框架生态全景从Spring AI到LangChain4j2.1 Spring AI让Spring开发者无缝上手Spring AI是Spring生态里专门做大模型应用集成的项目。它带来的最大价值是把“接入模型”这件事做成了Spring开发者最常见的姿势加依赖、写配置、注入Bean。核心抽象有三个ChatModel负责对话生成StreamingChatModel负责流式对话EmbeddingModel负责文本向量化。你只需要在配置文件里声明模型服务商的API Key和Base URL框架会自动装配好这些Bean。业务代码里基本就是注入ChatClient、构造Prompt、拿ChatResponse这套流程对熟悉Spring的人来说几乎没有理解门槛。最值得说的是Spring AI的自动配置能力。模型服务商换一家对于调用方来说只是改配置、换依赖业务代码几乎不需要动。这一点在企业里价值巨大因为很多公司不希望被单一模型厂商绑定。同时Spring AI提供了ToolCallback机制来实现函数调用还内置了一些RAG组件比如向量存储抽象、文档读取器虽然不像Python生态那么“什么都给”但已经覆盖了绝大多数Spring项目的实际需求。如果你所在团队已经深度使用Spring Boot用Spring AI的决策成本极低。2.2 LangChain4j功能更全的Java版LLM编排框架LangChain4j是另一个必须了解的框架。看名字就知道它的设计思路对齐了Python社区里非常活跃的LangChain但并不是照搬而是根据Java语言特点和工程习惯做了重设计和优化。LangChain4j在功能覆盖上更“慷慨”多轮对话的ChatMemory、多种工具调用的Tool注解、AiServices面向服务的封装、RAG流水线、不同向量存储的适配它都有。其中AiServices的设计很符合Java开发者的直觉——定义一个接口加上注解框架自动生成实现把模型调用、工具执行、记忆管理串起来。这让业务代码看起来非常干净特别适合需要编排复杂链路的场景。它也提供Spring Boot Starter可以很好地嵌入Spring项目。相比Spring AILangChain4j的社区更新节奏更快很多新模型能力支持得比较及时。不过功能多的另一面是学习曲线更陡概念较多刚上手时容易觉得“文档里什么都提到了但不知道该用哪个”。我的经验是先用一条最简链路跑通再慢慢引入Memory和Tool不要一开始就追求把所有组件都用上。2.3 轻量自研什么时候该自己封装框架虽好但不是万能。我见过不少团队在仅有一个对话场景、几乎没有复杂链路的情况下硬是引入框架结果光排查框架配置问题就花了一周。这种情况下轻量自研反而更合适。自研的核心是一套面向模型API的统一网关封装。你需要做的无非是这几件事定义统一请求/响应模型封装HTTP客户端连接池、超时、重试处理流式响应统一日志和异常。这部分代码量并不大在Java 17及以上版本里原生HttpClient加上Jackson就能搞定。等业务需求变复杂比如需要多工具调用、记忆管理时再引入框架也来得及自研的网关还可以作为底层适配层继续复用。这里有个常见误区自研不等于从零硬造。你可以基于对框架源码的理解只抽取自己需要的部分比如那个流式SSE解析器抄明白逻辑再按自己的需求改这比直接引依赖更可控。轻量自研适合的场景通常具备三个特征调用量不大、场景固定、团队不希望引入太多新依赖。2.4 选型决策速查把前面这些梳理成一张决策表能解决80%的选型纠结团队以Spring Boot为主想最短时间上线AI功能 - 选Spring AI需要多轮记忆、多工具编排、复杂Agent链路 - 选LangChain4j只做一两个固定Prompt场景希望依赖最少 - 裸调HTTP或轻量自研已有存量调用封装只是升级模型 - 继续维护轻量网关必要时引入框架选型没有绝对的对错关键是把“现在最需要的能力”和“框架最擅长的事情”对上。不要为一个还没出现的复杂场景提前买单也不要等到链路复杂到失控才想起框架。3. 实操过程与核心环节实现从零跑通大模型接入3.1 最朴素的HTTP调用入门先从一个不依赖任何框架的最小闭环开始。你用Java 17自带的HttpClient去调用大模型API整个过程能让你对“接入”这件事建立最直接的体感。第一步把API密钥放进环境变量不要硬编码在代码里export LLM_API_KEY你的密钥 export LLM_BASE_URLhttps://api.example.com/v1第二步写一个构造请求体的小工具把消息列表序列化成JSONpublic class ChatRequestBuilder { public static String build(String systemPrompt, String userMessage) throws JsonProcessingException { ObjectMapper mapper new ObjectMapper(); MapString, Object payload new LinkedHashMap(); payload.put(model, your-model-name); payload.put(messages, List.of( Map.of(role, system, content, systemPrompt), Map.of(role, user, content, userMessage) )); payload.put(temperature, 0.7); payload.put(max_tokens, 1024); return mapper.writeValueAsString(payload); } }第三步发起请求并把响应解析出来String apiKey System.getenv(LLM_API_KEY); String baseUrl System.getenv(LLM_BASE_URL); HttpClient client HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) .build(); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(baseUrl /chat/completions)) .timeout(Duration.ofSeconds(60)) .header(Content-Type, application/json) .header(Authorization, Bearer apiKey) .POST(BodyPublishers.ofString(ChatRequestBuilder.build(你是Java架构师, 如何设计线程池))) .build(); HttpResponseString response client.send(request, HttpResponse.BodyHandlers.ofString()); JsonNode root new ObjectMapper().readTree(response.body()); String content root.path(choices).path(0).path(message).path(content).asText(); System.out.println(content);这段代码的结构可以直接复用到任何模型服务商差异只在URL和密钥位置。我在实际工作中会额外做三件事把HttpClient定义成单例复用避免每次请求重建连接把请求和响应都打一条结构化日志方便排查在解析响应前先检查HTTP状态码非200一律抛异常不要让上层拿到半截内容。3.2 流式输出的Java实现细节流式响应SSEServer-Sent Events是对话应用体验的关键。大模型生成完整个内容需要十几秒如果等全部生成完再返回用户早就觉得系统卡死了。流式就是让服务端一边生成一边推送。Java原生的HttpClient支持异步发送并把响应体当作行流来处理HttpRequest request HttpRequest.newBuilder() .uri(URI.create(baseUrl /chat/completions)) .header(Content-Type, application/json) .header(Authorization, Bearer apiKey) .POST(BodyPublishers.ofString(bodyWithStreamFlag)) .build(); client.sendAsync(request, HttpResponse.BodyHandlers.ofLines()) .thenAccept(response - { response.body().forEach(line - { if (line.startsWith(data:)) { String data line.substring(5).trim(); if ([DONE].equals(data)) return; JsonNode node new ObjectMapper().readTree(data); String delta node.path(choices).path(0) .path(delta).path(content).asText(); // 这里把delta推给前端 pushToClient(delta); } }); });这段代码的关键在于正确处理SSE的空行和事件名。有些服务端会发送data:前缀有些会带\n\n空行作为事件结束标记解析时先用lines()拿到每一行再过滤比一次性读取整个字节流更稳。我踩过的坑是直接把BodyHandlers.ofString()处理流式响应结果要等流结束才返回完全失去流式意义。实际上生产环境我不会直接用原生HttpClient写SSE解析而是借助Spring AI或LangChain4j对流式协议做的封装。但理解底层原理依然很重要排查问题、优化流程时能少走大量弯路。3.3 用Spring AI搭建一个对话服务现在看Spring AI如何把上面这些复杂度收起来。假设你有一个Spring Boot项目首先加依赖dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-chat/artifactId version版本号以官方最新为准/version /dependency然后在application.yml里做最小配置spring: ai: model: chat: api-key: ${LLM_API_KEY} base-url: ${LLM_BASE_URL} options: model: your-model-name temperature: 0.7业务代码里注入ChatClient即可Service public class ChatAssistant { private final ChatClient chatClient; public ChatAssistant(ChatClient chatClient) { this.chatClient chatClient; } public String ask(String question) { return chatClient.prompt() .system(你是一个经验丰富的Java技术顾问回答简洁专业。) .user(question) .call() .content(); } public FluxString askStream(String question) { return chatClient.prompt() .user(question) .stream() .content(); } }看到区别了吗同步调用用call()返回ChatResponse流式调用用stream()返回Reactor的FluxString和Spring WebFlux天然契合。这就是框架的价值协议细节、连接管理、错误转换都被处理好了你只需要关心业务逻辑。有个细节需要注意Spring AI不同版本对配置项命名有调整老版本是spring.ai.openai.api-key这类写法新版本统一收敛到spring.ai.model.chat.*结构下。升级版本时配置不生效优先检查配置路径而不是业务代码。3.4 让模型调用你的Java方法函数调用落地函数调用是目前企业落地价值最高的一项能力。场景很典型用户问“帮我把订单状态改成已发货”模型本身没有权限执行这个动作它需要识别意图、提取参数“订单号”和“状态”然后调用你注册的Java方法。原理一句话你把一个函数的名称、描述、参数结构JSON Schema发给模型模型在需要时返回一个“调用请求”你的代码执行这个方法再把真实结果反馈给模型生成最终回复。LangChain4j的做法很直接定义一个带Tool注解的类public class OrderTools { Tool(根据订单号更新订单发货状态) public String updateShipment(String orderId, String status) { // 这里调用真正的订单服务 return 订单 orderId 已更新为[ status ]; } }然后通过AiServices把它绑定到接口上interface OrderAssistant { String chat(String userMessage); } OrderAssistant assistant AiServices.builder(OrderAssistant.class) .chatLanguageModel(chatModel) .tools(new OrderTools()) .build(); String answer assistant.chat(订单A12345改成已发货);这个流程跑通之后你会发现两个隐藏价值第一模型变成了“意图识别器”把自然语言翻译成结构化的工具调用交互体验完全不同第二真正有权限的操作永远在你的系统里执行模型不可能绕过你定义的函数对外部系统动手安全边界反而更清晰。我强烈建议第一次接触函数调用的读者先用一个最简单的工具类比如模拟查库存跑通全链路再接入真实业务。因为函数调用链路涉及的调试点很多包括模型是否“看得懂”你的函数描述、参数反序列化是否严格、执行异常怎么回传给模型这些都是一步步调的。3.5 给模型装一个“内网知识库”RAG落地RAG解决的是模型“不知道你业务内部知识”的问题。比如客服机器人需要知道你们公司的退换货政策这些信息不在模型训练数据里。RAG的做法是先把这些文档切成小块、做嵌入向量、存进向量库用户提问时在向量库里检索最相关的几块内容连同问题一起交给模型生成回答。在Java侧实现一个最小RAG链路Spring AI提供了相对完整的基础组件// 1. 加载并切分文档 DocumentReader reader new PagePdfDocumentReader(classpath:return-policy.pdf); ListDocument documents reader.get(); // 2. 向量化并写入向量存储 VectorStore vectorStore SimpleVectorStore.builder() .embeddingModel(embeddingModel) .build(); vectorStore.add(documents); // 3. 查询时先检索再问答 QuestionAnswerAdvisor advisor new QuestionAnswerAdvisor(vectorStore); String answer chatClient.prompt() .user(退货周期是几天) .advisors(advisor) .call() .content();QuestionAnswerAdvisor会自动完成“向量检索 拼接上下文 生成回答”全套流程。实际项目中要注意三件事文档切分大小要控制我一般按512个字符加一部分重叠避免把语义切断不管用哪种向量库生产环境都要加持久化内存向量库重启就丢每次检索的TopK和相似度阈值要根据效果调整TopK太大模型会被不相关内容干扰。我最想强调的还是“切分”这个环节。中英文混排、表格转文字之后的文档切分策略稍不留神就会导致检索盲区。建议先用一批真实业务问题做回归测试不要拿模板文档试很多问题只有真实数据才能暴露。3.6 生产环境的必配清单开发和跑通链路之后离上线还差一段距离。我基于实际项目总结了下面这份清单每一项都曾经在某个现场救过我一命超时控制连接超时10秒读取超时60秒或者更长护栏写清楚避免模型端异常导致线程一直挂起。重试策略只对可重试的异常连接失败、5xx、限流做指数退避重试业务校验错误和4xx一票否决。限流与熔断模型API有TPM/RPM限制用Bucket4j或Resilience4j做客户端限流避免并发突然打崩上游。密钥管理密钥放配置中心或环境变量不落代码库定期轮换审计调用量。日志与Trace统一日志格式带上请求ID把Prompt和响应都打进去方便事后分析链路追踪标记出模型调用的耗时和Token消耗。成本控制在入口层记录每次调用的Token数按月汇总设置异常预算。模型调用成本不像数据库那么透明不接入计量仪表盘月底账单会让你惊讶。这一节看似琐碎但它决定了一个AI功能是“能跑”还是“能扛”。很多团队Demo惊艳、上线翻车问题几乎都出在这份清单缺少项。4. 常见问题与排查技巧实录4.1 连接超时但服务端明明正常这是接入初期最常遇到的问题。现象是调用方等了几秒后抛超时但用别的工具直接测试同一个API是通的。排查思路分三步走。第一步看代理配置JVM默认不会走系统代理但公司内网环境如果强制走代理HttpClient需要显式设置ProxySelector第二步看TLS握手某些老JDK版本对模型服务商用的TLS版本不兼容升级JDK或显式配置SSLContext第三步看DNS解析有时候是内网DNS没放行新域名调InetAddress.getByName()测一下即可。这类问题一旦定位基本都是环境配置而非代码逻辑。所以我在代码里会把异常信息里带上请求URI和耗时日志一出就能看出卡在哪个环节。4.2 模型输出总是被截断你设置了max_tokens1024但某些长回答还是戛然而止。检查响应里的finish_reason字段如果值是length说明是因为达到输出上限而截断如果是stop说明正常结束。解决办法有两个方向调大max_tokens但这会增加成本和单次延迟更聪明的办法是让Prompt更结构化比如要求“先给结论再给理由不要连篇铺陈”。对于需要长文输出的场景还可以在模型收到内容后做分块拼接但流式接口在应用层拼接有上下文管理复杂度不如直接从prompt引导来得实惠。4.3 并发上去之后内存飙升流式接口如果处理不当会带来很大的内存压力。典型原因是把整个SSE流缓存到内存里再返回完全失去了流式意义另一种是把线程池开得过大每个模型调用占一个线程几百并发直接OOM。解决方式是明确区分阻塞与异步同步接口用有界线程池比如ThreadPoolExecutor把最大线程控制在合理范围流式接口优先使用WebFlux或Spring MVC的异步模式让吞吐不依赖线程数。监控上盯住GC曲线和堆内存在对应时段的增长能很快定位是不是有响应体在内存里堆积。4.4 函数调用参数反序列化失败模型生成的工具调用参数偶尔会不合法比如字符串里出现多余逗号、日期格式不合规。直接用Jackson强转成POJO会抛异常而且异常发生在框架内部你很难拿到原始消息。我的做法是写一层参数校验与兜底先获取MapString,Object原始参数再按需转换转换失败时把原始内容和异常一起回传给模型让模型自行修正。这个“自动纠错”机制在实践中效果非常好模型通常能根据错误信息重新生成一份合法参数。4.5 排查工具箱与速查表排查AI类问题常规debug手段不够用因为不确定性在模型这一侧。我把自己的排查顺序总结成一张表症状优先排查点参考解法请求超时网络代理、TLS、DNS显式设置代理、升级JDK、检查域名解析响应截断finish_reason、max_tokens调大上限、结构化Prompt输出格式不对模型温度、System Prompt调低temperature、增加输出格式约束与示例并发OOM线程池、流式缓存有界线程池、异步流式处理工具参数报错JSON Schema、反序列化先解析为Map做校验再转POJOToken用量超预算无用量统计入口层统一计量设置月预算和自动告警还有一个实用技巧用本地日志把每次调用的原始请求和原始响应完整打出来哪怕格式丑一点也要先有。AI场景的Bug很难靠脑内复现一定要有“现场录像”才能反推哪一步出了问题。个人实操心得与后续扩展建议文章写到这儿核心的技术路径都过了一遍。最后聊点我个人在实际操作中的体感变化。最开始我也是一头扎进框架源码里想在Java里复刻Python那套玩法后来发现方向错了。Java接入大模型的核心价值不在“模型研究”而在“系统集成”把模型当作一个能力输入让它和现有业务系统发生化学反应。所以我的建议是从最小的对话闭环开始先不做复杂架构。跑通之后接着做两件事扩展第一把函数调用接上你的核心业务接口这是最能体现价值的环节第二把RAG接上你维护得最好的那部分文档库大概率第一版效果一般但迭代几轮后会让整个系统的知识密度立刻不一样。等到这两步都稳了再回头考虑Agent编排、多模型路由这些更重的东西。方向对了速度反而不那么重要。 
长河君 · 2026/10/22 13:34:10 · 阅读 1.2k Java接入大模型实战：从HTTP调用到Spring AI与LangChain4j
去年有个朋友跑来找我说他们公司想上AI功能但后端全是Java几十个微服务、上百万行代码总不能为了接一个大模型API就把技术栈推到重来。这个场景我太熟了。过去一年里几乎每隔一段时间就会碰到类似的询问Java到底能不能玩转大模型答案当然是能而且比很多人想象的更稳、更成熟。这篇文章就围绕“Java接入大模型”这件事把思路、框架选型和落地细节掰开揉碎聊一遍覆盖从最小可运行的对话原型到生产级配置的全过程给正在观望的Java后端工程师和架构师一条清晰的参考路径。先说清楚这篇文章要解决什么问题第一让你理解Java接入大模型有哪些路线可选各自适合什么场景第二把当前主流的Java侧大模型框架生态讲明白知道它们之间有什么区别、怎么选第三给出可以直接照抄的接入流程包括普通HTTP调用、Spring AI、LangChain4j、函数调用和RAG第四整理我实际踩过的坑和排查方法。不管你之前接触过多少AI开发这篇文章都会尽量用大白话把里面的门道讲清楚。1. 先想清楚Java接入大模型的整体思路与方案选型1.1 你到底需要接的是什么很多人一上来就问“我想接入大模型”但真正的需求千差万别。我习惯把接入需求分成几个阶梯每个阶梯的技术复杂度完全不一样。最低阶梯是“纯文本问答”给一句Prompt返回一段文本。这类需求直接调HTTP接口就够了不引入任何框架。第二阶梯是“流式对话”像ChatGPT那样一个字一个字蹦出来。需要处理流式响应对HTTP客户端编排和超时控制有要求。第三阶梯是“结构化输出”让模型返回JSON、表格、固定格式的文本需要做提示词工程和输出校验甚至在代码里做二次解析。第四阶梯是“函数调用”模型在回答过程中调用你定义的Java方法比如查库存、下单、查天气。这是目前企业落地最实用的一层。第五阶梯是“RAG检索增强生成”把私有知识库向量化先检索再生成解决模型不知道你内部业务的问题。把这几个阶梯画出来你就会发现根本不需要一上来就上重型框架。如果是第一个阶梯裸调HTTP反而是最可控的方案到了第四、第五阶梯再考虑框架带来的结构化能力才划算。这个判断会在后面反复影响选型所以第一步一定要想清楚。1.2 三条主流路线横向对比在当前Java生态里接入大模型基本只有三条路线没有太多花样路线代表方案优点缺点适合场景裸调HTTPJava标准库HttpClient Jackson依赖最少完全可控调试直观流式、函数调用、上下文管理全都要自己写轻量接入、定制需求极强、不想绑定框架Spring AISpring官方风格集成自动配置 Starter与Spring Boot体系无缝融合学习成本低部分高级特性如复杂RAG还在快速演进存量Spring项目快速上线AI能力LangChain4j面向Java的LLM编排框架概念对齐LangChain功能全面Chain/Memory/Tool/RAG都有成熟封装概念较多上手需要一段时间消化需要复杂链路编排的Java项目这三条路线不互斥。很多团队从裸调HTTP起步验证了可行性之后再在核心模块引入Spring AI或LangChain4j来承接复杂链路。我个人的建议是公司有强Spring背景默认看Spring AI要上复杂Agent/多轮路由/多工具编排LangChain4j更稳只做一两个固定场景裸调HTTP最省事。1.3 Java生态为什么“迟到”但恰好不晚大模型爆发初期主流工具链几乎都围绕Python构建Java社区显得安静。这不是Java不行而是AI研发和算法团队习惯用Python第一波工具天然长在Python生态里。但真正到了企业生产环境问题就变了。Java的存量优势极强。大多数银行、电商、制造企业的业务系统都是Java用户体系、订单系统、权限系统跑在Java上。大模型要真正产生业务价值绝不是孤立聊个天而是要读取订单、调库存、联动工单系统。这时候Java接入大模型不是在“造轮子”而是在“搭桥”——把大语言模型的能力桥接到现有业务系统里。这正是Java生态后来居上的核心逻辑Python侧重模型实验和算法Java侧重系统工程和可靠交付。当大模型从Demo走向生产Java的稳定运行时、成熟线程模型、完善的监控体系反而成了加分项。所以与其说Java“迟到”不如说它等到了最需要它的阶段。这个视角在选型时非常重要你选框架不是为了追新而是为了在现有系统里稳妥地把AI能力用起来。2. 框架生态全景从Spring AI到LangChain4j2.1 Spring AI让Spring开发者无缝上手Spring AI是Spring生态里专门做大模型应用集成的项目。它带来的最大价值是把“接入模型”这件事做成了Spring开发者最常见的姿势加依赖、写配置、注入Bean。核心抽象有三个ChatModel负责对话生成StreamingChatModel负责流式对话EmbeddingModel负责文本向量化。你只需要在配置文件里声明模型服务商的API Key和Base URL框架会自动装配好这些Bean。业务代码里基本就是注入ChatClient、构造Prompt、拿ChatResponse这套流程对熟悉Spring的人来说几乎没有理解门槛。最值得说的是Spring AI的自动配置能力。模型服务商换一家对于调用方来说只是改配置、换依赖业务代码几乎不需要动。这一点在企业里价值巨大因为很多公司不希望被单一模型厂商绑定。同时Spring AI提供了ToolCallback机制来实现函数调用还内置了一些RAG组件比如向量存储抽象、文档读取器虽然不像Python生态那么“什么都给”但已经覆盖了绝大多数Spring项目的实际需求。如果你所在团队已经深度使用Spring Boot用Spring AI的决策成本极低。2.2 LangChain4j功能更全的Java版LLM编排框架LangChain4j是另一个必须了解的框架。看名字就知道它的设计思路对齐了Python社区里非常活跃的LangChain但并不是照搬而是根据Java语言特点和工程习惯做了重设计和优化。LangChain4j在功能覆盖上更“慷慨”多轮对话的ChatMemory、多种工具调用的Tool注解、AiServices面向服务的封装、RAG流水线、不同向量存储的适配它都有。其中AiServices的设计很符合Java开发者的直觉——定义一个接口加上注解框架自动生成实现把模型调用、工具执行、记忆管理串起来。这让业务代码看起来非常干净特别适合需要编排复杂链路的场景。它也提供Spring Boot Starter可以很好地嵌入Spring项目。相比Spring AILangChain4j的社区更新节奏更快很多新模型能力支持得比较及时。不过功能多的另一面是学习曲线更陡概念较多刚上手时容易觉得“文档里什么都提到了但不知道该用哪个”。我的经验是先用一条最简链路跑通再慢慢引入Memory和Tool不要一开始就追求把所有组件都用上。2.3 轻量自研什么时候该自己封装框架虽好但不是万能。我见过不少团队在仅有一个对话场景、几乎没有复杂链路的情况下硬是引入框架结果光排查框架配置问题就花了一周。这种情况下轻量自研反而更合适。自研的核心是一套面向模型API的统一网关封装。你需要做的无非是这几件事定义统一请求/响应模型封装HTTP客户端连接池、超时、重试处理流式响应统一日志和异常。这部分代码量并不大在Java 17及以上版本里原生HttpClient加上Jackson就能搞定。等业务需求变复杂比如需要多工具调用、记忆管理时再引入框架也来得及自研的网关还可以作为底层适配层继续复用。这里有个常见误区自研不等于从零硬造。你可以基于对框架源码的理解只抽取自己需要的部分比如那个流式SSE解析器抄明白逻辑再按自己的需求改这比直接引依赖更可控。轻量自研适合的场景通常具备三个特征调用量不大、场景固定、团队不希望引入太多新依赖。2.4 选型决策速查把前面这些梳理成一张决策表能解决80%的选型纠结团队以Spring Boot为主想最短时间上线AI功能 - 选Spring AI需要多轮记忆、多工具编排、复杂Agent链路 - 选LangChain4j只做一两个固定Prompt场景希望依赖最少 - 裸调HTTP或轻量自研已有存量调用封装只是升级模型 - 继续维护轻量网关必要时引入框架选型没有绝对的对错关键是把“现在最需要的能力”和“框架最擅长的事情”对上。不要为一个还没出现的复杂场景提前买单也不要等到链路复杂到失控才想起框架。3. 实操过程与核心环节实现从零跑通大模型接入3.1 最朴素的HTTP调用入门先从一个不依赖任何框架的最小闭环开始。你用Java 17自带的HttpClient去调用大模型API整个过程能让你对“接入”这件事建立最直接的体感。第一步把API密钥放进环境变量不要硬编码在代码里export LLM_API_KEY你的密钥 export LLM_BASE_URLhttps://api.example.com/v1第二步写一个构造请求体的小工具把消息列表序列化成JSONpublic class ChatRequestBuilder { public static String build(String systemPrompt, String userMessage) throws JsonProcessingException { ObjectMapper mapper new ObjectMapper(); MapString, Object payload new LinkedHashMap(); payload.put(model, your-model-name); payload.put(messages, List.of( Map.of(role, system, content, systemPrompt), Map.of(role, user, content, userMessage) )); payload.put(temperature, 0.7); payload.put(max_tokens, 1024); return mapper.writeValueAsString(payload); } }第三步发起请求并把响应解析出来String apiKey System.getenv(LLM_API_KEY); String baseUrl System.getenv(LLM_BASE_URL); HttpClient client HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) .build(); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(baseUrl /chat/completions)) .timeout(Duration.ofSeconds(60)) .header(Content-Type, application/json) .header(Authorization, Bearer apiKey) .POST(BodyPublishers.ofString(ChatRequestBuilder.build(你是Java架构师, 如何设计线程池))) .build(); HttpResponseString response client.send(request, HttpResponse.BodyHandlers.ofString()); JsonNode root new ObjectMapper().readTree(response.body()); String content root.path(choices).path(0).path(message).path(content).asText(); System.out.println(content);这段代码的结构可以直接复用到任何模型服务商差异只在URL和密钥位置。我在实际工作中会额外做三件事把HttpClient定义成单例复用避免每次请求重建连接把请求和响应都打一条结构化日志方便排查在解析响应前先检查HTTP状态码非200一律抛异常不要让上层拿到半截内容。3.2 流式输出的Java实现细节流式响应SSEServer-Sent Events是对话应用体验的关键。大模型生成完整个内容需要十几秒如果等全部生成完再返回用户早就觉得系统卡死了。流式就是让服务端一边生成一边推送。Java原生的HttpClient支持异步发送并把响应体当作行流来处理HttpRequest request HttpRequest.newBuilder() .uri(URI.create(baseUrl /chat/completions)) .header(Content-Type, application/json) .header(Authorization, Bearer apiKey) .POST(BodyPublishers.ofString(bodyWithStreamFlag)) .build(); client.sendAsync(request, HttpResponse.BodyHandlers.ofLines()) .thenAccept(response - { response.body().forEach(line - { if (line.startsWith(data:)) { String data line.substring(5).trim(); if ([DONE].equals(data)) return; JsonNode node new ObjectMapper().readTree(data); String delta node.path(choices).path(0) .path(delta).path(content).asText(); // 这里把delta推给前端 pushToClient(delta); } }); });这段代码的关键在于正确处理SSE的空行和事件名。有些服务端会发送data:前缀有些会带\n\n空行作为事件结束标记解析时先用lines()拿到每一行再过滤比一次性读取整个字节流更稳。我踩过的坑是直接把BodyHandlers.ofString()处理流式响应结果要等流结束才返回完全失去流式意义。实际上生产环境我不会直接用原生HttpClient写SSE解析而是借助Spring AI或LangChain4j对流式协议做的封装。但理解底层原理依然很重要排查问题、优化流程时能少走大量弯路。3.3 用Spring AI搭建一个对话服务现在看Spring AI如何把上面这些复杂度收起来。假设你有一个Spring Boot项目首先加依赖dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-chat/artifactId version版本号以官方最新为准/version /dependency然后在application.yml里做最小配置spring: ai: model: chat: api-key: ${LLM_API_KEY} base-url: ${LLM_BASE_URL} options: model: your-model-name temperature: 0.7业务代码里注入ChatClient即可Service public class ChatAssistant { private final ChatClient chatClient; public ChatAssistant(ChatClient chatClient) { this.chatClient chatClient; } public String ask(String question) { return chatClient.prompt() .system(你是一个经验丰富的Java技术顾问回答简洁专业。) .user(question) .call() .content(); } public FluxString askStream(String question) { return chatClient.prompt() .user(question) .stream() .content(); } }看到区别了吗同步调用用call()返回ChatResponse流式调用用stream()返回Reactor的FluxString和Spring WebFlux天然契合。这就是框架的价值协议细节、连接管理、错误转换都被处理好了你只需要关心业务逻辑。有个细节需要注意Spring AI不同版本对配置项命名有调整老版本是spring.ai.openai.api-key这类写法新版本统一收敛到spring.ai.model.chat.*结构下。升级版本时配置不生效优先检查配置路径而不是业务代码。3.4 让模型调用你的Java方法函数调用落地函数调用是目前企业落地价值最高的一项能力。场景很典型用户问“帮我把订单状态改成已发货”模型本身没有权限执行这个动作它需要识别意图、提取参数“订单号”和“状态”然后调用你注册的Java方法。原理一句话你把一个函数的名称、描述、参数结构JSON Schema发给模型模型在需要时返回一个“调用请求”你的代码执行这个方法再把真实结果反馈给模型生成最终回复。LangChain4j的做法很直接定义一个带Tool注解的类public class OrderTools { Tool(根据订单号更新订单发货状态) public String updateShipment(String orderId, String status) { // 这里调用真正的订单服务 return 订单 orderId 已更新为[ status ]; } }然后通过AiServices把它绑定到接口上interface OrderAssistant { String chat(String userMessage); } OrderAssistant assistant AiServices.builder(OrderAssistant.class) .chatLanguageModel(chatModel) .tools(new OrderTools()) .build(); String answer assistant.chat(订单A12345改成已发货);这个流程跑通之后你会发现两个隐藏价值第一模型变成了“意图识别器”把自然语言翻译成结构化的工具调用交互体验完全不同第二真正有权限的操作永远在你的系统里执行模型不可能绕过你定义的函数对外部系统动手安全边界反而更清晰。我强烈建议第一次接触函数调用的读者先用一个最简单的工具类比如模拟查库存跑通全链路再接入真实业务。因为函数调用链路涉及的调试点很多包括模型是否“看得懂”你的函数描述、参数反序列化是否严格、执行异常怎么回传给模型这些都是一步步调的。3.5 给模型装一个“内网知识库”RAG落地RAG解决的是模型“不知道你业务内部知识”的问题。比如客服机器人需要知道你们公司的退换货政策这些信息不在模型训练数据里。RAG的做法是先把这些文档切成小块、做嵌入向量、存进向量库用户提问时在向量库里检索最相关的几块内容连同问题一起交给模型生成回答。在Java侧实现一个最小RAG链路Spring AI提供了相对完整的基础组件// 1. 加载并切分文档 DocumentReader reader new PagePdfDocumentReader(classpath:return-policy.pdf); ListDocument documents reader.get(); // 2. 向量化并写入向量存储 VectorStore vectorStore SimpleVectorStore.builder() .embeddingModel(embeddingModel) .build(); vectorStore.add(documents); // 3. 查询时先检索再问答 QuestionAnswerAdvisor advisor new QuestionAnswerAdvisor(vectorStore); String answer chatClient.prompt() .user(退货周期是几天) .advisors(advisor) .call() .content();QuestionAnswerAdvisor会自动完成“向量检索 拼接上下文 生成回答”全套流程。实际项目中要注意三件事文档切分大小要控制我一般按512个字符加一部分重叠避免把语义切断不管用哪种向量库生产环境都要加持久化内存向量库重启就丢每次检索的TopK和相似度阈值要根据效果调整TopK太大模型会被不相关内容干扰。我最想强调的还是“切分”这个环节。中英文混排、表格转文字之后的文档切分策略稍不留神就会导致检索盲区。建议先用一批真实业务问题做回归测试不要拿模板文档试很多问题只有真实数据才能暴露。3.6 生产环境的必配清单开发和跑通链路之后离上线还差一段距离。我基于实际项目总结了下面这份清单每一项都曾经在某个现场救过我一命超时控制连接超时10秒读取超时60秒或者更长护栏写清楚避免模型端异常导致线程一直挂起。重试策略只对可重试的异常连接失败、5xx、限流做指数退避重试业务校验错误和4xx一票否决。限流与熔断模型API有TPM/RPM限制用Bucket4j或Resilience4j做客户端限流避免并发突然打崩上游。密钥管理密钥放配置中心或环境变量不落代码库定期轮换审计调用量。日志与Trace统一日志格式带上请求ID把Prompt和响应都打进去方便事后分析链路追踪标记出模型调用的耗时和Token消耗。成本控制在入口层记录每次调用的Token数按月汇总设置异常预算。模型调用成本不像数据库那么透明不接入计量仪表盘月底账单会让你惊讶。这一节看似琐碎但它决定了一个AI功能是“能跑”还是“能扛”。很多团队Demo惊艳、上线翻车问题几乎都出在这份清单缺少项。4. 常见问题与排查技巧实录4.1 连接超时但服务端明明正常这是接入初期最常遇到的问题。现象是调用方等了几秒后抛超时但用别的工具直接测试同一个API是通的。排查思路分三步走。第一步看代理配置JVM默认不会走系统代理但公司内网环境如果强制走代理HttpClient需要显式设置ProxySelector第二步看TLS握手某些老JDK版本对模型服务商用的TLS版本不兼容升级JDK或显式配置SSLContext第三步看DNS解析有时候是内网DNS没放行新域名调InetAddress.getByName()测一下即可。这类问题一旦定位基本都是环境配置而非代码逻辑。所以我在代码里会把异常信息里带上请求URI和耗时日志一出就能看出卡在哪个环节。4.2 模型输出总是被截断你设置了max_tokens1024但某些长回答还是戛然而止。检查响应里的finish_reason字段如果值是length说明是因为达到输出上限而截断如果是stop说明正常结束。解决办法有两个方向调大max_tokens但这会增加成本和单次延迟更聪明的办法是让Prompt更结构化比如要求“先给结论再给理由不要连篇铺陈”。对于需要长文输出的场景还可以在模型收到内容后做分块拼接但流式接口在应用层拼接有上下文管理复杂度不如直接从prompt引导来得实惠。4.3 并发上去之后内存飙升流式接口如果处理不当会带来很大的内存压力。典型原因是把整个SSE流缓存到内存里再返回完全失去了流式意义另一种是把线程池开得过大每个模型调用占一个线程几百并发直接OOM。解决方式是明确区分阻塞与异步同步接口用有界线程池比如ThreadPoolExecutor把最大线程控制在合理范围流式接口优先使用WebFlux或Spring MVC的异步模式让吞吐不依赖线程数。监控上盯住GC曲线和堆内存在对应时段的增长能很快定位是不是有响应体在内存里堆积。4.4 函数调用参数反序列化失败模型生成的工具调用参数偶尔会不合法比如字符串里出现多余逗号、日期格式不合规。直接用Jackson强转成POJO会抛异常而且异常发生在框架内部你很难拿到原始消息。我的做法是写一层参数校验与兜底先获取MapString,Object原始参数再按需转换转换失败时把原始内容和异常一起回传给模型让模型自行修正。这个“自动纠错”机制在实践中效果非常好模型通常能根据错误信息重新生成一份合法参数。4.5 排查工具箱与速查表排查AI类问题常规debug手段不够用因为不确定性在模型这一侧。我把自己的排查顺序总结成一张表症状优先排查点参考解法请求超时网络代理、TLS、DNS显式设置代理、升级JDK、检查域名解析响应截断finish_reason、max_tokens调大上限、结构化Prompt输出格式不对模型温度、System Prompt调低temperature、增加输出格式约束与示例并发OOM线程池、流式缓存有界线程池、异步流式处理工具参数报错JSON Schema、反序列化先解析为Map做校验再转POJOToken用量超预算无用量统计入口层统一计量设置月预算和自动告警还有一个实用技巧用本地日志把每次调用的原始请求和原始响应完整打出来哪怕格式丑一点也要先有。AI场景的Bug很难靠脑内复现一定要有“现场录像”才能反推哪一步出了问题。个人实操心得与后续扩展建议文章写到这儿核心的技术路径都过了一遍。最后聊点我个人在实际操作中的体感变化。最开始我也是一头扎进框架源码里想在Java里复刻Python那套玩法后来发现方向错了。Java接入大模型的核心价值不在“模型研究”而在“系统集成”把模型当作一个能力输入让它和现有业务系统发生化学反应。所以我的建议是从最小的对话闭环开始先不做复杂架构。跑通之后接着做两件事扩展第一把函数调用接上你的核心业务接口这是最能体现价值的环节第二把RAG接上你维护得最好的那部分文档库大概率第一版效果一般但迭代几轮后会让整个系统的知识密度立刻不一样。等到这两步都稳了再回头考虑Agent编排、多模型路由这些更重的东西。方向对了速度反而不那么重要。