Spring AI 2.0 五大更新：Java 后端如何切入 Agent 开发

Spring AI 2.0 的发布在 Java 后端圈里讨论度不低，但真正值得关注的更新其实只有五个。一位 B 站 UP 主在实战课程分享中逐条拆解了这些变化，并给出了从多模型接入到 MCP 开发的学习路径。本文结合其观点，梳理 Spring AI 2.0 的核心改动与 Java 开发者切入 Agent 开发的现实选择。

版本基线抬升：Spring Boot 4 + Spring 7 的代价

第一个更新是版本基线的硬性抬升：Spring AI 2.0 抛弃了 Spring Boot 3 和 Spring 6，必须基于 Spring Boot 4 和 Spring 7。据该 UP 主观察，Spring Boot 4 和 Spring 7 本身并没有带来太多诱人的新特性，这种“为追版本而更新”的做法让他颇为反感。

更现实的麻烦在于工具链。Spring Boot 4 要求 IDEA 2025 以上版本，意味着开发者还没开始写第一行 AI 代码，就得先完成全套环境升级。第三方中间件的兼容性也是未知数——项目里依赖的各类组件是否能平滑迁移，需要逐一验证。

对于企业项目而言，这种升级成本不能忽视。如果现有系统稳定运行在 Spring Boot 3 上，贸然跟进 2.0 可能带来不必要的迁移风险。比较务实的做法是先在小规模项目或学习环境中验证，再评估生产环境的升级时机。

Tools 解析上浮：从黑盒到可观测

第二个更新被该 UP 主评价为“非常好”。Spring AI 2.0 为了更好地支持 React Agent，重构了 Tools 的设计：原先 Tools 的解析发生在底层的 Chat Model，现在上浮到了上层的 Chat Client 的 Advisor 中。

这一改动带来两个直接好处。其一是可观测性——通过日志 Advisor 可以监控 Tools 传递的信息。在旧版本中，Tools 解析藏在底层 Chat Model 里，上层的日志 Advisor 根本看不到 Tools 到底传了哪些信息给大模型，完全是一个黑盒。现在通过日志就能直观查看，排查问题方便很多。

其二是为 Agent 机制打基础。基于内置的 Function Calling 递归 Advisor，可以实现“观察—思考—行动”的循环：根据任务不断迭代、自我纠错，直到任务完成。这是 Spring AI 迈向 Agent 非常关键的一步。

Function Calling 与 ReAct 循环

Function Calling（函数调用）是大模型与外部工具交互的基础机制：开发者用 JSON Schema 描述可用工具，模型在推理时判断是否需要调用、调用哪个，并生成结构化参数，由宿主程序执行后把结果回传给模型。早期 OpenAI 的 function calling 与后来的 tool calling 基本同义。

ReAct（Reasoning + Acting）是把这一机制串成循环的经典范式：模型先输出思考（Thought），再决定行动（Action，即调用工具），拿到观察结果（Observation）后继续推理，直到给出最终答案。Spring AI 2.0 中基于内置 Function Calling 递归 Advisor 实现的“观察—思考—行动”循环，本质就是 ReAct。理解这一点，就能明白 Tools 解析上浮为何是关键前置条件——只有工具调用过程在上层 Advisor 链路中可见、可拦截，才能在其外围叠加递归与日志逻辑。

AgentUtils：对标 Claude Code 的 Agent 开发库

第三个更新是 Spring AI 设计了一套 AgentUtils 的 Agent 开发库。据该 UP 主描述，这是一个“逆向 Claude Code”的 Agent 工具库，帮助开发者更好地开发 Agent，且必须基于 Spring AI 2.0 使用。

这个库的定位值得琢磨。它把 Agent 开发中常见的模式封装成工具，降低了从零搭建 Agent 循环的门槛。但也要注意，它强依赖 Spring AI 2.0，意味着采用它就必须接受前述的版本基线抬升。

Claude Code 的 Agent 设计为何被借鉴

Claude Code 是 Anthropic 推出的终端内编码 Agent，其架构思路在 Agent 工程圈影响很大：核心是一个极简的“模型 + 工具”循环，工具集以文件读写、Shell 执行、搜索等基础能力为主；大量行为约束不写在代码里，而是写在系统提示与项目级配置文件（如 CLAUDE.md）中；通过子 Agent 分派、上下文压缩、权限确认等机制控制长任务的上下文与安全边界。

所谓“逆向 Claude Code”的 Agent 库，通常是把这套模式抽象成可复用的组件：循环调度器、工具注册与执行、上下文管理、中断与人工确认等。对 Java 开发者而言，这意味着不必从零设计 Agent 主循环，而是专注在工具实现与业务编排上；但也需注意这类库往往带有特定模型的假设，换模型后提示词与工具描述可能需要重新调优。

MCP 传输协议更替：Streamable HTTP 取代 SSE

