听到 Spring AI Alibaba 停更的消息我正在给一个旧项目升级 AI 能力。说实话第一反应是愣住第二反应是完了Java 又要被人嘲讽一遍。这两年大模型的风头几乎全被 Python 生态抢去了Java 好不容易冒出一个能顺手对接大模型的 AI 应用开发框架怎么说停就停但等我静下心来把整件事的来龙去脉捋清楚之后反而松了一口气。这个组件停更并不代表 Java 在 AI 应用开发领域出局恰恰说明这条路已经走通了——官方的 Spring AI 框架已经接手模型生态开始分化Java 开发者的选型反而比之前更清晰。这篇文章不打算写长篇大论的情绪宣泄。我想把Spring AI Alibaba 停更这件事拆开看它为什么走到这一步停更后 Java 开发者还能走哪些路以及我实际把项目迁移到 Spring AI 官方框架后踩过哪些坑。如果你正在纠结Java 还有没有希望希望这篇能给你一个基于事实的答案而不是一个情绪化的结论。1. 停更消息背后大家到底在慌什么1.1 先回忆一下这个组件解决过什么问题Spring AI Alibaba 在 Java 生态里的地位一句话就能说清它让 Spring Boot 开发者可以用非常Java的方式调用大模型。在它出现之前Java 接入大模型的路子无非两种要么直接对着 HTTP API 手写封装要么引入 Python 服务再做一层 RPC。前者简陋后者别扭。它真正的价值在于把调用模型、管理对话上下文、做流式输出、注册工具函数这些高频需求整理成了可被 Spring 自动装配的组件开发者只需要写几行配置加一个注入点就能在业务代码里完成一次模型调用。它也顺带打通了阿里云百炼平台上的模型服务。对很多习惯了这套云生态的团队来说这是一条低门槛的接入路径。所以在停更消息传开之后我身边不少人的第一反应是我项目里依赖的组件是不是以后没人管了我的 AI 功能是不是要重写甚至有人开始认真考虑要不要转做 Python。1.2 组件停更和 Java 的前途其实是两个层面的问题恐慌的背后其实是 Java 开发者长久以来的集体焦虑。过去一年多社区里反复出现类似的论调AI 领域的核心工具全是 Python 写的招人全要 PythonJava 是不是已经退出 AI 牌桌了。这种情绪需要一个出口Spring AI Alibaba 的停更就成了那个出口。但把这两件事放在一起看就会发现逻辑并不成立。组件停更属于某个具体工具的生命周期结束Java 在 AI 应用开发里有没有位置则取决于业务系统集成大模型的需求是否真实存在。事实是这个需求不仅存在而且越来越大。企业不可能为了做一个客服机器人就把整个订单系统用 Python 重写更常见的方式是让现有 Java 服务去调用大模型 API把模型能力嵌入业务流程。这才是 Java 工程师真正的主战场。所以慌可以但慌的方向应该是我该选哪个新组件而不是我是不是该转行。2. 冷静拆解为什么 Spring AI Alibaba 会走到停更这一步2.1 官方框架与这套组件功能确实高度重叠任何开源项目的停止维护都先看它是不是还拥有不可替代的价值。Spring AI 官方框架从诞生起就把多模型支持当作核心卖点OpenAI、通义千问、智谱、Ollama 都在官方适配列表里。也就是说Spring AI 官方框架本身已经覆盖了 Spring AI Alibaba 的大部分能力包括统一的 ChatClient、流式输出、工具调用、结构化输出这些基础功能。两个功能高度重叠、服务对象又完全相同的项目放在同一个生态里结局基本是可以预见的维护者会优先保住覆盖面更广、社区更大的那个。官方框架的 issue 反馈更快、版本迭代更频繁、第三方教程更多Spring AI Alibaba 在功能上和社区热度上都渐渐失去了存在感。2.2 模型 API 的标准化让专门适配的价值被稀释再往深一层看模型接入层的格局也变了。过去每家平台的 API 风格都不同厂商 SDK 的价值在于为你屏蔽这些差异。但这两年OpenAI 兼容协议逐渐成为事实标准很多模型平台都直接提供了兼容端点。换句话说开发者只需要改一个 base-url很多代码几乎不用动。这一变化对生态组件是致命的。当一个组件的核心价值是为某个平台做适配而这个平台自己把适配层做成了标准协议时组件的存在理由就被上下两头同时挤压了上面有官方框架的统一抽象下面有平台自带的 SDK 和兼容接口。夹在中间的组件自然会走到维护停滞的状态。这是非常正常的技术生态现象和技术语言本身的优劣没有关系。2.3 开源维护的账不是一次性的代码贡献我见过不少对停更的误读以为停更等于项目烂尾或者背后有什么惊天秘密。其实绝大多数开源组件的停更只是维护者算了一笔精力账。开源项目发布之后要处理 GitHub issue、适配依赖升级、修复版本兼容、写文档、发 release。这些工作持续消耗维护者的时间。当贡献者的精力有限、项目的差异化价值又越来越小的时候把资源集中到更主流的项目上是再正常不过的决策。这里我不去猜测任何内部原因单看公开信息就能得出的结论是Spring AI 官方框架已经提供了平替能力迁移成本可控社区共识也在往官方框架集中。与其说这次停更是某个框架被抛弃不如说是一次项目组合的主动收敛。3. 今天 Java 开发者真正可以走的四条 AI 路线3.1 路线一Spring AI 官方框架最稳的主航道如果项目本身是 Spring Boot 技术栈我的第一推荐永远是 Spring AI 官方框架。它不像某些 AI 框架那样要求你改掉原有编程习惯而是完全顺着 Spring 的方式走依赖注入、自动装配、配置外部化、AOP 扩展这些 Spring 开发者熟悉的概念都能直接复用团队上手成本较低。能力上ChatClient 提供同步、流式、工具调用、多模态等多种交互方式Advisors 可以统一处理 Prompt 增强、上下文记忆、日志审计StructuredOutputConverter 能直接把模型输出映射成 Java 对象。这些都是企业级 AI 应用的高频需求官方框架已经做得比较完整版本迭代也足够快。对大多数只想在业务系统里接入模型能力的团队来说这是投入产出比最高的一条路。3.2 路线二LangChain4jAI 原生开发者的另一只手LangChain4j 是另一个值得认真考虑的框架。它在设计上借鉴了 LangChain 的组件化思路但用纯 Java 实现因此 Java 开发者不需要切换语言即可获得相近的开发体验。它内置的 AiServices、PromptTemplate、ChatMemory、RAG 管道、Tool Executor 等组件对做 Agent、RAG、复杂调用链编排这类 AI 原生应用特别友好。如果你要做的不是一个在订单系统里加个智能问答的集成场景而是一个以模型能力为核心、需要精细编排多步调用链的 AI 产品LangChain4j 的表达力可能比 Spring AI 更强。它也支持接入各类模型平台并且社区一直保持活跃。缺点是学习曲线略陡项目结构和 Spring 生态耦合不深部分功能需要自己额外适配 Spring 的事务、监控体系。3.3 路线三不引框架自己封装一个 ChatService这个选择容易被低估但它其实适合不少场景。大模型的 API 本质就是 HTTP POST 加 JSON 数据Java 的 RestClient 或 WebClient 完全能胜任。如果只是内部小工具、原型演示、或者团队对引入新框架有强约束自己封装一个 ChatService 是务实的选择依赖少、逻辑透明、出了问题能直接看到代码。代价也很明确。流式解析、自动重试、请求超时、上下文管理、费用统计、内容审计这些工程能力不会因为你少引入一个框架就消失它们会变成你自己要写的代码。我的建议是如果你当前的需求简单到只需要把 Prompt 发出去、把结果接回来自己封装没问题一旦开始频繁做流式输出和工具调用就该考虑回到框架上来。3.4 路线四直接用平台 SDK 直连第四条路是绕开 Spring AI 生态直接使用模型平台的 Java SDK。比如阿里云百炼平台、OpenAI 等都有自己的官方 SDK这类 SDK 的好处是能第一时间拿到平台新发布的能力比如最新的函数调用格式、推理参数、多模态接口等。如果团队对某个平台的服务依赖非常深几乎不考虑换厂家用它的 SDK 是最省心的路径。缺点也同样明显不同平台的 SDK 风格不统一命名习惯、回调方式、序列化方式都有差异。一旦后面想换模型平台这些差异都要靠自己的适配层来抹平。我的判断是这种方式更适合从零起步、深度绑定单一平台的场景不太适合那些模型切换频繁或需要统一接入多家的中大型项目。3.5 四条路线放在一起对比路线学习成本工程化程度模型切换成本典型适用场景Spring AI 官方框架中高低Spring Boot 企业应用、业务系统集成LangChain4j中高中中Agent、RAG 类 AI 原生应用自己封装 HTTP 调用低低中轻量内部工具、原型验证平台 SDK 直连低低高深度绑定单一平台、追求最新能力选型的时候不要只看框架的功能列表更要看团队的能力积累和项目生命周期。功能最全的框架不一定最适合你能让你和团队长期迭代不费力的才是好选择。4. 用 Spring AI 官方框架做一个可运行的对话应用4.1 项目初始化与依赖清单以 Spring Boot 3.x 为例。新建一个工程只需要引入 Web 模块和 Spring AI 的 OpenAI 兼容 Starter。下面这段依赖是当前比较典型的做法dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId /dependency之所以选择 OpenAI 兼容 Starter是因为现在大量模型平台都提供 OpenAI 兼容端点。这样一来无论你最终接的是哪家模型代码层面都不需要大幅改动只需要改配置。如果你手上的是老版本依赖注意核对 Spring AI 的版本兼容关系以 Maven 中央仓库里的实际版本为准就好。4.2 通过配置把一个模型平台接进来在 application.yml 里配置好 base-url、api-key 和模型名spring: ai: openai: base-url: ${AI_BASE_URL} api-key: ${AI_API_KEY} chat: options: model: ${AI_MODEL:gpt-4o-mini}这里的 AI_BASE_URL 需要替换为你所用模型平台的兼容地址。很多平台都提供 OpenAI 兼容协议你只需要把地址填进去。api-key 用环境变量注入不要写死在配置文件里这是基本的安全习惯。model 名称务必跟所选平台的实际模型 ID 保持一致比如有的平台叫 deepseek-chat有的叫 qwen-plus命名并不统一。这种配置方式其实藏着一个很实际的好处换模型平台的时候通常只需要改环境变量业务代码一行都不用动。我建议团队把这个当作默认约定把模型作为可替换资源来管理而不是绑定在某一家上。4.3 写一个流式对话接口核心代码非常简单一个 Controller 就能跑起来RestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient builder.build(); } PostMapping(value /chat, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString chat(RequestBody MapString, String body) { String message body.get(message); return chatClient.prompt(message) .stream() .content(); } }ChatClient 是 Spring AI 官方框架的统一入口Builder 由框架自动装配。这个接口返回 Flux 配合produces TEXT_EVENT_STREAM_VALUE前端可以按 SSE 格式接收流式数据实现打字机效果。相比一次性等待完整响应流式输出能显著降低用户的等待焦虑这也是目前对话类应用的标配体验。4.4 跑起来之后最容易踩的几个小坑第一模型名写错是最常见的问题。模型 ID 在不同平台、不同区域可能不一样调用前先到平台控制台确认你当前账号有权访问的模型列表。第二别忽略超时配置。大模型响应不像普通数据库查询那么稳定高峰期可能出现几十秒的等待甚至是错误码合理配置连接超时和读取超时避免把错误直接暴露给用户。第三关注上下文长度和 Token 消耗。对话一旦变长历史消息会把上下文窗口塞满费用也会快速上升建议对发送给模型的历史消息做窗口裁剪。第四错误码要分级处理比如限流类的暂时性错误可以做重试而鉴权失败类错误一定要立即暴露出来处理。这套最小可运行的骨架搭好之后再往上加 Function Calling、结构化输出、多轮记忆都是顺理成章的事情。先把链路跑通再逐步完善工程细节比一次性追求大而全会轻松很多。5. 我自己迁移时的真实体验和踩过的坑5.1 类与 API 的变化没有想象中那么可怕我实际做过一次从 Spring AI Alibaba 风格组件到 Spring AI 官方框架的迁移。最直观的变化是核心入口的统一。过去你要先构造一个平台相关的模型客户端再拿它去做对话调用现在所有功能都围绕 ChatClient 这个统一入口展开构造方式也改成了 Builder 模式。从使用感受上说这其实是变简单了只是刚开始找一个旧功能在新框架里对应哪个类需要花点时间。如果你是老版本迁移我建议不要一上来就对全部代码做替换而是先搭一个最小的 ChatClient Demo 把流程跑通再去逐个替换业务模块。这样每一步都有可验证的中间态排查问题会快很多。5.2 配置项的迁移要小心对照配置层的变化是最容易踩坑的地方。老组件风格的配置项和 Spring AI 官方框架的配置项并不完全对应。列举一下我迁移时做的对应关系旧配置项参考官方 Spring AI 配置项平台相关 api-keyspring.ai.openai.api-key平台相关 base-urlspring.ai.openai.base-url模型名配置spring.ai.openai.chat.options.model温度、最大 Token 等参数spring.ai.openai.chat.options.temperature 等如果你手头项目用的依赖版本较旧配置项名可能不完全相同最稳妥的办法是去看对应版本 jar 包里的配置元数据或者直接搜索代码中的spring.ai前缀。宁可多花十分钟确认也不要靠记忆硬写配置写错通常会报出非常抽象的错误排查起来反而更浪费精力。5.3 函数调用和结构化输出需要重新适配老组件里用过的函数调用能力在官方框架里的写法发生了变化。Spring AI 官方框架支持通过 Tool 注解标注一个 Java 方法让它作为工具供模型调用这种写法更符合 Java 开发者的直觉也不用自己去解析模型返回的工具调用参数了。结构化输出同理。官方框架提供了 StructuredOutputConverter可以把模型返回的 JSON 直接映射到强类型对象上。迁移的时候原先手写 JSON 解析和字段映射的逻辑可以大部分删掉这也是为什么迁移完之后我发现整体代码量反而减少了。代码量减少这种事在重构中并不常见一旦遇到通常说明你走的方向是对的。5.4 迁移后我删掉了一批补丁代码还有一个体会值得分享旧组件时代为了绕过框架限制或补齐某个不支持的场景我写了不少补丁代码比如手动维护上下文、自己处理流式消息切分。迁移到官方框架后这些补丁里的大部分都失去了存在必要因为框架的抽象层已经覆盖了这些能力。删掉它们之后项目的可读性提升了一个档次。所以说停更这件事带来的最坏结果并不是项目要重写而是项目终于有机会改用一条更主流、更健康的路线。迁移过程中遇到的问题是暂时的迁移完成后的维护体验提升却是长期的。6. 回到最初的问题Java 还有希望吗6.1 Java 在 AI 应用开发里的真实位置我接触过很多焦虑的 Java 开发者他们说到底还是在纠结一个问题AI 时代我手里的技术栈还值不值钱。我的答案是值但你要找对位置。AI 应用开发通常可以拆成三层模型训练与微调推理服务和业务系统集成。第一层几乎被 Python 主导第二层也开始被各类推理框架和模型服务化工具占据但第三层——把模型能力接进真实业务系统、处理权限、事务、监控、稳定性——这一层恰恰是 Java 的主场。绝大多数企业的 AI 落地都不是从训练一个模型开始的而是从把现成的模型能力对接到业务流程开始的。客服工单分类、合同信息抽取、智能搜索引擎、报表的自然语言查询这些都是 Java 服务加一个模型 API 就能完成的活儿。做这些事不需要你把 Java 扔掉去学 Python你真正需要补充的是 AI 应用设计的思维方式。6.2 不同情况的团队我的建议不一样如果你的团队主力是 Spring Boot 技术栈业务形态以企业系统为主那直接选 Spring AI 官方框架把它当成主航道投入产出的确定性最高。如果你正在做一个以 Agent、RAG 为核心能力的 AI 产品可以考虑 LangChain4j它对调用链编排和上下文管理的表达更灵活。如果只是内部小工具自己封装一个 HTTP 客户端完全够了不必为了用框架而用框架。如果公司大量使用了某平台的云上能力那就用它的官方 SDK 往上堆业务换取最快的功能跟进速度。这里我格外想提醒一句框架选型只是技术决策别把它上升到信仰层面。以我们平时遇到的问题复杂度来看绝大多数业务场景下这几个框架拉不开质的差距真正拉开差距的是团队的工程能力和对模型行为的理解。6.3 比选框架更重要的事其实不在框架里最后说一个容易被忽略的点。过去两年我观察到一个规律不管项目用的哪个框架最终做出来的 AI 功能好不好用更多取决于团队对模型能力边界的理解取决于 Prompt 设计取决于有没有一套可靠的评测集来持续验证效果。框架解决的只是怎么调用模型的问题而调用了以后到底得到什么这个问题框架帮不了你。Java 开发者不需要焦虑式转行。更值得做的是把语言和框架的争论放到一边去理解你选的模型擅长什么、不擅长什么去搭建针对真实业务场景的评测集去设计能够兜底和纠错的产品流程。这些能力不会因为某个组件停更就失效它们才是你在 AI 时代真正值钱的部分。我自己现在的工作习惯是每接到一个 AI 相关的需求先不急着选框架先做两件事一是把模型能力边界列清楚二是把最核心的 Prompt 原型跑通。框架的选型往往放到第二步才做因为这时候我对需求的理解已经足够支撑我去判断一个技术方案的成本。也建议你下次再听到类似Java 完了的消息时先冷静问一句说出这句话的人是真的评估过技术选型还是只是被恐慌情绪推着走。技术判断这件事从来不应该靠情绪来定。