大模型上下文协议（MCP）：AI 应用的“USB-C”接口技术

香菜TTT2026-09-17 20:04

摘要

在 AI 应用爆发式增长的今天，如何让大语言模型高效、安全地连接外部工具和数据源，成为了开发者面临的核心挑战。模型上下文协议（Model Context Protocol，MCP）作为 Anthropic 于 2024 年底推出的开放标准，正在成为解决这一问题的关键方案。本文将从技术架构、协议原理、工程实践三个维度，深入剖析 MCP 协议的设计思想与实现细节。

一、为什么需要 MCP？

1.1 碎片化的工具集成困境

在 MCP 出现之前，AI 开发者面临着一个典型的 N × M 集成陷阱 ：如果你想让 NNN 个大模型（如 Claude、GPT、Llama）连接到 MMM 个数据源或工具（如 GitHub、Slack、SQL 数据库），理论上需要编写并维护 N×MN \times MN×M 个不同的集成接口。

这种碎片化带来的问题包括：

  • 重复开发：每个工具都需要单独适配，尽管认证、请求、响应解析的逻辑高度相似
  • 契约不稳定：不同模型的 Function Calling 接口和 Prompt 格式各不相同
  • 上下文割裂：A 工具查到的认证信息，B 工具无法直接复用

用一个数学公式来表达这种复杂度：

Ctraditional=N×MC_{traditional} = N \times MCtraditional=N×M

其中 CCC 表示集成成本，NNN 为模型数量，MMM 为工具数量。

1.2 MCP 的解决思路

MCP 的核心设计目标是：让任何 AI 模型能够用同一种方式，连接任何外部工具和数据源。

通过引入统一的协议层，MCP 将集成复杂度从乘法降为加法：

CMCP=N+MC_{MCP} = N + MCMCP=N+M

这意味着：每个模型只需实现一次 MCP 客户端，每个工具只需实现一次 MCP 服务器，即可实现任意组合的互联互通。

二、MCP核心架构

2.1 客户端-主机-服务器模型

MCP 协议架构是经典的**客户端-主机-服务器（Client-Host-Server）**模型，包含三个核心角色：

角色 职责 示例
Host（主机） AI 应用的运行环境，负责整体调度和安全策略 Claude Desktop、Cursor、自定义 Agent
Client（客户端） 嵌入在 Host 中，管理与 Server 的连接和会话 MCP 客户端实例
Server（服务器） 对外暴露工具和数据源 GitHub Server、SQL Server

这种架构的关键设计原则是关注点分离：

  • Host 只负责 AI 推理和用户交互
  • Client 只负责通信协议
  • Server 只负责具体工具的实现

2.2 协议层与传输层

MCP 的架构分为两个层次：

协议层（Protocol Layer） 处理消息帧、请求/响应链接和高级通信模式。核心类包括：

typescript 复制代码 
class Protocol<Request, Notification, Result> {
  // 处理请求-响应模式
  // 处理通知模式
}

传输层（Transport Layer） 处理客户端和服务器之间的实际通信，支持多种传输机制：

  1. Stdio 传输：使用标准输入/输出进行通信，适用于本地进程
  2. HTTP + SSE 传输：使用 Server-Sent Events 进行服务器到客户端的消息推送，使用 HTTP POST 进行客户端到服务器的消息发送

对于个人开发者和小型团队，Stdio 模式是最简单的启动方式------不需要任何额外配置，Python 或 Node.js 脚本直接就能跑起来。

2.3 消息格式：JSON-RPC 2.0

MCP 的所有通信消息都采用 JSON-RPC 2.0 格式。这是一个轻量级的远程调用协议，格式简单，解析容易。

MCP 定义了四种消息类型：

消息类型 描述 是否包含 ID
请求（Request） 期望获得响应的消息 是
结果（Result） 对请求的成功响应 是
错误（Error） 表示请求失败 是
通知（Notification） 不需要响应的单向消息 否

请求消息的结构如下：

json 复制代码 
{
  "jsonrpc": "2.0",
  "id": "request-123",
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": {
      "location": "San Francisco"
    }
  }
}

这种格式的好处是：它跟具体模型无关。不管你用的是 Claude、GPT 还是 DeepSeek，只要它们能发送 JSON-RPC 请求，就能和 MCP Server 通信。

三、核心原语：Tools、Resources、Prompts

MCP 协议定义了三种核心原语（Primitive），分别对应不同的能力：

3.1 Tools（工具）

Tools 是 Agent 可以调用的函数，是"主动"的------Agent 决定何时调用。

