最近 Spring 生态最值得关注的两条主线是：Spring Boot 4.1 继续补齐生产级基础设施，Spring AI 2.0 则把重点从“能接模型”推进到“能构建可组合、可校验、可观察的 Agent 应用”。
如果你最近还停留在 Spring Boot 3.x + Spring AI 1.x 的使用习惯里，那么这一轮更新值得认真看一下。它不是简单的版本号变大，而是在把 Java 应用接入 AI 的方式往工程化方向推。
简单说：
- Spring Boot 4.1 更像是一次生产底座升级，重点在 gRPC、观测、HTTP 客户端安全、Spring Batch MongoDB、懒加载 JDBC 连接、依赖升级和若干安全修复。
- Spring AI 2.0 更像是一次架构重整，重点在 Boot 4 / Framework 7 基线、统一工具调用、Advisor 链、自纠错结构化输出、模型提供方收敛和更清晰的配置 API。
下面按开发者最容易用到的角度梳理。
Spring Boot 4.1：更关注生产系统的“边角功夫”
Spring Boot 4.1.0 已在 6 月 10 日发布。从 release notes 看，它不是一个只堆新 starter 的版本，而是把很多生产系统里的细节问题往前收了一步。
1. gRPC 进入 Boot 原生支持范围
Spring Boot 4.1 开始提供编写和测试 gRPC server/client 应用的支持。它支持独立的 Netty gRPC server，也支持 Servlet 集成，把 gRPC 暴露在 HTTP/2 之上。
这件事的意义在于：如果团队里已经有 Java 微服务、内部 RPC、服务间调用或跨语言调用诉求，以前可能会在 Spring Boot 应用旁边自己拼 gRPC 配置，现在可以更多依赖 Boot 的自动配置和测试支持。
对于 Spring 开发者来说，这会降低两个成本：
- 本地开发和测试的接入成本；
- Spring 配置模型、依赖管理和 gRPC 运行时之间的磨合成本。
它不意味着所有 REST 接口都要改成 gRPC，但对内部高频调用、强契约接口和跨语言服务来说，Boot 4.1 之后可以更自然地纳入 Spring 技术栈。
2. HTTP 客户端增加 SSRF 防护能力
Boot 4.1 新增了 InetAddressFilter 相关能力，阻塞式和响应式 HTTP 客户端都可以通过它拦截特定地址，帮助应用降低 SSRF 风险。
这个更新放在今天很现实。很多应用已经开始让 AI Agent、工作流、插件系统或动态配置去访问外部 URL。如果应用里有“根据用户输入抓取 URL”“根据模型输出调用接口”“根据 webhook 自动拉取资源”的逻辑，那么 SSRF 不再只是安全团队嘴里的抽象风险。
这类能力最好前置到公共 HTTP 客户端层，而不是散落在每个业务方法里手写黑名单。Boot 把它纳入客户端配置后，团队可以更容易建立统一规则。
3. 观测能力继续增强，OpenTelemetry 更顺手
Boot 4.1 对观测链路做了不少增强，包括：
@Async方法上下文传播；- Kafka、RabbitMQ 等组件的 observation convention 自动应用；
- OpenTelemetry SDK 开关、采样器、Span/Log limits 等配置；
- 支持读取更多 OpenTelemetry 环境变量；
- OTLP exporter 支持 SSL bundle；
- OTLP metrics 支持 compression 和 exemplars 相关能力。
这类更新看起来没有“新功能”那么刺激，但对线上系统很有价值。尤其在 AI 应用里，一次请求可能经过 HTTP 接入、模型调用、工具调用、数据库、消息队列和异步任务。如果上下文断了，排查问题会非常痛苦。
Boot 4.1 的方向很明确：让可观测性更像默认能力，而不是每个团队自己拼装。
4. Spring Batch 可以把 JobRepository 放进 MongoDB
Spring Batch 很长时间里默认假设 JobRepository 存在关系型数据库里，因为它需要记录 job、step、execution、状态和重试信息。
Boot 4.1 新增了 Spring Batch + MongoDB 的自动配置，并提供对应 starter。官方示例里，一个批处理任务可以把 Batch 元数据写入 MongoDB，同时把业务数据写入 PostgreSQL。
这对两类团队比较有用：
- 业务数据或平台基础设施本来就在 MongoDB 上；
- 批处理只是系统的一部分，不想为了 Batch 元数据额外维护一套关系型数据库。
需要注意的是，MongoDB 侧通常要满足事务要求，例如官方示例里使用了单节点 replica set。也就是说，它降低的是 Spring Batch 接入 MongoDB 的配置成本，不是取消了 Batch 对一致性和持久化的要求。
5. JDBC 连接可以懒获取
Boot 4.1 新增了 spring.datasource.connection-fetch 配置，支持 eager 和 lazy。设置为 lazy 时，自动配置的连接池 DataSource 会包装成 LazyConnectionDataSourceProxy，只有真正执行 JDBC 语句时才从连接池取物理连接。
这对某些事务方法很有帮助。有些代码会开启事务，但在某些分支下并不会访问数据库。过去事务开始时就可能拿连接，现在可以把连接获取推迟到真正需要时。
它不是万能性能开关，但对连接池压力、复杂事务分支和高并发服务来说，值得在压测环境里验证。
6. 依赖基线整体前移
Spring Boot 4.1.0 同步升级了一批 Spring 项目版本，例如：
- Spring Framework 7.0.8
- Spring Security 7.1.0
- Spring Data BOM 2026.0.0
- Spring Integration 7.1.0
- Spring Kafka 4.1.0
- Spring Batch 6.0.4
- Micrometer 1.17.0
- Micrometer Tracing 1.7.0
- Reactor BOM 2025.0.6
第三方依赖也有大量升级，包括 Hibernate、Kafka、MongoDB Driver、OpenTelemetry、Netty、Jetty、Kotlin、Mockito 等。
如果你的项目依赖范围比较广，升级 Boot 4.1 不应该只看“能不能启动”，还应该重点回归：
- 数据访问层；
- 安全认证与授权；
- HTTP 客户端；
- 消息队列；
- observability 配置；
- native image 或 AOT；
- 测试框架和构建插件。
Spring AI 2.0：从“模型集成”走向“Agent 框架”
Spring AI 2.0.0 GA 在 6 月 12 日发布，随后官方又连续发了工具调用和结构化输出的专题文章。结合来看，这一轮变化的核心不是“又支持了几个模型”，而是把 Spring AI 的内部架构往 Agent 应用需要的方向重做了一遍。
1. 基线切到 Spring Boot 4 / Framework 7
Spring AI 2.0 面向 Spring Boot 4.0 / 4.1 和 Spring Framework 7.0 设计。这意味着如果你要完整使用 2.0 的新能力，项目技术栈也要跟着进入 Boot 4 这一代。
如果现有项目还在 Boot 3.5.x，短期可以继续关注 Spring AI 1.1.x 维护版本。官方在 6 月 12 日同时发布了 Spring AI 1.0.9 和 1.1.8，用于仍在旧基线上的项目修复问题。
所以这里的升级判断很简单：
- 新项目、实验项目、AI 原型：优先看 Spring Boot 4.1 + Spring AI 2.0。
- 存量 Boot 3.x 生产项目：先评估 Boot 4 迁移成本，再决定是否上 Spring AI 2.0。
- 只需要小修小补：关注 1.1.x 维护版本，不要为了追新强行迁移。
2. ChatClient 成为更核心的使用入口
Spring AI 2.0 更强调 ChatClient 作为常用 API，ChatModel 更像底层构件。
这和 Spring 生态的风格是一致的：应用层代码尽量围绕一个更稳定、更可组合的客户端 API 编写，底层模型实现可以随着 OpenAI、Anthropic、Google、Ollama、DeepSeek 等提供方变化而调整。
如果你之前直接围绕某个 ChatModel 做了很多封装，迁移到 2.0 时建议重新审视边界：哪些逻辑应该放在 ChatClient、Advisor、Tool 或 Converter 层，哪些才是真正跟模型供应商绑定的代码。
3. 模型提供方支持更收敛
Spring AI 2.0 对核心支持的模型提供方做了收敛，官方列出的核心 chat model providers 包括：
- OpenAI
- Anthropic
- Amazon Bedrock
- Google GenAI
- Mistral AI
- DeepSeek
- Ollama
其中 OpenAI、Anthropic、Google 等实现进一步向官方 SDK 收敛。这样做的好处是更容易跟上模型 API 的新能力，比如原生结构化输出、工具调用扩展、缓存参数和厂商特有选项。
代价是：一些模型或存储的支持会更多转向社区扩展或厂商协作维护。对企业项目来说，这反而是好事，因为核心模块更稳定，边缘集成更容易按需选择。
4. 工具调用被提升为 Advisor 链中的一等能力
Spring AI 1.x 也能 tool calling，但每个 chat model 内部各自维护工具调用循环。问题是你很难观察中间步骤，也很难把工具调用和记忆、审计、重试、评估等逻辑组合起来。
Spring AI 2.0 把工具调用提升到 Advisor 链里，由 ToolCallingAdvisor 负责完整的工具调用循环。模型返回 tool call 后，Advisor 执行工具，把结果追加进上下文，然后继续调用模型，直到模型不再要求调用工具。
这带来几个实际好处：
- 可以更清楚地控制工具调用发生在哪里；
- 可以观察每轮工具调用；
- 可以和 memory、logging、evaluation、structured output 等能力组合；
- streaming 和 blocking 调用都能覆盖；
- 不同模型之间的工具调用行为更统一。
定义工具的方式也很 Spring：
class WeatherTools {
@Tool(description = "Get the current weather for a given city")
public String getWeather(String city) {
return weatherService.fetch(city);
}
}
然后通过 ChatClient 显式传入：
String response = ChatClient.create(chatModel)
.prompt("What's the weather in Amsterdam?")
.tools(new WeatherTools())
.call()
.content();
对 Java 团队来说，这比“在 prompt 里让模型自己猜接口格式”可靠得多。工具就是应用代码的一部分，有类型、有 schema、有描述，也能被测试和审计。
5. 大量工具场景下支持渐进式工具披露
Agent 一旦进入真实业务，很容易遇到“工具太多”的问题。几十个工具还好，上百个工具全部塞给模型，既浪费 token，也会增加模型选错工具的概率。
Spring AI 2.0 引入 ToolSearchToolCallingAdvisor，思路是先为工具集建索引，然后让模型按需检索相关工具，而不是每次请求都暴露所有工具。
这对企业 Agent 很关键。一个内部 Agent 可能同时连接工单、代码仓库、知识库、CRM、数据库、告警平台和部署系统。真正可用的系统不能只靠“把所有工具丢给模型”，而要能做权限、检索、分组和渐进披露。
6. 结构化输出支持自纠错和厂商原生约束
这是最近最适合写实战教程的一项能力。
Spring AI 一直支持：
ActorsFilms films = chatClient.prompt()
.user("Generate the filmography for a random actor.")
.call()
.entity(ActorsFilms.class);
也就是让模型输出符合 Java 类型的内容，再解析成 record 或对象。
但真实项目里，LLM 输出经常会漂移：少字段、多字段、类型错、套了 Markdown code fence、返回了一段解释而不是纯 JSON。Spring AI 2.0 给了两个新开关。
第一个是 validateSchema()：
ActorsFilms films = chatClient.prompt()
.user("Generate the filmography for a random actor.")
.call()
.entity(ActorsFilms.class, spec -> spec.validateSchema());
它会在解析前做 schema 校验。如果模型输出不符合要求，Spring AI 会把具体错误反馈给模型并重试，默认最多 3 次。这个机制由 StructuredOutputValidationAdvisor 支撑。
第二个是 useProviderStructuredOutput()：
ActorsFilms films = chatClient.prompt()
.user("Generate the filmography for a random actor.")
.call()
.entity(ActorsFilms.class, spec -> spec.useProviderStructuredOutput());
它会尽量使用模型厂商原生的结构化输出能力，把 schema 作为 API 级约束传给 provider，而不是仅仅在 prompt 里告诉模型“请按 JSON 输出”。
两者还可以组合：
ActorsFilms films = chatClient.prompt()
.user("Generate the filmography for a random actor.")
.call()
.entity(ActorsFilms.class, spec -> spec
.useProviderStructuredOutput()
.validateSchema());
这在下面这些场景尤其有价值：
- 从用户输入中抽取结构化表单；
- 让模型生成审批、路由、分类、标签等决策对象；
- Agent 调用工具前先生成参数对象；
- 从文档中抽取知识图谱节点；
- 让模型输出可落库的业务实体。
注意：.entity(...) 只能用于 .call()，不能直接用于 .stream()。因为类型转换需要完整响应，流式输出只是一段段文本。
7. Memory、tool call 和结构化输出可以组合
Spring AI 2.0 的 Advisor 链是这一轮更新背后的关键。
工具调用、结构化输出重试、memory、evaluation，本质上都需要在模型调用前后插入逻辑，有些还需要多轮循环。以前这些能力如果散落在不同模型实现里，会很难组合。
现在它们被拉到更统一的链路中，开发者就可以思考：
- memory 应该记录最终回答，还是记录每轮 tool request / tool response？
- tool calling 之前是否要加权限检查？
- 结构化输出失败后是否允许重试？
- 每一轮工具调用是否要写审计日志？
- 如果模型调用成本太高，是否需要在 Advisor 层做预算控制？
这也是 Spring AI 2.0 最重要的方向：它不只是“帮你调模型”，而是在帮你搭 Agent 应用的中间层。
最近安全更新也值得留意
这轮 Spring release train 附带了不少安全相关内容。这里挑和 Boot / AI 关系比较近的几个提醒。
Spring AI Vector Store 元数据过滤问题
6 月 12 日，Spring 官方发布了 CVE-2026-47835，涉及 Spring AI Vector Stores 在 Elasticsearch、OpenSearch 和 GemFire Vector Stores 中处理特殊字符的方式。受影响版本包括 Spring AI 1.0.x 和 1.1.x。
如果你的应用使用 Spring AI Vector Store，并且允许用户输入进入 metadata filter，一定要优先检查版本和修复建议。
这类问题的本质是：AI 应用里的“检索条件”也是输入面。不能只防 prompt injection，向量检索、metadata filter、工具参数、外部 URL 都要纳入安全边界。
Spring Boot Mail 和 Artemis 相关修复
Spring Boot 近期也有安全 advisories，例如 Mail auto-configuration 没有启用 SSL hostname verification、Artemis embedded broker 默认数据目录可预测等问题。
如果你使用邮件发送、嵌入式消息组件或相关 starter，不要只看大版本更新，也要跟进对应维护版本里的修复。
该不该现在升级？
可以按项目类型判断。
新项目或 AI 原型
建议直接从 Spring Boot 4.1 + Spring AI 2.0 开始。
原因很简单：Spring AI 2.0 的主要设计就是面向 Boot 4 / Framework 7，Agent、tool calling、structured output 这些能力也都在 2.0 上更完整。如果你今天新建 AI 应用，没有太多历史包袱，没必要再绕回旧基线。
存量 Boot 3.x 业务系统
不要为了 Spring AI 2.0 直接硬升。
Boot 4 / Framework 7 会带来依赖基线、Jakarta、Spring Security、数据访问、构建插件、测试工具等多方面变化。建议先做兼容性评估：
- 当前是否强依赖 Boot 3.x starter；
- 自定义 auto-configuration 是否需要调整；
- Security 配置是否受影响；
- 数据库、消息队列、HTTP 客户端和 observability 是否有行为变化；
- 测试框架和构建插件是否支持新版本；
- 团队是否已有足够回归测试。
如果只是想在业务系统里小规模接入模型，可以先继续使用 Spring AI 1.1.x 维护版本，把核心 AI 能力封装在边界清晰的模块里。
已经在做 Agent 的团队
建议重点评估 Spring AI 2.0。
如果你的系统已经开始涉及工具调用、记忆、结构化输出、MCP、RAG、审计和多模型切换，那么 2.0 的 Advisor 架构会比 1.x 更适合长期维护。
尤其是下面几类代码，值得尽快迁移验证：
- 自己手写工具调用循环；
- 自己解析模型 JSON 输出；
- 自己维护 prompt 级 JSON schema；
- 在工具调用中缺少审计和权限控制；
- 一次性向模型暴露大量工具；
- 需要把 tool calling 和 memory 组合。
一个更实际的学习路线
如果你想快速跟上这一轮更新，可以按这个顺序看：
- 先读 Spring Boot 4.1 release notes，了解新基线和迁移影响。
- 再看 Spring AI 2.0 GA，理解为什么它切到 Boot 4 / Framework 7。
- 然后单独学习 tool calling，因为它是 Agent 的核心执行机制。
- 最后做一个 structured output demo，把模型输出转成 Java record，并开启
validateSchema()。
一个最小实验项目可以这样设计：
- Spring Boot 4.1
- Spring AI 2.0
- 一个
ChatClient - 一个
@Tool工具，例如查询天气、查订单或查知识库 - 一个 Java record，用于接收模型结构化输出
- 开启
validateSchema() - 加一层日志，记录每次工具调用和最终返回对象
这个 demo 不需要很复杂，但它能覆盖 Spring AI 2.0 最关键的几个变化。
总结
最近 Spring Boot 和 Spring AI 的更新可以用一句话概括：
Spring Boot 4.1 在继续把生产系统的基础设施做厚，Spring AI 2.0 则在把 AI 应用从“模型 API 调用”推进到“Agent 工程化框架”。
前者关心的是 HTTP 客户端安全、观测、数据连接、批处理、gRPC、依赖基线和线上可维护性；后者关心的是工具调用、结构化输出、Advisor 链、模型供应商抽象、记忆和可组合执行流程。
如果你只是偶尔调一次模型，可能感知不会特别强。但如果你正在用 Java 做 RAG、内部 Agent、智能客服、代码助手、知识库问答或业务流程自动化，那么这一轮更新值得认真投入时间。
尤其是 Spring AI 2.0 的两个方向：工具调用 Advisor 化、结构化输出自纠错。它们解决的不是 demo 问题，而是真实项目里最容易踩的两个坑：模型到底能不能可靠地调用业务能力，以及模型结果到底能不能安全地交给后续 Java 代码处理。