Spring AI 2.0.0 在 6 月 12 日正式发布，到现在已经两个半月。知乎热度是肉眼可见的：光知乎上，近半个月就冒出来将近二十篇 Spring AI 相关文章，写 mall 系列的大 V macrozheng 也下场发了篇《Spring AI 2.0太香了》的实战。
但点开评论区，是另一个画面。知乎上阅读最高的那个问题不是"怎么用"，而是"为什么要用"：“为什么要使用springai？感觉没什么必要，python用的好好的，为什么要用java?”，一个问题攒了超过十万阅读。知乎一边说，公司主系统全是 Spring Boot，为了接一个大模型难道用 Python 重写？另一边说，AI 生态就是 Python 的天下，Java 别来凑热闹。
不站队，先说结论，可能有点反直觉：Spring AI 2.0 值得用，但你能不能上，跟 AI 没关系——取决于你的项目还停在 Spring Boot 哪一代。
Spring AI 2.0 想做的不是"模型适配器"
要理解 2.0，先理解它为什么把自己的 API 掀了。
1.x 时代的 Spring AI 本质是一堆 SDK 集合，一家模型厂商一个适配层。2.0 官方定位变了：它想做 Java 生态的"AI 原生运行时"，官方给它的身份是 Spring 生态面向 AI 领域的扩展，目标是让 Java 开发者像用 Spring MVC、Spring Data 一样自然地构建 AI 应用。知乎社区有个类比很到位：就像你用 JDBC 写数据库访问，不关心底下是 MySQL 还是 PostgreSQL，以后写 AI 能力也不用关心底下是 DeepSeek、通义还是 OpenAI，ChatClient 就是那个统一入口。设计上落地为三件事：ChatClient 取代 ChatModel 成为面向业务的主 API，工具调用从模型内部抽出来变成链上的一等 Advisor，MCP 跟进 2025-11-25 新规范、Streamable HTTP 成为默认传输。
先看一个跑起来是什么样。有知乎作者用 Spring Boot 4.1 + Spring AI 做了个电商客服：模型不知道你店里卖什么、卖多少钱，写一个查商品的方法标上 @Tool，顾客问"USB数据线多少钱"，模型自己去查数据库再组织回答——价格是表里写死的，不是模型随口编的。知乎
先看 9 个破坏性变更，挑跟你有关的
野心的代价是不兼容。有知乎作者把官方 Upgrade Notes 里三十多条变更归纳成了 9 个破坏性变更，社区对这次升级的概括相当狠：“如果你把这个版本当成普通的 1.x → 1.y 升级，编译报错会教你做人”。知乎
基线上跳。这是最硬的一条：Spring AI 2.0 要求 Spring Boot 4、Spring Framework 7、Jackson 3。Jackson 3 不是改个版本号，包名从 com.fasterxml.jackson 换成了 tools.jackson，自己写过几百行 ObjectMapper 定制的，这段跑不掉。
ChatModel 不再是主角。1.x 时代还直接 new OpenAiChatModel 手写调用循环的，这次必须换成 ChatClient。官方态度很明确：ChatClient 给业务用，ChatModel 给框架作者用。
模型接入大扫除。spring-ai-openai 成了对接所有"OpenAI 兼容 API"的唯一入口，DeepSeek、通义、GLM 都从这儿走；Azure 前缀没了，OCI Generative AI 移交 Oracle 维护。好消息是国内接 DeepSeek 的用户，base-url 配置方式没变。
工具调用坑最多。原来藏在 ChatModel 里的工具调用循环，2.0 自动注册成 ToolCallingAdvisor——你在 1.x 手动加过的会变成重复注册、执行两次；internalToolExecutionEnabled 开关则被直接删掉。
默认值静默变化。Anthropic 默认 maxTokens 从 500 跳到 4096，默认温度被移除。依赖"默认短回复"做超时假设的代码，行为会变，这类坑编译不报错，跑起来才知道。
配置扁平化。spring.ai.openai.embedding.options.model 这种俄罗斯套娃式的嵌套层级全部压平，.options 段没了，升级前记得对 application.yml 做一次全文搜索。
剩下的 Options 不可变化、MCP 生态换血、对话记忆重构，属于用到才会碰、照着文档能改的。社区已经有人做了 1.x 与 2.0 的逐条迁移对照图，升级时可以对着过一遍：
真正的门槛：AI 选型和升级债纠缠在一起
有意思的部分来了。Spring Boot 3.5.x 今年 6 月正式结束开源支持，3.5 及更早的 3.x 版本不再收到社区安全补丁和 Bug 修复。知乎也就是说，大多数 Java 团队账面上都摆着同一件事：Boot 必须升。而 Spring AI 2.0 偏偏要求 Boot 4——两笔债纠缠在了一起。
我把社区的信息整理成三类人，对号入座。
第一类：还在 2.x，或者 3.0—3.4。 迁移路径是 2.x → 3.x → 4.0，中间隔着 javax 到 jakarta 的命名空间迁移、JDK 从 8 到至少 17 的版本升级，外加整条依赖链更新，工作量不小。知乎我的建议是：别为了 AI 去升 Boot。AI 需求先用 LangChain4j 或直接 HTTP 调模型 API 交付，Boot 迁移单独立项，等站上 4.x，Spring AI 2.0 可以无缝接回来。另外提醒一句，Spring AI 1.x 同样要求 Boot 3.x，2.x 用户连 1.x 都上不了。
第二类：已经在 3.5。 最纠结的一批，两条路。保守路：用 Spring AI 1.x 先把 AI 业务交付了，Boot 和 Spring AI 2.0 留到同一个升级窗口一起升，只折腾一次回归。激进路：直接 4.x + 2.0，但得把那 9 个破坏性变更逐条过一遍。别忘了 Boot 4.0 自己也有坑，虚拟线程从 3.2 的可选实验特性变成了推荐默认值，原来精心调过的线程池参数可能全部失效。知乎两个大版本升级叠在同一个发布窗口，风险是乘法不是加法。
第三类：已经上了 Boot 4，或者纯新项目。 没什么可犹豫的，直接上 Spring AI 2.0。加个 Starter、配个 Bean、注入 ChatClient，三步就能让 AI 在项目里跑起来，流式输出一行 stream() 返回 Flux，跟 WebFlux 天然一体。
对话记忆也是现成的：Spring AI 支持内存、JDBC、Neo4j、MongoDB、Redis 等多种记忆存储，按团队现有的中间件情况选就行。知乎
那什么时候 LangChain4j 更合适
有位两边都踩过的作者给了个很实在的对比：流式输出这块，Spring AI 一个 ChatClient、一个 stream() 一行搞定，返回的就是 Flux，跟 Spring WebFlux 天然一体。知乎
但如果你要的是 RAG、多工具调用、快速迭代这种"框架深度"，LangChain4j 目前更成熟——AiServices、对话记忆、检索链路是一整套，Spring AI 还在追。知乎他那句话值得抄进备忘录：选型不是看哪个功能多，是看你最痛的那个场景它顺不顺。拿最痛的场景跑半小时 demo，比读十篇对比文更有手感。
还有一条国产路线提一句：模型以通义系为主、深度用阿里云的团队，Spring AI Alibaba 可以并列评估——阿里的技术栈就是 Java，他们暂时是不可能放弃的，这个框架的对接成本会更低。微博
最后，把值得盯的信号列清楚
Spring Boot 4.1 的正式版节奏。截至 8 月，最新补丁版本是 4.0.7，4.1.0-RC1 已经发布，社区教程已经在 4.1.0 上跑。知乎4.1 默认开虚拟线程，会改变 AI 服务的性能模型，这个坑我们之前已经写过，别等线上 P99 报警才想起来。
Spring AI 2.0 的 OpenRewrite 自动化配方。官方已经为 MCP 相关的三类变更提供了 recipe。知乎后续会不会铺开到其他破坏性变更，直接决定升级成本的天花板。
MCP 废弃 SSE 传输之后的生态迁移进度。还在用 SSE 的，宜早不宜迟。
Boot 4.0 的开源支持只到今年 12 月，观望中的团队，窗口在收窄。
最后说给还在犹豫的人。"为什么用 Java 做 AI"能有十万阅读，不是因为它有标准答案，而是国内大量业务系统就是 Java 写的，不可能为了一个 AI 都用 Python 重新写一遍。微博Spring AI 2.0 未必成熟，但它是 Spring 官方第一次把"AI 接进存量 Java 系统"当成一个需要统一运行时来解的问题。值不值得花时间，取决于你对号入座的是上面哪条路。唯一确定的是：Boot 3.5 的支持已经停了，这笔债不会自己消失，与其被两头分别拖着走，不如并进 AI 选型里一次算清楚。
