Model Context Protocol（MCP）技术深度解析

Model Context Protocol（MCP）技术深度解析

一、协议定位与形式化定义

Model Context Protocol（MCP）是由 Anthropic 于 2024 年 11 月 25 日首次发布的开放标准协议，旨在为大语言模型（LLM）应用与外部数据源、工具及服务之间建立统一、安全、可互操作的通信通道。该协议目前已捐赠至 Linux 基金会旗下的 Agentic AI Foundation（AAIF）进行开放治理，其 TypeScript 与 Python SDK 的月度下载量已突破四亿次，社区构建的 MCP Server 超过 13,870 个。

从形式化角度，MCP 可定义为一个四元组 P = (M, T, C, S)，其中：

M 为消息空间，所有消息均遵循 JSON-RPC 2.0 规范，分为 Request、Response 和 Notification 三类原语；

T 为传输层集合，定义消息的物理承载方式；

C 为能力协商机制（Capability Negotiation），约束通信双方可执行的操作子集；

S 为安全模型，定义身份认证、授权与数据保护的规则集合。

MCP 的核心设计哲学可概括为：将 LLM 与外部系统的交互从"应用层硬编码"下沉为"标准化的网络协议"，从而将 N 个模型与 M 个工具之间 N×M 的适配复杂度降为 N+M。

二、架构拓扑：Host-Client-Server 三层模型

MCP 采用严格的三层架构，各层职责如下：

2.1 Host（宿主）

Host 是运行 LLM 的宿主应用程序，例如 Claude Desktop、Cursor IDE、VS Code Copilot 或企业自研的 AI Agent 平台。Host 承担以下职责：

（1）管理用户交互界面与 LLM 推理循环；

（2）实例化并管理一个或多个 MCP Client；

（3）实施安全策略边界，决定哪些 Server 可被访问、哪些工具可被调用；

（4）维护用户授权上下文（如 OAuth Token 的获取与刷新）。

2.2 Client（客户端）

Client 是 Host 内部的协议连接组件，与 MCP Server 维持一对一的逻辑连接。每个 Client 实例封装了：

（1）协议状态机：管理初始化握手（旧版）或请求自包含语义（新版）；

（2）传输适配器：将 JSON-RPC 消息映射到具体的传输通道（stdio、HTTP 等）；

（3）能力缓存：缓存 Server 声明的 Tools、Resources、Prompts 清单；

（4）生命周期管理：处理连接建立、心跳、重连与优雅关闭。

关键约束：一个 Host 可同时运行多个 Client，但每个 Client 仅连接一个 Server。这种设计确保了故障隔离------某个 Server 的崩溃不会影响其他 Server 的可用性。

2.3 Server（服务器）

Server 是能力的提供者，以轻量级进程或远程服务的形式暴露三类核心原语（详见第三节）。Server 的设计原则为"最小权限"：每个 Server 仅暴露其职责范围内的工具和数据，不跨域访问。

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

MCP Server 通过三种原语向 Client 暴露能力，三者在语义上对应"执行"、"读取"和"模板"三种交互模式。

3.1 Tools（工具）------可执行的操作

Tool 代表 Server 可执行的具体操作，类似于函数调用。每个 Tool 的定义包含：

name：唯一标识符（如 "query_database"）；

description：自然语言描述，供 LLM 理解何时及如何调用该工具；

inputSchema：基于 JSON Schema 的输入参数约束；

outputSchema（2025-06-18 版新增）：结构化输出的 Schema 定义；

annotations：行为标注（如 readOnlyHint、destructiveHint、idempotentHint）。

LLM 通过推理决定是否调用某个 Tool，生成符合 inputSchema 的参数，Client 将调用请求转发给 Server 执行，Server 返回结果后由 LLM 整合为自然语言回复。

3.2 Resources（资源）------可读取的数据

Resource 代表 Server 可向 LLM 上下文注入的数据，类似于 RESTful 中的 GET 资源。Resource 通过 URI 标识（如 "file:///project/src/main.py" 或 "postgres://db/orders/schema"），支持：

静态资源：固定 URI 直接读取；

资源模板（Resource Templates）：参数化 URI 模式，如 "repo://{owner}/{repo}/issues/{number}"；

订阅与变更通知：Client 可订阅资源变更，Server 在数据更新时推送 notifications/resources/updated。

3.3 Prompts（提示模板）------可复用的交互模板

Prompt 是 Server 预定义的交互模板，通常由用户显式触发（而非 LLM 自主决策）。例如，一个代码审查 Server 可提供 "review_pr" Prompt 模板，包含固定的系统提示词和参数占位符。

