MCP 完整指南：从架构、协议原语到生产实践

Model Context Protocol，简称 MCP，已经成为 AI 应用连接外部工具与数据源的事实标准之一。
如果把大模型看作“会推理的内核”，那么 MCP 解决的问题就是：如何让这个内核以统一、可扩展、可审计的方式接入外部世界。

MCP 最常被描述为“AI 世界的 USB-C 接口”。这个比喻并不夸张，因为它确实在做一件类似的事情：

为 AI 应用提供统一的接入方式
为外部系统提供统一的暴露方式
将“模型 × 工具 × 数据源”的集成复杂度从 N x M 降到更可控的形态

本文基于 Google Cloud、MCP 官方文档与 MCP 中文站资料，系统梳理 MCP 的完整概念体系。

一、MCP 到底解决什么问题

没有 MCP 之前，AI 应用如果要访问文件、数据库、搜索服务、业务 API，通常有两种做法：

在每个 AI 产品里硬编码一套工具调用逻辑
为每个模型、每个系统单独做一层定制适配

这会带来几个问题：

接口风格不统一
工具发现机制不统一
模型迁移成本高
接入新系统时重复造轮子
安全与授权边界难以标准化

MCP 的核心价值就是把这类“上下文接入”和“工具交互”抽象成标准协议，让 AI 应用不必为每个外部系统重新发明通信层。

二、MCP 的定义

根据 MCP 官方文档，MCP 是一个 用于将 AI 应用连接到外部系统的开放标准协议。
它允许 AI 应用连接三类对象：

数据源：例如本地文件、数据库、API 返回结果
工具：例如搜索、计算、文件操作、第三方 API 调用
工作流：例如预定义 prompt、交互模板、结构化操作链

从协议目标上看，MCP 不是“替代函数调用”，而是把函数调用、上下文暴露、客户端能力声明、传输方式、生命周期协商统一纳入同一套协议模型。

三、MCP 的参与者：Host、Client、Server

MCP 是标准的 client-server 架构，但在 AI 场景里有三个角色需要分清。

1. MCP Host

Host 是承载用户交互和模型调用的 AI 应用本体。
例如：

Claude Desktop
Claude Code
VS Code
Cursor
Chat 型 AI 工作台

Host 负责：

管理一个或多个 MCP Client
协调模型与外部能力的连接
决定如何把 MCP 返回的内容喂给模型
管理用户授权和交互体验

2. MCP Client

Client 是 Host 内部与单个 MCP Server 建立连接的组件。
一个重要细节是：

一个 Host 通常会为每个 MCP Server 创建一个独立 Client 连接。

也就是说，Host 是“总控层”，Client 是“连接实例层”。

3. MCP Server

Server 是真正向外暴露上下文或能力的程序。
它可以暴露：

Tools
Resources
Prompts

Server 可以本地运行，也可以远程运行。

4. 本地 Server 与远程 Server

官方文档明确区分：

本地 MCP Server：通常使用 stdio，由客户端作为子进程拉起
远程 MCP Server：通常使用 Streamable HTTP，可服务多个客户端

这个区分很重要，因为它直接影响：

部署方式
授权方式
性能模型
安全边界

四、MCP 的两层结构：Data Layer 与 Transport Layer

MCP 可以拆成两层：

1. Data Layer

数据层定义的是 JSON-RPC 2.0 语义协议，包括：

生命周期管理
能力协商
核心原语
通知机制
进度与取消等实用能力

这是大多数开发者最需要理解的一层，因为真正影响工具设计与上下文交换的逻辑都在这里。

2. Transport Layer

传输层定义的是 消息如何被送达，包括：

如何建立连接
如何封装与分帧消息
如何做认证
如何支持远程通信

协议层和传输层解耦后，同一套 MCP 语义就可以跑在不同通信机制上。

五、MCP 的生命周期

MCP 不是无状态的“一次请求一次响应”协议，而是一个 有状态连接协议。
官方规范把生命周期分成三个阶段：

Initialization
Operation
Shutdown

1. Initialization

初始化必须是连接建立后的第一步。
客户端会发送 initialize 请求，其中包含：

