Spring AI 2.0 正式发布：Java 程序员必须关注的 8 个升级清单

这两年，Java 开发的风向变得很快。

以前大家聊 Spring Boot、Spring Cloud、微服务，现在越来越多公司开始问 AI 落地、RAG、Agent、工具调用和 MCP。

AI 应用开发，已经从「加分项」变成了「新标配」。

而就在最近，Spring AI 2.0.0 正式版本终于发布了。

历经 8 个里程碑版本、2 个候选版本之后，这个版本不再只是简单补几个模型、加几个 Starter，而是对整个 Agent 开发体系做了一次比较彻底的重构。

一句话总结：

Spring AI 2.0 的重点，不是让 Java 能调用大模型，而是让 Java 能更像样地构建 Agent 应用。

如果你现在还没认真看 Spring AI 2.0，这篇文章建议收藏。

我给你拆成 8 个重点，看完基本就知道这次升级到底值不值得跟了。

先看 Maven 依赖

Spring AI 2.0.0 正式版的 BOM 依赖如下：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.ai</groupId>
            <artifactId>spring-ai-bom</artifactId>
            <version>2.0.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

如果你之前已经用过 Spring AI 1.x，那么这次升级要重点关注底层依赖、配置结构、工具调用、MCP 集成等变化。

如果你还没用过 Spring AI，那反而可以直接从 2.0 开始学。

因为它的架构思路已经更接近未来 Java AI 应用的主流形态。

1、基础底座升级：Spring Boot 4 + Jackson 3

Spring AI 2.0.0 最明显的变化之一，是底层基础全面升级。

它把 Spring Boot 4 作为最低支持版本，并支持 Spring Boot 4.0.x 和 4.1.x。

这意味着什么？

意味着 Spring AI 2.0 可以直接吃到 Spring Boot 4 这一代框架的能力红利。

比如更现代的依赖体系、更清晰的配置模型、更强的可观测性支持，以及 Spring 生态整体向新一代基础设施迁移后的统一能力。

同时，Spring AI 2.0 也从 Jackson 2 升级到了 Jackson 3。

对于 AI 应用来说，JSON 处理不是小事。

因为大模型调用、结构化输出、工具参数、MCP 资源、RAG 元数据，很多地方都离不开 JSON 序列化和反序列化。

Spring AI 2.0 还补充了自定义默认 JsonMapper 的说明，并引入 JsonHelper 工具类，让复杂 JSON 场景的配置更统一。

这一条对业务开发的影响是：以后你做 AI 应用，不只是能调模型，而是能更稳地处理模型输出和工具输入。

2、空安全升级：JSpecify 全面引入

Spring AI 2.0 对整个代码库引入了 JSpecify 空安全注解。

这个变化看起来不如「Agent」「MCP」那么刺激，但对工程项目非常重要。

AI 应用天然会面对很多不确定输入：

模型返回可能为空；

工具结果可能为空；

配置项可能缺失；

上下文记忆可能不存在；

RAG 检索结果可能没有命中。

如果这些边界没处理好，项目跑着跑着就容易出现空指针问题。

引入空安全之后，哪些参数必填、哪些参数可选，会表达得更明确。

对于 Kotlin 用户来说，这一点尤其友好，因为 Kotlin 本身就非常重视空安全语义。

一句话：Spring AI 2.0 开始把 AI 应用开发当成严肃工程来做，而不是 Demo 框架。

3、配置体系重构：Options 更清晰了

Spring AI 1.x 中，随着模型越来越多、配置越来越复杂，不同实现之间难免会出现一些重复和不一致。

到了 2.0，官方对配置选项体系做了一次大规模重构。

重点有几个：

• • 必填配置和可选配置区分更明确；
• • 默认值统一放到 Options 层；
• • Options 全部使用 Builder 模式创建；
• • 创建后不可变；
• • Builder 支持统一的配置合并能力；
• • 配置项和配置属性进一步解耦；
• • 移除了配置文件中多余的 .options 层级。

这背后其实解决的是一个老问题：

当你接入多个模型时，配置到底应该由谁管？

是配置文件管？

是模型实现管？

是调用方动态传？

还是 ChatClient 默认补？

Spring AI 2.0 更明确地区分了 ChatClient 和 ChatModel 的职责。

ChatClient 是开发者更常用的高级 API，可以接受一些默认配置的补充；

ChatModel 更偏底层模型能力封装，需要更完整、更明确的配置。

这对企业项目很关键。

因为企业项目里最怕的不是不能跑，而是跑起来之后配置散落各处，出了问题没人知道到底是哪个参数生效了。

配置越清晰，AI 应用越容易走向生产。

4、模型生态收敛：少而精，而不是多而乱

Spring AI 2.0 还有一个很值得关注的方向：模型支持开始收敛。

官方现在重点聚焦这些模型生态：

