前阵子社区里都在议论某个国产 Spring AI 扩展包停更的事说实话刚看到这个消息的时候我也愣了一下。这个扩展包一度被看作 Java 接入大模型最顺手的路径之一依赖一引、配置一写就能把对话补全、向量检索、工具调用接到 Spring Boot 项目里。现在它不维护了很多 Java 开发者的第一反应是——Java 在 AI 时代是不是又输了一次我的判断恰恰相反这反而是 Java 开发者重新思考 AI 集成方式的好时机。这篇文章不灌鸡汤我会结合自己迁移一个内部知识库机器人的真实经历聊聊 Java 做 AI 开发到底还有没有戏以及框架停更之后项目该怎么选、怎么落地。1. 先别急着唱衰停更消息意味着什么1.1 这套框架当初解决了什么问题在它出现之前Java 开发者接大模型的体验并不好。虽然各家模型厂商基本都提供了 HTTP 接口但落到 Spring Boot 项目里时你仍然要自己处理一堆脏活用 RestTemplate 或 WebClient 拼 JSON手动组装 system 和 user 消息处理 SSE 流式输出面对不同厂商的接口差异写适配代码想在对话里加工具调用还得自己维护函数声明格式。这套国产扩展包的核心价值就是把这些重复劳动收敛成一套 Spring Boot Starter。它把大模型交互抽象成了几个非常“Spring 味”的组件ChatModel 负责对话补全EmbeddingModel 负责向量化VectorStore 负责向量检索还有统一的 Prompt 模板和工具调用抽象。对当时大量已经使用 Spring Boot 的后端团队来说这几乎是零成本上手。只需要在 classpath 里加一个依赖在 application.yml 里配置好模型服务的地址和密钥然后像注入普通 Service 一样注入对应的 Model 接口就可以开始写业务了。这种设计在当时是很有吸引力的。它本质上是在复刻 Spring 生态最擅长做的事情把复杂的中间件访问能力封装成可声明式使用的 Bean。对于习惯了 Spring 的开发团队这比直接读大模型厂商的 API 文档要友好得多。所以停更消息传开后大家担心的不是少了一个工具包而是“我们之前围绕它写的代码现在往哪放”。1.2 停更引发哪些连锁反应停更的直接后果有三层。第一层是依赖安全开源组件停止维护后新爆出的 CVE 没人修复代码扫描工具会把风险等级标得很高。第二层是兼容性停滞Spring Boot 和 JDK 都在按自己的节奏升级扩展包不跟着升级过不了多久就会遇到版本冲突、方法签名过期这类问题。第三层是社区内容的时效性网上一堆教程和 Demo 都是基于老版本写的新项目照着做很容易踩到废弃 API。但这里有一个容易被放大的点很多项目其实只用了这个框架非常浅的一层能力。大部分业务场景无非就是调用对话接口、拼一段 Prompt、把结果返回给前端真正用到高级 RAG、工具调用、Agent 编排的项目并没有那么多。浅层使用意味着迁移成本并没有想象中吓人换个实现方案改动范围通常能控制在一个 adapter 包里面。我见过不少团队遇到这种事后第一时间想把项目推倒重来或者干脆跳去用 Python 重写服务。这种冲动可以理解但大多没有必要。框架停更应该被看作一个架构信号而不是技术路线的判决书。它提醒我们AI 应用开发框架还很年轻选型时不能把身家性命押在任何一个短期热门项目上。1.3 为什么“Java 不适合 AI”的声音总会冒出来这波唱衰 Java 的论调和过去几年其实没太大区别。一个原因是 Python 在机器学习社区的先发优势太明显训练框架、论文复现、算法工程师的日常工具链几乎都围绕 Python 展开导致很多人形成了“AI 就是 Python”的刻板印象。另一个原因是 JVM 本身的重感Spring Boot 应用启动慢、内存占用高、依赖树复杂和 Python 那种脚本式起手体验形成鲜明对比。但我们需要把“训练模型”和“构建 AI 应用”分清楚。如果你要做大模型预训练、微调、强化学习这些偏底层的算法工作Java 确实不是主力语言很难撼动 Python 的地位。但绝大多数企业要做的不是训练模型而是把现成的模型能力接入业务系统。这种 AI 应用开发涉及用户权限、数据隔离、事务处理、系统监控、灰度发布全是 Java 后端最成熟的能力。换句话来说模型可以跑在别人提供的服务上但能把模型和公司内部数据、业务流程安全地连接起来这活儿 Java 生态是撑得住的。2. Java 在 AI 时代的基本盘比想象中稳2.1 企业级系统的存量优势是最大护城河一个容易被忽略的事实是绝大多数公司的核心业务系统依然跑在 Java 上。订单、支付、库存、用户中心、权限体系、数据报表这些系统经年累月积攒的稳定性和业务复杂度不是用 Python 写几个 AI Demo 就能替代的。AI 要真正产生价值就必须和这些系统深度对接而不是在外部单独搭一套技术栈。举个例子我参与过的内部知识库项目最初也想把服务单独拆出去用 Python 写。结果一落地就发现不对知识库里的文档权限要和公司统一身份系统打通搜索记录要写入审计日志调用量要和内部计费系统对齐。如果不借助 Java 生态里现成的认证框架、ORM 和消息队列这些事情都要重新造一轮轮子时间和成本都很高。在这种背景下Java 开发者的位置很微妙AI 模型本身不是我们提供的但 AI 应用怎么在现有企业土壤里长出来往往需要我们这些后端开发来搭桥。桥搭得好不好取决于对 Spring 生态、并发模型、分布式事务这些基本功的掌握程度而不是会不会写 Python。只要企业级 Java 存量还在Java 在 AI 应用层就有基础盘。2.2 LLM 应用开发的真正难点不在语言很多人以为写一个 ChatGPT 壳子就是 AI 开发其实站在应用层看调用模型只是最外面的一步。真正花时间的是数据处理、效果优化和稳定性保障。以企业知识库问答为例难点根本不在于“调用 ChatGPT 的 API”而在于怎么把 PDF、Word、数据库里的内容转换成适合检索的文本块怎么设计向量化的批处理任务怎么设置合理的相似度阈值避免召回一堆垃圾内容怎么评估系统升级后回答质量是变好还是变坏。这些问题和语言没有半点关系。你完全可以在 Java 里实现一套稳健的文档解析管线用异步任务批量生成向量把召回结果缓存在 Redis 里再配合一套回归评测脚本每次调整 Prompt 后自动跑一批测试问题。这些都依赖工程能力而工程能力恰恰是 Java 社区最不缺的东西。框架停更是损失了一个便捷封装但没有伤到 Java 做 AI 工程化的根基。另外大模型厂商对外提供的核心接口现在基本都有 Java 版本或者至少是标准 HTTP REST 接口。无论官方 SDK 是否好用作为 Java 开发者我们手里始终握着 WebClient、RestClient 这些基础武器。最坏的情况下直接照着 API 文档手写一个客户端工作量也不至于失控。2.3 Java/AI 工具链现状盘点停更一个扩展包不代表没有替代品。Spring 官方自己也在推进一套 AI 相关项目重点是让 Spring Boot 开发者可以用统一的 ChatClient 接口接入不同模型厂商。它依然提供对话、Prompt 模板、结构化输出、工具调用这些常见能力并且和 Spring Boot 的配置体系、自动装配体系契合度更高。如果你不想离开 Spring 生态这条路是比较平滑的。另一个活跃的选项是 LangChain4j它为 JVM 开发者带来了类似 LangChain 的抽象包括 ChatLanguageModel、EmbeddingModel、ContentRetriever、工具调用等概念。相比 Spring AILangChain4j 的编排能力更强对 Agent、多轮对话、链式调用这类场景支持更多社区更新频率也比较可观。除这两类框架外还有几类值得留意的底牌Deep Java Library 适合做模型推理和部署ONNX Runtime 的 Java API 可以在某些场景下跑量化模型各大模型厂商基本都提供了 Java SDK 或兼容 HTTP 调用向量数据库普遍提供 Java 客户端。把这些工具摊开看Java 的 AI 工具链虽然不如 Python 花哨但做企业级落地是够用的。关键是选型时不要只看名气要用自己的场景去卡能跑通闭环的才是有效的方案。3. 框架停更之后项目该怎么走三条迁移路线3.1 路线一转向活跃维护的 Spring AI 官方模块如果你的团队熟悉 Spring Boot现有代码大量使用注解和自动装配最平滑的迁移方向是替换成 Spring AI 官方模块。它保留了 Spring 的风格你依然可以定义一个配置类用 Bean 声明语言模型客户端再把 Prompt 模板做成 SpEL 模板文件业务代码里注入 ChatClient 使用。这种方式的主要优势是学习成本低。原来用扩展包的开发者大部分心智模型可以直接平移过来模型被封装成 BeanPrompt 由模板管理向量库通过 VectorStore 接口访问。迁移时通常只需要调整依赖坐标、修改少量配置项然后把代码里的旧 Client 类型替换成新接口。缺点是 Spring AI 本身发展也快API 偶尔会出现调整建议升级前仔细看 release note。这里要提醒一句Spring AI 官方模块面向的模型厂商很多接入层做了适配但不同厂商的能力边界不同。你的业务如果重度依赖某一家特有的函数调用方式迁移前需要先在测试环境把核心场景过一遍别等到上线那天才发现某个参数不生效。3.2 路线二用 LangChain4j 替换把 Spring 当成 Web 壳LangChain4j 是我这次迁移最终选择的方案原因是它把模型交互抽象得更轻同时提供了更丰富的编排原语。它不强制你按 Spring 的方式组织代码但你完全可以把它塞进 Spring Boot 项目里把 Spring 当作普通的 Web 框架来用把 AI 逻辑放在独立的 Service 层。核心概念并不复杂ChatLanguageModel 对应一个可对话的模型实例Message 是消息的不可变描述Tool 注解用来标记可被模型调用的 Java 方法ContentRetriever 用来和向量库对接。你不再需要关心底层 HTTP 调用细节也不用自己拼 JSON 格式的系统提示词代码的可读性会比手写回调高一个台阶。如果你之前的系统用了很多定制 Prompt迁移时可以把 Prompt 模板抽取成资源文件再结合 LangChain4j 的 PromptTemplate 加载。迁移过程中比较费劲的是工具调用部分模型调用的方法签名、参数描述和 Java 方法里的类型要逐一对齐。这部分没有太多捷径只能靠用例回归慢慢磨。3.3 路线三不上框架直接封装大模型 HTTP 接口有些项目很适合不上任何 AI 框架尤其是只使用一两家模型厂商的基础对话能力、没有复杂 Agent 编排需求的场景。直接用一个 WebClient 封装 REST 接口把请求体、鉴权、超时、流式响应统一处理总共可能只需要几百行代码却拥有最高的可控性。我见过有的团队嫌弃框架太重最终选择这种方式项目里只依赖 Jackson 和 Spring Web 模块自己定义 ChatCompletionRequest、ChatCompletionResponse 数据类SSE 用 Flux 接收工具调用则直接按厂商文档传送 JSON Schema。优点是没有任何中间层出事可以直接从 HTTP 层排查不存在框架更新把代码改坏的烦恼。缺点是所有底层细节都要自己扛比如模型服务返回格式变化、限流策略、错误码归类维护成本会随业务复杂度的上升而上升。这个方案特别适合两类人刚接触大模型开发、想搞清楚原理的初学者以及业务极其稳定、只对接一个固定模型服务的老项目。它不能算是退步反而是一种很有性价比的架构。3.4 三条路线怎么选成本、风险与场景对照选型没有标准答案但可以用一张表把关键差异摆出来对照着看。我根据自己使用过的项目管理经验整理了下面这个选型参考你可以把它当作讨论时的起点而不是最终结论。维度Spring AI 官方模块LangChain4j自封装 HTTP 接口学习成本低熟悉 Spring 即可快速上手中需要理解新的抽象概念高需要自己处理协议细节功能完整度高覆盖对话、Prompt、向量、工具调用较高编排和 Agent 设计更强低能跑通但高级能力要自己造框架锁定风险中跟随 Spring 生态节奏中API 版本演进较快低依赖的是标准 HTTP 接口社区活跃度高有官方团队持续迭代高开源社区更新频繁不依赖社区内部维护适合场景以 Spring Boot 为主的企业项目需要对模型做复杂编排的中型项目单厂商、低复杂度、强可控需求如果项目里几乎没有 Agent 编排只是把大模型当增强搜索或表单辅助选 Spring AI 官方模块最省心。如果要做多轮对话、动态选择工具、串联多个模型LangChain4j 是更顺手的选择。如果团队里没有精力维护抽象层同时业务调用场景非常固定自封装 HTTP 接口是一种能保底的做法。说到底选型的核心指标不是哪个框架名气大而是哪个方式让团队最容易维护、最容易排障。4. 迁移实操复盘把一个内部知识库机器人搬到 LangChain4j4.1 迁移前的系统长什么样我碰到的这个项目是一个内部知识库机器人约两万行左右的 Java 代码主要功能是让员工通过聊天形式检索公司制度、项目文档和客户资料。原系统基于 Spring Boot 搭建使用的那套扩展包提供了 ChatClient、EmbeddingModel 和向量存储抽象整体结构看起来是清晰的一个 ChatRecord 保存会话上下文一个 KnowledgeRetriever 从向量库召回相关资料一个 PromptService 拼接提示词最后调用模型把结果返回给前端。但真正动手迁移时发现代码里到处散落着对旧框架类型的引用。比如有的地方直接用了 ChatMemoryStore 接口有的地方把向量库的 Document 对象直接当业务对象用。这些隐式依赖比依赖坐标替换麻烦得多因为它们意味着业务代码已经和框架对象产生了深度耦合。所以迁移第一步不是改 pom 文件而是先把框架相关的类型从业务代码里剥离出来。4.2 迁移的五步关键操作第一步是替换依赖。把原来停更扩展包的依赖注释掉换成 LangChain4j 的核心包和适配具体模型厂商的模块。以 Maven 项目为例改动大概长这样dependency groupIddev.langchain4j/groupId artifactIdlangchain4j/artifactId version1.0.0-beta1/version /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-open-ai/artifactId version1.0.0-beta1/version /dependency需要注意的是 LangChain4j 的版本号更新频繁beta 版本之间的 API 有可能变化建议不要追新选一个经过验证的版本锁住。第二步是统一模型入口。我在项目里定义了一个应用层接口比如 AssistantService把“回答问题”和“流式输出”作为两个方法暴露出来内部再去调用 ChatLanguageModel。这样业务层只依赖我们自己定义的接口和底层框架彻底隔开。public interface AssistantService { String answer(String question, String context); FluxString streamAnswer(String question, String context); }第三步是重写 Prompt 组装。原来 Prompt 大量使用字符串拼接阅读和修改都很费劲。我用 LangChain4j 的 PromptTemplate 把提示词挪到了资源文件里传参时用 Map 绑定变量这样比较清晰。第四步是接入工具调用。迁移前旧框架里有一部分功能是让机器人查询员工考勤系统和会议室状态这部分需要模型动态决定是否调用 Java 方法。在 LangChain4j 里只需要在 Spring Bean 的方法上加上 Tool 注解并给出描述框架会把 Java 方法描述转成模型可理解的 JSON Schema。第五步是回归测试。这个步骤最枯燥也最值钱。我们把历史问题整理成一组测试集包含需要知识库检索、需要工具调用、需要截断上下文等十几种场景每次改动后自动跑一遍对比回答是否仍然包含关键信息点。4.3 必须收藏的踩坑清单整个迁移过程中有几个坑值得专门写出来。第一个坑是流式输出里的线程模型。LangChain4j 的 stream 方法返回 Flux响应是异步的如果在 doOnNext 回调里直接做数据库写入或远程调用容易把事件循环堵住。我最初在回调里记录用户日志结果高并发测试时出现明显卡顿后来改成把原始 token 先收集到内存缓冲区等流结束再统一落库。第二个坑是工具调用参数不匹配。模型返回的参数是 JSON 字符串如果 Java 方法参数名和 JSON 字段不一致或者类型对不上工具调用就会静默失败。排查方式是打开框架的 debug 日志把模型返回的 function call 消息打出来逐字段比对。最好的防御方式是工具方法的参数对象不要用大而全的 POJO尽量用基础类型组合。第三个坑是超时处理。模型服务偶尔会变慢默认超时时间可能不够。我在配置里显式设置了连接超时和读取超时并且加了简单的重试策略。但重试要小心幂等性比如查询类工具可以放心重试下单、审批这类操作就不要自动重试否则容易产生重复动作。第四个坑是向量库的索引重建。旧框架和新框架对向量文档 ID 的生成规则不一样直接复用原来的向量数据可能导致检索结果错乱。我们当时没注意上线后机器人的回答质量突然下降查了半天发现是 embedding 批次对不上。解决办法是清洗原向量库用新框架重新灌数据成本不低但结果干净。5. 经过这轮迁移我给 Java 开发者的三点建议5.1 让 AI 模块可替换不要被框架绑架这次迁移给了我们一个非常强烈的体感框架可以被替换但真正麻烦的是业务代码里的框架痕迹。如果从一开始就定义好应用层接口把模型的模型、Prompt、向量库全部封装在独立的 AI 模块里停更风波最多就是改一个 Maven 依赖和几十行配置而不会波及整个业务系统。设计时可以参考适配器模式面向业务定义一套稳定的语义接口比如“回答用户问题”“检索相关文档”“执行指定工具”底层实现交给具体框架去完成。这样即便是从 LangChain4j 换到 Spring AI或者再换到自封装 HTTP 调用都只需要重写适配器包业务代码基本不动。这个习惯在 AI 框架快速迭代的今天比任何选型技巧都重要。5.2 把非模型能力当成核心竞争力模型能力本身是外部提供的各家模型在通用问答上的效果差异会越来越小真正拉开差距的是谁能把模型接好、用好、评估好。我越来越觉得Java 开发者应该把精力放在那些和模型无关、却决定业务效果的能力上文档怎么解析和切分召回策略怎么调优输出格式怎么校验成本怎么统计。举个例子同一个知识库用同样的模型A 团队做了文档结构的层级切分和标题增强B 团队只是按固定长度盲目切块最后问答效果可能差出好几个身位。这些能力不依赖任何前沿论文更依赖的是对业务的理解和扎实的工程基本功。Java 生态在排障、监控、测试领域有非常多成熟工具这些都是 AI 应用稳定性的保障。5.3 关注 JVM 本身在 AI 场景的演进框架停更并不代表 JVM 停滞Java 生态这些年也在为 AI 场景做一些底层改进。虚拟线程让高并发、IO 密集的 LLM 调用变得便宜过去用异步回调硬撑的并发模型现在可以用同步写法实现更好的吞吐。GraalVM 可以缩短冷启动时间对部署在边缘场景或 Serverless 环境里的 AI 应用很有价值。我的建议是别把目光只锁在 AI 框架上也要关注 JVM 自身的版本演进。JDK 21 之后的 LTS 版本带来了很多实用的并发和内存改进但在实际开发中还有大量团队停留在老版本上这其实比框架停更更容易埋下隐患。存量系统如果一直卡在 JDK 8哪怕换了新 AI 框架能用的并发手段也有限长期看会越来越吃力。6. 回到最初的问题Java 还有希望吗6.1 唱衰者和支持者各自手里有哪些论据唱衰者的论据并不是完全没道理。Python 在 AI 领域的生态厚度短期无法撼动大部分模型发布后首先支持的是 Python SDK新框架、新概念的原型代码也几乎都是用 Python 写的。Java 在工具链新鲜度上确实落后半拍尤其是 Agent 相关的开源项目活跃度差距明显。支持者的论据则集中在工程落地上。模型能力本身正在逐步标准化HTTP 接口和 OpenAI 兼容协议成了事实标准这意味着 Java 调用模型的成本在下降。企业 AI 系统需要身份认证、权限控制、灰度发布、可视化监控这些正是 Java 生态最强的地方。模型越成熟应用层越需要稳定可靠的工程底座Java 的价值反而会更突出。6.2 框架停更不等于生态终结我们得客观看待开源框架的生命周期。AI 应用层还处在很早期的阶段今天很热门的框架过两年被新方案取代是常态。某个具体扩展包停更只能说明它完成了阶段性任务或者它的形态不再适合当下需求不能用来推断整个 Java 技术路线有问题。Spring 生态里也有过不少组件从炙手可热到归于沉寂但 Spring 整体依然活跃。真正值得关注的不是某个框架是否继续更新而是标准接口是否开放、业务代码是否可迁移、团队是否具备独立解决底层问题的能力。只要这三条是肯定的换框架只是一个普通的重构任务而不是伤筋动骨的大事。Java 生态的耐受力过去十几年已经反复验证过了一次 AI 扩展包停更远到不了生死存亡的程度。6.3 我的个人判断把话说得更直白一点短期内 Java 会被 AI 替代这个命题我是不相信的。企业级系统的维护和升级需求依然庞大懂 Spring 生态、懂分布式架构、又愿意去研究大模型接入方式的开发者在市场上反而更值钱。框架停更带来的不是“Java 没希望”而是一次清洗让那些纯粹靠封装吃红利的项目退场让真正理解业务和模型交互的人浮上来。我个人在这次迁移里最大的体会是焦虑往往来自对未知的恐惧真正动手把代码迁完之后发现事情比想象中简单。如果你还在犹豫要不要继续深耕 Java我的建议是不要因为一个停更公告改变方向而是去弄清楚你的项目到底依赖了框架的哪些能力那些能力换成另一种实现需要多少工作量。大多数情况下答案都是可控的。最后分享一个小技巧无论你最终选 Spring AI、LangChain4j 还是自封装 HTTP 接口都把 Prompt 模板和评测用例当成一级资产来沉淀单独建目录维护。框架换了一次又一次模板和评测才是你业务知识库真正的护城河。下次再有人跟你说“Java 不行了”你可以心平气和地打开自己的评测报告用结果说话。