第四个更新是 MCP 的传输方式变化：Streamable HTTP 取代了已废弃的 SSE，成为默认传输协议。SSE 在长连接场景下的局限性早已被讨论，Streamable HTTP 的切换顺应了 MCP 生态的演进方向。

对于正在做 MCP 服务端或客户端开发的 Java 团队，这意味着需要检查现有实现是否依赖 SSE，并及时调整。新项目则可以直接基于默认协议起步，减少后期迁移成本。

MCP 与 SSE、Streamable HTTP 的关系

MCP（Model Context Protocol）是 Anthropic 提出的开放协议，用于让 AI 应用以统一方式连接外部工具、数据源和提示模板，可粗略类比为“AI 领域的 LSP”。它定义了 Server 与 Client 之间的 JSON-RPC 消息格式，而传输层负责这些消息怎么走。

最初的远程传输基于 HTTP + SSE：客户端先建立一条 SSE 长连接接收服务端推送，再通过单独的 HTTP POST 发送请求，需要维护两个端点与持续连接，在负载均衡、网关和断线重连场景下都比较麻烦。Streamable HTTP 把两者合并到单一端点，服务端可按需在同一响应流中返回 SSE 事件或普通 JSON，并支持会话恢复，对无状态部署更友好。因此 MCP 规范将其定为默认传输方式，SSE 传输被标记为废弃。

Tool Search：按需加载节省 Token

第五个更新加入了一个按需加载的 Tool Advisor，叫做 Tool Search Tool Calling Advisor。它在请求大模型之前，会根据当前任务的提示词检索与当前对话相关的 Tool，只把相关的工具发给大模型。

这样做既节省 Token，也能有效减少噪音、提升推理质量。当工具数量较多时，全量注入 Tool 定义会占用大量上下文，按需检索是一个实用的优化方向。

工具数量膨胀带来的上下文压力

工具调用的一大隐性成本是工具定义本身的 Token 开销。每个工具的名称、描述和参数 Schema 都要写进系统提示或请求体，当工具数量达到几十上百个时，仅定义就可能占用数千乃至上万 Token，既增加费用，也稀释模型对当前任务相关信息的注意力，导致选错工具或参数生成不稳定。

Tool Search 的思路是把工具检索做成一个前置步骤：先用当前对话的提示词在工具库中做相关性检索（可以是向量检索或关键词匹配），只把 Top-K 相关工具的定义注入请求。这与 RAG 检索文档的思路同构，只是检索对象从知识片段换成了工具描述。代价是增加一次检索开销，且检索召回不准时可能漏掉必要工具，实际使用中通常需要保留核心工具的常驻注入作为兜底。

Spring AI 的定位：做好基座，上层交给 Agent 框架

该 UP 主对 Spring AI 2.0 的整体判断是：除上述五点外没有太多亮点新特性。真正能打动他使用 2.0 的，可能是用 AgentUtils 开发 Agent，但 Java 生态里的 Agent 框架并不少——Spring AI Alibaba Agent Framework、AgentScope 等方案都做得不错。

在他看来，Spring AI 的定位非常清晰：只做各个大模型的基本对接，以及 Tool、MCP、RAG 的基本实现；更上层的 Tool Advisor 则留给 Agent 扩展。用他的话说，Spring AI 把自己当作基座，开发者在上层做扩展，“各自为战，做好自己擅长的领域”。

这个定位对 Java 后端开发者有实际指导意义：不要指望 Spring AI 包办企业级 Agent 的全部能力，把它当作模型接入层和工具调用层，Agent 编排逻辑则根据项目需求选择更专门的框架。

Java 后端的学习路径

该 UP 主给出的路线覆盖了从大模型选型、微调，到 AI 开发 Agent 框架，再到项目实战的完整链路，实战项目包括智能客服、RAG 知识库、垂直 Agent 的 Workflow 流程开发以及部署环节。对于 Java 后端来说，这条路径的合理性在于：先掌握模型接入和 Tool/MCP 的基础能力，再进入 RAG 和 Agent 编排，最后落到具体业务场景。

需要提醒的是，课程推广中提到的“无偿分享”资料仅是该 UP 主的个人行为，读者应自行判断资料质量与适用性，核心还是回到官方文档和实际动手验证。

常见问题

Spring AI 2.0 必须升级到 Spring Boot 4 吗？ 是的，2.0 强制要求 Spring Boot 4 和 Spring 7，无法在 Spring Boot 3 环境下使用。

Tools 解析上浮后，旧代码需要改吗？ 如果依赖底层 Chat Model 的 Tools 解析行为，需要检查 Advisor 链路的配置，确保日志监控和递归调用按新机制工作。

MCP 的 SSE 还能用吗？ SSE 已被废弃，默认传输协议改为 Streamable HTTP，建议新项目直接采用新协议。