MCP（Model Context Protocol）：让AI真正“能说会做“的协议

MCP（Model Context Protocol）是Anthropic推出的标准化协议，旨在解决AI能说不能做的困境。该协议为AI与外部工具/数据源建立统一接口，支持工具发现、调用和资源访问。MCP采用三层架构（Host-Client-Server）和JSON-RPC通信，包含工具、资源和提示三大核心组件，实现AI与外部世界的安全交互。相比传统插件系统，MCP降低了开发成本，解决了工具碎片化和

Dreamchaser追梦

37人浏览 · 2026-02-07 12:41:22

Dreamchaser追梦 · 2026-02-07 12:41:22 发布

文章目录

一、引言：AI的"工具困境"

1.1 从ChatGPT到Claude：AI能说不能做的尴尬

当我们与ChatGPT或Claude对话时，常常会遇到这样的场景：

用户：“帮我查一下今天北京的天气，然后发邮件给团队”
AI：“抱歉，我无法访问实时天气数据，也无法发送邮件…”

这就是AI的"工具困境"——能说不能做。AI模型虽然拥有强大的语言理解和生成能力，但缺乏与外部世界交互的能力。它们就像被困在信息孤岛中的智者，知道如何解决问题，却无法真正执行。

1.2 传统解决方案的局限性

为了解决这个问题，业界尝试了多种方案：

Prompt Engineering时代：通过精心设计的提示词，让AI"假装"能执行操作，但本质上只是文本生成。

Plugins时代：每个AI平台（如ChatGPT）都需要单独开发插件系统，开发者需要为不同平台重复开发，成本高昂。

Function Calling时代：让AI可以调用预定义的函数，但存在以下痛点：

工具定义分散，难以统一管理
上下文管理困难，多轮对话中工具状态容易丢失
缺乏标准化，每个平台都有自己的实现方式

1.3 MCP的诞生：一个标准化的解决方案

2024年，Anthropic推出了Model Context Protocol（MCP），旨在为AI与外部工具/数据源之间建立一个标准化的通信协议。MCP就像USB-C接口一样，统一了各种设备的连接标准，让AI能够真正"能说会做"。

二、MCP是什么？

2.1 定义

MCP（Model Context Protocol），即模型上下文协议，是一个开放标准，用于AI应用与外部数据源和工具之间的安全、结构化通信。

2.2 核心定位

MCP的核心定位是：AI与外部工具/数据源的"通用接口"。

它不关心具体的工具实现，只定义了一套标准化的通信协议，让AI能够：

发现可用的工具
调用工具执行操作
访问外部资源
获取实时数据

2.3 类比理解

想象一下，如果没有USB-C接口，每个设备都需要自己的充电线和数据线，那将是多么混乱的场景。MCP就是AI世界的"USB-C接口"：

统一标准：所有工具都遵循同一套协议
即插即用：工具可以轻松接入和移除
安全可靠：内置权限控制和错误处理机制

三、MCP的背景与由来

3.1 AI工具集成的演进史

让我们回顾一下AI工具集成的发展历程：

Prompt Engineering时代（2020-2022）

特点：通过精心设计的提示词，让AI"假装"能执行操作
局限：本质上只是文本生成，无法真正执行

Plugins时代（2022-2023）

特点：各AI平台推出自己的插件系统
局限：开发者需要为不同平台重复开发，生态碎片化

Function Calling时代（2023-2024）

特点：AI可以直接调用预定义的函数
局限：缺乏统一标准，上下文管理困难

MCP时代（2024至今）

特点：标准化协议，统一生态
优势：一次开发，多平台复用

3.2 现有系统的痛点

在MCP出现之前，AI工具集成面临以下痛点：

工具碎片化
- 每个AI平台需要单独适配
- 开发者需要重复开发相同功能
- 生态割裂，难以形成统一标准
上下文管理困难
- 多轮对话中工具状态容易丢失
- 无法跨会话保持工具状态
- 上下文信息难以有效管理
开发成本高
- 需要为每个平台单独开发
- 缺乏统一的开发工具和文档
- 调试和维护成本高
安全性问题
- 缺乏统一的权限控制机制
- 工具调用缺乏安全验证
- 数据访问权限管理混乱

