Spring AI 升级窗口到了：Jackson 3、MCP 包迁移与 CVE 修复要怎么一次过

Java

发布日期: 2026-03-29

导语：
截至 2026 年 3 月 29 日，Java 生态里最值得企业团队关注的一次版本动作，不是一个单点框架 patch，而是 Spring AI 在 3 月 17 日同时发布了 2.0.0-M3、1.1.3 和 1.0.4 三条线，并且明确带来了 breaking changes、MCP 相关包迁移、Jackson 2 到 Jackson 3 的升级，以及 CVE-2026-22729 和 CVE-2026-22730 的修复。这类更新最容易让团队做错一件事：只看“新功能有没有用”，忽略“升级路径本身有没有坑”。

1. 这次升级真正麻烦的地方在哪里

表面看，这只是一次常规发布。但从官方说明看，2.0.0-M3 涉及的变化很集中：

MCP 注解从社区包迁到 Spring AI core。
MCP transport 实现从 MCP Java SDK 迁到 Spring AI 项目自身。
Anthropic 集成切换到官方 Java SDK。
Jackson 2 全面切到 Jackson 3。
ToolContext 去掉对 conversation history 的依赖。

这些点里，最容易出问题的不是业务代码，而是周边生态：序列化配置、starter 自动装配、MCP 扩展、内部封装库、工具调用历史假设。只要团队内部做过二次包装，就不该把这次升级当成“升个 patch”。

2. 更稳妥的升级策略

我建议按发布线分而治之，而不是全员直冲 2.0.0-M3。

第一类团队，是已经在试验 MCP 和新 agent 架构的。
这类团队可以评估 2.0.0-M3，但前提是愿意承担 breaking changes 和 API 适配成本。

第二类团队，是已经上线 Spring AI 功能、但更看重稳定性的。
优先走 1.1.3 或 1.0.4，先吃掉 CVE 修复和稳定性修复，把风险控制住。

第三类团队，是还在 PoC 的。
别急着升到最新 milestone，先把目标能力和现有封装理清楚。很多团队升级太快，结果把一堆原本没必要碰的依赖一并打乱。

3. 推荐的实操流程

第一步，画依赖图。
梳理项目里所有直接和间接依赖 Spring AI 的模块，尤其是序列化、自定义 tool adapter、MCP server/client 封装。没有依赖图，升级失败后根本不知道先修哪层。

第二步，先编译不过，再谈运行。
MCP 包迁移和 Jackson 3 切换通常会带来明显的编译错误。不要急着靠 IDE 自动修复，把错误按类别归档：包名变化、类型变化、方法签名变化、配置项失效。

第三步，单独回归 JSON 和 tool 调用链。
Jackson 3 不是简单替换版本号。凡是涉及对象映射、序列化定制器、向量库 filter、工具结果封送的地方，都要回归。ToolCallAdvisor 的流式支持和 ToolContext 变化，也意味着你得重新确认历史上下文是怎么被传入工具的。

第四步，把安全修复和功能升级分开验收。
不要一边上新能力，一边混着验证 CVE 修复。建议建两组用例：一组验证兼容和功能，一组验证漏洞修补后的行为没有倒退。

第五步，灰度发布别离开 JVM 视角。
Spring AI 是 Java 应用的一部分，最终仍要落回 JDK、序列化、线程模型、HTTP 客户端、依赖注入。建议同时在 JDK 26 或当前生产基线上分别回放一轮，以免框架问题和运行时问题缠在一起。