Spring AI Alibaba停更不用慌，Java做AI的三种路径与实战

看到Spring AI Alibaba停更的消息，估计不少Java同行的心里都咯噔了一下。Spring AI Alibaba是Spring AI生态里的国内模型适配层，大家用它接入国产大模型和向量数据库，图的就是省事。结果项目一停更，很多人第一反应是：Java在AI这个局里是不是彻底没戏了？我能不能把这套业务代码换成Python重写？

先给结论：没到那个地步。停更一个组件，不代表整个Java的AI路线就断了。Spring AI官方项目还在迭代，Java生态里还有LangChain4j这类专门做LLM应用框架的替代品，更别提你完全可以自己封装模型调用。这篇文章我就把这件事拆开聊一聊：Spring AI Alibaba到底停了什么、Java在AI领域卡在哪、现在想用Java做AI应用有哪些能落地的路，以及我实际调通的代码长什么样。

1. 先弄清楚Spring AI Alibaba到底凉了什么

1.1 它当初解决的是什么问题

Spring AI Alibaba这个项目定位很明确：它是Spring AI官方框架的国内增强层。Spring AI本身是统一抽象的模型调用接口，设计目标是让开发者用一套代码接入不同的大模型服务商，但官方适配的重点长期放在国际主流模型上，对国内模型和国内云环境支持有限。Spring AI Alibaba做的就是把这块补上：适配国内常见的通义系模型、提供更贴合国内开发者的向量存储兼容方案，以及一个基于Spring AI的开发脚手架。

对当时的Java开发者来说，这个项目确实解决了一个实际问题：你不需要自己研究各家模型SDK的差异，也不用关心Spring AI和国内模型之间的兼容性坑，引入依赖、写几行配置、注入客户端就能开始对话。尤其在私有化部署场景，很多企业要求模型完全跑在内网，Spring AI Alibaba的本地化支持比官方默认配置更接近可用的状态。

但问题也出在这里：这个项目本质上是跟着上游走的中间层，上游Spring AI每个版本都在快速变化，模型市场的竞争格局也在变，中间层要持续做适配，维护成本非常高。

1.2 停更意味着什么，不意味着什么

看到停更消息，先分清楚两个层面。

停更的直接后果是：以后国内新出的模型规格，这个项目大概率不会跟进适配了；一些依赖它做的Spring Boot版本升级，可能不再有官方保障；安全补丁和bug修复也会慢慢停摆。如果项目已经接了它，短期内还能继续用，但如果底层依赖或上游接口有破坏性变更，你就得自己动手解耦或迁走。这就好比一套租房里的定制家具，房东搬走了家具还在，但以后坏了没人修，想添置新的也没人帮你量尺寸。

但不意味着Java没有希望。理由有三层：

第一，Spring AI Alibaba只是一个适配层，不是Java接入AI的唯一通道。它上层的Spring AI还在正常发展，你完全可以绕开这个中间层，直接用Spring AI连兼容接口的模型服务。

第二，Java的AI应用场景从来不是“从零训练一个模型”，而是“把已有的模型能力嵌进企业系统”，这块确实没有替代品。Java最擅长的是什么？是处理高并发、事务、复杂业务编排、和存量系统做集成。AI应用恰恰需要这些东西。

第三，国内大量企业的技术栈还是以Spring Boot为主，团队里Java工程师一堆，不可能因为一个适配组件停更就全员转型。现实是，业务要的是“能用、能落地、能修”，接近九成的企业做AI功能的方式不是训练模型，而是调接口、做应用编排。

所以，停更这件事我们当作一个信号去看就好：它说明中间层适配业务没那么好做，但它远不足以说明Java生态在AI时代被判了死刑。

2. Java在AI时代到底行不行

2.1 训练侧认输，应用侧别慌

先把Java和AI的关系掰开说。AI这个领域实际上分两个完全不同的赛道：模型训练与算法研究和模型应用与工程落地，前者是Python的天下，后者才是Java的主场。

为什么训练侧Java很难上位？因为深度学习生态的工具链、预训练框架、GPU计算库、数据科学工具都是围绕Python构建的，模型研究讲究快速实验、频繁改动，Python的灵活性和胶水特性在这里碾压Java的静态类型和编译思维。这不是Java不够强，是生态惯性太大，硬挤进去的意义也不大。

