Spring AI 到了 2.0：Java 项目要不要现在接

先给结论：**Spring AI 值不值得现在接，取决于你手上有几处调用点、以及你有没有「模型要替我动手」这一格。**只有一两处补全文本的系统，接它省下的是几十行 HTTP，换来的是整个装配面；有多路调用、带工具、还要换供应商的系统，不接才是给自己找活。

这个判断我是从自己那条链路上算出来的。

发生了什么

公开报道集中在今年（GA 那一批消息落在 2026 年下半年刚开始）：Spring AI 推进到 2.0 这一大版本并 GA，MCP 原生集成在里面，不再靠外挂那层适配。它被讨论的位置通常挨着 Spring Boot 4.1 那一档——配套的几个小版本号各家文章对不齐，要落进构建文件的话以官方那一页为准（Boot 4 本身怎么迁不在这篇里说，见 Spring Boot 4 迁移）。

这里只取一个结论：大版本 GA 不等于你动它的时点到了，它等于从此可以按能力算账，而不是按风险算账。该问的不是特性清单，是个更老的问题：框架这一层买的是什么，不买的话自己写会写下什么。

我这一路的实情

本站前台那个助手就是 Java 侧接模型的样本。生产代码里调模型的地方是两处对话加一处出图：一处后台写作辅助（整段拿回答），一处访客助手（带工具）。调用面收成一层薄封装的两个方法 chat(messages)、chatWithTools(messages, tools)，底下压的就是 Spring AI 的 OpenAI starter，走 OpenAI 兼容协议；阻塞那一轨在根 pom 的 enforcer 里被禁掉，只留响应式，因为整个服务是 WebFlux 的。地址与模型名只从 spring.ai.openai.* 一处读，选哪家由 aryee.ai.llm.provider 定，两头取值同出一个环境变量 CMS_AI_MODEL；换上游动的是地址、密钥、模型名那三格 CMS_AI_ 变量，Java 文件不改。

**买到的三件事我都认为值。**协议与序列化：请求体形状、错误映射、流式帧的解析（这两路没上流式，要用时不必自己写）。这一块自己写一遍，就会变成谁都不敢碰的私有代码。function calling 的 schema 与回环：工具怎么声明、参数怎么落成 Map、多轮怎么接，比多数团队预估的费工。切换成本：只要对面说兼容协议，换一家就是换配置。

**没买到的那些才是重点。**下面四样是我这边真实写着、任何版本的框架都不会替我做的：

1. **超时是三档不是一个数。**访客等着的那一路 45 秒，写作辅助 60 秒，出图 150 秒——出图要等对面轮询完，卡在和对话同一档会把一次正常等待判成失败。框架给的是客户端超时，你要的是按业务路的等待预算。
2. 失败分两档，还要留台账。「这一档部署没接模型」和「这一句上游没答」是两个错误码，因为一个重试有救、一个没有；访客那一句先落库再问模型，答没答上都留一行。
3. **检索判据。**Spring AI 给了 embedding 与向量那一套抽象，本站把它显式关掉（spring.ai.model.embedding: none）：猜「先读哪一篇」用的是内存里的字二元组召回，过不了门限、或者头一名和后面那一篇拉不开，就一篇都不喂。门限是在本站真标题上量出来的，收紧它靠评测集。
4. **模型那只手接的是业务入口，不是数据库。**助手替访客递预约走的是页面那张表单同一个服务方法，五道守卫一道不少。框架知道怎么把参数递给模型，不知道你这台系统里谁能写。

还有一条反面：依赖一进 classpath，六类模型的自动配置条件全成立，而建 bean 第一步就验凭据，缺 key 直接把整个上下文带走。所以「这一档不用 AI」不能靠不给密钥，得按家关掉。自己写一条 HTTP 不会有这一格：框架给的不只你想要的那一条，它给的是一个装配面。

接框架 vs 自己写：哪一层谁负责

层	接框架之后还剩什么	自己写要写什么	一句话判据
协议与鉴权装载	给地址和 key，其余不用看	请求体、错误映射、各家差异	仓库里有几处裸 URL 片段
工具调用	schema 与回环，参数校验仍在自己手上	声明结构、多轮回环、参数落地	模型要不要替你动手改数据
流式	帧解析，端到端语义仍要自己定	SSE 读写、断流与重放边界	你现在有几路真需要流式
超时与重试	一个客户端级默认值	按业务路分档的等待预算	每路能等多久，你说得出来吗
失败转移与计量	不在这一层	也不该在应用层	放网关那层做，见 网关成了必选项
检索与预读	抽象和接口形状	判据、门限、喂不喂的决定	判据能不能被固定问题量出来
输出收口	全在你这边	全在你这边	前端按什么渲染就要抹平什么
装配面	一批模型的开关与启动风险	无，但也没有依赖升级	启动脚本容不容得下那几格关掉

模型答的那一句也要收口：提示词里禁过 markdown，它照样隔几条漏一个星号加粗，而前台窗口按纯文本画句子——落库前先用正则摘掉成对符号，再按码点截断。这一格两边都得自己写，最能说明框架帮不到哪一步。

MCP 是 2.0 最硬的卖点，而它是一条方向问题：把自家能力暴露给别人的 agent，或者反过来挂别人的工具。这两条今年都不在你的计划里，那这一项就是零，别拿它当跟的理由。

跟与不跟，各自的条件

现在就接，如果这四条中了三条以上：调用点两处以上；模型要替你动手；上游不止一家、或者已经挂在自建网关后面；没人愿意长期维护协议差异那段代码。四条同时成立时，自己写的那段会长成一个小框架，而维护它的只有你自己。

今年先不动，如果：全服务只有一两处「给一段文本、回一段文本」；模型跑在异步任务里，超时和失败由队列兜着；或者你的主体不在 Spring 上——那时候换语言侧的 SDK 比在 Java 里引一套装配便宜得多。

中间还有一条路：先不接框架，但把调用点收成一格接口——只有一处实现、只有一处能被替换。这一步花不掉半天，而它让「以后要不要接」变成一个随时可改的主意。

判据给四道，都能当场数：

1. 你们那套现在有多少处直接发 HTTP 调模型？搜一遍 URL 片段，数字比感觉可靠。
2. 换一次供应商要动几个文件？答案是零个、只动配置的话，你其实已经买过这个能力了。
3. 有几路调用需要不同的超时、不同的失败码？一路都不用，框架的超时抽象就是白给。
4. 模型有没有一格工具要写回业务库？没有，上面那半壁论证对你们暂时不成立。

一句收尾

框架层买的是协议、schema、依赖坐标这三样，买不到等待预算、失败分档、检索判据、业务闸门这四样——后者才是把模型接进业务系统真正费工的地方，而它在 2.0 和在手写之间没有差别。所以我的判据很简单：调用点两处以上、工具要动我的手，就接；只有一两处补全、没有手要动，就先自己写，把接口留好。今年的顺序是网关那层先立住，框架这层按调用点数决定，Boot 大版本按它自己那篇的排期走——三件事分开算，别让一次升级替你做另外两次决定。