最近社区里被一个问题刷屏了Spring AI Alibaba 停更了Java 还有希望吗先给结论有希望而且希望比很多人想象的都大。但我要先把话说明白——“Spring AI Alibaba 停更”这件事是真的可它跟我们讨论的“Java 能不能做 AI”根本就是两码事。很多同学把“某个框架没维护”直接等于“这条技术路线走不下去了”这中间漏掉了太多关键信息。这篇文章我不想灌鸡汤就干三件事把这个项目停更的真实原因扒清楚把 Java 在 AI 落地链路里的位置摆正再给一套你现在就能上手复现的技术方案。后面还会把我在本地跑通 Spring AI 官方主项目 Ollama 做知识库问答的完整过程放出来包括遇到的坑和排查方法。看完你大概会明白Java 做 AI 不是没戏只是需要换一套思维方式和选型路径。1. 先看真相Spring AI Alibaba 的“停更”意味着什么1.1 这个项目到底是什么来头很多新手容易搞混 Spring AI 和 Spring AI Alibaba我先把这层关系理清楚。Spring AI 是 Spring 官方出的 AI 应用开发框架目标是把主流大模型厂商的调用接口抽象成一套统一 API让开发者写一套代码就能接这家模型或者那家模型。它更像是一个“适配层”解决的是 Java 后端接入大模型时的重复劳动问题。Spring AI Alibaba 则是一个面向国内模型生态的适配项目主要补的是阿里系模型如通义千问等与 Spring AI 的对接空缺同时引入了一些国内开发者在落地时更习惯的组件。它出现的那段时间中文圈推荐度非常高原因很简单——当时 Spring AI 官方主项目对国内模型的适配还不够顺手很多教程宁可直接用这个中文友好的项目。换句话说它可以理解成“本地化适配分支”不是 Spring AI 本身更不是 Java 生态的全部。这个定位很重要后面所有讨论都建立在这层认知上。1.2 “停更”背后的真实状态我特意去翻了项目的更新记录和社区讨论。老实说这个项目的活跃度在过去一年多确实明显下滑版本迭代基本停滞代码提交频率大幅下降issue 里不少提问得不到及时回应release 记录也停在了一个早期的版本。用“事实上的停更”来形容并不冤枉它。但停更的原因并不是“这条路走不通”更不是“Java 写 AI 是错的”。它更像是开源项目里很常见的一种状态项目发起方把人力投入撤回了团队重排优先级国内模型厂商各自推出了自己的官方 SDK直接减少了社区对这个适配层的依赖Spring AI 官方主项目自身在快速迭代逐渐补上了很多原本只有这个项目才有的能力。这种情况在开源社区太常见了。一个项目只要核心维护者不再投入它就会慢慢“冷却”。哪怕代码仍然可以正常编译、正常使用只要没人迭代短期看就等于停更。但大家要分清项目冷却 ≠ 技术底座废了更不等于这个语言生态没希望。1.3 把“框架焦虑”和“语言焦虑”拆开之所以要把这层关系单独拎出来写一节是因为我在评论区看到太多被标题带偏的言论。有人说“Java 完蛋了”有人说“赶紧转行学 Python 吧”这些结论都过度简化了。打个比方你常用的一个翻译插件下架了不代表你学的英语就没用了更不代表所有英语翻译工具都消失了。Spring AI Alibaba 停更只代表这个“适配组件”本身需要更多社区支持或者你的项目应该切换接入方式它绝不代表 Java 后端没有 AI 开发能力。Spring 官方主项目 Spring AI 到现在依然保持着稳定的发布节奏新的版本功能越来越多社区讨论也一直很活跃。所以我的态度很明确既然你对 Java AI 开发有真实需求与其纠结“哪个仓库不更新了”不如花时间把官方主项目吃透或者直接用云厂商 SDK 接入。这些路不但没有消失反而是越来越宽了。2. 认清现实Java 在 AI 时代没被淘汰只是换了个工种2.1 大模型开发的两条赛道别站错位置恨多人一想到“AI 开发”脑海里自动浮现的是训练大模型、调参、跑显卡集群。这种极客式的理解当然没有错但它只是 AI 产业的一部分。我们把大模型开发分成两条赛道来看赛道一模型研发。也就是预训练、微调、对齐、推理优化这些偏研究、偏算法的方向。在这个赛道Python 确实有巨大优势生态工具链都是现成的数据科学家也习惯用它。赛道二应用落地。也就是把已经训练好的模型接入到真实的业务系统里让用户能通过 API、聊天框、业务按钮真正用起来。这个赛道考验的技术点完全不同接口整合、鉴权、流式输出、并发控制、数据接入、稳定性保障。Java 在企业级后端干了这么多年积累的大量能力恰好落在赛道二里。你想想看一个普通企业要让 AI 赋能现有业务流程他需要的是什么是一个大模型不一定。他需要的是把现有的客户数据、订单数据、知识库文档喂给模型同时保证现有的业务系统不崩、权限不漏、响应及时。这正是 Java 后端最常见的老本行。用生活化的类比解释训练大模型就像造发动机Python 在这件事上是专业选手但把发动机装进整车、配上油箱、刹车、仪表盘让它能安全地跑在公路上这是汽车工程师的事。Java 就是那个干了十几年汽车集成的工程师。你说发动机换代了汽车工程师就没饭吃了恰恰相反每次有新型发动机出来会换装、会调校的工程师反而更抢手。2.2 AI 应用落地链路里Java 能拿下的关键环节我再列一下实际项目里跟大模型对接时绕不开的工程问题你看看这些是不是 Java 的强项API 网关与权限控制大模型接口要有网关转发、密钥管理、按用户限流这是 Java 最常见的中间件场景流式输出与响应编排模型回答是一段一段吐出来的要用 SSE 或 WebSocket 推到前端Java 的响应式编程和虚拟线程在这里非常顺手任务编排与状态管理多轮对话、多工具调用、复杂 Agent 流程里的状态保存和回滚后端工程化是强项RAG 知识库链路文档解析、切片、向量化、检索、重排这整条管道本质上是一套数据加工流程Java 完全能hold住可观测性链路追踪、指标采集、日志归集这些本来就是 Java 应用平台最成熟的部分。所以答案是Java 不是在 AI 浪潮里出局了而是从聚光灯下的“算法码头”转向了更靠后的“工程码头”。这里没有多少人写高深的研究论文但每天支撑着大量真实业务的上线。2.3 一个容易忽略的优势存量系统衔接还有一件事很多初学者压根意识不到——大多数企业里现存的业务系统就是 Java 写的。你让公司把核心客户系统推倒重做换一门语言去接 AI成本高到难以想象。更合理的路径是用 Java 在现有系统里加一层“AI 接入服务”让老系统快速拥有新能力。我之前帮一个朋友调过类似场景这里就叫模拟项目X吧一个不太新的内部运维系统需要接一个问答机器人来回答文档里常见问题。真正的核心难点根本不是调模型接口而是要把散落在一堆旧格式文档里的知识清洗、切片、入库还要保证老系统的工单权限在问答里不起冲突。这些工作里面模型只是一个黑盒周边十件事每一件都是 Java 的老战场。所以你看框架停更真的不该动摇你扎根这个语言的信心。3. Java 开发者的 AI 技术选型参考3.1 四条主流接入路线放下“有没有希望”这种宏观焦虑落到具体项目里Java 开发者面前其实有非常清晰的选型路径。我根据自己的实践把最常见的四类方案整理成了一张对比表方案统一抽象度中文生态适配维护活跃度学习成本适合场景Spring AI官方主项目高逐步增强高中Spring Boot 项目接入主流大模型LangChain4j高尚可高中高需要复杂 Agent、多工具编排云厂商官方 SDK低高国产模型高低深度绑定某家云平台本地推理 Java 客户端中取决于模型中中离线、私有化、数据敏感场景这张表怎么看我给几条经验如果你的项目本身就是 Spring Boot想快速把聊天接口跑通、让前后端联调起来Spring AI 官方主项目是最省心的。你不必因为 Spring AI Alibaba 停下来就绕开官方主线。如果业务里有复杂的 Agent 编排、多步工具调用、丰富的会话内存管理LangChain4j的抽象更灵活但它的文档更新节奏没有那么稳需要你对源码做一定的追踪。如果公司已经选定某家云平台的模型直接用官方 SDK最稳只是要注意厂商绑定问题将来换模型的工作量会更大。如果是私有化部署、数据不出内网的场景Ollama Java 客户端是很好的组合后面我会给出一个具体可跑的例子。3.2 向量库选型不能拍脑袋RAG 落地一定绕不开向量数据库。很多新手一上来就选大牌结果数据和预算都撑不住。这里我给一个简单的决策逻辑单机 Demo / 快速验证用 SimpleVectorStore 就够了那是 Spring AI 内置的内存向量库零运维成本中小规模数据几万条以内用 Redis 的向量检索模块或 Elasticsearch 的向量能力充分利用已有中间件大规模数据百万级向量上 Milvus 这类专业向量数据库或者用云厂商的向量检索服务。另外提醒一句向量库一旦上线embedding 模型就不要再轻易换了。换来换去导致向量维度不一致、语义空间变了旧索引全部失效这个坑我踩过后面着重讲。3.3 本地模型选型的现实考量本地推理方案里模型选型比框架更影响体验。如果只是跑通流程用 3B 左右的小模型就足够了如果要追求中文质量可以往 7B 到 14B 的模型走但得先确认显卡和内存扛不扛得住。embedding 模型方面中文场景我建议优先用 bge-m3 这一类对中文支持比较好的向量模型。对比过英文为主的模型中文的语义检索效果差距很明显尤其在搜索企业内部中文文档的时候。4. 实操用 Spring AI Ollama 跑一个带知识库的本地问答服务说了那么多选型不亲手跑一遍始终是纸上谈兵。这一节我给出一个完整可复现的 Demo本地部署 Ollama用 Spring AI 官方主项目接入把一份测试文档变成可以被检索的知识库最终做成一个简单的 RAG 问答接口。4.1 环境准备JDK、Maven、Ollama我的本地环境是JDK 17Maven 3.9Ollama本地模型运行工具下载后一条命令就能拉起模型Spring Boot 3.4 左右 Spring AI 1.0 M 系列先装 Ollama。装好后在命令行拉两个模型一个聊天模型一个 embedding 模型。我用的是ollama pull qwen2.5:3b ollama pull bge-m3这里稍微解释一下为什么要两个模型。在 RAG 链路里embedding 模型负责把文档切片变成向量存起来聊天模型负责根据用户的提问生成回答。两者职能不同不能混用。提示如果你的机器内存小于 16G建议用更小的模型比如 qwen2.5:1.5b。模型跑起来后内存占用会明显上升别等 OOM 了再回头调。4.2 创建工程与依赖配置新建一个 Spring Boot 工程在pom.xml里加 Spring AI 相关依赖。这里非常关键Spring AI 的版本迭代比较快不同版本之间的配置项经常有变化不要盲抄老博客。我用的 BOM 管理版本这样能最大程度避免依赖冲突。dependencyManagement dependencies dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-bom/artifactId version1.0.0-M6/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-ollama-spring-boot-starter/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-vector-store-simple/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-tika-document-reader/artifactId /dependency /dependenciesspring-ai-tika-document-reader用来解析 PDF、Word、Markdown 等文档Demo 阶段有它非常省事。4.3 配置 application.ymlSpring AI 对接 Ollama 的配置集中在application.yml里核心就三块Ollama 服务地址、聊天模型名、embedding 模型名。server: port: 8080 spring: ai: ollama: base-url: http://localhost:11434 chat: options: model: qwen2.5:3b temperature: 0.7 embedding: options: model: bge-m3这份配置的含义是用默认的 Ollama 服务地址聊天走qwen2.5:3b向量化走bge-m3。这些配置项在官方文档里都有对应说明但不同小版本的命名可能略有差异所以还是那句话以你实际引入的版本源码为准。4.4 核心代码实现我的代码分成三部分向量库初始化、知识库写入、问答接口。向量库存放切好的文档向量。Demo 阶段用 SimpleVectorStore它在内存里跑重启后数据就没了。要想持久化后面可以换成 Redis 或其它向量库。Configuration public class RAGConfig { Bean public SimpleVectorStore simpleVectorStore(EmbeddingModel embeddingModel) { return SimpleVectorStore.builder(embeddingModel).build(); } Bean public ChatClient chatClient(ChatClient.Builder builder) { return builder.build(); } }接着写一个服务类读取文档、切片、写入向量库。切片的逻辑可以先用最简单的方式按固定长度切每段之间留一些重叠。这个 Demo 里我直接按段落切更贴近实际场景。Service public class KnowledgeService { private final SimpleVectorStore vectorStore; private final EmbeddingModel embeddingModel; public KnowledgeService(SimpleVectorStore vectorStore, EmbeddingModel embeddingModel) { this.vectorStore vectorStore; this.embeddingModel embeddingModel; } public void load(String filePath) throws IOException { DocumentReader reader new TikaDocumentReader(new FileSystemResource(filePath)); ListDocument documents reader.get(); ListDocument splitDocs documents.stream() .flatMap(doc - splitByParagraph(doc).stream()) .toList(); ListDocument documentsWithEmbeddings this.embeddingModel.embed( splitDocs, EmbeddingOptions.EMPTY, null); vectorStore.add(documentsWithEmbeddings); } private ListDocument splitByParagraph(Document doc) { String[] paragraphs doc.getText().split(\\n\\s*\\n); return Arrays.stream(paragraphs) .filter(p - p.trim().length() 20) .map(p - Document.builder().text(p.trim()).build()) .toList(); } }上面这段代码里embed这个方法最容易忽略它负责把每个文档切片的文本转成向量并回写到 Document 对象里这样vectorStore.add才能存到正确的向量。不少人在这一步漏掉导致检索时报“文本没有 embedding”的错误。再写问答接口。RAG 的原理很简单用户提问后先去向量库里检索跟问题最相关的几个切片把它们拼进 Prompt 里再把整个 Prompt 发给大模型。Service public class ChatService { private final ChatClient chatClient; private final SimpleVectorStore vectorStore; public ChatService(ChatClient chatClient, SimpleVectorStore vectorStore) { this.chatClient chatClient; this.vectorStore vectorStore; } public String ask(String question) { String prompt createPrompt(question); return chatClient.prompt(prompt).call().content(); } private String createPrompt(String question) { ListDocument similarDocs vectorStore.similaritySearch( SearchRequest.builder(question).withTopK(3).build() ); String context similarDocs.stream() .map(Document::getText) .collect(Collectors.joining(\n\n---\n\n)); return 请基于以下参考资料回答用户问题。 如果资料中没有相关内容请明确表示不知道。 参考资料 %s 用户问题 %s .formatted(context, question); } }最后加一个简单的 Controller 暴露接口RestController public class ChatController { private final ChatService chatService; private final KnowledgeService knowledgeService; public ChatController(ChatService chatService, KnowledgeService knowledgeService) { this.chatService chatService; this.knowledgeService knowledgeService; } PostMapping(/load) public String load(RequestParam String path) throws IOException { knowledgeService.load(path); return loaded; } PostMapping(/ask) public String ask(RequestParam String question) { return chatService.ask(question); } }4.5 跑起来验证效果启动服务后先在本地准备一份测试文档比如一个 Markdown 文件里面写几个只有该文档才有的冷门知识点。然后按顺序调用两个接口curl -X POST http://localhost:8080/load?path/tmp/test.md curl -X POST http://localhost:8080/ask?question这个系统的默认超时时间是多少重点看回答内容。如果知识库里没有相关内容模型大概率会给你编一个答案而接入了 RAG 后它应该能从文档切片中检索到对应段落并给出有出处的回答。这个对照实验比看一百篇文章都更能让你理解 RAG 的价值。我当时跑通这个 Demo 的时候还顺手测了一件事改文档内容后不重新加载看看模型会不会检索到旧数据。答案是会的因为旧向量还留在内存里。这提醒我真实项目里知识库的更新机制必须单独设计否则系统就是个“只会读旧知识的笨机器人”。5. 实战排查这 8 个问题我踩过别走老路Demo 能一次跑通是运气跑不通才是常态。这一节我把我遇到的问题整理成速查表再挑三个典型详细展开。5.1 问题速查表现象可能原因解决思路启动报 Connection refusedOllama 服务没启动或地址不对先确认ollama list能正常返回模型列表接口返回 401 / 403配置了错误的 API Key或本地服务鉴权未关检查 base-url 配置Ollama 默认本地不用鉴权拉模型一直失败网络波动或模型名写错核对模型全名必要时多试几次向量库检索结果为空文档没有正常 embed或查询与文档语义相差大打印vectorStore.count()看条目数不为 0 再继续查中文回答内容很少小模型本身中文能力弱换 qwen2.5 系列或加大上下文长度内存持续上涨SimpleVectorStore 把全文和向量都放内存换成 Redis 或 Elasticsearch 向量检索扔进去的 PDF 乱码扫描版 PDF 没有文字层先用 OCR 处理成可检索文本配置项和网上文章对不上Spring AI 版本更新导致命名变化直接读引入版本源码里的属性类5.2 最容易翻车的三个点先说维度不匹配。我在初学的时候第一次用的 embedding 模型叫nomic-embed-text后来换成了 bge-m3结果发现向量维度变了旧索引查不到内存向量库里全是脏数据。这个坑的教训是向量数据库不是换了模型就能无缝迁移的生产环境一定要在设计之初就确定好 embedding 模型升级要走数据重建流程。第二个容易翻车的点是文档切片质量问题。切得太碎每段信息不完整检索出来上下文不连贯切得太粗单段超长embedding 的效果急剧下降。我后来用“按段落切 控制长度上限 相邻段落补 20 字重叠”的策略准确率才明显上来。技巧听起来简单但很多人就是不愿花这十分钟调宁可去买更贵的模型。第三个是生产化问题。SimpleVectorStore 在 Demo 里非常棒但真实业务里数据量一上来内存直接吃紧而且服务一重启知识全丢。我在某个模拟项目里换成了 Redis 的向量检索模块后内存和重启问题同时解决了。所以我的建议是项目一开始就可以把向量库抽象成接口别把 Demo 里的内存实现当成最终方案。5.3 给想直接上生产的同学加餐除了排查问题我再说一个真实项目里比模型更影响上线的环节超时和重试。大模型接口调用普遍比普通 HTTP 接口慢动辄几秒到几十秒。如果直接用默认的 HTTP 配置很容易遇到超时。我当时解决的方式非常简单给 RestClient 设置了连接超时和读取超时读取超时给了 60 秒。不要小看这个配置很多人上线后才发现生产环境的慢响应跟模型没半点关系纯粹是客户端等不起。另外对模型接口做重试也要格外小心因为大模型接口不是幂等的用户可能已经收到了一半回答你再重试一次就会重复生成。这种场景更适合做“断点续传”或“用户主动重试”而不是盲目自动重试。还有一点SSE 流式输出在企业场景里是非常容易被忽略的刚需。如果用户界面需要打字机效果后端必须用流式响应把模型输出的 event 不停推给前端。Spring AI 对 SSE 的支持很成熟但前端的 EventSource 和后端的响应格式必须测试对齐不然前端收到的数据总是少了最后一行。用几句真实体会收尾这篇文章从 Spring AI Alibaba 停更聊开到最后变成了一份 Java AI 落地的实操笔记。说到底我的想法很简单不要把“某个框架停更”当成职业危机也不要把“语言热度”当成技术准绳。Java 在 AI 时代的价值不在于追着热点跑而在于它足够稳能把模型能力真正变成业务流程的一部分——稳本身就是一种很难替代的优势。补充一个我近期的体会从 Spring AI 官方主项目新增的 Function Calling 和消息记忆机制入手可以试着把一个内部系统逐步升级成多 Agent 应用。这个过程里你会接触到工具调用、状态管理、并发编排这些硬核问题而它们恰好是 Java 后端的老本行。走完这一步你对“Java 还能不能做 AI”这个问题就不再需要任何人的答案了。