Spring AI 2.0五大更新解读：迈向Agent智能体时代

Spring AI 2.0：一次定位清晰的升级

Spring AI 2.0发布已有一段时间，作为Java生态中连接大模型能力的重要框架，它的每一次迭代都牵动着后端开发者的神经。从0.1到1.0，再到如今的2.0，Spring AI一路走来，逐渐明确了自己在AI应用开发栈中的位置。

这里有必要先理解Spring AI的来龙去脉。Spring AI 是 Spring 官方在生成式 AI 浪潮下推出的应用开发框架，其设计理念深受 LangChain、LlamaIndex 等 Python 生态框架的启发，旨在为 Java/Kotlin 开发者提供一套统一、可移植的 API 来对接各类大模型。它通过可移植性抽象层，屏蔽了 OpenAI、Anthropic、Azure OpenAI、Ollama 等不同厂商 API 的差异，让开发者可以通过一致的 ChatClient 接口调用模型，而无需为每个供应商编写适配代码。这种设计延续了 Spring 一贯的“约定优于配置”与依赖注入哲学，使 AI 能力能够自然融入既有的企业级 Java 应用架构中。

据B站相关技术UP主的分析，这次Spring AI 2.0的核心更新其实可以归纳为五个方面。相比一些博眼球的“大版本”，Spring AI 2.0的更新更像是一次务实的架构调整——它没有堆砌华而不实的特性，而是围绕一个明确目标：支持Agent（智能体）开发。

本文将逐一拆解这五大更新，并探讨Spring AI在整个Java AI框架格局中的定位与取舍。

更新一：强制升级到Spring Boot 4与Spring 7

Spring AI 2.0最直接、也最具争议的变化，是它彻底抛弃了Spring Boot 3和Spring 6，必须基于Spring Boot 4和Spring 7运行。

这一改动在开发者社区引发了一些不满。正如原视频作者所言：“我挺反感这种为了追版本而进行更新。”问题在于，Spring Boot 4和Spring 7本身并没有带来太多杀手级新特性，却带来了实打实的迁移成本：

• 需要将开发工具升级到 IDEA 2025 及以上版本；
• 项目中依赖的第三方中间件的兼容性存在不确定性；
• 整套技术栈的强制升级增加了落地风险。

换句话说，还没开始体验2.0的新能力，团队就得先付出一轮全套升级的代价。对于生产环境的项目而言，这种“先升级再说”的策略需要谨慎评估。值得一提的是，Spring Boot 4 与 Spring 7 全面提升了对 JDK 17+ 乃至虚拟线程、GraalVM 原生镜像等新特性的支持，长远看有利于AI应用的高并发场景，但短期内这些红利难以直接抵消迁移带来的阵痛，这也是社区争议的根源所在。

更新二：Tools解析上浮，打破黑盒

如果说第一点是槽点，那第二点则被普遍认为是Spring AI 2.0最有价值的改进。

从ChatModel上浮到ChatClient

在旧版本中，Tools（工具调用）的解析发生在底层的 ChatModel 中。这带来一个明显的问题：上层的日志Advisor无法监控到工具究竟向大模型传递了哪些信息，整个工具调用过程对开发者而言是一个黑盒。

要理解这个改进的意义，需要先了解 Function Calling 这一能力。Function Calling（函数调用，也称 Tool Calling）是现代大模型的一项核心能力：模型在生成回答的过程中，可以判断是否需要调用外部工具（如查询数据库、调用 API、执行计算），并以结构化 JSON 的形式输出调用参数，由应用层执行后再将结果返回给模型继续推理。整个过程涉及模型与应用之间的多轮交互，如果这些交互细节被封装在底层不可见，排查问题就如同盲人摸象。

2.0将Tools的解析上浮到了上层的 ChatClient 的 Advisor 中。这里的 Advisor 是 Spring AI 借鉴 Spring AOP 切面思想设计的拦截器机制，允许开发者在请求发往模型的前后插入自定义逻辑。这个看似简单的架构调整，带来了两个实实在在的好处：

1. 可观测性提升：通过日志Advisor，开发者可以直观地查看Tools传递的具体信息，调试和监控不再盲目；
2. 为Agent铺路：这一改动是Spring AI迈向Agent架构的关键前提。

对于任何做过工具调用调试的开发者来说，能看到“工具到底传了什么”这件事，价值大家都看得到。

更新三：内置Agentic机制，走向自我迭代

Spring AI 2.0基于内置的 Function Calling 递归 Advisor，实现了完整的 Agentic 机制。

观察—思考—行动的循环

所谓Agentic，指的是智能体能够根据任务，进行**观察（Observe）、思考（Think）、行动（Act）**的循环，并不断迭代、自我纠错，直到任务完成。这正是当前AI Agent开发的核心范式（ReAct）。

ReAct（Reasoning + Acting）是在 Function Calling 基础上形成的经典 Agent 范式，由普林斯顿与 Google 研究者于 2022 年提出，它将“推理链”与“行动”交替进行，使模型能够边思考边操作外部环境，从而完成复杂的多步任务。Spring AI 2.0 通过“递归 Advisor”将这一循环内置化——当模型返回工具调用请求时，框架自动执行工具、回填结果并再次调用模型，如此往复直到模型给出最终答案，开发者无需手写这段循环控制逻辑。

