最近这几天我微信里陆续有同行甩过来一张截图内容是某个技术交流群里在讨论“Spring AI Alibaba 已停更”的消息然后跟着一句灵魂拷问Java 是不是在 AI 时代出局了说实话每次这种“某某框架停更”的消息一出来Java 圈子总要沸腾一次上一次是某个开源中间件停止维护这次轮到了 AI 集成组件。作为一个从 JDK 1.6 时代一路写过来的老 Java我想先给个结论框架停更不代表 Java 没希望恰恰相反Java 在企业级 AI 应用落地中的位置比很多人想象的要稳固得多。这篇文章不贩卖焦虑只聊实际的Java 在 AI 生态里到底还能做什么、除了 Spring AI Alibaba 我们还有什么牌可打以及我自己在项目里绕过框架、直接上手对接模型接口的完整实操过程。1. 先把“停更”这件事拆开看清楚1.1 开源组件的生命周期本来就是这样的任何一个开源项目都会经历诞生、活跃、维护、沉寂这几个阶段。Spring AI Alibaba 从项目角度来说本来就是某个时段内为了补齐 Spring AI 生态在特定云环境下的集成能力而推出的组件它的定位偏“实验性”和“生态配套”。这类项目在快速迭代一段时间后如果内部技术路线调整、核心成员转岗、或者官方生态里出现了更通用的替代方案就会进入一种“不再频繁提交代码”的状态这是开源世界里的常态和“项目烂尾”是两回事。我经历了太多类似的情况。十年前我们在生产环境用的某个 SOA 框架后面整个团队都不维护了但系统照样跑得稳稳当当。框架停更是个信号提醒你关注替代方案和长期依赖风险但不能直接把“框架停更”等同于“技术方向死亡”。你要知道全球还有数以百万计的 Java 生产服务在跑这些系统不会因为某个 AI 调用组件不更新就崩掉。1.2 为什么一点风吹草动就能带起节奏这次消息之所以传播得这么快恰恰踩中了 Java 开发者的集体焦虑。这两年 AI 大模型火起来之后业界的主流声音几乎都是 Python 的什么新模型发布、什么训练框架更新、什么开源工具库第一波代码示例全是 Python。Java 开发者天天看这类信息很难不怀疑自己手里的家伙是不是过时了。再加上市面上有些咨询类自媒体特别喜欢制造“某某语言已死”的标题来获取流量。Java 号称全球使用最广泛的语言之一自然被盯上。一条“某 AI 组件停更”的消息配上“Java 未来堪忧”的解读点击率直接拉满。但真正在企业里做过 AI 落地的技术人都明白语言只是工具关键看你在解决什么问题。Java 在大型企业里做了二十多年核心业务系统这些系统不会因为 AI 概念火了就整体迁移到 Python。迁移的成本、稳定性风险、团队技术栈的重塑哪一个都不是小数。1.3 框架的边界和语言的边界要分清我们得把问题拆成两层来看。第一层是“Spring AI Alibaba 停更了”这只说明某个开源项目不再活跃维护了不代表 Spring 官方生态停止进军 AI更不代表 JVM 技术体系失去价值。第二层才是真正值得思考的问题Java 生态应对 AI 应用开发到底有没有足够的生产力。我的判断是有。Spring 官方确实在推进 Spring AI 这个项目不管你怎么看它它一直在迭代。而且更重要的是大模型对外暴露的接口本质上是 HTTP 接口。HTTP 这个东西Java 从诞生第一天就在玩Servlet、WebClient、HttpClient、OkHttp、Feign哪一个不能调外部服务大模型供应商给你一个 REST API你拿到一个 API Key 就能调这里面根本没有任何独门技术壁垒。换句话说即使所有 Spring AI 相关组件都停了Java 开发者依然可以拿着最基础的 HTTP 客户端去对接模型代码量多一点但完全能做到。搞清楚这一层焦虑就消解了一大半。2. 重新认识 Java 在 AI 应用中的真实身位2.1 AI 技术栈的分工不要搞混很多人一说 AI 就想到训练大模型然后想到 Python 和 GPU 集群于是觉得 Java 没用。这其实是把 AI 技术栈看窄了。AI 落地到业务系统通常分成三层。最底层是模型训练这一层确实以 Python 为主Java 的戏份很少。中间层是模型服务化把训练好的模型包装成推理服务这一层已经开始出现 Java 的身影比如用 Java 写高性能推理网关。最上层是业务集成也就是把模型能力嵌入到用户的订单系统、客服系统、风控系统、内容推荐系统里这一层 Java 从来都是主力。企业里绝大多数的 AI 需求集中在业务集成和编排这一层。模型大多是外部 API 提供的或者由内部算法团队部署好一个服务Java 应用要做的就是把业务数据取出来、拼提示词、调模型接口、拿到结果、做后处理、落库、返回给前端。这个过程没有任何一个环节是 Python 的专利反而 Java 的类型安全、工程化能力、事务管理能力在处理复杂业务逻辑时比 Python 脚本更舒服。2.2 Spring AI 解决了什么、没解决什么Spring AI 这个项目往简单了说就是把“调用大模型 API”这件事做成了 Spring 风格的抽象。它定义了 ChatClient、EmbeddingModel、PromptTemplate 这些概念让你可以用类似写 Spring Data JPA repository 的方式来调用模型。它帮你处理了协议封装、消息转换、与向量数据库的集成等繁琐事省了不少代码。但它的边界也很明显它只是一个 AI 应用的辅助层不是操作系统也不是中间件。它的存在价值取决于整个 Spring 生态的推进节奏。如果它更新慢了你的业务系统并不会因此瘫痪如果它有些接口设计不够稳定你完全可以绕过它直接调用底层 HTTP API。换句话说你可以把 Spring AI 当作一个可选加速器而不是唯一的出路。理解了这一点就不会把它当成救命稻草也不会因为它的波动而恐慌。2.3 Java 做 AI 应用落地优势比你想的更实在我在几家公司的项目里负责过 AI 功能集成最直观的感受是Java 的存量生态真的太强了。你要给一个成熟的 Java Web 项目加一个“智能客服”入口工程上的阻碍几乎为零。代码复用、鉴权体系、监控告警、日志链路、灰度发布、配置中心这些全部现成。而同样的功能如果要用 Python 单独做一套服务你得重新搭框架、搭部署链路、搭权限体系然后还要处理 Java 与 Python 之间的网络调用问题运维复杂度直接翻倍。再就是性能。Java 经过这么多年的 JIT 优化在常规并发接口上表现非常稳定配合虚拟线程处理高并发 IO 场景也游刃有余。模型推理本身很慢通常一次请求要好几百毫秒甚至几秒这部分时间足以让 Java 完成大量的业务逻辑编排。而 JVM 生态里有非常成熟的连接池、熔断器、重试组件这些在生产环境中的价值是评测文章里很难体现出来但真出问题的时候会非常感谢当初选了 Java。3. 除了等框架Java 开发者手上还有哪些牌3.1 直接用 HTTP 客户端调大模型 API这是最朴素也是我最常用的一条路。大模型厂商通常都会提供 OpenAI 兼容的接口协议输入一个 Message 列表输出一个 Completion 结果。Java 里随便一个 HTTP 客户端都能处理。下面是一个最小可用的例子用 JDK 11 自带 HttpClient 来实现HttpClient client HttpClient.newHttpClient(); String requestBody { model: gpt-4o-mini, messages: [ {role: system, content: 你是一名Java架构师回答要简洁明确。}, {role: user, content: 请解释一下JVM的类加载机制} ] } ; HttpRequest request HttpRequest.newBuilder() .uri(URI.create(https://api.example.com/v1/chat/completions)) .header(Content-Type, application/json) .header(Authorization, Bearer System.getenv(LLM_API_KEY)) .POST(HttpRequest.BodyPublishers.ofString(requestBody)) .build(); HttpResponseString response client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println(response.body());这段代码没有任何框架依赖放到任何 Java 工程里都能跑。很多人觉得直接调 API 很原始但恰恰是这种原始的方式最可靠因为你完全掌控请求的构造和解析不被任何中间层绑架。生产环境里我甚至见过有团队专门去掉框架封装改回直接用 HTTP就为了减少一层不确定性。3.2 拥抱 LangChain4j 这条独立生态如果你的项目确实需要更高层的抽象又不想绑定到一个一时兴起的组件上LangChain4j 是近几年 Java 圈子里值得关注的 AI 编程库。它借鉴了 LangChain 的思路专门为 Java 做了适配模块划分比较清晰支持聊天模型、嵌入式模型、RAG、工具调用等。社区活跃度也比较可观很多 Java AI 相关的开源项目都选择基于它做二次封装。选型的时候我的建议是不要被“官方”两个字迷惑。Spring 生态的东西确实规范但其他成熟的社区项目往往更灵活。LangChain4j 的好处是接口设计比较贴近 Java 开发者的习惯而且它对多家模型厂商做了适配切换模型厂商的成本很低。如果团队里有人用过 LangChain4j我通常建议直接在它上面做统一封装而不是自己从零折腾一个 AI 基础层。3.3 自己在 Spring Boot 里封装一个 AI Service其实大多数 Java 项目的 AI 需求并没有那么复杂无非是“输入文本输出文本”。这种情况下自己在工程里封装一个轻量的 AI Service 完全够用好处是业务代码完全可控逻辑一目了然。我们可以用一个配置类来管理模型信息和 API Key用一个 Service 类来封装调用逻辑再暴露成一个普通接口给上层业务调用。这种方式的核心价值不在于代码多少而在于它把“大模型”这个外部依赖抽象成了你熟悉的领域服务后续想加缓存、加日志、加降级策略都是顺手的事。而且它没有任何额外框架学习的成本团队里任何一个中级工程师都能维护。我参与的好几个项目最后都采用了这种思路效果比硬套重型框架更稳妥。3.4 用 Java 生态的向量数据库组件做 RAGRAG 是当前企业落地大模型应用最热门的方向它的核心思想是先检索再生成先从企业自己的文档库中检索出相关知识片段拼进提示词里再让模型基于这些片段回答。Java 生态在这个领域并不缺组件Spring AI 本身就支持向量数据库集成同时 Java 也有很多专门的向量检索客户端库。实际跑过 RAG 项目的同学都知道真正繁琐的工作不在调用模型而在文档解析、切分、向量化存储、检索调参、相关性重排。这些工作大多发生在业务系统内部与模型接口的耦合度很低Java 完全可以胜任。我在某个文档问答项目里用 Java 写了一个文档解析和向量入库的流水线输入是 PDF 和 Word输出是检索接口整个过程非常顺利没有碰到任何必须借助 Python 才能解决的问题。3.5 Function CallingJava 一样玩得转Function Calling 是让模型根据用户指令识别出需要调用的工具函数并输出结构化参数然后由业务系统执行真实函数。这个机制在企业自动化场景里非常有用比如“帮我查一下订单状态”这个过程模型负责理解意图Java 服务负责真正去查数据库。实现方式也不复杂无非是把 Java 方法的名称、描述、参数 Schema 传给模型然后根据模型返回的 JSON 去反射调用对应方法。我个人的实战体会是Function Calling 的稳定性比很多人预期的要好关键是把字段描述写得足够清晰比如“参数 startDate 表示查询起始日期格式为 yyyy-MM-dd”模型就能非常准确地生成参数。这一块做下来你会发现模型本质上就是一个对话式意图路由器而具体的执行职责完完全全落在 Java 业务系统里。4. 实操完全不用 Spring AI 组件从零搭一个 Java LLM 调用层4.1 项目初始化和依赖选择我建立一个普通的 Spring Boot 工程版本选择当前稳定发布版本即可。依赖里不需要任何 AI 组件只用 spring-boot-starter-web再加一个 Lombok 用来减少样板代码。为了发 HTTP 请求我用 Spring 自带的 RestClient它在 Spring Boot 3.2 之后变得很顺手比传统 RestTemplate 清爽比原生的 HttpClient 更好用。需要说明的是我刻意不引入 Spring AI 的任何模块就是为了验证一个观点脱离特定 AI 框架纯 Java 照样能构建完整的 AI 应用能力。下面是我的 pom.xml 核心部分parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.3.5/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies当然你完全可以把 RestClient 换成 OkHttp 或者原生 JDK HttpClient效果一样。我的建议是尽量少引入外部依赖因为 AI 调用层本身不需要复杂的 IO 框架标准库里的能力足够用了。4.2 用配置类管理模型参数我把模型 API 的地址、Key、默认模型名放到 application.yml 里用 ConfigurationProperties 绑定到一个配置类。这是 Java 工程里非常标准的做法好处是环境差异开发、测试、生产可以通过不同配置文件切换而不需要改代码。ai: api-url: https://api.example.com/v1/chat/completions api-key: ${LLM_API_KEY} model: gpt-4o-mini max-tokens: 2048 temperature: 0.7对应的配置类Data Component ConfigurationProperties(prefix ai) public class AiProperties { private String apiUrl; private String apiKey; private String model; private Integer maxTokens; private Double temperature; }这里要注意API Key 不要直接写在配置文件里用环境变量方式注入是基本安全要求。很多公司的代码仓库就是这么泄露的。我之前接手过一个项目apiKey 直接写在 yml 文件里并提交到了 git后面不得已做了全量密钥轮换非常折腾。4.3 封装 ChatClient 核心逻辑我定义一个 AiChatClient 类负责组装请求、发送 HTTP 请求、解析响应。方法设计很简单就是传入一个包含聊天消息的列表返回模型生成的文本。考虑到很多业务场景需要流式输出打字机效果我在这里提供两个方法一个是普通阻塞返回完整结果一个是流式返回。先看普通方法的实现Service RequiredArgsConstructor public class AiChatClient { private final RestClient restClient; private final AiProperties props; public String chat(String userMessage) { return chat(systemPrompt(), userMessage); } public String chat(String systemMessage, String userMessage) { MapString, Object messageRequestBody Map.of( model, props.getModel(), max_tokens, props.getMaxTokens(), temperature, props.getTemperature(), messages, List.of( Map.of(role, system, content, systemMessage), Map.of(role, user, content, userMessage) ) ); Map?, ? response restClient.post() .uri(props.getApiUrl()) .header(Content-Type, application/json) .header(Authorization, Bearer props.getApiKey()) .body(messageRequestBody) .retrieve() .body(Map.class); List? choices (List?) response.get(choices); Map?, ? firstChoice (Map?, ?) choices.get(0); Map?, ? message (Map?, ?) firstChoice.get(message); return (String) message.get(content); } private String systemPrompt() { return 你是一个乐于助人的助手回答问题时应当准确、简洁、实用。; } }代码里的细节一个是请求体用 Map 构建Jackson 自动序列化为 JSON另一个是响应解析用 Map 方式先取到最外层再一层层往下钻。可能有人觉得用 Map 不够类型安全但 AI 服务的响应结构不同厂家略有差异用 Map 才能保证兼容性反而比硬建一个 Response DTO 更省心。流式输出的实现麻烦一点因为要处理 Server-Sent Events 格式。我之前踩过坑这里直接把核心逻辑放出来public void chatStream(String userMessage, ConsumerString onChunk) { // 设置响应类型为 text/event-stream MapString, Object requestBody Map.of( model, props.getModel(), stream, true, max_tokens, props.getMaxTokens(), messages, List.of( Map.of(role, user, content, userMessage) ) ); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(props.getApiUrl())) .header(Content-Type, application/json) .header(Authorization, Bearer props.getApiKey()) .POST(HttpRequest.BodyPublishers.ofString( JsonUtil.toJson(requestBody))) .build(); HttpClient client HttpClient.newHttpClient(); client.sendAsync(request, HttpResponse.BodyHandlers.ofLines()).thenAccept(response - { response.body().forEach(line - { if (line.startsWith(data: )) { String data line.substring(6); if ([DONE].equals(data)) { return; } // 这里解析出增量内容回调给上层 onChunk.accept(parseChunkContent(data)); } }); }).join(); }这段代码没有依赖 Spring AI 的流式抽象纯 JDK 网络库就实现了流式输出。在实际项目里流式输出常见于客服对话和文档续写场景用起来效果非常不错。注意每收到一格 chunk 就立刻 flush 给前端体验上就是打字机效果。唯一要留意的坑是 SSE 的解析中有些厂商会在行首加空行有些会带多个 data: 字段建议代码里做一层容错遇到解析不了的行直接忽略不要抛异常中断整个流。4.4 暴露 REST 接口并接入测试有了 ChatClient接口层就很简单了。我写了一个 AiController提供了一个同步接口和一个流式接口。同步接口返回 JSON流式接口用 SseEmitter 把内容一棒一棒推送出去。RestController RequestMapping(/api/ai) RequiredArgsConstructor public class AiController { private final AiChatClient aiChatClient; PostMapping(/chat) public MapString, String chat(RequestBody ChatRequest request) { String result aiChatClient.chat(request.prompt()); return Map.of(content, result); } PostMapping(/chat-stream) public SseEmitter chatStream(RequestBody ChatRequest request) { SseEmitter emitter new SseEmitter(0L); new Thread(() - { try { aiChatClient.chatStream(request.prompt(), chunk - { try { emitter.send(chunk); } catch (IOException e) { emitter.completeWithError(e); } }); emitter.complete(); } catch (Exception e) { emitter.completeWithError(e); } }).start(); return emitter; } }实测下来同步接口的响应耗时和直接调模型 API 差不多因为网络传输和模型推理本身是耗时大头Java 侧的封装开销几乎可以忽略。SseEmitter 这种老牌技术依然很好用浏览器端配合 EventSource 就能直接接收。4.5 给这个轻量调用层加上生产级能力上面这套代码能跑通但离生产级还差几步。我强烈建议至少补上三类能力。第一是超时控制模型推理慢的时候可能超过 30 秒但等待时间如果无上限会拖垮线程池建议给 RestClient 设置连接超时和读取超时。第二是重试策略网络抖动和模型服务临时限流都很常见对 429 和 5xx 做指数退避重试能显著提升成功率。第三是熔断降级如果模型服务持续不可用不能把故障传染给主业务可以提前准备一个兜底回复或返回原提问的文案。这些能力在 Spring Boot 生态里都有现成组件比如 Resilience4j 或者 Sentinel自行接入即可。把这三块补上后你会发现这个轻量调用层已经具备了和大型框架同等级别的工程能力而且代码逻辑完全在你掌控之中。5. 常见问题与排查技巧实录5.1 模型接口兼容性比想象中重要我见过太多人因为框架的模型适配列表不够新而焦虑实际上各家模型厂商为了降低接入门槛普遍提供 OpenAI 兼容接口。这意味着你可以用同样的请求格式只换一个 api-url 和 api-key就能从一家模型切换到另一家。我自己的项目里就维护了一个模型供应商列表每个供应商只差一个 baseUrl 和模型名切换成本极低。因此在设计 Java AI 调用层时请优先选择兼容 OpenAI 协议的接口这能让你在模型选型上保持最大的自由度也能有效应对某个模型服务涨价或下线的情况。5.2 流式响应的截断与乱码问题流式输出最常见的两个坑一是内容被截断通常是因为 max_tokens 设置得太小模型还没说完就被强制停掉了表现为整段内容戛然而止二是中文乱码常见原因是读取流时没有指定 UTF-8 编码HTTP 响应的 Content-Type 也没有 charset 信息。排查第一个问题可以在响应中检查 finish_reason如果这个字段是 length 就说明触发了长度限制调大 max_tokens 即可。排查第二个问题确保在构造 HttpResponse.BodyHandlers 时显式指定 StandardCharsets.UTF_8并在 HTTP 响应头中尽可能带上 charset。这两个问题我都在项目里遇到过现在写代码时都会刻意注意。5.3 API Key 的安全管理配置里直接写 Key 是新手最容易犯的错误但成年人更要警惕的是另一个场景日志里把请求体完整打出来了里面包含了 Authorization 头。一旦日志系统权限控制不严Key 就泄露了。我的做法是统一封装一个日志过滤器对 authorization 字段做脱敏同时重试间不允许把 Key 拼到 URL query 里只通过 header 传递。如果你的团队用到了网关层最好在网关就统一注入鉴权头不要下放到各个业务服务自己处理否则管理成本会失控。5.4 模型服务故障如何优雅降级有一次我们在线上遇到模型服务全量不可用如果当时没有降级策略智能客服入口会直接超时堆积最终拖垮整个网关。后来我沉淀了一套方案先对模型调用做超时控制比如 15 秒没响应就当作失败再对失败情况做参数重写比如将请求自动切换到一个备用的轻量模型如果备用也失败就返回人工客服提示并记录一条待处理工单。这个降级链路在多个项目里测试下来非常稳定。总结起来就是一句话默认情况下绝不允许因为模型服务故障而阻塞主业务流程。5.5 我踩过的生态环境适配坑虽然我上面主推轻量封装但并不是说 Spring AI 完全不用看。之前在一个微服务项目里团队希望快速上线一个 RAG 问答功能直接引入了当时的 AI 集成组件结果遇到两个问题模型版本升级后接口参数不兼容需要修改组件配置不同环境里依赖的向量数据库版本也不一致导致连启动都困难。后来我们把组件版本锁定并针对模型调用做了很薄的一层适配接口再更换模型时就再也没有大面积改代码的痛楚。这件事让我形成一个习惯不管是官方组件还是社区框架一律在它外面再包一层自己的抽象不能让自己的业务代码直接依赖某个组件的类型和 API否则组件一停更你的代码就要跟着停更。6. 最后想说点掏心窝的话写了这么多再说回标题那个问题Java 还有希望吗我个人的答案是有希望而且比很多焦虑的人以为的更确定。大模型本身是一个潮流但企业级软件的基础设施从来不会因为潮流而轻易崩溃Java 在事务处理、并发能力、工程生态、人才储备方面的家底太厚了这些能力在 AI 应用落地时依然是最稀缺的。我不否认 Python 在算法侧和快速原型上的优势也不回避 Java 在模型训练生态里存在感不足的事实但我们需要做的是在各自的位置上把活干好。如果你是个 Java 开发者与其陷在“框架停更了是不是没希望”的焦虑里不如花一个周末把我上面这个轻量 AI Service 自己动手写一遍。写完你就会发现AI 能力接入 Java 应用这事本质上就是把一个 HTTP 接口玩出花来框架永远是锦上添花真正决定项目价值的还是你对业务的理解和工程化落地能力。最后再分享一个小技巧每次看到类似“某某组件停更、某某生态药丸”的消息先别急着转载去翻一下项目仓库的 issues 和 pull requests看看项目维护者最近都在忙什么。很多所谓“停更”只是低活跃并不是死了而就算真的死了也不代表你所在的整个技术方向会跟着陪葬。技术人的底气从来不是来自某个框架的更新频率而是来自你随时能把手上的事做成做好的能力。