四、传输层演进：从 stdio 到无状态 HTTP

传输层是 MCP 架构中变化最剧烈的部分，其演进轨迹反映了协议从本地开发工具向云原生基础设施的转型。

4.1 stdio 传输（本地进程）

适用于本地场景。Host 以子进程方式启动 Server，通过标准输入（stdin）和标准输出（stdout）交换 JSON-RPC 消息。每行一个 JSON 对象（newline-delimited JSON）。优点是零网络开销、天然隔离；缺点是仅限本机、无法水平扩展。

4.2 HTTP + SSE 传输（2024 初版，已废弃）

早期远程传输方案采用双端点设计：Client 通过 HTTP POST 发送请求，Server 通过 Server-Sent Events（SSE）长连接推送响应和通知。该方案存在固有缺陷：SSE 连接是有状态的，服务端必须维护连接映射，无法适配无状态负载均衡和 Serverless 架构。

4.3 Streamable HTTP 传输（2025-03-26 版引入）

统一为单一 HTTP 端点（如 POST /mcp），Server 可选择以普通 JSON 响应或升级为 SSE 流返回。该方案在保留流式能力的同时，允许简单的请求-响应模式。但此版本仍要求初始化握手（initialize / initialized）和会话标识（Mcp-Session-Id），本质上仍是有状态协议。

4.4 无状态核心（2026-07-28 版，当前最新）

2026 年 7 月 28 日发布的第五版规范是 MCP 历史上最大规模的架构重构，其核心变化为：

（1）移除强制握手：不再要求 initialize / initialized 交互序列。每个 HTTP 请求都是自包含的（self-contained），携带完整的协议版本、方法名和参数。

（2）移除会话 ID：不再存在 Mcp-Session-Id。任何请求可路由到任意 Server 实例，天然适配 Kubernetes 负载均衡和 Serverless 弹性伸缩。

（3）引入 Mcp-Method 和 Mcp-Name HTTP 头：

POST /mcp HTTP/1.1

MCP-Protocol-Version: 2026-07-28

Mcp-Method: tools/call

Mcp-Name: search_web

Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search_web","arguments":{"query":"quantum computing"}}}

这使得 API 网关、负载均衡器和可观测性系统可以在不解析请求体的情况下进行路由、限流和监控。

（4）缓存语义：tools/list 和 resources/read 等幂等操作支持标准 HTTP 缓存头（ETag、Cache-Control），减少重复调用。

（5）多轮请求（Multi-Turn Tool Requests, MRTR）：对于需要多步交互的工具调用（如分页查询、渐进式数据加载），通过请求体内的 _meta 字段携带续接上下文，而非依赖服务端会话状态。

（6）弃用标记：Roots、Sampling 和 Logging 三项旧版能力被标记为 deprecated，分别由新的扩展机制替代。

五、能力协商与版本控制

5.1 能力协商机制

在旧版（2025-11-25 及之前）中，连接建立时的 initialize 阶段完成能力协商：

Client 发送 initialize 请求，声明自身支持的协议版本和能力集（如 sampling、roots）；

Server 响应其支持的协议版本和能力集（如 tools、resources、prompts、logging）；

Client 发送 initialized 通知，确认协商完成，连接进入就绪状态。

在 2026-07-28 版中，协商被简化为请求级声明：每个请求通过 MCP-Protocol-Version 头声明协议版本，Server 在响应中确认或降级。能力发现通过 tools/list、resources/list、prompts/list 方法按需获取。

5.2 版本协商策略

MCP 采用语义化版本标识（日期格式：YYYY-MM-DD）。协商规则为：

（1）Client 声明其支持的最高版本；

（2）若 Server 支持该版本，则按该版本交互；

（3）若不支持，Server 返回其支持的最高版本，Client 决定是否降级兼容；

（4）2025-06-18 版起，版本不兼容时必须显式拒绝，禁止静默降级。

六、安全模型

MCP 的安全设计经历了从"最小化信任假设"到"企业级零信任架构"的演进。

6.1 传输层安全

所有远程通信强制要求 TLS 1.2+。stdio 传输依赖操作系统进程隔离。

6.2 认证与授权（2026-07-28 版强化）

新版规范将 OAuth 2.1 与 OpenID Connect（OIDC）作为远程 Server 的强制认证机制：

（1）动态客户端注册（Dynamic Client Registration）：Client 可在运行时向 Server 的授权端点注册，无需预配置；

（2）Client ID Metadata Document（CIMD）：通过元数据文档描述 Client 身份，支持企业级身份联邦；

（3）细粒度 Scope：每个 Tool 可声明所需的 OAuth Scope，实现工具级别的权限控制；