3.3 Anthropic推出MCP的动机

Anthropic推出MCP的动机很明确：

统一生态：建立AI工具集成的统一标准
降低门槛：让开发者更容易为AI应用开发工具
提升体验：让AI能够真正与外部世界交互
开放标准：推动整个AI生态的发展

四、MCP的核心原理

4.1 架构设计

MCP采用三层架构设计：

Host（宿主）

运行AI模型的平台
例如：Claude Desktop、其他AI应用
负责管理Client和Server之间的连接

Client（客户端）

AI应用本身
例如：Claude模型
负责理解用户意图，选择并调用合适的工具

Server（服务器）

提供工具和资源的服务端
例如：文件系统服务器、数据库服务器、API服务器
负责执行具体的操作，返回结果

4.2 三大核心组件

MCP定义了三大核心组件：

Tools（工具）

定义：可执行的操作
示例：搜索、计算、API调用、文件操作
特点：有输入参数，返回执行结果
用途：让AI能够执行具体操作

Resources（资源）

定义：可读取的数据
示例：文件、数据库表、API数据
特点：只读访问，提供数据内容
用途：让AI能够访问外部数据源

Prompts（提示）

定义：可复用的提示模板
示例：代码审查模板、数据分析模板
特点：预定义的提示词，可动态填充
用途：提高AI处理特定任务的效率

4.3 工作流程

MCP的完整工作流程如下：

流程说明：

用户请求：用户提出需求
意图理解：AI分析用户意图，确定需要哪些工具
工具发现：AI向MCP Server查询可用工具
工具选择：AI根据需求选择合适的工具
工具执行：AI调用工具，Server执行操作
结果返回：Server返回执行结果
结果整合：AI整合多个工具的结果
用户回答：AI生成最终回答返回给用户

4.4 通信协议

MCP基于JSON-RPC 2.0协议，支持双向通信：

协议特点：

标准化：基于JSON-RPC 2.0，成熟可靠
双向通信：支持Client和Server之间的双向消息传递
多种传输方式：支持stdio、HTTP、SSE等多种传输方式
类型安全：强类型定义，减少错误

五、MCP在Agent中的应用原理

5.1 Agent的定义与特点

**Agent（智能体）**是能够自主决策、使用工具、进行多轮交互的AI系统。与传统的对话AI不同，Agent具有以下特点：

自主决策：能够根据目标自主选择行动
工具使用：能够调用外部工具完成任务
多轮交互：能够进行复杂的多步骤任务
状态管理：能够维护任务执行状态

5.2 MCP如何赋能Agent

MCP为Agent提供了强大的能力支持：

动态上下文管理

Agent可以实时获取最新数据
支持动态加载和更新上下文信息
确保Agent始终使用最新的数据

工具发现机制

Agent启动时自动发现所有可用工具
支持运行时动态发现新工具
无需手动配置工具列表

状态持久化

跨会话保持工具状态
支持任务中断和恢复
维护长期记忆

多工具编排

Agent可以组合多个工具完成任务
支持工具之间的依赖关系
实现复杂的多步骤任务

5.3 实际应用场景

场景1：智能助手Agent

功能：

查询天气、发送邮件、管理日程
根据用户需求自动选择工具
整合多个工具的结果

场景2：数据分析Agent

功能：

连接数据库、生成报表、数据可视化
理解自然语言查询，转换为SQL
自动生成图表和报告

场景3：代码助手Agent

功能：

读取代码库、执行测试、部署应用
代码审查、bug修复、重构建议
自动化开发流程

5.4 多Agent协作中的MCP

在多Agent系统中，MCP充当"工具总线"的角色：

优势：

工具共享：多个Agent共享同一套工具集
统一管理：集中管理工具权限和配置
资源复用：避免重复开发相同功能
协作支持：Agent之间可以协作完成任务

六、MCP的优势

6.1 标准化带来的好处

