Spring AI整合MCP协议实战：工具调用、安全认证与企业级部署

在 Spring I/O 2026 大会上，AWS 的 James Ward 和 Maximilian Schellhorn 带来了一场关于 MCP（Model Context Protocol）与 Spring AI 深度整合的演讲。从协议基础到企业级扩展，从安全认证到上下文优化，这场演讲几乎覆盖了 MCP 生态的方方面面。本文将系统梳理其中的核心要点，帮助 Java 开发者快速掌握 MCP 的实战用法。

为什么需要MCP协议

大语言模型（LLM）虽然具备强大的推理能力，但本质上仍然是无状态的——它们无法主动获取实时信息，也无法直接执行外部操作。要构建真正可用的 AI Agent，需要三个核心组件：记忆（对话追踪与上下文管理）、知识（额外的文档和数据）以及工具（按需获取信息和执行操作的能力）。

工具调用（Tool Calling）的基本流程并不复杂：用户提问后，LLM 判断需要调用哪个工具，应用层实际执行调用，再将结果返回给 LLM 做最终的总结输出。这一机制源自 OpenAI 在 2023 年推出的 Function Calling 概念——LLM 并不直接执行函数，而是输出一个结构化的 JSON 对象，声明它想调用哪个函数以及传入什么参数，由应用层负责实际执行并将结果回传。这种设计将 LLM 的推理能力与外部系统的执行能力彻底解耦，是构建 AI Agent 的基础范式。

但问题在于，如果每个开发者都要在自己的代码库中手动编写各种工具函数（获取天气、查询客户、管理任务等），这既低效又难以维护。

MCP 正是为解决这个问题而生——它通过标准化的 JSON-RPC 协议，让任何 MCP 客户端都能连接任何 MCP 服务器，实现即插即用的工具集成。JSON-RPC 是一种轻量级的远程过程调用协议，使用 JSON 作为数据格式，定义了请求（包含方法名和参数）和响应（包含结果或错误）的标准结构。MCP 选择 JSON-RPC 而非 REST 或 gRPC，主要是因为它的双向通信能力和极简的协议开销——一个完整的调用只需要 method、params 和 id 三个字段，天然适合跨语言、跨平台的通信场景。

Spring AI中的MCP实战

基础工具定义与调用

在 Spring AI 中创建 MCP 服务器非常简洁。只需添加 spring-ai-starter-mcp-server-webflux 依赖，然后通过 @McpTool 注解定义工具即可。Spring AI 团队创建了 Java 版的 MCP SDK，并在此基础上封装了 Spring 特性。

演讲者展示了一个最简单的加法工具，并分别在 AWS Kuro 编码助手、IntelliJ IDE 和 MCP Inspector 中进行了调用验证。MCP 的标准化意味着同一个服务器可以无缝对接不同的客户端——这正是协议的核心价值。

MCP工具调用演示

高级工具特性详解

除了基础的工具调用，Spring AI 的 MCP 实现还支持多种高级特性：

输出 Schema 定义：通过设置 generateOutputSchema = true，可以让工具返回结构化的类型对象而非原始文本，客户端能够据此进行类型验证。

日志与进度推送：通过注入 McpSyncRequestContext，服务器可以向客户端发送日志消息和进度更新，这对长时间运行的任务尤其有用。

Elicitation（动态引出）：这是 MCP 的一个较新特性。当某些参数不是每次都必需，但在特定条件下需要用户提供时（比如用户未设置首选航空公司），服务器可以通过 elicitation 机制动态向用户请求输入，然后继续执行工具调用。

Sampling（采样调用）：这是一个更高级的特性，允许 MCP 服务器反向调用客户端侧的 LLM。当服务器本身没有 LLM 访问权限但需要 AI 能力时，可以通过 sampling 机制借用宿主端的 LLM。

Sampling流程演示

Resources、Prompts与MCP Apps

Resources（资源）用于表示文件、数据库记录等内容，分为静态和动态两种。与工具不同，工具是模型控制的（模型决定何时调用），而资源的使用方式取决于应用层——比如 Claude Desktop 会将远程资源像本地文件一样展示给用户。

Prompts（提示模板）提供了一种快捷方式，让 MCP 服务器可以向用户提供预定义的提示模板。这对于引导用户使用特定工作流非常有价值，类似于命令行的 --help。

MCP Apps 是最新的扩展能力，允许在支持富 UI 的 Agent 中渲染 HTML 内容。演讲者展示了一个购物清单应用，它利用 MCP Resources 传递 HTML，通过工具调用触发渲染。Shopify 在 MCP 开发者峰会上也展示了类似的产品搜索场景——用户无需离开聊天环境就能与外部系统交互。

传输方式与远程部署

MCP 的传输层与协议层是解耦的。本地模式通过 stdio（标准输入/输出）通信，远程模式则使用 Streamable HTTP。对于需要服务器主动推送的有状态操作（如 sampling 和 elicitation），会建立 Server-Sent Events（SSE）通道。SSE 是 HTML5 规范中定义的一种服务器向客户端单向推送数据的技术，基于 HTTP 长连接实现。与 WebSocket 的全双工通信不同，SSE 只支持服务器到客户端的单向流，但它的优势在于协议简单、支持自动重连、天然兼容 HTTP 基础设施（代理、负载均衡器等）。在 MCP 的 Streamable HTTP 传输模式中，SSE 负责服务器主动推送场景（如进度通知、日志消息），而客户端到服务器的请求仍使用标准 HTTP POST。

本地与远程MCP服务器对比