但应用侧完全是另一回事。什么叫应用侧？就是你不用自己训练模型，而是调用现成的大模型API，做一个带有业务逻辑和交互界面的系统。比如：企业内部知识库问答、客服工单自动分类、合同关键信息抽取、代码审查助手、给ERP系统加一个智能搜索入口。这些场景里，大模型只是个引擎，你真正要做的是写一套业务逻辑把它包起来，而这恰恰是Java和Spring生态干了十几年的事。

举个例子，某公司的订单中心是Java写的，数据在MySQL里，权限体系在Spring Security里，现在想加一个功能：用户用自然语言查订单。你只需要在原有项目里加一个模块，处理用户的提问，拼接查询条件和上下文，调用模型生成SQL或者走既有查询接口。这种活让团队把所有业务系统用Python重构一遍去适配AI，成本高到没有老板会签字。

所以，Java在AI时代的位置，不是去跟Python抢模型训练的地盘，而是把AI能力像数据库、消息队列一样作为基础设施嵌进企业软件。这个层面的需求量，一点不比训练侧小。

2.2 Java的AI短板的真相

当然也得承认，Java做AI有一些真实的障碍，不避讳。

第一个短板是官方SDK和示例的贫富差距。大模型厂商和开源项目发布API时，优先给的永远是Python SDK和Python示例，Java SDK往往要么没有，要么维护频率低。这就导致Java开发者在网上搜“如何调用某模型API”，搜出来的全是Python代码，你得自己翻译成Java，遇到SDK里不支持的参数还要去读源码，体验确实不如Python顺手。

第二个短板是AI生态里的周边组件，Java适配还不算成熟。做RAG（检索增强生成）你需要向量数据库、Embedding模型、文档解析工具。Python社区里有大量成熟的集成方案，Java这边要么靠框架帮你封装，要么就得自己组合几个库。好在很多主流组件（比如各类向量数据库服务）都有Java客户端，只是示例少一些。

第三个短板，坦率讲是心理层面的。AI新技术一出来，社区讨论都是Python，Java相关的项目显得低调，容易给人“Java要被淘汰”的错觉。实际上你去看企业级AI落地的案例，很多关键系统还是Java在做后端支撑，只是因为讨论度低，显得不起眼。

说白了，Java的AI短板不是硬伤，是生态成熟度问题：东西能用，但需要你去踩坑、去补全。做技术选型做的是匹配度，不是比谁的话题热度高，这一点放到哪个技术栈都成立。

3. 不用慌，Java做AI还有这几条路

3.1 路线一：继续跟进Spring AI官方

Spring AI Alibaba停了，但Spring AI官方项目还在正常迭代。官方项目提供的核心能力我实际用过之后，感觉比很多人想象中要完整：对话补全、聊天记忆、结构化输出、提示词模板、函数调用、RAG的向量检索流程，基本都有抽象。而且它跟Spring Boot的配置体系结合得很紧密，配置文件里写模型参数，注入客户端直接用，符合Java后端一贯的编程习惯。

使用Spring AI官方有个小技巧：尽量选择实现了OpenAI兼容协议的大模型服务或中间件。很多模型服务商为了省事，直接提供OpenAI兼容接口，Spring AI的openai模块能通过自定义base-url连上去。这样你既用了官方框架的能力，又绕开了Spring AI Alibaba停更带来的国内模型适配缺口。我用这个方式接过几个不同来源的模型服务，只要把base-url换成对应地址，其余代码基本不用动。

需要考虑的地方是Spring AI的API更新速度也不算慢，从早期版本到现在的接口变化幅度不小。如果你打算在生产环境用，建议锁一个版本，别频繁追新，等新版本稳定再评估迁移。

3.2 路线二：LangChain4j这个宝藏

如果你的项目不在Spring生态里，或者你需要比Spring AI更灵活的LLM应用编排能力，LangChain4j值得重点看。这个框架的定位是Java版的LLM应用工具箱，它的灵感来自Python的LangChain，提供了模型对话、消息历史管理、工具/函数调用、RAG、自动化Agent等功能。

LangChain4j最让我喜欢的一点是设计上比较务实。它不强行套Spring的模板，核心API本身就是纯Java的轻量封装，你可以在任何Java项目里用它，哪怕是老的Servlet项目也能贴进去。它支持的模型服务很多，主流的在线大模型服务基本都有对应模块，也支持你在本地用兼容OpenAI协议的服务，算下来覆盖面很够用。