（4）Token 绑定：Access Token 与特定 Client 实例绑定，防止 Token 重放。

6.3 Elicitation 机制（2025-06-18 版引入）

当 Server 执行工具时需要用户额外输入（如确认删除操作、提供敏感参数），Server 可向 Client 发起 elicitation 请求，由 Host 向用户展示交互界面。该机制确保人在回路（Human-in-the-Loop），防止 LLM 在无人监督下执行破坏性操作。

6.4 已知威胁模型

（1）工具描述投毒（Tool Description Poisoning）：恶意 Server 在 Tool 的 description 字段中注入提示词注入（Prompt Injection）载荷，诱导 LLM 执行非预期操作。由于 LLM 无法在语义层面区分"数据"与"指令"，这是 MCP 面临的根本性安全挑战。

（2）跨 Server 上下文泄露：当 Host 同时连接多个 Server 时，一个 Server 的输出可能被注入另一个 Server 的输入上下文，形成间接提示注入（Indirect Prompt Injection）通道。

（3）权限过度授予：Server 为完成复杂任务可能申请超出实际需要的系统权限（如文件系统读写、网络访问），形成权限提升风险。《计算机研究与发展》2026 年发表的实证研究表明，社区 MCP Server 中约 34% 存在权限声明与实际需求不匹配的问题。

（4）无状态化后的新攻击面：2026-07-28 版移除会话状态后，会话劫持风险消除，但引入了请求伪造、头部注入和缓存投毒等新攻击向量，需由 Server 实现者自行防御。

七、与相关协议的形式化对比

7.1 MCP 与 Language Server Protocol（LSP）

LSP 是微软为编辑器与语言服务之间设计的协议，MCP 的早期架构（有状态、双向、JSON-RPC 2.0）明显借鉴了 LSP。核心差异在于：

LSP 是"编辑器驱动"的，Server 被动响应；MCP 是"模型驱动"的，LLM 自主决策调用时机。

LSP 的 Server 能力集是固定的（补全、诊断、跳转等）；MCP 的 Server 能力是动态发现的、无限可扩展的。

2026-07-28 版后，MCP 已脱离 LSP 的有状态范式，转向无状态 HTTP 模型，二者在架构上已根本分道。

7.2 MCP 与 OpenAPI / RESTful API

OpenAPI 描述的是"人类开发者如何调用 API"；MCP 描述的是"AI 模型如何发现和调用能力"。MCP 在 OpenAPI 之上增加了：

语义层：自然语言 description 供 LLM 理解；

发现层：tools/list 动态枚举，无需预知端点；

协商层：能力声明与版本协商；

交互层：Elicitation、流式响应、多轮续接。

7.3 MCP 与 A2A（Agent-to-Agent Protocol）

Google 于 2025 年提出的 A2A 协议解决的是"Agent 与 Agent 之间的协作"问题，而 MCP 解决的是"Agent 与工具/数据之间的连接"问题。二者是互补关系：一个 AI Agent 通过 MCP 调用工具获取数据，通过 A2A 与另一个 Agent 协商任务分工。

八、协议状态机与消息流（以 tools/call 为例）

以 2026-07-28 版无状态模式为例，一次完整的工具调用消息流如下：

步骤 1：LLM 推理层决定调用工具 search_web，生成参数 {"query": "quantum error correction"}。

步骤 2：Host 内的 MCP Client 构造 JSON-RPC Request：

{

"jsonrpc": "2.0",

"id": 42,

"method": "tools/call",

"params": {

"name": "search_web",

"arguments": {"query": "quantum error correction"},

"_meta": {"progressToken": "pt-001"}

}

}

步骤 3：Client 通过 HTTP POST 发送至 Server 端点 /mcp，携带 MCP-Protocol-Version、Mcp-Method、Mcp-Name 头。

步骤 4：Server 验证 OAuth Token、检查 Scope 权限、校验 inputSchema。

步骤 5：Server 执行实际业务逻辑（调用搜索 API）。

步骤 6：Server 返回 JSON-RPC Response：

{

"jsonrpc": "2.0",

"id": 42,

"result": {

"content": [

{"type": "text", "text": "Quantum error correction is a collection of techniques..."}

],

"isError": false

}

}

步骤 7：Client 将结果注入 LLM 上下文，LLM 继续推理或生成最终回复。

若步骤 5 中工具执行需要用户确认（如删除操作），Server 返回 elicitation 请求，流程中断等待用户响应后继续。

九、生产部署架构与工程实践

9.1 云原生部署模式

2026-07-28 版的无状态设计使 MCP Server 可以像普通微服务一样部署：