• • OpenAI
• • Anthropic
• • Amazon Bedrock
• • Google GenAI
• • Mistral AI
• • DeepSeek
• • Ollama

其中，OpenAI、Anthropic、Google GenAI 等实现都做了统一，逐步收敛到基于官方 SDK 的实现方式。

这其实是一个很务实的选择。

早期框架为了快速扩展，通常会尽可能多地接各种模型。

但模型厂商 API 更新太快，如果每个实现都自己维护一套逻辑，很容易出现适配滞后、功能不一致、代码重复的问题。

直接基于官方 SDK，可以更快跟进厂商的新 API、新模型、新能力。

这也说明 Spring AI 2.0 的目标不是「我支持一切」，而是「我把核心生态支持好」。

对开发者来说，这反而是好事。

AI 框架拼到最后，不是看模型列表有多长，而是看核心模型能不能稳定、完整、快速跟进。

5、Agent 能力增强：工具调用循环进入 Advisor 链

这次 Spring AI 2.0 最核心的变化，我认为是 Agent 能力增强。

在 Spring AI 1.x 中，每个 ChatModel 内部都有自己的工具调用循环。

能用是能用，但问题也明显：

你很难统一拦截；

很难替换执行策略；

很难对每次工具调用过程做细粒度控制；

不同模型内部实现还可能不一致。

Spring AI 2.0 把 Tool Calling Loop 提升到了 Advisor 链中的最高优先级。

ChatClient 会把每次请求交给有序的 Advisor 链处理，并且支持循环，让 Advisor 可以重新进入下游链。

这套机制不仅能驱动工具调用循环，也能驱动结构化输出重试循环、评估循环。

这个设计很重要。

因为真正的 Agent，不是一次模型调用就结束。

它往往是：

思考一次；

调用工具；

拿到结果；

继续判断；

再调用工具；

最后生成答案。

如果这个循环藏在每个模型内部，框架就很难做统一治理。

如果它被抽到 Advisor 链里，开发者就有机会做拦截、增强、替换和编排。

这就是 Spring AI 从「模型调用框架」走向「Agent 基础设施」的关键一步。

6、统一工具调用：ToolCallingAdvisor 自动接管

在 Spring AI 2.0 中，ToolCallingAdvisor 会由 ChatClient 自动注册，并实现完整的工具调用往返流程。

以前分散在不同聊天模型里的临时工具循环被移除了。

这意味着工具调用能力变得更统一。

你不需要去关心某个模型内部到底怎么跑工具循环，也不需要担心不同模型实现差异太大。

如果你需要显式控制每次工具迭代，也可以选择退出自动模式，自己手动驱动循环。

这个设计兼顾了两类人：

一类是普通业务开发者，希望开箱即用；

一类是高级 Agent 开发者，希望能自己控制执行策略。

以前很多 Java 程序员做 Agent，会觉得 Python 生态更灵活。

但 Spring AI 2.0 这次其实已经在补这个短板。

工具调用统一之后，Java 写 Agent 才真正有了工程化底座。

7、海量工具支持：渐进式工具暴露

当 Agent 只有三五个工具时，把所有工具都塞给模型，问题不大。

但如果是企业级 Agent 呢？

比如你有文件工具、Shell 工具、数据库工具、工单工具、知识库工具、监控工具、部署工具、报表工具……

几十个、上百个工具同时暴露给模型，会发生什么？

第一，上下文爆炸；

第二，模型选择困难；

第三，调用准确率下降；

第四，成本上升。

Spring AI 2.0 新增了 ToolSearchToolCallingAdvisor，引入渐进式工具暴露机制。

简单理解就是：

不是每次请求都把全部工具塞给模型，而是先对完整工具集建立索引，需要时再让模型检索相关工具，然后按需增量暴露。

这对复杂 Agent 应用非常关键。

因为 Agent 一旦进入生产，不可能永远只有几个工具。

它一定会不断接入内部系统、外部系统、数据源、工作流和自动化能力。

工具越多，越不能靠蛮力塞上下文，必须靠检索和渐进式暴露。

8、结构化输出自修复：让 JSON 更可靠

结构化输出一直是 AI 应用里的高频需求。

比如你希望模型返回：

用户意图分类；

JSON 参数；

工单字段；

表单内容；

评估结果；

代码审查结论。

但大家都知道，大模型有时候就是不听话。

哪怕你要求它返回 JSON，它也可能多说一句废话；

哪怕你开启模型原生 Structured Output，它也可能返回不符合业务校验规则的数据。

Spring AI 2.0 引入了 StructuredOutputValidationAdvisor。

当结构化输出校验失败时，它可以触发修正流程，让模型重新生成结果。

这个能力看似细节，实际上非常实用。

因为在生产项目里，结构化输出失败不只是格式问题，它会直接影响后续流程：

工具调用参数错了，任务执行就错；

字段解析失败，业务流程就断；

校验不通过，自动化链路就卡住。

