MCP（Model Context Protocol，模型上下文协议）
一、定义与本质
MCP（Model Context Protocol，模型上下文协议） 是由 Anthropic（Claude 的母公司）于 2024 年 11 月推出的开源开放标准协议。它旨在标准化大语言模型（LLM）与外部工具、数据源、提示词（Prompts）之间的集成方式。
通俗来说，MCP 是 AI 应用的 “通用接口” 或 “USB-C 端口” —— 正如 USB-C 统一了电子设备的连接方式，MCP 提供了一种标准化方式，让 AI 应用能够连接各种外部系统，而无需为每个工具单独开发适配代码。
“MCP 是 AI 领域的通用连接器，它通过开放标准协议，打通了大模型与外部世界之间的壁垒。” —— Anthropic
二、解决的核心问题
在 MCP 出现之前，AI 系统面临 “N × M 集成难题”：
- 每个大模型/智能体（N）对接每个 API、数据库、工具（M）都需要定制化的连接器
- 导致重复开发、集成碎片化、维护成本极高
- 不同 AI 应用之间无法共享工具生态
MCP 的解决方案：
通过统一的协议层，让 AI 模型无需为每个工具单独开发适配代码，实现了 “一次开发，处处集成”。
传统方式：N 个应用 × M 个工具 = N×M 个适配器
MCP 方式：N 个应用 + M 个 Server = N+M 个实现
三、核心架构（客户端-服务器模型）
MCP 采用 客户端-服务器架构（Client-Server），主要包含以下组件：
┌─────────────────────────────────────────┐
│ Host（主机） │ ← AI 应用，如 Claude Desktop、Cursor、VS Code
│ ┌─────────┐ ┌─────────┐ │
│ │ MCP │ │ MCP │ │
│ │ Client 1│◄────►│ Client 2│ ... │ ← 客户端实例，每个 Server 对应一个
│ └────┬────┘ └────┬────┘ │
└────────┼────────────────┼───────────────┘
│ │
▼ ▼
┌────────────────┐ ┌────────────────┐
│ MCP Server │ │ MCP Server │ ← 外部能力提供者（本地/远程）
│ (文件系统) │ │ (GitHub API) │
└────────────────┘ └────────────────┘
1. Host（主机）
- 发起请求的宿主应用，如 Claude Desktop、Cursor、VS Code 等 AI 应用
- 负责管理多个 MCP Client 实例和权限控制
- 是用户直接交互的界面
2. Client（客户端）
- Host 内部创建的 MCP 客户端实例
- 与 Server 维持 一对一连接
- 处理协议级别的生命周期（初始化、能力协商、心跳检测）
3. Server（服务器）
- 轻量级外部程序，暴露特定能力
- 可以是本地进程（通过
stdio通信）或远程服务（通过SSE/HTTP通信） - 开发者只需实现一次，所有 MCP Client 均可连接
一个 Host 可以同时连接多个 MCP Server，形成丰富的能力生态。
四、核心原语（Primitives）
MCP 定义了四种基本能力单元，Server 可向 AI 模型暴露以下上下文：
| 原语 | 英文 | 类型 | 说明 |
|---|---|---|---|
| 资源 | Resources | 只读数据 | 类似文件、数据库记录、API 响应，供模型读取上下文 |
| 工具 | Tools | 可执行函数 | 模型可调用的外部操作（如发送邮件、查询天气），需用户确认 |
| 提示词模板 | Prompts | 预设模板 | 用户可选择的预定义提示词，类似快捷指令 |
| 采样 | Sampling | 模型补全 | 允许 Server 向 Host 请求模型生成内容（较少见） |
详细说明
Resources（资源）
- 模型可读取的文档、数据（如本地文件、数据库内容、API 返回数据）
- 是只读的，用于为模型提供上下文信息
Tools（工具/函数）
- 模型可调用的操作（如搜索引擎、计算器、发送邮件、查询日历）
- 通常需要用户确认后才能执行
- 这是 MCP 中最常用的能力
Prompts（提示词模板）
- 可复用的指令片段
- 帮助用户快速使用特定功能
五、通信原理与协议细节
1. 传输层（Transport）
- Stdio：本地子进程通信，适合本地工具（如文件系统、数据库）
- SSE（Server-Sent Events）/ HTTP：远程服务通信，适合云端 API
2. 消息格式
基于 JSON-RPC 2.0 标准：
// Client 请求示例
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "read_file",
"arguments": { "path": "/tmp/test.txt" }
}
}
// Server 响应示例
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [{"type": "text", "text": "文件内容..."}]
}
}
3. 生命周期
- Initialization（初始化）：交换协议版本、能力声明（Capabilities）
- Operation（运行）：双向请求/响应 + Server Push 通知
- Termination（终止）：优雅关闭连接
六、为什么 MCP 很重要？
对开发者的价值
- 大幅降低 AI 应用与外部系统集成的开发成本和复杂度
- 无需为每个工具写定制代码，实现插件式开发
- 工具生态可跨应用复用
对 AI 应用/智能体的价值
- 获得丰富的工具和数据生态
- 突破预训练知识的限制，实现实时数据访问和任务执行
- 从"静态知识库"进化为能实时交互、执行任务的"智能代理"
对终端用户的价值
- AI 助手能访问个人数据（如日历、笔记）并代表用户执行操作
- 体验更个性化、更强大
七、行业采用现状
MCP 正迅速成为 LLM 智能体工具集成的事实标准：
- 模型提供商：OpenAI、Google、Anthropic 等已支持或正在集成
- 开发平台：Cursor、Cline、VS Code、Dify、Spring AI 等已集成
- 应用场景：
- AI 编程助手查询代码仓库
- 企业聊天机器人分析数据库
- AI 根据 Figma 设计稿生成网页
- 个人助手管理日历和邮件
八、MCP 与 Function Calling 的区别
| 特性 | Function Calling | MCP |
|---|---|---|
| 层级 | 模型层面的能力 | 应用层协议 |
| 集成方式 | 每个平台单独定义工具 | 统一标准化协议 |
| 开发模式 | 定制化集成 | 插件式开发，即插即用 |
| 生态互通 | 孤岛化 | 跨平台兼容 |
| 通信能力 | 单向调用 | 双向通信（支持 Server Push） |
简单理解：Function Calling 是模型"能调用函数"的能力，而 MCP 是"如何发现、注册、执行、展示这些工具"的完整协议标准。
九、使用流程示例
用户提问："帮我总结桌面上的 report.pdf"
Host (Claude Desktop)
│
▼
MCP Client ──JSON-RPC──► Filesystem Server (本地进程)
│ │
│◄────Resources----------┘
│ (读取 PDF 内容)
▼
模型获得上下文 ──► 生成总结 ──► 展示给用户
多 Server 组合示例：
用户提问："查一下我本周的会议安排，然后把报告发到团队 Slack"
Host
├──► Calendar Server ──► 获取会议安排
└──► Slack Server ──► 发送消息
十、局限性与安全挑战
尽管 MCP 前景广阔，目前也存在一些问题：
安全与隐私
- 恶意代码执行：本地 Server 可能执行危险操作
- 凭证盗窃：Server 可能窃取敏感信息
- 提示注入攻击：通过资源内容操纵模型行为
- 缺乏统一认证授权机制
架构限制
- 当前是有状态协议（支持推送通知），限制了无服务器（Serverless）部署
- 工具数量限制：模型提供商通常限制单次调用的工具数量（如 128 个），需要配合 RAG 等检索方案扩展
生态成熟度
- 仍处于快速发展阶段，协议版本可能变化
- 高质量 Server 的生态还在建设中
十一、总结
MCP 是 AI 领域的"通用连接器"，它通过开放标准协议，打通了大模型与外部世界之间的壁垒，让 AI 从"静态知识库"进化为能实时交互、执行任务的"智能代理"。
随着 OpenAI、Google 等巨头的采纳，MCP 正在成为构建 AI 应用基础设施的关键一环。对于开发者而言，理解并掌握 MCP，意味着能够更高效地构建具有外部能力的 AI 应用。
参考链接
欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。
更多推荐
5
0- 0
已为社区贡献1条内容
所有评论(0)