Spring AI 进入 M5 之后，Java 团队该把模型接入层彻底收口了

Java

发布日期: 2026-05-05

导语：
到 2026 年 5 月 5 日，Java 方向最值得工程团队动手消化的一组变化，集中在 Spring 生态。4 月 27 日，Spring AI 发布 1.0.6 / 1.1.5 / 2.0.0-M5；4 月 23 日，Spring Boot 3.5.14 发布并集中修复一批安全问题；4 月 17 日，Spring Framework 6.2.18 与 7.0.7 继续把修复往 Boot 线传递。单看这些版本号，像普通升级新闻。真把 release notes 摊开，你会发现一个更值得重视的趋势：Java 团队做 AI 应用时，模型接入层必须开始主动收口，不能再让 provider 差异散落在业务代码里。

Spring AI 2.0.0-M5 这次最关键的，不是“又加了几个模型”，而是它果断做了不少清理：Azure OpenAI 模块、Vertex AI 模块、ZhipuAI 集成、OCI GenAI 集成都被移出主仓库或转为新路径，spring-ai-openai 则全面切到官方 openai-java SDK。这个信号已经很明确了：团队不该继续把各家模型接入当成一堆平铺直叙的 starter，而应该把真正稳定的抽象边界收紧到自己的平台层。

1. 为什么这次升级值得认真看

Java 企业项目很容易形成一种习惯：先把能用的 starter 都接上，等后面再慢慢抽象。放在普通数据库或消息队列集成里，这种做法还有缓冲空间；放在 AI 这一层，风险会大得多。因为 provider 变化比大家想的快，官方模块的进退也比传统中间件更频繁。

Spring AI M5 这次直接给了几个提醒：

某些 provider 不再适合继续放在主仓库。
官方 SDK 的收敛会影响配置和调用方式。
旧的 options merge 思路也在调整，combineWith() 取代之前一些更散的合并逻辑。

这不是语法层的小改动，而是在提醒你：模型接入边界如果不干净，升级会越来越痛。

2. Java 团队最常见的几种坏味道

第一种，是业务层直接感知 provider 差异。
Controller、Service 甚至 Job 里充满 if (provider == ...) 这样的分支，或者直接拼各家私有参数。短期看起来灵活，长期就是维护灾难。

第二种，是把 provider-specific 配置散落到多份 YAML。
今天试 OpenAI，明天试 Azure，后天又接别的模型，配置越加越多，最后没人知道哪些还在生效。

第三种，是把 Prompt、memory、tool calling 和 provider 初始化绑在一起。
一旦换 SDK、换模型、换区域，整条链都要动，测试面会爆炸。

如果你在项目里已经能闻到这些味道，M5 这次正好给了你一个重构窗口。

3. 一套更稳的 Spring AI 收口办法

第一步，先建立统一的模型访问门面。
不要让业务代码直接 new 各家 ChatModel。哪怕底层仍然依赖 Spring AI，也应该在你自己的应用里包一层标准接口，把输入、上下文、工具参数和返回结构收束住。

第二步，把 provider 配置集中到单一模块。
无论是 OpenAI、Azure OpenAI，还是未来其他供应商，都让一组配置和装配逻辑负责。业务模块只看抽象，不看供应商。

第三步，明确“可迁移配置”和“业务配置”的边界。
模型名、endpoint、timeout、重试、区域这些都属于可迁移配置；业务模板、领域术语、输出格式这些才属于业务配置。两者混在一起，后续换模型会异常痛苦。

第四步，升级前先清 provider 依赖。
Spring AI M5 已经把一些集成从主仓库移出，这恰好逼着团队审视：这些 provider 是不是应该继续保留？是否需要切到新仓库？哪些其实只是历史试验代码？

第五步，把安全修复和 AI 升级一起做。
Spring Boot 3.5.14 和 Framework 6.2.18 修掉的 TLS hostname verification、弱 PRNG、临时目录、DevTools secret comparison 等问题都不是边角料。AI 应用常常本来就接很多外部端点和敏感配置，不该把这批安全修复视为和 AI 无关的普通升级。

4. 一套可执行的迁移顺序

如果你现在维护一个用 Spring AI 的 Java 服务，我建议按这个顺序来：

先升级 Spring Boot / Framework 到受支持修复版本。
梳理项目里直接引用的 Spring AI provider 模块，列出哪些已迁移、弃用或准备移出主仓库。
把 openai-java 相关变化消化掉，重点检查自定义参数、tool choice、extra body 这类容易受 SDK 切换影响的部分。
针对 combineWith() 和配置合并逻辑跑回归，确认默认参数没有悄悄变化。
给每个模型接入路径补一层 contract test，验证相同输入在不同 provider 下最关键的行为是否稳定。

这一步里我最推荐补的是 contract test。很多 Java 团队测试做得不少，但 AI 接入这层反而只做 happy path。实际上 provider 升级最怕的不是完全报错，而是半隐性的行为漂移。

5. 怎么判断你的收口做得够不够

我通常会问三个问题：

换一个 provider，业务代码要不要改？
升级 SDK 或 starter，影响是不是能局限在平台层？
出现模型或区域切换时，能不能通过配置和回归快速完成替换？

只要这三个问题里有两个答不上来，说明接入层还没收住。

6. 结语

5 月 5 日这波 Java 相关新闻真正有价值的地方，不在于版本本身，而在于它再次提醒团队：AI 接入不该是一片散装集成。Spring AI 进入 M5，Spring Boot 和 Framework 又连着补安全修复，正是把模型接入层收口、把 provider 差异赶出业务代码的好时机。等模型供应商和官方模块再变几轮，谁边界做得干净，谁后面就会轻松很多。