Spring AI 大模型应用开发实战流程:MCP(Model Context Protocol)篇
(2026年1月视角 · 生产级实用指南)
MCP 是目前(2026年初)最被看好的下一代工具/资源/上下文标准化协议,由 Anthropic 发起,已被 Spring AI 深度集成,成为 Java 生态构建复杂 Agent、多工具系统、跨服务上下文共享的最主流选择之一。
MCP vs 传统 Function/Tool Calling 对比(2026现状)
| 维度 | 传统 Function Calling | MCP (Model Context Protocol) | 谁赢?(生产视角) |
|---|---|---|---|
| 标准化程度 | 各家模型自己定义 | 开放协议(类似 USB-C) | MCP ★★★★★ |
| 工具发现机制 | 基本靠硬编码/每次传 | 自动发现 + 动态更新 + 通知机制 | MCP 大胜 |
| 支持能力类型 | 主要 Tool/Function | Tool + Resource + Prompt Template + Sampling | MCP 更全面 |
| 部署方式 | 全塞在一个应用里 | 独立轻量 MCP Server(可分布式) | MCP 更解耦、更可扩展 |
| 跨团队/跨系统复用 | 差 | 极好(生态已出现大量预制 Server) | MCP 完胜 |
| Spring AI 支持度 | 原生很好 | 非常完善(Client/Server 双 Starter) | 平手 |
| 目前生态成熟度 | 很高 | 快速上升中(2025年底~2026年爆发) | Function Calling 暂领先 |
| 未来潜力(2~3年) | 中等 | 极高(已成为 Agent 基础设施候选) | MCP 占优 |
一句话总结:
短期用 Function Calling 最快落地,长期想做复杂、可维护、可组合的 Agent 系统 → MCP 是更未来的选择。
Spring AI 中 MCP 的典型实战开发流程(2026推荐路径)
阶段1:理解核心概念与角色分工
- MCP Client:通常是你核心的 Spring AI 应用(ChatClient 所在的项目)
- 负责连接多个 MCP Server
- 自动发现工具/资源/prompt
- 把发现的能力注册成 ToolCallback 给大模型用
- MCP Server:独立的小服务(可以很多个)
- 每个 Server 只负责一类能力(单一职责)
- 常见类型:文件系统、数据库、天气API、企业内部系统、知识库、计算器等
- 传输方式:stdio(本地进程)、SSE/http(远程)、未来可能有更多
- 三种主要能力(MCP 比传统 Tool Calling 丰富的地方):
- Tools → 可执行函数(类似传统 function calling)
- Resources → 只读资源获取(文件内容、数据库记录、API响应等)
- Prompts → 标准化 Prompt 模板(可参数化复用)
阶段2:最快跑通 Hello MCP(推荐起步方式)
方式A:本地 stdio 最快(开发/调试首选)
- 新建 MCP Server 项目(天气预报示例)
<!-- MCP Server 核心依赖(2026年最新稳定) -->
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-starter-mcp-server</artifactId>
</dependency>
<!-- 或使用 webflux/sse 远程方式 -->
<!-- <artifactId>spring-ai-starter-mcp-server-webflux</artifactId> -->
- 定义一个简单 Tool
@McpTool(name = "get_weather", description = "获取指定城市当前天气")
public WeatherInfo getWeather(
@McpParam("city") String city,
@McpParam(value = "date", required = false) String date) {
// 模拟调用真实天气API
return weatherApi.get(city, date);
}
- 启动 Server(stdio方式最简单)
# 推荐使用 npx 或直接 java -jar 启动
java -jar mcp-weather-server.jar
方式B:Client端连接(最常见生产方式 – SSE远程)
spring:
ai:
mcp:
client:
streamable-http: # 或 stdio、其他transport
connections:
weather:
url: http://weather-mcp.yourdomain.com:8080
calculator:
url: http://localhost:9090 # 另一个计算器服务
files:
url: stdio:npx @mcp/filesystem ./data
- 使用方式几乎和普通 Tool Calling 一模一样!
String response = chatClient.prompt()
.user("明天上海天气怎么样?顺便算一下 28℃ 转 华氏度是多少?")
.call()
.content();
大模型会自动发现并调用多个 MCP Server 提供的工具。
阶段3:典型生产级 MCP 架构推荐(2026主流做法)
[前端/业务系统]
↓
[核心 Agent 应用 (MCP Client)]
├── MCP Client (自动发现&注册所有工具)
├── ChatClient / ChatModel
└── 连接 ↓ (多路)
├── MCP Server - 文件系统(本地/共享盘)
├── MCP Server - 企业知识库(RAG专用)
├── MCP Server - 内部CRM/ERP API
├── MCP Server - 实时计算/风控引擎
└── MCP Server - 第三方服务(天气/股票/翻译...)
优点:
- 解耦极强:每个业务域维护自己的 MCP Server
- 权限隔离更容易
- 可独立升级/灰度
- 工具可复用给多个 Agent/多个团队
阶段4:进阶必知点(生产必踩&必会)
- 动态工具更新(2025下半年~2026大热功能)
- Server 工具新增/删除会主动通知 Client
- Client 可热更新可用工具列表
- 安全与权限(最重要!)
- 使用
McpToolFilter做运行时鉴权 - 建议每个 Server 带用户上下文(JWT/Principal)
- 性能与稳定性
- SSE 连接建议设置心跳
- 重要 Server 做高可用(多实例 + 负载均衡)
- 国产模型兼容现状(2026.1)
- 通义千问、DeepSeek、豆包、智谱 → 基本都已支持 MCP 调用
- 部分模型在采样(sampling)和 resource 获取上还有细微差异
总结:2026年 MCP 实战推荐选择路径
业务复杂度/长期性 推荐方案
─────────────────────
简单Demo/快速验证 → 传统 @Tool / Function Calling
中型项目、稳定需求 → 传统 Function + Advisors
复杂Agent、多系统集成 → MCP(强烈推荐)
大型企业、生态化建设 → MCP + 自建多个领域 Server(终极形态)
MCP 正在成为 Java 体系里“下一代 Agent 基础设施”最有力的候选。
想深入某个具体场景(文件系统操作、企业内部系统对接、动态工具热更新、多 Server 权限管理、国产模型最佳实践等),欢迎继续提问!🚀