另外还要说一句：Quarkus加LangChain4j也是一条路。如果你对启动内存和性能敏感，或者想尝试GraalVM原生镜像部署，Quarkus社区配合LangChain4j做微服务的成熟度已经比很多人想象中高了。不过这条路的学习曲线比单纯用Spring Boot要陡，适合愿意折腾的团队。

3.3 路线三：自己封装模型调用

还有一种看起来很笨、其实非常可控的方案：不用任何AI框架，直接用Java原生SDK或轻量HTTP客户端封装模型接口。

这个方案适合什么样的情况？你的需求非常简单，比如只做一次性问答、只调用一个模型接口、不需要复杂的状态管理，那引入一个重框架反而制造麻烦。直接用一个HttpClient发POST请求、解析JSON响应、把结果映射到自己的业务对象，代码量不大，效果直接可见，出了问题还能精确到具体哪一行。

自己封装需要关注的点是模型接口返回的内容结构。大模型API返回的JSON里通常包含回答内容、Token用量、结束原因等字段，不同服务商字段名会有差异。我的做法是先定义一个对应响应结构的Record类，用Jackson反序列化，再把非关键字段忽略掉。另外流式输出如果要用，直接处理批量SSE格式，需要单独写解析逻辑。这样做的优点是零框架依赖，维护成本完全可控。

如果你预计未来会接多个模型、要做灵活的提示词切换，那还是上框架吧，自己封装的成本会随着功能增加水涨船高，没必要重复造轮子。

3.4 三条路怎么选：一张对比表

4. 实测演示：用Spring Boot搭一个最小RAG问答

4.1 依赖与配置准备

说了这么多，还是直接上代码更踏实。下面这个例子展示的是：用Spring Boot接入一个兼容OpenAI协议的模型服务，做一个带向量检索的最小RAG问答。整个过程不依赖Spring AI Alibaba，只用Spring AI官方能力。

先在pom.xml里加依赖。Spring AI的依赖坐标随着版本变化，下面这种写法基于当前较新的发布版本，具体版本号建议以官方文档为准：

<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-openai-spring-boot-starter</artifactId> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-pdf-document-reader</artifactId> </dependency>

配置方面，把模型服务地址和密钥放在application.yml里：

spring: ai: openai: base-url: http://your-model-service:8000/v1 api-key: ${LLM_API_KEY} chat: options: model: your-chat-model-name temperature: 0.7 embedding: options: model: your-embedding-model-name

这段配置说三件事：第一，base-url指向你的模型服务地址，不管它是云上的还是内网部署的，只要兼容OpenAI协议就能填。第二，模型名要和服务商提供的模型ID一致。第三，embedding模型单独指定，因为这个模型负责把文本转成向量，为后面的相似度检索服务。

4.2 核心代码：读文档、存向量、做问答

RAG的原理一句话说清楚：把用户的私有知识切分成片段，转成向量存进向量数据库，用户提问时先检索出相关片段，再让模型基于这些片段生成回答。这个流程绕开了模型训练时没见过你的私有数据的问题。

我写一个服务类，包含三步：解析文档、保存向量、回答问题。

@Service public class RagService { private final VectorStore vectorStore; private final ChatClient chatClient; public RagService(VectorStore vectorStore, ChatClient.Builder chatClientBuilder) { this.vectorStore = vectorStore; this.chatClient = chatClientBuilder.build(); } public void ingest(Resource pdfResource) { var reader = new PagePdfDocumentReader(pdfResource); var documents = reader.get(); vectorStore.add(documents); } public String answer(String question) { var relatedDocuments = vectorStore.similaritySearch(question); var context = relatedDocuments.stream() .map(d -> d.getText()) .reduce("", (a, b) -> a + "\n" + b); var prompt = """ 你是一名企业内部知识库助手。请根据下面的资料内容回答用户问题。 如果资料中没有相关内容，请直接回答“根据现有资料无法回答该问题”。 资料内容： %s 用户问题：%s """.formatted(context, question); return chatClient.call(prompt); } }

我在演示时用SimpleVectorStore作为演示用的向量存储，它把数据存在内存里，重启会丢，更适合原型开发。生产环境建议换用支持持久化的向量数据库，Spring AI对主流向量数据库都有适配，配置一下连接信息就能切换。这个设计的好处是业务代码不用改，只改配置和依赖。

