模型上下文协议（MCP）概述
模型上下文协议（MCP, Model Context Protocol） 是一种为 AI 模型设计的通用上下文通信协议。它让模型与外部工具、数据资源和运行环境之间建立一个统一、安全、可扩展的接口。你可以把 MCP 理解为“AI 世界的 USB-C” —— 用一条标准化通道，让模型与一切外部系统互联。
MCP 概述
MCP 是由 Anthropic 提出的开放标准，用于规范 AI 模型与外部系统（如工具、数据库、文件或 API）之间的通信方式。协议基于 JSON-RPC 2.0（Remote Procedure Call，远程过程调用），支持两种传输形式：
- 标准输入输出（stdio）：适用于桌面或本地模型环境。
- HTTP + SSE（Server-Sent Events，服务器推送事件）：适用于远程网络交互场景。
MCP 的目标是让模型能像访问本地资源一样，安全地使用外部工具与数据，而不必为每种组合编写独立适配器。这种统一接口极大简化了模型集成的复杂度。
架构与角色
下表介绍 MCP 协议中的三类核心参与者及其职责：
| 角色 | 描述 | 主要职责 |
|---|---|---|
| Host（主机） | 模型运行的宿主环境，如 IDE、桌面应用或 CLI | 启动模型进程并建立客户端连接 |
| Client（客户端） | 代理层，位于模型与外部系统之间 | 转发消息、维护上下文、缓存资源元数据 |
| Server（服务器） | 提供具体功能或数据接口 | 实现 MCP 规范，暴露工具、资源与提示模板 |
下方流程图展示了 MCP 的典型交互结构：
运行机制说明
模型通过 Client 向 Server 发现可用能力，Server 响应可调用的工具（Tools）、资源（Resources）和提示模板（Prompts）。Client 负责中继、缓存与权限控制，所有通信通过 JSON-RPC 请求/响应完成，确保安全与一致性。
协议原语（Primitives）
MCP 的核心由三类原语（Primitive）构成，分别定义了模型可访问的能力类型。下表总结了三类原语及其典型用途：
| 原语 | 说明 | 示例 |
|---|---|---|
| Tools（工具） | 模型可调用的具体函数或操作 | 创建事件、查询数据库、发送邮件 |
| Resources（资源） | 模型可访问的数据对象 | 文件、文档、数据库表、API 响应 |
| Prompts（提示模板） | 定义任务上下文的文本模板 | 不同任务场景下的系统提示 |
这些原语共同描述了 MCP Server 能向模型提供的能力清单。模型可通过 tools/list、resources/list 等方法动态发现，再按需调用，实现灵活扩展。
通信机制与安全模型
在 MCP 协议中，通信机制与安全模型是保障模型与外部系统安全协作的基础。
传输层
MCP 基于 JSON-RPC 2.0，定义了双向请求 - 响应机制。典型通信包含以下阶段：
- Initialize 握手：双方交换协议版本与能力声明。
- List 查询：客户端发现服务器暴露的工具与资源。
- Call/Get 调用：模型发起工具调用或数据请求。
- Notify 通知：服务器实时告知更新（如加载新工具）。
下方时序图展示了 MCP 的典型通信流程：
安全与访问控制
MCP 强调最小权限原则（Principle of Least Privilege）与用户授权边界：
- 每个工具与资源都带有权限说明；
- 客户端可过滤模型的访问范围；
- 敏感操作支持二次确认；
- 服务器可本地部署以保护隐私数据。
这种设计确保模型只能访问被授权的资源，防止越权和数据泄露。
双向能力：客户端的扩展接口
除了服务器向模型提供能力外，MCP 也允许服务器反向请求客户端完成任务，实现模型、主机与外部系统的双向协作。
下表总结了 MCP 客户端扩展接口的能力类型及典型方法：
| 能力类型 | 功能 | 典型方法 |
|---|---|---|
| Sampling（采样） | 请求客户端调用其内部模型生成文本或代码 | sampling/complete |
| Elicitation（引出） | 通过用户界面获取额外输入 | elicitation/request |
| Logging（日志） | 服务器向客户端发送调试或运行日志 | logging/event |
这种设计让 MCP 不仅是“模型访问外部世界”的通道，也能反向利用模型宿主的能力，实现协同执行，提升系统灵活性。
协议交互范式
在典型的大语言模型（LLM, Large Language Model）调用场景中，MCP 的工作模式如下：
- 模型发现能力：通过
list方法了解可调用资源。 - 模型执行任务：选择合适工具并发起
call请求。 - 结果返回与上下文更新：服务器返回数据，客户端缓存上下文。
- 动态通知：当 Server 功能变化时，通过
notify机制同步。
这种机制让模型能像访问 API 一样访问任意系统资源，同时保持一致的语义层与安全边界。
设计动机与价值
过去，每个 AI 助手或智能体要访问外部数据，都必须为每个数据源定制适配层。MCP 的出现解决了这一“碎片化适配”问题。
下方图表对比了传统方式与 MCP 标准的优势：
通过 MCP，模型能在需要时动态拉取信息，而无需一次性塞入所有上下文数据，从而显著提升上下文效率与扩展性。
关键特性与优势总结
下表总结了 MCP 的关键特性与优势维度：
| 维度 | 特性 | 说明 |
|---|---|---|
| 标准化 | 基于 JSON-RPC 定义的通用通信结构 | 兼容性强，可跨语言实现 |
| 可扩展性 | 三类原语可自定义扩展 | 支持任何工具或数据源接入 |
| 安全性 | 权限声明与用户确认机制 | 防止模型越权访问 |
| 生态开放性 | 统一协议层，促进开源组件协作 | 客户端与服务器可独立开发 |
| 开发简化 | 消除专用适配器 | 减少模型集成复杂度 |
| 可组合性 | 与提示模板和工具系统协同 | 支持多模型共享接口 |
总结
MCP 让 AI 模型具备了“连接世界”的能力。它并不改变模型推理逻辑，而是建立了一个安全、标准、可编排的上下文通道。借助 MCP，AI 系统可以像模块化操作系统那样，把模型、工具、资源与提示模板拼装成可协作的智能体生态。