优势	说明
一次开发，多平台复用	开发一个MCP Server，可以在多个AI平台使用
降低集成成本	无需为每个平台单独开发适配
生态统一	形成统一的工具生态，便于管理和维护

6.2 技术优势

类型安全

强类型定义，减少运行时错误
工具参数和返回值都有明确的类型定义
IDE支持自动补全和类型检查

安全性

内置权限控制机制
支持沙箱隔离
工具调用需要明确授权

可扩展性

插件化架构，易于扩展
支持动态加载和卸载工具
不影响核心系统稳定性

可观测性

完整的日志记录
支持监控和追踪
便于调试和问题排查

6.3 开发体验优势

开发工具完善

提供完善的SDK和文档
支持多种编程语言
丰富的示例代码

调试友好

清晰的错误信息
支持本地调试
便于问题定位

社区支持

活跃的开源社区
丰富的工具库
及时的技术支持

6.4 对比分析

特性	MCP	传统Function Calling	自定义API集成
标准化	✅ 统一标准	❌ 各平台不同	❌ 完全自定义
复用性	✅ 一次开发多平台使用	❌ 需要适配	❌ 需要适配
类型安全	✅ 强类型定义	⚠️ 部分支持	❌ 无
工具发现	✅ 自动发现	❌ 手动配置	❌ 手动配置
安全性	✅ 内置权限控制	⚠️ 需要自行实现	⚠️ 需要自行实现
开发成本	✅ 低	⚠️ 中	❌ 高

七、MCP的劣势与挑战

7.1 核心问题：MCP服务器过多导致的Token暴涨

虽然MCP带来了诸多优势，但在实际应用中，特别是Agent场景下，存在一个严重的性能问题：

问题现象：

当Agent连接多个MCP服务器时，上下文token数量急剧增长
10个MCP服务器可能消耗数万tokens
占用模型上下文窗口的30-50%

实际影响：

成本飙升：token消耗增加，API调用成本大幅上升
响应变慢：上下文过大，模型处理时间增加
可能超出限制：超出模型上下文窗口限制，导致任务失败

7.2 Token暴涨的原理

根本原因

每个MCP服务器的Tools、Resources、Prompts信息都需要加载到Agent的上下文中，这些信息会随着服务器数量线性增长。

累积效应

具体分析：

工具描述信息累积
- 每个工具需要包含：名称、描述、参数定义、参数说明
- 单个工具描述约200 tokens
- 10个服务器，每个5个工具 = 10,000 tokens
资源元数据膨胀
- Resources的URI、描述、类型信息都需要加载
- 文件系统服务器可能提供数百个文件资源
- 每个资源描述约100 tokens
Prompt模板累积
- 每个MCP服务器可能提供多个Prompt模板
- 即使不使用，也会完整加载到上下文
- 单个模板约300 tokens
执行结果保留
- 工具执行的结果会保留在对话历史中
- 多轮对话中，历史信息不断累积
- 无法自动清理，token持续增长

Token增长过程

数量级估算：

单个MCP Server：约2000 tokens（工具+资源+提示）
10个MCP Server：约20,000 tokens
加上执行结果和对话历史：可能达到30,000-50,000 tokens
对于128K上下文窗口的模型，可能占用30-50%

7.3 缓解策略

虽然token暴涨是MCP的一个挑战，但可以通过以下策略缓解：

1. 按需加载（Lazy Loading）

不在初始化时加载所有工具
根据用户需求动态加载相关工具
减少初始token消耗

2. 描述压缩

精简工具和资源的描述信息
只保留必要的参数说明
使用缩写和简化描述

3. 上下文管理

定期清理不活跃的工具信息
使用工具摘要而非完整描述
实现智能的上下文压缩

4. 服务器合并

将相关功能的服务器合并
减少服务器数量
统一管理相关工具

7.4 其他挑战

除了token暴涨问题，MCP还面临以下挑战：

生态成熟度

相对较新，工具库还不够丰富
社区规模较小，资源有限
需要时间发展成熟

性能考虑