每个 Tool 包含以下关键字段：

  • name：工具的唯一标识符
  • title：人类可读的显示名称
  • description：详细说明工具的功能和使用场景
  • inputSchema：JSON Schema 格式的输入参数定义
json 复制代码 
{
  "name": "weather_current",
  "title": "获取当前天气",
  "description": "获取指定位置的当前天气信息",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "城市名称"
      },
      "units": {
        "type": "string",
        "enum": ["metric", "imperial"],
        "default": "metric"
      }
    },
    "required": ["location"]
  }
}

3.2 Resources（资源）

Resources 是 MCP Server 暴露的数据源，是"被动"的------Agent 按需读取。

资源可以是静态的（如一个 Markdown 文件），也可以是动态的（如实时读取的日志流）。MCP 支持订阅模式，当底层数据发生变化时，Server 会通过 JSON-RPC 通知主动推送更新。

3.3 Prompts（提示模板）

Prompts 是预定义的 Prompt 片段，可以复用。

例如，一个专门用于"金融审计"的 MCP Server 可以提供一套标准的 Prompt 模板。当用户选择该模板时，模型会自动获得必要的背景知识引导，从而大幅降低由于提示词质量差导致的幻觉。

3.4 三种原语的对比

原语 控制方 用途 类比
Tools 模型控制 执行动作 函数调用
Resources 应用控制 读取数据 文件读取
Prompts 用户控制 交互模板 快捷指令

四、能力协商与生命周期管理

4.1 初始化握手

MCP 会话的生命周期始于能力协商握手 。客户端发送 initialize 请求，双方交换关键信息：

json 复制代码 
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "elicitation": {},
      "roots": {"listChanged": true}
    },
    "clientInfo": {
      "name": "my-ai-app",
      "version": "1.0.0"
    }
  }
}

初始化的核心目的包括：

  1. 协议版本协商：确保双方使用兼容的协议版本
  2. 能力发现：声明各自支持的功能特性
  3. 身份交换：提供调试和兼容性所需的信息

4.2 能力声明

服务器在响应中声明其支持的能力：

json 复制代码 
{
  "protocolVersion": "2025-06-18",
  "capabilities": {
    "tools": {"listChanged": true},
    "resources": {"subscribe": true, "listChanged": true},
    "prompts": {"listChanged": true}
  },
  "serverInfo": {
    "name": "weather-server",
    "version": "2.1.0"
  }
}

能力协商的数学表达可以理解为：

Capabilitiessession=Capabilitiesclient∩CapabilitiesserverCapabilities_{session} = Capabilities_{client} \cap Capabilities_{server}Capabilitiessession=Capabilitiesclient∩Capabilitiesserver

只有双方都声明支持的能力，才能在会话中使用。

4.3 工作流程

MCP的核心工作流程是一个客户端-服务器协作的闭环，整体分为7个阶段:

1)初始化连接：主机应用启动后，MCP Client与MCP Server建立连接。一个主机可以同时连多个Server，每个Server负责不同的工具和资源。

2)获取工具列表：Client 从Server拉取可用的工具清单，包括每个工具的名称、参数、用途描述。这一步相当于"能力注册"，让模型知道手里有哪些牌可以打。

3)构造Function Calling请求：用户输入问题后，Client把工具描述和用户问题一起打包发给LLM。传输格式是结构化的Function Calling，告诉模型"你现在能调用这些函数"。

4)模型智能决策：LLM根据上下文和工具信息，判断是否需要调用外部工具、调用哪个、传什么参数。比如用户问天气，模型就会选择getWeather工具并填入城市参数。

5)工具调用执行：如果模型决定调用工具，Client把调用请求转发给Server，Server负责实际执行一一跑脚本、查数据库、调API，然后把结果返回。

6)结果整合：工具执行结果传回LLM，模型把这个结果和原始问题、对话上下文糅在一起，生成最终的自然语言回答。

7)用户响应输出：Client把模型生成的回答展示给用户，完成一次完整的人机协作。

五、传输层详解

5.1 Stdio 传输

Stdio 传输适用于本地进程通信：

  • MCP Server 作为子进程启动
  • 通过 stdin/stdout 和 Client 通信
  • 部署简单，延迟极低
  • 只能本地使用，无法跨机器调用
python 复制代码 
# 启动 MCP Server 子进程
process = subprocess.Popen(
    ["python", "weather_server.py"],
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE
)

5.2 HTTP + SSE 传输

SSE 传输适用于远程服务：

  • MCP Server 作为独立的网络服务运行

  • Client 通过 HTTP 请求建立长连接

  • Server 通过 SSE 推送事件

  • 适合生产环境

    Client Server
    | |
    |-- POST /mcp/message --------->| (客户端到服务器)
    |<-- SSE /mcp/sse --------------| (服务器到客户端)
    | |