4.3 跑通这个小Demo之后，你会发现哪些坑

我自己写这类Demo踩过几个比较典型的坑，分享出来帮你省时间。

第一，embedding模型和chat模型不能随便换。如果embedding用的模型和你检索时用的模型不一致，向量空间的语义分布会对不上，导致检索结果明显变差。建议固定一套模型组合，别今天用一个明天换另一个。

第二，向量检索结果不是越多越好。一开始我以为把检索出来的所有片段全塞进提示词里，模型回答会更准。实际测试发现，上下文塞得太长反而让模型注意力分散，回答变得啰嗦甚至跑偏。一般取三到五条相关性最高的片段就够了，重点是质量不是数量。

第三，模型服务地址的连通性测试要先于代码测试去做。很多朋友一上来就写代码，结果模型地址配错，错误的响应格式导致整个应用启动失败。我先用curl或Postman直接请求一次接口，确认返回结构没问题，再开始写Java代码，排查边界清晰很多。

第四，OpenAI兼容协议不等于每个服务都完全一样。多数服务实现了基础的对话补全接口，但流式、工具调用、超参支持程度参差不齐。对接前扫一眼对方的接口文档，确认你要用的能力在对方服务上受支持，不然运行时才开始排查就费劲了。

5. 做技术选型，得先看清楚自己的场景

5.1 哪些场景完全可以继续用Java做AI

聊完代码，回到那个焦点的选择题：Java还有希望吗？我的答案是，做企业级AI应用，Java不仅有希望，还是最务实的选项。

适合继续用Java的场景有一个共性：AI是作为模块嵌入系统，而不是系统围绕AI重建。你可以把AI能力看作一种新的服务依赖，Java把现有的业务系统、权限体系、数据模型完整保留，然后加一层AI调用的服务或者模块就好。这类场景在企业里是绝大多数。

典型例子包括：在已有的CRM里加一个销售线索摘要生成按钮，用AI自动生成周报并推送给管理者，给客服系统接入知识库问答机器人，在后台管理系统中让AI辅助审核用户提交的文本信息。这些功能看起来都带AI，但主体仍然是Java业务系统的工程能力：身份认证、数据隔离、审计日志、异常处理、异步任务，一样都不能缺。Java在这里的竞争力远强于Python。

团队层面也一样。很多企业团队的Java工程师对Spring Boot的熟练度非常高，你让他们用Python从零开始写一个服务，光是环境管理、依赖管理、部署方式就够折腾一个月。用Java在现有体系里做增量开发，是把现有团队能力转化为AI交付能力的最快路径。

5.2 不建议硬扛Java的场景

保持客观，也有不适合Java硬扛的场景，碰到就老老实实混搭。

第一种是需要做模型微调或模型训练的场景。如果你要自己调一个专有模型，数据集处理、训练脚本、实验记录这些环节用Python生态的效率明显更高。这时候Java不要冲进去当主力，老老实实做一个模型服务网关的角色就好。

第二种是算法团队独立孵化、没有历史包袱的项目。一个全新的AI产品，核心团队都是算法工程师，那工程侧用Python也合理，没必要为了Java而Java。

第三种是业务逻辑极度依赖AI编排、推理链路很复杂的场景。比如一串多Agent协作的复杂流程，很多成熟参考案例都是Python写的，你用Java做也行，但要接受很多现成示例没法直接抄。这时候换个思路：Java负责业务和入口，AI编排部分用Python单独部署，两边通过接口通信。不要有“一个系统必须只有一种语言”的心理包袱，混搭才是企业系统的常态。

我见过一些团队被框架停更事件吓到，想立刻把所有路线推翻重选。我的建议是先别动存量系统，在技术选型时把“能不能把现有资产利用起来”作为第一原则，很多焦虑其实就解决了。框架是工具，业务在你自己手里，工具换了重新装一个就好，业务模型是不会因为某个工具停更就塌掉的。

最后分享一个实际体会。当初我看到Spring AI Alibaba停更，第一反应也是赶紧去测试Spring AI官方和LangChain4j，对比了一圈以后，反而觉得自己之前过度依赖中间层是件好事：逼着我理解了底层模型调用和向量检索的原理，现在接什么服务都不慌。Java做AI这件事，需要的不是等一个完美的框架，而是理解AI应用的核心链路，然后用自己熟悉的技术把它工程化落地。工具永远在变，工程能力才是那个保值的东西。