protocolVersion
capabilities
clientInfo

服务器则返回：

它支持的协议版本
它声明的能力
serverInfo

初始化阶段完成两件关键事：

版本协商
能力协商

如果版本不兼容，连接应当终止。

2. notifications/initialized

初始化成功后，客户端还会发送：

json
1{
2  "jsonrpc": "2.0",
3  "method": "notifications/initialized"
4}

这相当于告诉服务端：握手完成，可以进入正常工作态。

3. Operation

运行阶段就是正常的协议通信，包括：

列出工具
调用工具
读取资源
获取 prompt
发通知
请求采样
请求用户输入

4. Shutdown

关闭阶段用于优雅结束连接，释放资源，避免残留状态污染后续会话。

六、MCP 的核心概念：Primitives

Primitives 是理解 MCP 的关键。
它定义了客户端与服务端到底能交换什么。

MCP 的原语分成两大类：

服务器暴露的原语
客户端暴露的原语

1. 服务器原语

服务器可暴露三种核心能力：

Tools

Tools 是可执行函数。
适合表达“做一件事”。

例如：

查询数据库
调用天气 API
创建 issue
执行文件读写
调用搜索接口

协议层面，Tool 具备：

唯一 name
title
description
inputSchema

客户端通过：

tools/list
tools/call

完成工具发现和调用。

Tool 的设计理念是 model-controlled，即模型可以根据上下文自动发现和调用工具。
但规范也明确强调：为了安全，应用层应尽量保留 human in the loop，让用户有机会确认或拒绝工具执行。

Resources

Resources 是上下文数据源。
适合表达“给模型看什么”。

例如：

文件内容
数据库 schema
API 返回结果
git 仓库信息
应用状态快照

Resource 的核心标识是 URI。
官方规范里列出的常见方案包括：

https://
file://
git://
自定义 URI scheme

Resources 更偏 application-driven。
也就是说，Host 通常决定如何展示和注入这些资源，而不一定完全交给模型自动调用。

常见方法包括：

resources/list
resources/read

有些场景还会使用资源模板与订阅更新。

Prompts

Prompts 是服务端提供的可复用提示模板。
适合表达“如何与模型交互”。

例如：

一个代码审查模板
一个 SQL 分析模板
一个调查问卷式 prompt
一组 few-shot 示例

Prompts 的设计理念更偏 user-controlled。
这意味着它通常更适合由用户显式选择，而不是像 Tool 一样直接由模型自行决定。

常见方法包括：

prompts/list
prompts/get

2. 客户端原语

除了服务器向客户端暴露能力，MCP 还支持客户端向服务器声明自己拥有哪些能力。

Sampling

Sampling 允许服务器请求客户端代为调用宿主 LLM。
这是一个很关键但经常被忽略的能力。

它的意义是：

服务器作者不必自己绑定某家模型 SDK
服务端可以保持模型中立
模型访问权仍由 Host 控制

也就是说，Server 可以说：“请你帮我向当前模型发一次 completion 请求”，但真正选哪个模型、是否允许调用、怎么计费，仍由 Client/Host 掌控。

Roots

Roots 允许客户端把“文件系统可操作边界”暴露给服务器。
它的作用不是提供文件内容本身，而是定义操作范围。

例如：

当前项目目录
某个 workspace
多仓库集合

Roots 的核心价值是 权限边界。
Server 可以知道自己被允许在哪些目录中工作，而不是默认拥有整个文件系统的访问能力。

Elicitation

Elicitation 允许服务器通过客户端向用户请求额外信息。
它适用于交互式工作流，例如：

询问 GitHub 用户名
请求确认部署环境
让用户补充缺失参数

规范要求这类请求应尽量避免索取敏感信息，并且应用层应明确告诉用户“是哪个 server 在请求什么数据”。

Logging

Logging 用于服务端向客户端输出日志，方便：

调试
监控
问题定位

它不是业务能力原语，但对工程可观测性很重要。

七、MCP 的通知与实用能力

除了核心原语，MCP 还定义了一些横切能力。

1. Notifications

通知是无响应的 JSON-RPC 消息。
典型用途包括：