网络延迟（如果Server在远程）
JSON序列化/反序列化开销
多服务器并发调用的性能影响

兼容性

主要支持Claude系列模型
其他AI平台的适配度有限
需要各平台逐步支持

八、MCP与其他方案的对比

8.1 MCP vs Agent + Function Call

架构对比

MCP架构：

统一的Server层管理工具
工具发现和调用标准化
支持跨平台复用

Function Call架构：

直接调用函数，无中间层
需要手动管理工具
平台特定实现

适用场景

场景	MCP	Function Call
多平台支持	✅ 适合	❌ 不适合
工具复用	✅ 适合	❌ 不适合
简单场景	⚠️ 可能过度设计	✅ 适合
复杂工具生态	✅ 适合	⚠️ 管理困难

8.2 MCP vs LangChain Tools

设计理念差异：

MCP：协议层，定义通信标准，不关心具体实现
LangChain Tools：框架层，提供工具抽象和编排能力

使用场景对比：

特性	MCP	LangChain Tools
定位	协议标准	开发框架
跨平台	✅ 是	❌ 否
工具发现	✅ 自动	⚠️ 手动配置
生态	⚠️ 较新	✅ 成熟

九、实践建议

9.1 何时选择MCP？

适合使用MCP的场景：

✅ 多平台支持需求

需要为多个AI平台提供工具
希望一次开发，多平台复用

✅ 复杂工具生态

有大量工具需要管理
需要统一的工具发现和管理机制

✅ 标准化需求

希望遵循行业标准
需要与其他系统互操作

✅ 长期维护

工具需要长期维护和更新
希望降低维护成本

不适合使用MCP的场景：

❌ 简单场景

只有少量简单工具
不需要跨平台支持

❌ 性能敏感

对延迟要求极高
无法接受token开销

❌ 平台特定

只在一个平台使用
不需要标准化

9.2 如何开始使用MCP？

第一步：了解MCP规范

阅读官方文档
理解协议规范
熟悉JSON-RPC 2.0

第二步：选择开发语言

MCP支持多种语言（Python、TypeScript、Go等）
选择熟悉的语言开始

第三步：开发MCP Server

实现Tools、Resources、Prompts
遵循MCP规范
编写测试用例

第四步：集成到AI应用

在AI应用中连接MCP Server
测试工具调用
优化性能

9.3 最佳实践

1. 工具设计

保持工具功能单一，职责明确
提供清晰的工具描述和参数说明
实现合理的错误处理

2. 性能优化

避免加载过多不必要的工具
精简工具描述信息
实现按需加载机制

3. 安全性

实现权限控制
验证输入参数
限制资源访问范围

4. 可维护性

编写清晰的文档
提供示例代码
保持代码简洁

十、工程实践：Spring AI集成MCP服务

10.1 Spring AI简介

Spring AI是Spring生态系统中的AI应用开发框架，提供了统一的API来集成各种AI模型和服务。在MCP集成方面，Spring AI通过标准化的接口和抽象层，简化了MCP服务的开发和使用。

Spring AI的核心定位：

提供统一的AI应用开发框架
简化AI模型和工具的集成
支持多种AI服务提供商
提供MCP协议的标准实现

10.2 Spring AI的核心架构

Spring AI采用分层架构设计，通过抽象层屏蔽底层实现细节：

10.3 Spring AI的关键接口

Spring AI为了连接MCP服务器，需要实现以下标准接口：

1. ToolProvider接口

作用：工具提供者，负责向Agent提供可用的工具列表。

public interface ToolProvider {
    /**
     * 获取所有可用的工具定义
     */
    List<ToolDefinition> getTools();
    
    /**
     * 执行工具调用
     */
    ToolExecutionResult execute(ToolExecutionRequest request);
}

关键方法：

getTools()：返回工具列表，Agent通过此方法发现可用工具
execute()：执行工具调用，处理具体的业务逻辑

2. ToolDefinition接口

作用：定义工具的元数据信息。

public interface ToolDefinition {
    String getName();           // 工具名称
    String getDescription();    // 工具描述
    Map<String, Object> getParameters();  // 参数定义（JSON Schema格式）
}