（1）容器化：每个 MCP Server 打包为独立容器，通过 Kubernetes Deployment 管理；

（2）水平扩展：无会话亲和性要求，Service / Ingress 可自由轮询分发请求；

（3）Serverless 适配：每个请求自包含，可运行于 AWS Lambda、Cloudflare Workers 等 FaaS 平台；

（4）网关集成：Mcp-Method 和 Mcp-Name 头使 API Gateway（如 Kong、Envoy）可在 L7 层进行路由、限流、熔断和可观测性采集，无需解析请求体。

9.2 可观测性

生产环境建议对 MCP 流量实施全链路追踪：

请求级：通过 Mcp-Method + Mcp-Name + 请求 ID 构建分布式追踪 Span；

指标级：工具调用延迟（P50/P99）、错误率、Token 消耗；

日志级：OpenTelemetry 集成，记录每次工具调用的输入参数摘要和输出状态；

审计级：企业合规要求记录"谁在什么时间通过哪个 Agent 调用了哪个工具、传入了什么参数、返回了什么结果"。

9.3 迁移路径（旧版到 2026-07-28 版）

对于仍在运行 2025-11-25 版（有状态）的团队，官方建议的迁移优先级为：

P0（立即）：移除 initialize/initialized 握手逻辑，改为请求级版本声明；

P1（1-2 周）：移除 Mcp-Session-Id 依赖，确保每个请求自包含；

P2（2-4 周）：添加 Mcp-Method / Mcp-Name 头，适配网关路由；

P3（持续）：迁移 Sampling 和 Logging 到新扩展机制，接入 OAuth 2.1 认证。

十、开放问题与未来方向

10.1 语义安全问题尚无根本解

工具描述投毒和间接提示注入是 MCP 面临的"原罪"级问题。由于 LLM 在架构层面无法区分数据平面和控制平面，任何通过自然语言描述传递的元信息都存在被注入的风险。当前业界的缓解手段（输入过滤、沙箱执行、权限最小化）均为工程补丁，缺乏协议层面的根本性解决方案。

10.2 多 Agent 编排中的 MCP 角色

随着 Agentic AI 系统从单 Agent 向多 Agent 协作演进，MCP 需要回答：一个 Agent 是否可以作为另一个 Agent 的 MCP Server？工具调用的事务语义如何保证？跨 Agent 的上下文传递如何避免信息泄露？这些问题目前由 MCP Apps 和 Tasks 扩展（2026-07-28 版进入正式扩展体系）初步覆盖，但远未成熟。

10.3 形式化验证的缺失

截至目前，MCP 规范尚无配套的形式化验证模型（如 TLA+ 规约或 Coq 证明）。协议的正确性完全依赖实现者的自觉遵守和互操作性测试。对于安全关键场景（如医疗、金融），这是一个不可忽视的空白。

10.4 性能与规模化

当前 MCP 的 JSON-RPC over HTTP 模式在超高频调用场景（如每秒数千次工具调用）下存在序列化/反序列化开销。社区已有基于 gRPC 和 Protocol Buffers 的替代传输提案，但尚未进入正式规范。

十一、结语性评述

MCP 的技术意义不在于其单项设计的原创性------JSON-RPC 2.0 是 2010 年的规范，OAuth 2.1 是 IETF 的成熟标准，无状态 HTTP 是 Web 的基石------而在于它将这些成熟技术以一种面向 AI Agent 认知模式的方式重新组合，形成了一个"模型可理解、可发现、可调用"的标准化能力暴露层。

从 2024 年 11 月的初版到 2026 年 7 月的第五版，MCP 用不到两年时间完成了从"本地开发工具的插件协议"到"企业级云原生 AI 基础设施"的跨越。其无状态化转型的深层逻辑，是将 AI Agent 的工具调用从"类 LSP 的持久会话"范式转向"类 HTTP 的无状态请求"范式，从而使 MCP Server 能够无缝融入现有的微服务治理体系------服务网格、API 网关、可观测性平台、CI/CD 流水线------而无需为 AI 单独构建一套平行基础设施。

这一转型的代价是：Sampling（Server 反向调用 LLM）、Roots（Client 文件系统根目录暴露）和 Logging（协议级日志绑定活动连接）等有状态能力被弃用或重新设计。这反映了协议设计中一个永恒的张力：表达力与可伸缩性之间的权衡。MCP 在第五版中明确选择了后者，其赌注是：AI Agent 生态的规模化部署需求，远大于少数高级交互模式的表达力需求。

这一赌注是否正确，将在未来两到三年的产业实践中得到验证。