5.3 传输层对比

特性 Stdio HTTP + SSE
适用场景 本地集成 远程服务
部署复杂度 低 中
跨机器支持 否 是
延迟 极低 取决于网络
安全性 进程隔离 需要额外认证

六、工程实践：构建 MCP 服务器

6.1 服务器开发要点

根据 MCP 协议定义，Server 可以提供三种能力：

  1. Tools：可调用的函数
  2. Resources：可读取的数据源
  3. Prompts：预定义的提示模板

一个典型的 MCP Server 实现框架：

python 复制代码 
from mcp import Server, Tool

server = Server("weather-server")

@server.tool("weather_current")
async def get_current_weather(location: str, units: str = "metric"):
    """获取指定位置的当前天气"""
    # 实现天气查询逻辑
    return {"temperature": 22, "conditions": "sunny"}

@server.resource("weather://forecast/{city}")
async def get_forecast(city: str):
    """获取天气预报"""
    # 实现预报查询逻辑
    return forecast_data

6.2 客户端集成流程

客户端的核心工作流程包括：

  1. 依赖管理：使用 AsyncExitStack 管理异步上下文
  2. 环境变量配置：通过 dotenv 加载配置，避免硬编码敏感信息
  3. 动态工具发现 ：调用 session.list_tools() 获取可用工具
  4. 工具调用闭环 ：当大模型返回 finish_reason == "tool_calls" 时，自动解析参数并调用工具
python 复制代码 
async def process_query(session, query):
    # 动态发现工具
    tools = await session.list_tools()
    
    # 转换为 OpenAI Function Calling 格式
    tools_schema = convert_to_openai_format(tools)
    
    # 调用大模型
    response = await llm.chat(query, tools=tools_schema)
    
    # 处理工具调用
    if response.finish_reason == "tool_calls":
        result = await session.call_tool(
            response.tool_name,
            response.tool_arguments
        )
        # 将结果追加到上下文，再次请求大模型
        return await llm.chat(query, tool_result=result)

七、MCP 与其他协议的对比

7.1 协议层次定位

MCP 在 AI 协议生态中的定位可以用以下层次图表示：

层次 协议 用途
代理间通信 A2A、ACP Agent 之间的协商与协作
上下文提供 MCP Agent 访问工具和数据
服务接口 OpenAPI、GraphQL 传统 API 规范
传输层 HTTP、gRPC 底层通信

MCP 专注于代理如何访问工具和数据，而不涉及代理之间的对话。

7.2 MCP vs 传统 Function Calling

维度 Function Calling MCP
集成方式 每个工具单独适配 标准化协议
工具发现 静态配置 动态发现
跨模型兼容 依赖模型实现 模型无关
上下文共享 有限 完整支持
开发效率 低 高

7.3 MCP与Skills有什么区别？分别适用于什么场景？

（1），MCP给Agent提供"工具"，Skills给Agent提供"方法论" ，两者解决的是完全不同层面的问题。

MCP全称Model Context Protocol，是一套标准化的工具调用协议 ，让AI Agent 能调用外部服务 。查数据库、调API 。

读文件系统，都是通过MCP来实现的。它解决的是Agent"能不能做"的问题。

（2），Skills是一套指令文档，告诉Agent遇到某类任务应该怎么做、按什么顺序做、要注意什么。它解决的是Agent"会不会做"和"做得好不好"的问题。

MCP相当于给厨师配了一套厨具，锅碗瓢盆、烤箱微波炉；Skils相当于给厨师一本菜谱，红烧肉先焯水再上色，火候多大放多少料。光有工具不知道怎么用，做不出好菜；光有菜谱没有工具，也做不了饭。

(3)，两者的协作关系

实际的Agent系统中，MCP和Skills通常是配合使用的。看一个典型场景：

用户说："帮我创建一个MCP Server"

Agent的处理流程是这样的:

首先系统识别出这是一个"创建MCP Server"的任务，加载对应的Skil。然后Agent 读取Skill中定义的标准流程，包括创建项目结构、写Server 代码、配置Transport、注册 Tools等步骤。在执行过程中，Agent 通过 MCP协议调用文件系统工具来创建文件、调用终端工具来安装依赖。

（4）Skills与RAG

RAG侧重于"检索知识来回答问题"，检索粒度是知识片段Chunk，产出的是信息。

Skils侧重于"加载流程来指导行动"，加载粒度是完整的操作文档，产出的是行为。

在Agent系统中，两者可能同时存在：Skill告诉Agent 怎么处理文档问答任务，RAG负责在执行过程中检索具体知识。