更进一步，Spring AI还推出了一套名为 Agent Utils 的Agent开发库。据介绍，这个工具库“逆向”参考了 Claude Code 的Agent设计思路，旨在帮助开发者更高效地构建智能体。Claude Code 是 Anthropic 推出的命令行编程助手，以其精巧的任务分解、上下文管理和工具调用编排能力著称，被视为 Agent 工程实践的标杆之一。需要注意的是，Agent Utils 必须基于Spring AI 2.0 才能使用——这或许也是促使部分开发者升级的主要动力。

可以说，这两点更新（Tools上浮 + Agentic机制）共同构成了Spring AI从“对话框架”向“智能体基座”演进的核心叙事。

更新四：MCP传输协议切换到Streamable HTTP

第四个更新聚焦于 MCP（Model Context Protocol）的传输层。

在2.0中，Streamable HTTP 传输方式取代了已经被废弃的 SSE（Server-Sent Events），成为默认的传输协议。

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 于 2024 年底开源的一套标准协议，旨在统一大模型与外部工具、数据源之间的连接方式，被业界称为“AI 应用的 USB-C 接口”。它定义了服务端如何向模型暴露工具、资源和提示模板，正在被越来越多的框架和厂商采纳为事实标准。

这一调整与MCP协议本身的演进保持同步。早期 MCP 采用 SSE 作为远程传输方式，但 SSE 本质是单向的服务器推送，需要额外的 HTTP 通道处理客户端请求，在会话管理、双向通信和断线重连上较为笨拙。Streamable HTTP 则在单一 HTTP 端点上同时支持普通请求响应与流式推送，提供了更灵活、更稳定的传输能力。对于构建基于MCP的工具集成体系来说，这是一次必要的与时俱进。

更新五：按需加载的Tool Search Advisor

第五个更新引入了一个颇具实用价值的组件——Tool Search Tool Calling Advisor，即按需加载的工具Advisor。

用检索代替全量注入

传统做法是将所有可用工具的定义一次性发给大模型，这会带来两个问题：Token消耗大，以及过多无关工具造成的“噪音”干扰推理。

在企业级 Agent 场景中，工具数量可能达到数十甚至上百个，将全部工具定义注入到每次请求的上下文会带来严重的 Token 消耗和推理干扰——大模型的上下文窗口是有限且按量计费的，冗余信息不仅推高成本，还可能让模型在众多选项中“选择困难”，降低调用准确率。

Tool Search Advisor的思路是：在请求大模型之前，先根据当前任务的提示词，检索出与当前对话最相关的工具，只把这部分工具发给大模型。这一机制借鉴了 RAG（检索增强生成）的核心思想：先将工具描述向量化存入检索库，运行时根据用户意图做语义检索，只召回最相关的少数工具。这样做既节省了Token，又能有效减少噪音、提升推理质量。

在工具数量庞大的企业级场景中，这种“工具RAG”式的按需加载机制，是提升Agent效率和准确率的实用手段。

Spring AI的定位：做好基座，让上层各显神通

综合来看，除了Agent Utils之外，Spring AI 2.0并没有太多颠覆性的新特性。这反而折射出Spring AI对自身定位的清醒认知。

与其他Java Agent框架的分工

如今Java生态中的Agent框架已相当丰富，除了Spring AI，还有 Spring AI Alibaba、Agent Framework、Agent Scope 等多个选择，各自都做得不错。其中 Spring AI Alibaba 由阿里巴巴团队维护，深度整合了通义千问等国产模型与阿里云生态，并在多智能体编排上投入较多；而 Agent Scope 等框架则更侧重于复杂的智能体协作与流程编排。这种百花齐放的局面，恰恰说明 Java 在 AI 应用开发领域正在快速补齐与 Python 生态的差距。

在这样的格局下，Spring AI选择了一条清晰的路线：

我只做各个大模型的基本对接，以及Tool、MCP、RAG的基本实现。应用层的Agent扩展、上下文工程（Context Engineering），你们把我当作基座来扩展就行。

这里提到的上下文工程（Context Engineering）是近来备受关注的概念，它超越了单纯的提示词工程，强调如何系统性地组织、检索、压缩和动态注入模型所需的上下文信息——包括对话历史、检索结果、工具输出等，以在有限的上下文窗口内最大化模型的表现。Spring AI 将这部分复杂度留给上层框架，正体现了其分层解耦的设计取向。

这种“我做好底座，你做好上层”的分工哲学，其实颇为健康。与其在所有方向上追求大而全，不如专注于自己最擅长的领域——稳定、标准化的大模型接入层。上层框架则可以基于这个基座，去实现更复杂的多轮对话、复杂编排和智能体逻辑。

结语：务实的一步，而非革命

Spring AI 2.0是一次务实的架构升级：它的强制版本升级令人不适，但Tools上浮、内置Agentic机制、MCP协议更新和按需工具加载，都是朝着Agent时代迈进的坚实脚步。

对于Java开发者而言，是否升级取决于你的核心需求：如果你需要开发智能体、看中Agent Utils，2.0值得投入；如果只是做基础的模型对话，那么在评估好迁移成本前，不必急于跟进。

Spring AI用一次克制的更新，给出了自己在AI应用开发栈中的答案——做最可靠的那块基座。

核心要点