早上在技术群里看到有人转发消息说Spring AI Alibaba已经停更了紧接着就有人抛出那句老话Java还有希望吗说实话过去一两年里我类似的话听了太多回从Python要抢走Java饭碗到AI时代只认Python工程师再到如今Spring AI Alibaba都停了Java彻底没戏。消息本身真假先放一边这种焦虑的情绪倒是很真实尤其是对正在学Java、靠Java吃饭的开发者来说心里不犯嘀咕才奇怪。但这篇文章我想换个角度聊清楚一个适配层项目停更到底能不能说明整个技术栈的存亡Java在AI时代的位置到底是什么以及我们这些靠Spring全家桶吃饭的人现在到底该做点什么。1. 停更传闻背后先别急着唱衰Java1.1 一条停更消息为什么会让开发者焦虑先把这个项目是什么说清楚。Spring AI Alibaba是阿里系开源的一个桥接项目作用就是把通义千问等大模型能力封装进Spring AI的统一抽象层让Spring Boot开发者可以用熟悉的编程方式去调用大模型。它天然带着官方背书的光环所以在Java开发者心里分量不轻一旦传出停更很多人第一反应是连阿里都不玩了Java配不上AI。但冷静下来想一个开源仓库不再活跃背后可能的原因有很多项目核心成员转岗了、商业公司战略收缩了、功能已经稳定进入维护模式了或者是Spring AI官方生态已经把同类能力收编了第三方适配项目的空间被压缩了。最后这种情况在开源世界里非常常见原生的统一适配已经足够好专门的桥接层自然就退居幕后。这恰恰说明生态在成熟而不是生态在衰亡。所以与其盯着某一条停更消息恐慌不如把问题拆开看Java能不能做AI应用用什么做做到什么程度。这几个问题搞清楚了心里就有底了。1.2 开源世界的停更不等于死亡再往深一层说开源项目的沉默和生态的终结从来不是一回事。一个具体仓库的更新频率受团队资源、商业节奏影响很大而一个技术生态的生命力要看它是否有足够多的替代方案和应用场景。就拿Java来说光是Spring Boot这几年在云原生、微服务领域的地位就说明这个生态还没有走下坡路。而且从时间线看Java生态面对AI这个大浪潮的反应并不慢Spring官方在2024年就正式推出了Spring AI项目一直在迭代社区里LangChain4j这些JVM实现也在快速跟上。这说明Java世界没有缺席AI缺的反而是很多开发者对现状的了解和正确的定位。2. 先认清事实Java在AI世界里到底处于什么位置2.1 训练场是Python的天下应用场却不是很多焦虑的来源是把两个完全不同的场景混在了一起。大模型本身的训练、微调、跑实验确实是Python生态的主场PyTorch、transformers这些库都在那边搞算法研究的工程师用Python顺手极了。但这是造模型的人的世界实际上全球靠这个吃饭的人加起来也没想象的那么多。绝大多数Java开发者平时根本不碰模型训练我们要做的是用模型。怎么用最成熟的姿势是调用模型服务把HTTP请求发到推理接口或者本地推理服务拿回结果。这套东西本质上是服务端开发恰恰是Java最擅长的事。请求管理、连接池、熔断、限流、重试、序列化、事务协调这些工程化能力Java生态打磨了二十多年论可靠程度说一句企业级标配并不夸张。换句话说AI应用开发的竞争点越来越不在模型本身而在模型的工程化落地。模型是别人的但把模型接进业务流程的人很可能是Java工程师。2.2 企业落地的最后一公里还是Java的地盘看一个更具体的场景一家传统行业公司想给自己的客服系统接入大模型问答能力。它的核心业务流程、客户数据、订单系统大概率跑在Java技术上数据库连接、权限控制、审计日志、监控告警全是现有系统的资产。这时候公司不会把Java系统推倒重来换成Python更合理的方案是在现有系统里加一个智能问答模块收到用户问题检索知识库调用大模型生成回答然后记录到审计日志。这个模块的骨架就是用Spring Boot搭起来的。谁最熟这个骨架当然是Java工程师。AI要落地最终一定要长在业务系统上而业务系统的主力依然是Java。这就是我说最后一公里是Java底盘的原因。模型推理跑多快那是算力的事能不能稳定地嵌进现有业务流程那是工程的事。这两件事后面那件往往是决定项目成败的关键。3. 盘点当前Java系的AI技术栈到底有哪些能打的3.1 Spring AI官方项目仍是第一选择先说Spring AI本身。它是Spring官方在2024年发起的顶层项目目标就是给Spring生态提供一套统一的AI应用开发抽象类似当年Spring Boot简化Web开发一样让人用相对标准的方式去对接大模型、做RAG、做Agent。Spring AI这几年的迭代节奏一直没停下来功能从最早的一个ChatModel接口调大模型一路扩展到了Prompt模板管理、输出解析、向量存储抽象、检索增强、对话记忆、函数调用、流式响应、可观测性这些硬核能力。换句话说它已经从玩具阶段进化到了生产可用阶段。就算某个第三方适配项目不再更新Spring AI官方依然支持通过标准接口对接各种主流模型商也支持自定义接入。对Java开发者来说Spring AI最大的价值在于你不需要学一套全新的技术还是那一套依赖注入、配置管理、REST风格的玩法。学习曲线很平滑这是它能成为Java AI应用开发首选框架的重要原因。3.2 LangChain4jJVM上的另一条路径如果说Spring AI走的是Spring官方路线那LangChain4j走的就是社区路线。这个项目的目标是在JVM上复刻LangChain的能力模型支持对话记忆、文档切分、向量检索、Agent等。它不绑定Spring用起来更灵活也可以跟Spring Boot集成。LangChain4j的模块划分很像Java社区的作风核心模块、模型提供方模块、嵌入模型模块、向量库模块各自独立按需引入。这样做的好处是依赖可控坏处是版本兼容性需要自己留心。我的建议是如果项目本身对Spring体系依赖不深或者希望用更接近LangChain的编程模型LangChain4j值得一试如果项目就是标准的Spring Boot全家桶那Spring AI的集成体验更顺滑。3.3 JVM侧还有很多被低估的AI基础设施除了上面两个框架JVM生态里还有一批实用的AI基础设施普通开发者不太关注但生产项目里很常用DJL可以理解成Java版的深度学习推理库训练体验不如Python但部署Java服务的场景里直接用它跑ONNX格式的模型做推理省掉独立推理服务的运维成本。ONNX Runtime很多传统企业做图像分类、文本分类时会把PyTorch模型转成ONNX再用Java调用这条路非常成熟。向量检索能力Java生态里不缺Redis、PostgreSQL的向量插件、Elasticsearch的向量检索都能胜任Spring AI已经抽象了VectorStore接口换起来不麻烦。本地模型部署像Ollama这类工具解决了本地跑一个开源模型的需求它对外提供HTTP接口Java这边用RestClient或者OpenAI兼容客户端就能接模型是Python训练的没关系Java调用的是接口。把这些东西串起来看Java侧的AI技术栈其实是完整的接入层有Spring AI、LangChain4j推理层有DJL和ONNX Runtime存储和检索层有各种向量库应用层还是我们熟悉的Spring Boot。缺的不是工具而是对工具的认知。4. 实操用Spring Boot快速接一个RAG问答能力4.1 环境准备与依赖引入先把最短链路跑通理论聊多了容易飘落地才是硬道理。我以一个真实改造过的模拟项目X为例演示如何在现有Spring Boot服务里快速加上一个基于RAG的问答接口。这个方案不是为了炫技而是追求最短路径让读者可以照着做。假设场景某内部运维知识库散落着一堆文档你想让员工通过自然语言提问自动从文档里找答案。第一步在pom.xml里引入Spring AI的模型依赖。我本地环境用的是Ollama部署的开源模型它对外提供OpenAI兼容接口所以引入OpenAI starter就行。dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId /dependency然后在application.yml里做最小配置把模型的base-url指到本地推理服务spring: ai: openai: base-url: http://localhost:11434/v1 api-key: ollama chat: options: model: qwen2.5:7b这里有个细节我必须说一下很多同学一看OpenAI starter就觉得必须用OpenAI的官方服务。实际上这个starter接的是OpenAI兼容协议只要推理服务提供的是兼容接口都可以对接。我用Ollama本地部署就是为了验证这种方式在生产内网环境的可行性实测下来很稳。配置好后注入ChatModel就能发起第一次对话了。4.2 一个最简的RAG链路检索加生成RAG的核心思想很简单不过度神话它用户提问前先把知识库文档切成小块转成向量存进向量库提问时把问题向量化找出最相关的几块文档最后把文档内容和问题一起交给模型让模型基于资料作答。在Spring AI里配置向量存储和文档加载的代码并不复杂。我把模拟项目X里的核心链路简化成如下逻辑Component public class SimpleRetriever { private final ChatModel chatModel; private final VectorStore vectorStore; public SimpleRetriever(ChatModel chatModel, VectorStore vectorStore) { this.chatModel chatModel; this.vectorStore vectorStore; } public String ask(String question) { // 1. 从向量库召回最相关的3个文档片段 ListDocument docs vectorStore.similaritySearch(question, 3); String context docs.stream() .map(Document::getText) .collect(Collectors.joining(\n---分割线---\n)); // 2. 把上下文和问题组装成提示词 String prompt 你是一名运维知识助手请只依据以下资料回答用户问题。 若资料中没有相关信息请明确说“当前资料中未找到”。 资料 %s 问题 %s .formatted(context, question); return chatModel.call(prompt); } }代码量不多但这就是一个能跑的RAG闭环。在实际的模拟项目X里我提前用文档读取器加载了一批运维手册切分成512 token的小块批量写入向量库然后写了个REST接口把上面的ask方法暴露出去。整个改造花了大概半天时间其中最耗时的是文档切分粒度的调整而不是框架本身的接入。4.3 生产化小改造流式输出与对话记忆能跑和能上线之间隔着一层工程化。模拟项目X上线前我发现两个明显问题第一大模型生成速度慢前端等一个完整回答体验很差需要流式输出第二用户追问时需要结合上文否则每次问答都是独立的显得很傻。流式输出在Spring AI里用StreamingChatModel接口配合SSE协议下发前端可以像Chat应用一样打字机效果PostMapping(value /ask-stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString askStream(RequestBody String question) { return streamingChatModel.stream(prompt); }对话记忆我用Spring AI提供的ChatMemory机制在Advisor层维护最近几轮对话的上下文。它的思路很像Spring里的过滤器或AOP请求进入模型前先拼接历史消息响应返回后把新内容写入记忆。这样做的好处是业务代码不用到处传历史消息记忆逻辑被集中管理了。上线后整个链路稳定跑了一个月效果满意。5. 容易翻车的细节与常见误区5.1 实操中的几个翻车点这一节必须写因为实现一个Demo和让它稳定运行是两个世界。我把自己和同行在类似项目里踩过的坑整理出来照着排查能省很多时间。第一个坑是上下文长度爆炸。对话记忆如果无限累加历史消息很快顶到模型的上下文窗口上限。解决办法是设定轮次上限或者用Token长度裁剪只保留最近N轮。模拟项目X我设定的是保留最近6轮对话超过就丢弃更早的消息实测效果和资源占用都能接受。第二个坑是向量库的选型和索引参数。很多人直接用内存实现上线后重启就丢数据这在开发环境无所谓生产环境必须换持久化方案。另外向量检索的相似度阈值一定要测阈值设太高召回太少答案经常是未找到阈值设太低垃圾内容混进来回答质量直线下降。我一般会拿标准测试集跑几轮把召回率和精确率的平衡点摸出来。第三个坑是模型调用的超时和重试控制。本地推理服务偶发超时很常见外部模型API更是可能限流。业务接口不能因为模型超时就把整个服务拖死必须在调用层加超时和降级。Spring AI本身有重试机制但我习惯在更上层再包一层RestClient的超时配置双保险。第四个坑是流式输出的连接管理。SSE连接在企业网关后面容易被断开客户端需要做心跳或者自动重连。有一次模拟项目X的上线演练中测试反馈回答到一半界面就卡住排查后发现是网关空闲超时。这个问题不大但排查起来费时间提前在架构评审里提出来更省事。第五个坑是文档切分的边界处理。直接按固定字符数切文档会把一个完整段落拦腰切断检索时召回的内容语义不完整。最好用基于段落或者语义边界的切分器至少保证切出来的每块内容相对完整。这个对问答质量的提升非常明显。5.2 三个常见误区该纠正就纠正误区一AI应用开发就是写提示词。提示词是入口但工程化才是主体。提示词之外你得搞定文档管理、数据清洗、权限控制、审计合规、模型降级、成本监控。否则就是拿一个Demo当生产系统迟早出问题。误区二既然做AI就该把老系统推翻重写。事实上多数AI能力的落地方式是增量式的像中间件一样嵌进现有服务老逻辑不用动。Spring AI的模块化设计就是为了支持这种渐进式改造。误区三Java工程师应该去学Python否则就淘汰了。这想法不太符合实际。企业里Python工程师通常负责模型实验和数据探索而Java工程师负责把模型变成产品功能。两条赛道都需要人关键看你想站哪边。我见过不少Java工程师靠出色的工程能力把AI功能稳定落地反而比只会调参的人更吃香。还有一个偏见要说一下Spring AI就是套壳没有技术含量。套壳也分层次漂亮话谁都会说真让你把一次大模型调用做得有熔断、有审计、有流量控制、有成本计量难的不是调用那一行代码而是围绕这行代码的整套治理框架。Spring AI的价值恰恰在这里它把这些工程要素沉淀成可复用的框架能力。6. 结合个人经验给Java开发者的三点建议6.1 别追新概念先把一条链路做穿面对铺天盖地的AI术语我建议新手别一上来就铺开学。最好的办法是像我上面的实操那样先用一个最小RAG链路跑通然后逐个环节深挖向量检索的召回排序怎么调优、提示词怎么根据业务沉淀、流式输出怎么做异常恢复。别怕链路小跑穿一条线你对整个AI应用开发的理解会比单纯看十篇文章都深刻。6.2 让AI能力成为一个模块而不是一个项目我最近看很多团队的失败案例问题出在把AI当作一个独立的智能项目来做和核心业务各玩各的。反过来说成熟的做法是把AI当作一个可嵌入的模块或中间层它可以被多个业务模块复用。模拟项目X就是这么做的先把文档加载、向量检索、对话记忆这些能力封装成内部服务再逐步接入到客服工单、知识问答、报表解释等多个场景。一次建设多处复用ROI才会高。6.3 保持对模型变化的敏感度但别被模型牵着走大模型圈子迭代非常快今天这个模型跑分高明天那个模型又出来了如果你的应用架构跟着模型走会疲于奔命。正确的姿势是像Spring AI这样把模型抽象成一个可替换组件具体用哪个模型通过配置切换。我个人的体会是对企业应用来说稳定的抽象层、优雅的降级策略、可控的成本比最新最强模型重要得多。Java开发者的未来从来不是被某个框架的一篇停更公告决定的决定它的是你在工程化道路上积累了多深的功底。只要企业软件还是Java的底盘只要AI还要落到业务流程里Java就有持续的空间。与其焦虑不如打开IDE把第一个大模型接口跑起来这种手感比任何热搜都管用。