关键属性：

name：工具的唯一标识
description：工具的功能描述（会占用token）
parameters：参数定义，遵循JSON Schema规范

10.4 编写MCP服务示例

Spring AI提供了基于注解的简化方式来创建MCP服务器，让开发者可以快速上手。下面是一个简单的示例：

参考文档：Spring AI MCP Getting Started Guide

简单的MCP服务器示例

使用Spring AI的注解方式，只需几行代码即可创建一个MCP服务器：

@Service
public class WeatherService {

    @McpTool(description = "Get current temperature for a location")
    public String getTemperature(
            @McpToolParam(description = "City name", required = true) String city) {
        return String.format("Current temperature in %s: 22°C", city);
    }
}

添加依赖：

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-mcp-server-webmvc</artifactId>
</dependency>

配置文件：

spring.ai.mcp.server.protocol=STREAMABLE

这样，Spring AI会自动将标注了@McpTool的方法暴露为MCP工具，无需手动实现复杂的接口和配置。更多详细示例和高级用法，请参考Spring AI官方文档。

10.5 SSE模式下的通信交互

SSE（Server-Sent Events）是MCP协议中一种重要的传输方式，特别适合需要流式传输和实时反馈的场景。与传统的HTTP请求-响应模式不同，SSE允许服务器主动向客户端推送数据，实现单向流式通信。

10.5.1 SSE模式的特点

SSE模式的优势：

流式传输：支持实时推送数据，无需轮询
单向通信：服务器到客户端的单向数据流
自动重连：浏览器/客户端自动处理连接断开和重连
简单易用：基于标准HTTP协议，无需特殊协议

适用场景：

需要实时反馈的工具执行（如长时间运行的任务）
流式数据返回（如日志输出、进度更新）
服务器主动推送通知

10.5.2 SSE消息格式

SSE协议使用特定的文本格式传输数据：

# 标准SSE消息格式
event: message
id: 12345
data: {"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text","text":"北京今天晴天"}]}}

# 进度更新消息
event: progress
data: {"type":"progress","message":"正在查询天气数据..."}

# 心跳消息
event: ping
data: {}

# 错误消息
event: error
data: {"code":-32603,"message":"Internal error"}

关键字段说明：

event：事件类型（message/progress/error/ping）
id：消息ID（用于重连后恢复）
data：实际数据（JSON格式的JSON-RPC响应）

10.5.3 SSE模式与其他传输方式对比

特性	SSE	HTTP	STDIO	WebSocket
通信方向	单向（服务器→客户端）	双向（请求-响应）	双向（标准输入输出）	双向（全双工）
流式传输	✅ 原生支持	❌ 需要特殊处理	✅ 支持	✅ 支持
实时性	✅ 高	⚠️ 中等	✅ 高	✅ 高
复杂度	⭐⭐ 简单	⭐ 最简单	⭐⭐⭐ 中等	⭐⭐⭐⭐ 复杂
适用场景	流式数据、进度更新	简单请求-响应	本地进程通信	实时双向通信
浏览器支持	✅ 原生支持	✅ 原生支持	❌ 不支持	✅ 原生支持

10.6 MCP Client与Server的交互流程

MCP客户端与服务器之间的完整交互流程包括三个阶段：连接初始化、工具发现和工具调用。下图展示了从初始化到工具调用的完整通信过程：

流程说明：

初始化阶段
- 应用启动时创建MCP客户端
- 建立传输层连接（HTTP/STDIO等）
- 发送initialize请求，获取服务器能力
工具发现阶段
- Agent通过ToolProvider.getTools()获取工具列表
- MCP客户端发送tools/list请求
- 服务器返回工具定义（名称、描述、参数）
- Agent将工具信息加载到上下文中
工具执行阶段
- 用户提出需求，Agent分析并选择工具
- 调用ToolProvider.execute()执行工具
- MCP客户端发送tools/call请求，携带参数
- 服务器执行工具逻辑，返回结果
- Agent整合结果，生成最终回答