MCP 协议架构

MCP 的架构让模型与工具像操作系统调用一样安全、可组合、可观测，是智能体生态的底层基石。

模型上下文协议（MCP, Model Context Protocol）定义了一个通用的通信标准，用于连接 大语言模型（LLM） 与 外部系统能力（工具 / 资源 / 上下文）。它通过统一的协议结构与传输语义，让智能体具备安全、可组合、可观察的执行环境。

本章将从架构角色、交互流程、核心元素到安全机制系统解析 MCP 的设计原理。

整体架构概览

MCP 的核心思想是将模型与外部世界之间的接口抽象为标准化协议栈，使 LLM 可以通过一致方式访问各种资源和工具。下方流程图展示了 MCP 架构的角色分工与连接关系：

下表总结了 MCP 架构的核心角色及其职责：

Host 可同时连接多个 Server，使模型能够在同一上下文中调用不同系统资源。这种多连接机制是 MCP 可组合性的关键。

交互流程（消息生命周期）

MCP 的消息交互流程涵盖用户请求、模型决策、工具调用与结果反馈。下方时序图展示了完整的调用过程：

一个完整调用过程包括以下阶段：

1. 用户发起请求（IDE 或聊天界面提交指令）
2. 主机准备上下文（Host 提供工具列表、环境信息）
3. 模型决策与调用（模型选择并调用合适工具）
4. 客户端转发执行（Client 以 JSON-RPC 向服务器发送调用请求）
5. 服务器执行操作（完成任务并返回结果）
6. 结果整合与回答（模型基于结果生成最终输出）

MCP 的设计重点在于每次调用都有结构化输入与确定性输出，便于审计、调试与自动化重放。

核心定义与传输机制

MCP 协议包含一系列核心概念与传输层设计。下表总结了主要定义：

下表总结了 MCP 的传输层设计及适用场景：

生命周期与握手过程

MCP 连接生命周期分为初始化、运行中与关闭阶段。下表总结了各阶段关键动作（注意：这描述的是 2026-07-28 规范之前的会话式模型，新规范已转向无状态架构，详见下文）：

下方时序图展示了 MCP 握手与初始化过程：

MCP 的握手过程保证双方协商协议版本、能力集与通知机制，为后续调用奠定标准语义层。

2026-07-28 规范：无状态化重构

2026 年 7 月 28 日定稿的 2026-07-28 规范是协议诞生以来最大的一次修订：从有状态双向会话转向无状态请求/响应模型，官方定位是让智能体基础设施像 Web 的其余部分一样工作——无状态、可缓存、可路由、全球可达。

为什么要重构？旧规范中，客户端必须先完成 initialize / initialized 握手并绑定 Mcp-Session-Id 会话，服务器端请求（sampling、elicitation）还要求连接保持打开。这在生产环境意味着：负载均衡必须做会话黏连、水平扩展需要共享会话存储、网关无法仅凭请求本身完成路由与鉴权、CDN 难以介入。随着 MCP 成为事实标准，这些约束必须被移除。

核心变化

无会话、无握手。 新规范移除了 initialize / initialized 交换与 Mcp-Session-Id 标头，每个请求都在 _meta 中自带协议版本、客户端身份与能力，服务器发现改为可选的 server/discover RPC：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "deploy",
    "arguments": {},
    "_meta": {
      "protocolVersion": "2026-07-28",
      "clientInfo": { "name": "my-agent", "version": "1.4.0" },
      "capabilities": { "tasks": {} }
    }
  }
}

标头路由。 请求必须在 HTTP 标头中携带 Mcp-Method 与 Mcp-Name，网关可以直接基于标头做路由与鉴权，无需解析消息体——与 REST 的 X-Forwarded-*、gRPC 的 grpc-method 一脉相承：

POST /mcp HTTP/1.1
Host: mcp.example.com
Mcp-Method: tools/call
Mcp-Name: deploy
Authorization: Bearer <token>

多往返请求（MRTR）。 服务器端长连接请求被 MRTR 取代：服务器返回 resultType: "input_required" 与待回答问题，客户端收集响应后带着附加信息重试同一请求。交互语义保留，连接模型变成纯请求/响应。

可缓存的列表结果。 tools/list 等列表响应新增 ttlMs 与 cacheScope 字段，客户端、网关与 CDN 可以据此做层级缓存，显著降低高频低变请求的服务器负载。

Tasks 转正。 长时任务从实验特性转为正式扩展，提供基于轮询的 tasks/get 与 tasks/update，以及单一的 subscriptions/listen 流，为耗时数分钟的工具调用标准化了异步生命周期。

授权强化与废弃清单

授权层面有三项硬化：RFC 9207 发行者验证（授权服务器必须返回 iss 参数且客户端兑换前必须验证）、弃用动态客户端注册 DCR 转向客户端 ID 元数据文档 CIMD、客户端凭证绑定到特定发行者。规范同时引入了十二个月最短期限的正式废弃政策，本次废弃的能力如下：

Tier 1 SDK（TypeScript、Python、Go、C#）已完全支持新规范，Rust SDK 处于 beta 阶段；依赖旧会话标识符的实现可按废弃窗口逐步迁移。

新旧架构对比与基础设施影响

下图对比了旧有状态会话模型与新无状态请求模型：

从云原生视角，这次修订把 MCP 接入变成了标准的 HTTP 基础设施问题：

• 负载均衡：任意轮询 LB，无需黏连与共享会话存储；
• 网关：基于 Mcp-Method / Mcp-Name 标头做路由、限流与鉴权，Envoy/Kong 原生可用；
• 缓存：tools/list 等列表结果按 ttlMs 分层缓存，CDN 可直接命中；
• 可观测性：标头即 span 属性，链路追踪无需解析消息体；
• 多租户：请求自描述，租户路由不再依赖会话查找。

协议核心元素

MCP 通过工具、资源与提示模板三大元素让模型获得外部操作权。下表总结了各元素功能与示例：

所有工具均以结构化方式定义参数模式与返回类型，保证模型调用的稳定性与可预测性。

客户端特性扩展

MCP 客户端支持多种扩展特性，提升模型与外部系统的协作能力。下表总结了常见扩展特性及使用场景：

这些特性在初始化阶段协商启用，由 Host 控制是否允许。

安全与隐私设计

MCP 在设计上引入最小信任原则，保障用户控制与数据安全。下表总结了 MCP 的安全机制：

总结

MCP 协议为 AI 工程提供了统一的执行语义层，使模型具备以下特征：

• 标准化调用：统一工具与资源接口
• 可组合能力：任意模型可组合任意 Server
• 跨语言 / 跨平台互操作
• 可观测与安全可控

它让智能体的外部调用方式像操作系统的系统调用（syscall）一样稳定。在未来的 AI 原生体系中，MCP 将成为智能体运行时的 API 协议层，是连接模型推理与真实世界操作的基础标准。

参考文献

• Model Context Protocol 官方文档 - modelcontextprotocol.io
• The 2026-07-28 Specification（MCP 官方博客）- blog.modelcontextprotocol.io
• MCP Specification (2026-07-28) - modelcontextprotocol.io
• Security Design Considerations for AI-Driven Automation（美国国防部）- media.defense.gov
• MCP Message Types Reference — Portkey.ai
• @modelcontextprotocol/sdk (npm) - npmjs.com