Spring AI 2.0.0-M7 有什么值得学：MCP、ToolSpec 与 Java Agent 新写法
| ★ 文章定位：面向 Java / Spring Boot 开发者，用一篇文章讲清 Spring AI 2.0.0-M7 的关键更新、MCP 与 ToolSpec 的关系，以及如何用 Java 写出更工程化的 AI Agent。 |
文章摘要
Spring AI 2.0.0-M7 是 Spring AI 2.x 预览线中的一次重要节点更新。它并不是简单增加几个模型适配，而是继续把 Java 生态中的 AI 应用开发推向“工具化、协议化、Agent 化”。对于已经熟悉 Spring Boot 的开发者来说，最值得关注的不是某一个单独 API，而是 MCP、ToolSpec、ToolCallAdvisor、ChatClient、Advisor 与 Agentic Patterns 组合之后形成的新工作流。
如果你过去使用 Java 接大模型，多数场景可能停留在“调用 Chat API、拼 Prompt、返回文本”。而 Spring AI 的方向是：用熟悉的 Spring 编程模型，把模型、工具、向量库、业务服务、权限、日志、评估与部署统一纳入工程体系。M7 版本的更新，让“Java 写 Agent”变得更接近真实企业应用，而不只是 Demo。
一、为什么 Spring AI 2.0.0-M7 值得 Java 开发者关注
Spring AI 官方将项目定位为 AI engineering 的应用框架，目标是把 Spring 生态中强调的可移植性、模块化设计和 POJO 编程方式带入 AI 应用开发。它要解决的核心问题不是“如何调一次模型”，而是“如何把企业数据、业务 API 与 AI 模型稳定连接起来”。
在 2.0.0-M7 中，几个变化特别适合拿来学习：MCP Server 协议默认方向从 SSE 迁移到 Streamable HTTP；ToolCallAdvisor 成为工具调用在 Advisor 链路中的标准处理方式；新增 ToolSpec fluent API，用于程序化定义工具；同时更新 Gemini 2.5 Flash 与 Google Client Library BOM，并修复若干模型、Schema 与 Docker Model Runner 相关问题。
| ★ 适合阅读人群：Java 后端开发者、Spring Boot 工程师、企业知识库/Agent 应用开发者、想把 AI 工具接入现有业务系统的技术负责人。 |
1.1 从“AI 调用”转向“AI 工程”
很多 AI 应用的早期写法是：前端收集问题，后端拼接 Prompt，调用大模型，返回一段文本。这种方式适合演示，但一旦进入企业场景，就会遇到权限、审计、数据来源、工具调用、失败重试、模型切换、成本控制等问题。Spring AI 的价值在于把这些问题放进 Spring 工程体系里处理。
1.2 2.0.0-M7 的学习重点不是“追新”，而是“看方向”
M7 是 milestone 版本，不建议不加评估地直接用于核心生产链路。但它非常适合用来学习 Spring AI 下一阶段的抽象：模型可替换、工具可描述、协议可连接、Agent 可编排、调用链可观测。
二、Spring AI 2.0.0-M7 核心更新速览
| 更新点 | 官方说明/变化 | 对开发者的意义 |
| MCP 传输变化 | SSE transports deprecated；Streamable HTTP 成为新的默认 server protocol | 说明 MCP Server 方向更靠近标准 HTTP 服务化部署 |
| ToolCallAdvisor 默认化 | 工具调用进入 Advisor chain 的标准处理方式 | 便于统一处理工具调用、日志、权限、重试和观测 |
| ToolSpec Fluent API | 新增程序化定义工具的 API | 适合动态工具、插件化工具和非注解式工具定义 |
| Gemini 更新 | 更新 Gemini 2.5 Flash 与 Google Client Library BOM | 加强 Google 模型侧兼容与能力覆盖 |
| 关键修复 | ChatClient prompt options、Kotlin nullable schema、Docker Model Runner 等 | 降低实际项目中的边缘问题和集成成本 |
从表面看，这些更新分散在不同模块；从架构角度看，它们都在服务同一个方向：让 AI 应用从“单模型问答”走向“可调用工具、可接协议、可组合工作流”的工程模式。
三、MCP：从“接一个工具”到“接一个工具生态”
MCP（Model Context Protocol）可以理解为模型应用与外部工具、资源、Prompt 能力之间的标准连接协议。它解决的问题不是“某一个方法如何被模型调用”，而是“不同工具、不同服务、不同客户端之间如何用统一方式发现和调用能力”。
3.1 MCP Client 与 MCP Server 怎么理解
在 Spring AI 场景下，应用可以作为 MCP Client 去连接一个或多个 MCP Server。MCP Server 对外暴露工具、资源或 Prompt，Client 负责发现、选择并把能力交给模型工作流使用。你可以把 MCP Server 理解为“AI 工具服务”，例如文件检索服务、数据库查询服务、工单系统服务、企业知识库服务、代码仓库服务等。
3.2 M7 为什么强调 Streamable HTTP
M7 中官方明确提到 SSE transports 已 deprecated，Streamable HTTP 成为新的默认 server protocol。这意味着 MCP Server 更适合以标准 HTTP 服务形态运行，便于网关、认证、负载均衡、日志、安全策略和云原生部署。对于企业项目来说，这通常比临时脚本式工具更容易治理。
3.3 MCP 更适合什么场景
当你的工具需要被多个 Agent、多个应用或多个团队复用时，MCP 比在一个项目里硬编码 function calling 更合适。例如企业内部已有搜索服务、CRM 服务、库存服务、合同系统、知识库系统，未来都可以通过 MCP 暴露给不同 AI 应用。
四、ToolSpec：用 Java 更清晰地定义 AI 工具
在传统工具调用中，开发者常用注解方法或 Function 对象把某个业务能力交给模型调用。M7 新增的 ToolSpec fluent API 更偏向“显式描述工具”：工具叫什么、用途是什么、参数结构是什么、执行逻辑是什么，都可以用程序化方式表达。
4.1 @Tool、Function Calling 与 ToolSpec 的区别
| 方式 | 适合场景 | 优点 | 注意点 |
| @Tool 注解 | 工具固定、业务方法清晰 | 写法直观，适合 Spring Bean | 动态注册和复杂元数据表达能力有限 |
| POJO Function | 简单函数式调用 | 轻量、容易接入 | 工具描述和参数 Schema 需要额外管理 |
| ToolSpec | 动态工具、插件化工具、企业工具目录 | 可程序化定义工具元数据与执行逻辑 | API 细节需以 2.0.0-M7 文档和 IDE 提示为准 |
4.2 @Tool 注解示例
@Component
public class WeatherTools {
@Tool(description = “查询指定城市的天气信息”)
public String getWeather(@ToolParam(description = “城市名称”) String city) {
return weatherService.query(city);
}
}
String answer = chatClient.prompt(“北京今天适合出门吗？”)
.tools(weatherTools)
.call()
.content();
4.3 ToolSpec 概念性写法
下面代码用于说明 ToolSpec 的设计思路：把工具名称、描述、参数结构和执行逻辑放到一个显式工具定义中。由于 2.0.0-M7 仍是预览里程碑，具体包名和方法签名建议以项目依赖版本、IDE 自动补全和官方文档为准。
// 概念性示例：用于理解 ToolSpec 的工程价值
var weatherTool = ToolSpec.builder()
.name(“getWeather”)
.description(“查询城市天气，并返回温度、天气状况和出行建议”)
.inputSchema(“{“type”:”object”,”properties”:{“city”:{“type”:”string”}}}”)
.callback(arguments -> weatherService.query(arguments.get(“city”).toString()))
.build();
String result = chatClient.prompt(“帮我判断上海今天是否适合户外拍摄”)
.tools(weatherTool)
.call()
.content();
| ★ 实战建议：固定工具优先使用 @Tool；需要从数据库、配置中心或插件市场动态加载工具时，再考虑 ToolSpec；跨应用复用工具时，优先考虑 MCP。 |
五、Java Agent 新写法：不要只写 Prompt，要写工作流
Spring AI 官方 Agentic Patterns 参考了 Anthropic 关于有效 Agent 的研究，强调简单、可组合、可验证。它区分了 workflow 与 agent：workflow 是预定义路径的编排，agent 则让模型动态决定流程和工具使用。企业项目通常应该先从 workflow 开始，再在必要环节加入 agent 决策。
5.1 五类常见 Agentic Patterns
| 模式 | 适合场景 | 办公/开发示例 |
| Chain Workflow | 明确的顺序任务 | 需求分析 -> 方案生成 -> 代码草稿 -> 测试建议 |
| Routing Workflow | 输入类别不同，处理器不同 | 把用户问题分流到账单、技术、售后、知识库 |
| Parallelization Workflow | 多个独立子任务可并行 | 同时生成技术版、运营版、用户版文档 |
| Orchestrator-Workers | 任务无法预先完全拆分 | 让主 Agent 拆分任务，再调多个 Worker 执行 |
| Evaluator-Optimizer | 需要迭代提升质量 | 生成代码后自动审查，再优化安全性和可读性 |
5.2 Java Agent 的核心不是“自主”，而是“可控自主”
对企业团队而言，Agent 不是越自由越好，而是要在可控范围内完成任务。Spring 生态的优势是 Bean 生命周期、配置管理、权限控制、日志观测、测试框架、部署体系都比较成熟。把 Agent 放在这些工程基础之上，才更容易进入真实业务。
六、MCP vs ToolSpec vs Function Calling：到底怎么选
如果只是让模型调用一个天气接口，Function Calling 或 @Tool 就够了；如果你要把企业内部的多个业务系统接入 AI，并希望这些能力可被多个应用复用，MCP 更有价值；如果你想在 Java 项目内部构建一个可动态加载的工具目录，ToolSpec 是值得重点学习的新方向。
| 你的需求 | 推荐方案 | 原因 |
| 单项目内固定工具调用 | @Tool / Function Calling | 实现快，认知成本低 |
| 动态工具、插件市场、可配置工具 | ToolSpec | 工具元数据和执行逻辑可以程序化管理 |
| 跨系统、跨团队、跨客户端复用工具 | MCP | 协议化连接，便于服务治理 |
| 复杂业务 Agent | ToolSpec + MCP + Advisor | 工具、协议、权限、日志、重试、评估都需要纳入工程体系 |
七、实战案例：构建一个“资料检索 + 天气工具 + 报告生成”的 Java Agent
下面以一个办公场景为例：用户上传项目资料，希望系统检索相关内容、结合实时天气信息，生成一份外出调研计划。这个案例可以同时体现 RAG、Tool Calling、MCP 与 Agent 工作流。
7.1 项目结构建议
src/main/java/com/example/agent
├─ AgentApplication.java
├─ config/
│ ├─ ChatClientConfig.java
│ └─ McpClientConfig.java
├─ tools/
│ ├─ WeatherTools.java
│ └─ DocumentSearchTools.java
├─ workflow/
│ ├─ ResearchPlannerWorkflow.java
│ └─ EvaluationWorkflow.java
└─ controller/
└─ AgentController.java
7.2 依赖与版本提醒
Spring AI 2.x 对应 Spring Boot 4.x 方向。如果你当前项目仍在 Spring Boot 3.5.x，可以优先使用 Spring AI 1.1.x 稳定线学习生产落地；如果你想学习 M7 新特性，可以单独创建实验项目，避免直接改造生产系统。
<!– 概念性示例：具体 artifact 以 2.0.0-M7 文档为准 –>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-bom</artifactId>
<version>2.0.0-M7</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
7.3 工作流拆解
| 步骤 | Agent 行为 | 对应 Spring AI 能力 |
| 理解任务 | 识别用户要生成“调研计划” | Prompt + Structured Output |
| 检索资料 | 从向量库或知识库查询项目背景 | Vector Store / RAG |
| 调用工具 | 查询目标城市天气、交通、日程 | @Tool / ToolSpec / MCP |
| 生成计划 | 合并资料、天气与约束生成报告 | ChatClient + Advisors |
| 评估优化 | 检查是否缺少时间、地点、风险提示 | Evaluator-Optimizer Workflow |
7.4 输出报告模板
请基于检索资料和工具返回结果，生成调研计划：
1. 调研目标：一句话说明
2. 背景摘要：引用资料中的关键事实
3. 行程安排：按时间段列出任务
4. 风险提示：天气、交通、沟通风险
5. 待确认事项：列出需要人工确认的问题
要求：事实来自资料或工具结果，不要编造。
八、升级与迁移建议：M7 适合学习，但生产要谨慎
2.0.0-M7 是预览版本，适合技术验证、团队学习和新项目 PoC。已经上线的业务系统，如果没有明确需求，不建议只为追新而升级。更稳妥的路径是：先在实验分支验证 MCP、ToolSpec、Advisor 与模型兼容性，再评估是否迁移。
| 升级检查项 | 建议 |
| Spring Boot 版本 | Spring AI 2.x 面向 Spring Boot 4.x；老项目先评估 Boot 升级成本 |
| MCP 传输 | 检查是否依赖 SSE；新项目优先按 Streamable HTTP 设计 |
| 工具调用 API | 逐步从旧 FunctionCallback 思路迁移到 ToolCallback / ToolSpec / @Tool |
| 自动配置 | 关注 starter artifact 与 autoconfigure 拆分，避免依赖冲突 |
| 观测与安全 | 为工具调用增加日志、权限边界、异常处理和限流 |
| 生产发布 | 先灰度；保留回滚方案；对工具调用结果做可解释记录 |
| ★ 迁移原则：不要一次性重构全部 AI 能力。优先迁移工具定义层，再迁移 MCP 连接层，最后优化 Agent 编排与评估链路。 |
九、常见问题 FAQ
Q1：Spring AI 2.0.0-M7 可以直接用于生产吗？
不建议默认直接用于核心生产系统。M7 是 milestone 版本，适合学习和 PoC。生产项目建议优先使用稳定线，或经过充分测试后灰度引入。
Q2：MCP、ToolSpec、Function Calling 是替代关系吗？
不是完全替代。Function Calling 是基础能力，ToolSpec 是 Java 侧更清晰的工具定义方式，MCP 是跨系统工具协议。复杂项目通常会组合使用。
Q3：只做普通 ChatBot 需要学 MCP 吗？
如果只是 FAQ 问答或简单文档总结，可以暂时不学。但只要涉及外部工具、企业系统、多个数据源或跨团队复用，MCP 就值得提前了解。
Q4：ToolSpec 和 @Tool 怎么选？
固定业务方法优先 @Tool；需要动态加载工具、插件化工具目录或更细粒度工具 Schema 管理时，再考虑 ToolSpec。
Q5：Java Agent 会不会比 Python Agent 框架弱？
不一定。Python 生态工具更多，Java/Spring 的优势是企业工程、部署、权限、观测和系统集成。如果你的业务系统在 Java 体系内，Spring AI 的工程价值很高。
Q6：如何快速入门？
先做一个 ChatClient 调模型 Demo，再加一个 @Tool 工具，随后接入简单向量库，最后尝试 MCP Server。按这个顺序学习，成本最低。
十、总结：Spring AI 正在把 Java 带入 Agent 工程时代
Spring AI 2.0.0-M7 最值得学的地方，不是某个 API 的写法，而是它透露出的架构方向：MCP 负责标准化工具连接，ToolSpec 负责规范化工具定义，Advisor 负责统一治理调用链，Agentic Patterns 负责把任务变成可维护的工作流。
对于普通 Java 开发者，可以从 @Tool 与 ChatClient 入门；对于企业开发团队，建议重点关注 MCP、ToolSpec、权限治理、观测与评估；对于想做 AI Agent 产品的团队，则应该把 Spring AI 看成一个可以承载长期工程化演进的基础框架。
参考资料
• Spring Blog：Spring AI 1.0.8, 1.1.7, 2.0.0-M7 Available Now – https://spring.io/blog/2026/05/23/spring-ai-1-0-8-1-1-7-2-0-0-M7-available-now/
• Spring AI Reference：Introduction – https://docs.spring.io/spring-ai/reference/index.html
• Spring AI Reference：Spring AI API – https://docs.spring.io/spring-ai/reference/api/index.html
• Spring AI Reference：Building Effective Agents – https://docs.spring.io/spring-ai/reference/api/effective-agents.html
• Spring AI Reference：Upgrade Notes – https://docs.spring.io/spring-ai/reference/upgrade-notes.html
• Spring AI Project Page – https://spring.io/projects/spring-ai/