tools/list_changed
resources/list_changed
prompts/list_changed

这类机制使客户端无需不断轮询，就能在能力清单变化时动态更新。

2. Progress

对于长时间运行的请求，发送方可以在请求元信息中带上 progressToken，接收方之后通过：

json
1{
2  "jsonrpc": "2.0",
3  "method": "notifications/progress",
4  "params": {
5    "progressToken": "abc123",
6    "progress": 50,
7    "total": 100,
8    "message": "Reticulating splines..."
9  }
10}

回报进度。

这对以下场景很重要：

长时间索引
批量处理
多步骤工作流
远程任务执行

3. Cancellation

MCP 支持取消正在进行的请求。
取消通过 notifications/cancelled 发出，并携带：

被取消请求的 requestId
可选取消原因

这避免了长任务在用户已经放弃后仍继续消耗资源。

4. Ping

ping 是可选保活机制，用于检查连接另一端是否仍可响应。
这对于：

长连接
远程 server
网络不稳定环境

非常实用。

5. Tasks（实验性）

官方架构文档还提到 Tasks，用于支持可延迟获取结果的耐久型执行包装。
它主要面向：

昂贵计算
工作流自动化
批处理
多步骤长任务

这一块反映出 MCP 正在从“同步工具调用”继续向“异步工作流协议”扩展。

八、MCP 的传输机制

截至本文写作时间，官方标准传输主要有两种。

1. stdio

stdio 是本地进程通信方式：

Client 启动 Server 子进程
Server 从 stdin 读取 JSON-RPC 消息
Server 向 stdout 写出 JSON-RPC 消息

规范里有几个关键约束：

消息必须是 UTF-8
stdout 不能混入非 MCP 消息
日志应优先写到 stderr

这也是本地 MCP Server 最常见的运行方式。

2. Streamable HTTP

新版规范中，远程通信使用 Streamable HTTP。
它替代了更早版本里的 HTTP + SSE 模式。

其特点是：

客户端到服务端使用 HTTP POST
可选 SSE 用于流式消息
支持标准 HTTP 认证
推荐 OAuth 获取令牌

因此，当你在做远程 MCP Server 时，不能再只停留在“工具 schema 怎么写”，还必须考虑：

鉴权
会话管理
重连
幂等性
网络故障恢复

九、MCP 与 RAG 的区别

Google Cloud 这篇参考资料里对 MCP 和 RAG 的区分很清楚。

RAG 更偏“取资料”

RAG 主要解决：

从知识库检索相关内容
把检索结果拼进 prompt
提升回答准确性

它的重点是 信息增强。

MCP 更偏“接系统”

MCP 解决的是：

连接数据源
调用工具
执行动作
交换结构化上下文

它的重点是 标准化交互与执行。

二者并不冲突。
实际上在生产系统里，最常见的情况往往是：

用 MCP 暴露检索工具或知识库资源
用 RAG 负责检索与回答增强

换句话说，RAG 是一种能力模式，MCP 是一种协议层标准。

十、MCP 的安全模型

MCP 一旦落地，就不只是“提示词工程”问题，而是标准的系统安全问题。

1. 用户授权

主机在将数据或能力暴露给服务器前，应提供明确授权界面。
用户必须知道：

暴露了哪些工具
共享了哪些数据
哪些动作会被执行

2. 最小权限原则

这是 MCP 落地的第一原则：

只暴露必要 roots
只暴露必要 tools
只开放必要 scopes

不要为了方便把整个工作机、整个生产数据库、所有 API 凭证都挂给一个 Server。

3. Tool 风险控制

规范对 Tools 的态度非常明确：
它们可能触发真实副作用，因此应尽可能保留人工确认环节。

4. 敏感信息与 Elicitation

Elicitation 不应用于索取敏感数据。
这意味着：

密码
私钥
长期令牌
受监管隐私信息

都不应该通过普通 elicitation 流程直接让用户输入给某个 server。

5. 输出安全

Google Cloud 资料特别提醒了一个容易被忽略的点：
MCP 交互产出的内容也需要做输出安全处理，例如防止 XSS 或恶意注入。