演讲者明确建议企业环境优先采用远程 MCP 服务器，主要原因包括：

安全性：本地安装随机 MCP 服务器存在供应链攻击风险。供应链攻击是指攻击者通过篡改软件的依赖项、构建工具或分发渠道来植入恶意代码的攻击方式。近年来，npm、PyPI 等包管理生态频繁遭遇此类攻击。在 MCP 的语境下，本地安装的 MCP 服务器通常以 npm 包或二进制文件的形式分发，如果某个流行的 MCP 服务器包被攻击者劫持并注入恶意代码，所有安装该包的开发者机器都可能被入侵。远程 MCP 服务器通过将执行环境集中化，大幅缩小了攻击面——用户只需信任服务提供方，而非整个分发链路。
易用性：用户只需配置一个 URL 即可连接服务
可维护性：集中更新部署，无需分发本地二进制文件
可扩展性：支持水平扩展和负载均衡

企业级安全：OAuth认证流程

MCP 的授权框架基于 OAuth 标准。OAuth 2.0 是互联网上最广泛使用的授权框架，它允许第三方应用在用户授权下访问受保护资源，而无需暴露用户凭证。在 MCP 的安全架构中，OAuth 负责解决「谁有权调用哪些工具」的问题，这对于企业级部署至关重要——你不会希望任何人都能通过 MCP 服务器执行数据库操作或触发业务流程。

完整的认证流程如下：客户端首次请求返回 401，附带 www-authenticate 头指向受保护资源元数据；客户端获取授权服务器信息；完成客户端注册后获取 JWT Token；最终使用 Token 访问 MCP 服务器。JWT（JSON Web Token）将用户身份和权限信息编码为一个自包含的、经过签名的 JSON 结构，服务端无需查询数据库即可验证令牌的有效性，这种无状态验证特性与 MCP 的分布式架构天然契合。

MCP安全认证架构

客户端注册是当前争论最多的部分。演讲者介绍了三种主流方式：

预注册客户端：最适合企业内部环境，可精确控制哪些客户端能访问
动态客户端注册：已被认为不够安全（公开端点易被滥用）
客户端 ID 元数据文档（新方案）：客户端 ID 本身是一个 HTTPS URL，授权服务器可验证其中的客户端信息，Spring Authorization Server 正在开发对此的支持

水平扩展的挑战与方案

将 MCP 服务器水平扩展面临一个核心挑战：MCP 协议的初始化请求和后续请求需要路由到同一服务器实例。传统的解决方案是 Sticky Session（会话粘滞），即通过负载均衡器确保同一客户端的所有请求都被路由到同一台后端服务器，通常通过设置 Cookie 或基于 IP 哈希来实现。然而，这种方式与云原生架构的弹性伸缩理念相悖：当某个实例被缩容或重启时，绑定在该实例上的会话就会丢失。在 Serverless 环境（如 AWS Lambda、Azure Functions）中，实例的生命周期完全由平台控制，Sticky Session 几乎无法可靠实现。

目前有三种可行的解决路径：

等待协议演进：已有 SEP 提案要消除初始化调用，使协议本身无状态化
启用无状态模式：Spring AI 提供 stateless 配置选项，放弃 sampling 和 elicitation 等有状态特性
基础设施层解决：如 Agent Core Runtime 为每个 MCP 会话分配独立沙箱

演讲者指出，当前大多数 MCP 服务器实际上是无状态的，但随着长时间运行的有状态交互需求增长，协议和基础设施都需要持续进化来支持这些场景。

上下文效率优化：MCP并未过时

针对社区中「MCP 已死，用 CLI 替代」的论调，演讲者进行了深入反驳。当 10 个 MCP 服务器各带 50 个工具时，工具描述确实会占用大量上下文窗口（演示中达到 31%），导致准确性下降和成本增加。

这里需要理解上下文窗口与 Token 经济学的关系。上下文窗口是 LLM 单次推理时能处理的最大 Token 数量，虽然现代模型的上下文窗口已扩展到 128K 甚至更大，但上下文占用直接影响推理成本（按 Token 计费）和响应质量。研究表明，当上下文中无关信息过多时，模型的注意力会被稀释，导致关键信息被忽略——即所谓的「Lost in the Middle」现象。当 500 个工具描述占据了 31% 的上下文窗口时，不仅每次请求的 API 费用显著增加，模型选择正确工具的准确率也会明显下降。

CLI 方案在本地开发场景下可行，但存在明显局限：无法在远程企业部署中使用、缺乏标准化授权机制、且 LLM 使用 CLI 时往往需要多次试错（--help → 尝试参数 → 调整参数），实际消耗的上下文并不少。

真正的解决之道是让 MCP 协议本身更高效：

工具过滤：只给 Agent 提供它实际需要的工具子集，可通过 Spring 的工具过滤机制或集中式网关来管理
渐进式发现：使用「Tool Search Tool」模式，初始上下文中只暴露一个搜索工具，按需动态加载相关工具
Code Mode（实验性）：让 Agent 编写代码来批量执行工具调用，避免多次往返请求，只获取最终结果

总结

MCP 正在从一个简单的工具调用协议演进为完整的 AI Agent 集成标准。Spring AI 的深度整合让 Java 开发者能够以极低的门槛构建和部署 MCP 服务器。从 OAuth 安全认证到水平扩展策略，从有状态交互到上下文效率优化，整个 MCP 生态正在快速走向成熟。对于正在构建 AI Agent 的团队来说，现在是深入了解和采用 MCP 的好时机。