八、在Spring AI框架中如何集成MCP？

SpringAI集成MCP有两种角色，方向完全不同:

1）作为 MCP Client：你的Spring Boot 应用是AI Agent 的大脑，通过 MCP协议连接外部的 MCP Server 来获取工具能力。比如让AI助手能查数据库、操作文件、调用第三方API。

2）作为 MCP Server：你有现成的Java 业务系统，想把里面的能力暴露给Claude Desktop 或其他AI Agent 调用。

Spring Boot应用启动一个MCP Server端点，等着别人来连。

具体集成步骤:

引入spring-ai-mcp-client-spring-boot-starter 或 spring-ai-mcp-server-spring-boot-starter 依赖。

Client 角色在配置文件里声明要连的Server 地址；Server角色用@Tool注解标记方法，通过 description 描述功能，框架自动注册到MCP服务中。

九、MCP协议安全性设计包括哪些层面？

MCP协议的安全性设计围绕三层防护 展开：用户控制层、隔离沙箱层、传输验证层。

1）用户同意和控制

所有工具、资源、提示的访问都必须经过用户授权。Host应用负责权限管理，在调用敏感操作前弹窗让用户确认。用户得清楚知道哪些数据会交给模型、每个工具能干什么，授权前心里有数。

2）隔离与沙箱机制

工具调用被封装在MCP Server内部，模型压根碰不到原始敏感数据。Server充当中间层，即使模型被prompt注入攻击，攻击者也拿不到数据库密码、APIKey这些凭证。沙箱机制还能限制工具的执行环境，防止恶意代码跑飞。

3）加密传输与来源验证

MCP内置请求验证机制，只有通过身份校验的请求才能访问资源。SSE模式走HTTPS，数据全程加密；Stdio模式虽然是本地通信，但进程间也有隔离保护。

**

**

十、总结

MCP 协议通过标准化的客户端-服务器架构、统一的 JSON-RPC 消息格式、以及 Tools/Resources/Prompts 三种核心原语，成功解决了 AI 工具集成中的碎片化问题。

其核心价值可以概括为：

MCP=标准化协议+动态发现+模型无关性\text{MCP} = \text{标准化协议} + \text{动态发现} + \text{模型无关性}MCP=标准化协议+动态发现+模型无关性

随着 MCP 生态的不断发展，越来越多的开发者和企业正在加入这一标准。正如 HTTP 标准化了浏览器和网站之间的通信，MCP 正在标准化 AI 代理与外部世界的交互方式。

对于开发者而言，现在正是学习和采用 MCP 的最佳时机。无论是构建自己的 MCP Server，还是将现有工具接入 MCP 生态，都将为 AI 应用的开发带来显著的效率提升。

参考资料

  1. Red Hat. 什么是模型上下文协议（MCP）？
  2. MCP Java SDK. Overview
  3. 李洪亮. 深入理解 MCP 协议：从原理到工程实践. 腾讯云开发者社区
  4. MCP 中文文档. 核心架构
  5. 从API到Agent：MCP协议如何成为AI互联互通的新基础设施
  6. MCP Specification. Architecture
  7. MCP 协议详解：Anthropic 推出的 Model Context Protocol 将如何统一 AI 工具生态？
  8. MCP Specification. 基础协议
  9. Elastic. MCP 概述和新兴用例
  10. MCP Documentation. Architecture overview
相关推荐
钓鱼的肝1 小时前
梳理（1-5）
c++·经验分享·笔记·算法·青少年编程
aramae1 小时前
模拟实现strlen()函数 （C语言）
c语言·开发语言·后端
13线1 小时前
为什么要合并飞书和豆包
人工智能·飞书·火山引擎·豆包
wangqiaowq1 小时前
AI智能体学习
人工智能
科创致远1 小时前
科创致远 eSOP 电子作业指导书系统落地应用指南
大数据·人工智能·汽车·制造·精益工程
宅小年2 小时前
让 AI 用上你的资料，RAG 是怎么做到的？
人工智能
宅小年2 小时前
为什么你的 AI 越聊越“笨”，还越来越慢？
人工智能
宅小年2 小时前
AI 技能地图
人工智能
宅小年2 小时前
DeepSeek Harness 的插件，到底该怎么用？
人工智能
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02历年考研数学一、数学二、数学三真题试卷及答案PDF03GitHub 镜像站点04数学公理体系大全:第六章 选择公理的等价形式及证明05微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接072026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？08人工智能（AI）发展史：详细里程碑09ZCode 周末送额度活动开启：3 亿 Token 免费领取10Docker 环境下 Vulfocus 靶场搭建全流程（附镜像源问题解决方案）