6. 供应链安全

第三方 MCP Server 与第三方 Skill 一样，属于供应链入口。
一旦接入，就意味着你在允许外部代码进入自己的 AI 执行链。

十一、版本控制与演进

MCP 的版本号采用 YYYY-MM-DD 格式，例如：

2024-11-05
2025-06-18

这类版本号表示“最后一次发生不兼容变更的日期”。

官方版本策略有两个重点：

只要仍保持向后兼容，就不一定升级协议版本号
客户端和服务端可以同时支持多个版本，但每个会话必须协商出一个共同版本

这套策略的目的，是在快速演进与互操作性之间取得平衡。

十二、MCP 生态中的几个关键对象

除了协议本身，还需要知道几个工程对象。

1. SDKs

官方 SDK 已覆盖多种语言。当前官方资料列出的重点包括：

TypeScript
Python
C#
Go
Java
Rust
Swift
Ruby
PHP

如果要自己写 Server 或 Client，优先走官方 SDK，而不是手写协议细节。

2. MCP Inspector

MCP Inspector 是官方开发工具，用于：

调试 server
检查能力声明
验证消息交互
排查协议问题

对于 Server 开发者来说，这是第一优先级工具。

3. Registry

MCP 生态已经有官方 Registry，用于发现和发布 MCP Server。
这意味着 MCP 正在从“协议”走向“分发生态”。

4. Reference Servers

官方还维护参考服务器实现，方便开发者理解最佳实践与标准行为。

十三、一个最小 MCP 心智模型

如果只用一句话概括 MCP，可以写成：

Host 负责承载 AI 应用，Client 负责连接，Server 负责暴露能力；双方通过 JSON-RPC 2.0 在约定传输层上交换 Tools、Resources、Prompts 以及相关通知与控制消息。

换成最小流程图，大致是：

text
1User
2  -> Host
3  -> Client
4  -> initialize
5  -> Server
6
7Server
8  -> tools/resources/prompts metadata
9  -> Client
10  -> Host
11  -> LLM
12
13LLM
14  -> decides to call tool or use resource
15  -> Host/Client
16  -> Server
17  -> result
18  -> LLM
19  -> User

十四、MCP 适合什么，不适合什么

适合的场景

AI IDE 调用本地工程工具
聊天助手接入企业数据源
代码代理访问文件系统、Issue 系统、日志平台
多工具协同的 Agent 工作流
需要统一接入层的 AI 平台

不适合的预期

认为 MCP 本身等于 Agent 能力
认为只接上 MCP 就自然安全
认为 MCP 可以替代业务权限系统
把所有东西都暴露给模型后再靠 prompt 约束

MCP 是协议，不是策略。
它只定义了“怎么接”，不替你解决“该不该接、接多少、谁来批准、谁来审计”。

结语

MCP 的意义不在于又多了一个 AI 名词，而在于它把过去散乱的工具调用、上下文注入、用户交互、模型采样、权限边界和传输层细节，收敛进了一套可复用的标准协议。

如果你在做：

AI IDE
Agent 平台
企业知识助手
工具型聊天应用
多模型集成系统

那么 MCP 已经不是“可选了解”，而是应该进入基础设施视角来理解的协议。

参考链接

Google Cloud: 什么是 Model Context Protocol (MCP)
MCP 官方文档总览: What is the Model Context Protocol (MCP)?
MCP 官方架构文档: Architecture overview
MCP 官方版本文档: Versioning
MCP 官方规范总览: Specification 2025-06-18
MCP 官方 Tools 规范: Tools
MCP 官方 Resources 规范: Resources
MCP 官方 Prompts 规范: Prompts
MCP 官方 Sampling 规范: Sampling
MCP 官方 Roots 规范: Roots
MCP 官方 Elicitation 规范: Elicitation
MCP 官方 Transports 规范: Transports
MCP 官方 Lifecycle 规范: Lifecycle
MCP 官方 Ping 规范: Ping
MCP 官方 Progress 规范: Progress
MCP 官方 Cancellation 规范: Cancellation
MCP 中文站: MCP 中文站