结构化输出能自修复，AI 应用才更接近可靠系统。

9、MCP 集成升级：Java 生态跟上标准协议

MCP，也就是 Model Context Protocol，现在已经越来越像 AI 工具集成领域的事实标准。

Spring 团队本身就是 MCP Java SDK 的官方维护者之一，所以 Spring AI 对 MCP 的支持一直比较积极。

Spring AI 2.0 集成了 MCP Java SDK 2.0.0，并兼容最新的 MCP 规范。

这次比较值得注意的是注解驱动 MCP 开发。

比如通过：

• • @McpTool
• • @McpResource
• • @McpPrompt

就可以把 Spring Bean 暴露成 MCP 服务能力。

同时还引入了统一的 McpSyncRequestContext / McpAsyncRequestContext 参数，方便在服务处理方法中获取日志、进度报告、采样和请求信息。

客户端侧也提供了更完整的声明式回调模型。

另外，WebMVC 和 WebFlux 的传输实现从 MCP Java SDK 移动到了 Spring AI 体系中，和 Spring 框架自身的发布节奏保持一致。

流式 HTTP 成为默认传输方式，STDIO 仍然适合本地进程集成。

对于企业来说，MCP 的意义很大。

因为它让模型和工具之间有了更标准的连接方式。

未来你接内部系统、接知识库、接运维工具、接办公系统，都不应该再靠一堆私有适配乱飞。

MCP 是 Agent 接入外部世界的重要标准，而 Spring AI 2.0 正在把它带进 Java 工程体系。

10、社区扩展加速：记忆、工具、Agent 组件都来了

除了官方能力，Spring AI 2.0 周边社区也开始补齐很多 Agent 组件。

比如 spring-ai-session 提供了基于事件溯源的会话记忆实现，可以替代内置 ChatMemory。

它支持多种消息类型、Tool Call 消息、上下文压缩策略，以及基于 LLM 的自动摘要。

这类能力在长对话和复杂 Agent 场景里非常实用。

再比如 spring-ai-agent-utils，提供了 Agent Skills、文件工具、Shell 工具、Web 抓取工具、任务管理、自动记忆等常见能力。

这些组件说明一个趋势：

Spring AI 不再只是官方框架自己在发展，社区也在围绕它构建 Agent 生态。

这对 Java 程序员非常关键。

因为框架能不能成为标准，不只看官方代码，还要看生态能不能长起来。

Spring AI 2.0 之后，Java Agent 生态开始有了更清晰的扩展方向。

一张图看懂 Spring AI 2.0

本次升级拆成 4 个象限：

• • 基础底座：Spring Boot 4、Jackson 3、空安全；
• • 模型与配置：模型生态收敛、Options 重构；
• • Agent 核心：Advisor 链、统一工具调用、海量工具；
• • 生态集成：MCP 2.0、结构化输出、社区扩展。

最后总结：这次升级，Java 程序员真要重视

如果只看表面，Spring AI 2.0 好像只是一次版本升级。

但如果你把这些变化串起来看，会发现它的方向非常明确：

它正在从大模型接入框架，升级成面向 Agent 开发的 Java 基础设施。

这次最值得关注的不是新增了多少模型，而是这些能力：

1. 1. Spring Boot 4 作为新底座；
2. 2. Jackson 3 强化 JSON 能力；
3. 3. JSpecify 带来空安全语义；
4. 4. Options 配置体系更清晰；
5. 5. 模型生态从多而散转向少而精；
6. 6. Tool Calling Loop 进入 Advisor 链；
7. 7. ToolCallingAdvisor 统一工具调用；
8. 8. ToolSearchToolCallingAdvisor 支持海量工具；
9. 9. StructuredOutputValidationAdvisor 支持结构化输出自修复；
10. 10. MCP Java SDK 2.0.0 集成，注解驱动 MCP 开发；
11. 11. 社区记忆、工具、Agent 组件开始丰富。

对个人开发者来说，这意味着你可以用更熟悉的 Java/Spring 技术栈去做 RAG、工具调用、MCP、Agent。

对企业项目来说，这意味着 AI 应用可以更容易接入现有 Spring 生态：安全、监控、认证、配置、WebMVC、WebFlux、可观测性，全都能复用。

所以我还是那句话：

2026 年的 Java 程序员，不能只会 Spring Boot，也要开始补 Spring AI。

AI 不会淘汰 Java 程序员。

但会 Spring AI、懂 Agent 落地的 Java 程序员，一定会比只会 CRUD 的 Java 程序员更有竞争力。

Spring AI 2.0 已经发布。

接下来，就看你什么时候开始动手了。

如果你已经在项目里用 Spring AI，欢迎评论区说说你踩过哪些坑。

如果你还没开始，也建议先从这次 2.0 的核心变化学起。

先把底座搞明白，再去做 RAG、MCP、Agent，后面会顺很多。