最后更新: 2026-03-14 | 分类: AI 基础设施 / 协议
Model Context Protocol (MCP) 是 Anthropic 于 2024 年 11 月发布的开放协议，旨在标准化 AI 模型与外部工具、数据源之间的连接方式。通过统一的客户端-服务端架构，MCP 让 AI 应用可以”即插即用”地接入各种工具和数据源，而无需为每个集成编写定制代码。
截至 2025 年底，MCP 已获得广泛采纳：主流 AI IDE（Cursor、Windsurf、Cline）、Agent 框架（LangChain、OpenClaw、Dify）和桌面应用（Claude Desktop）均已支持 MCP。生态中已有 1,000+ 开源 MCP Server 覆盖文件系统、数据库、云服务、开发工具等场景。
核心结论: MCP 正在成为 AI 工具集成的事实标准协议，其设计简洁、生态增长迅速。与 Function Calling 相比，MCP 解决了跨模型标准化和工具复用问题，两者互补而非替代。
在 MCP 出现之前，每个 AI 应用都需要为每个工具编写定制集成代码：
MCP 的核心价值是解耦: 工具提供方只需实现一次 MCP Server，任何 MCP Client 都可以使用。
MCP 基于 JSON-RPC 2.0 协议，定义了三层能力：
支持参数验证和错误处理
Resources（资源）: 可读取的数据上下文
file:///path）可订阅变更通知
Prompts（提示模板）: 预定义的提示模板
MCP 支持三种传输方式：
| 传输方式 | 适用场景 | 说明 |
|---|---|---|
| stdio | 本地工具 | 通过标准输入输出通信，延迟最低 |
| Streamable HTTP | 远程服务（推荐） | 基于 HTTP POST 发送请求，支持 SSE 流式响应，取代旧版 HTTP+SSE |
| HTTP + SSE（旧版） | 兼容场景 | 旧版传输方式，已被 Streamable HTTP 取代 |
注意：MCP 规范（2025 年 3 月更新）已将 Streamable HTTP 列为推荐的远程传输方式。相比旧版 HTTP+SSE，Streamable HTTP 简化了连接管理——单个 HTTP 端点即可处理请求和流式响应，不再需要独立的 SSE 端点。旧版 HTTP+SSE 仍可用于向后兼容，但新项目应优先选择 Streamable HTTP。
Streamable HTTP 优势： - 统一端点：单个 HTTP URL 处理请求和响应，简化部署 - 灵活响应模式：支持标准 JSON 响应和 SSE 流式响应 - 无状态友好：每个请求独立处理，更易水平扩展 - 安全兼容：天然支持标准 HTTP 认证（OAuth 2.1、Bearer Token 等）
一个 MCP Server 通常包含：
# 简化的 MCP Server 结构
from mcp.server import Server
server = Server("my-tool")
@server.tool()
def search(query: str) -> str:
"""搜索功能"""
return perform_search(query)
@server.resource("config://settings")
def get_config() -> str:
"""读取配置"""
return load_config()
@server.prompt()
def summarize(text: str) -> str:
"""摘要提示模板"""
return f"请总结以下内容:\n{text}"
Server 生命周期:
1. Client 启动 Server 进程（stdio）或连接 Server（HTTP）
2. 双方进行初始化握手（initialize）
3. Server 声明能力（Tools / Resources / Prompts）
4. Client 按需调用
5. 连接关闭或超时
MCP Client 内置于 AI 应用中，负责：
| Client | 类型 | MCP 支持程度 |
|---|---|---|
| Claude Desktop | 桌面应用 | ⭐ 原生支持，最早实现 |
| Cursor | AI IDE | ✅ 完整支持 |
| Windsurf | AI IDE | ✅ 完整支持 |
| Cline | VS Code 插件 | ✅ 完整支持 |
| OpenClaw | Agent 平台 | ✅ 完整支持 |
| LangChain | 框架 | ✅ 通过适配器 |
| Dify | LLMOps 平台 | ✅ 支持 |
| Server | 功能 | 说明 |
|---|---|---|
| filesystem | 文件系统操作 | 读写文件、目录浏览 |
| github | GitHub API | Issues、PR、代码搜索 |
| git | Git 操作 | 提交、分支、diff |
| postgres | PostgreSQL | SQL 查询、Schema 浏览 |
| sqlite | SQLite | 轻量数据库操作 |
| puppeteer | 浏览器自动化 | 网页截图、DOM 操作 |
| brave-search | 网络搜索 | Brave Search API |
| fetch | HTTP 请求 | 网页内容抓取 |
| memory | 知识图谱 | 持久化记忆存储 |
| slack | Slack 集成 | 消息、频道操作 |
| 类别 | 代表项目 | 数量级 |
|---|---|---|
| 云服务 | AWS、GCP、Azure、Cloudflare | 50+ |
| 数据库 | MongoDB、Redis、Supabase、Prisma | 40+ |
| 开发工具 | Linear、Jira、Notion、Obsidian | 60+ |
| 设计工具 | Figma、Canva | 10+ |
| 通信 | Slack、Discord、Email | 20+ |
| 数据/分析 | BigQuery、Snowflake、Metabase | 30+ |
| 本地工具 | 终端、Python REPL、Node REPL | 20+ |
| AI 工具 | 图像生成、语音合成、翻译 | 30+ |
| 总计 | 1,000+ |
1. Filesystem Server - 读写本地文件、目录导航 - 支持路径权限控制 - 最基础也最常用的 Server
2. GitHub Server - 创建/管理 Issues 和 PR - 代码搜索、文件浏览 - CI/CD 状态查询 - 适合开发工作流自动化
3. PostgreSQL Server - 只读查询（安全考虑） - Schema 浏览和表结构查看 - 支持复杂 JOIN 和聚合
4. Puppeteer Server - 无头浏览器控制 - 网页截图、PDF 生成 - 表单填写、点击操作 - 需要注意沙箱安全
| 维度 | Function Calling | MCP |
|---|---|---|
| 标准化 | 各提供商不同（OpenAI、Anthropic 各自定义） | 统一协议（JSON-RPC 2.0） |
| 复用性 | 需为每个模型重新实现 | 一次实现，所有 Client 可用 |
| 发现机制 | 无（硬编码在调用中） | 动态发现（tools/list） |
| 工具类型 | 仅函数调用 | Tools + Resources + Prompts |
| 传输方式 | API 层（内嵌在聊天 API 中） | 独立协议（stdio / HTTP SSE） |
| 状态管理 | 无状态（每次调用独立） | 有状态（长连接、订阅通知） |
| 版本管理 | 无 | Server 版本化 |
| 功能 | Function Calling | MCP |
|---|---|---|
| 函数调用 | ✅ | ✅ |
| 参数校验 | ✅ | ✅ |
| 错误处理 | ⚠️ 基础 | ✅ 结构化错误 |
| 流式返回 | ✅ 部分支持 | ✅ 原生支持 |
| 资源访问 | ❌ | ✅ Resources |
| 提示模板 | ❌ | ✅ Prompts |
| 通知/订阅 | ❌ | ✅ 支持 |
| 跨模型兼容 | ❌ 需适配 | ✅ 统一接口 |
Function Calling 更适合: - 简单的单次函数调用 - 不需要复用的临时工具 - 对延迟极度敏感的场景 - 模型提供商原生支持的场景
MCP 更适合: - 需要跨多个 AI 应用复用的工具 - 复杂的工具生态（多种工具类型） - 需要资源访问和订阅的场景 - 长期维护的工具集成
两者关系: Function Calling 是 LLM 的底层能力，MCP 是更高层的协议标准。MCP Server 通常在内部使用 Function Calling 来触发工具执行。
MCP Gateway 模式出现（聚合多个 Server）
认证与安全标准化
沙箱化执行环境
性能优化
缓存层标准化
企业特性
合规审计
与 Agent 框架深度集成
风险描述：恶意 MCP Server 可以通过工具返回内容注入恶意指令，劫持 AI 模型的行为。例如，一个被攻陷的文件系统 Server 可能在文件内容中嵌入隐藏指令，诱导模型执行未授权操作。
攻击场景：
- 工具返回值中嵌入 ignore previous instructions 类型的注入指令
- Resource 内容中包含精心构造的提示，诱导模型泄露其他上下文
- 通过 Prompt 模板传递恶意参数
缓解措施： - 返回值沙箱化：Client 应对工具返回值做转义处理，防止注入指令被执行 - 权限最小化：Server 只暴露必要的工具和资源，减少攻击面 - 返回值审计：对工具输出进行异常检测（如包含疑似指令的文本） - 分层提示架构：将工具输出与系统提示隔离，使用独立的上下文窗口
风险描述：恶意或被攻陷的 MCP Server 可以通过多种渠道窃取用户数据。
攻击向量： - 工具参数外传：将用户敏感数据作为工具参数发送到外部服务器 - Resource URI 探测：通过枚举 URI 路径获取敏感文件内容 - 侧信道攻击：通过工具响应时间、错误信息等推断系统状态 - 第三方依赖：Server 依赖的 npm/pip 包可能包含数据收集代码
缓解措施： - 网络隔离：限制 MCP Server 的网络访问范围 - 数据脱敏：敏感数据在传递给 Server 前进行脱敏处理 - 审计日志：记录所有工具调用和 Resource 访问 - 供应链安全：定期审查 Server 的依赖包，使用 lockfile 锁定版本 - OAuth Token 范围限制：授予 Server 最小必要权限
风险描述：MCP 协议本身不定义细粒度的权限模型，Server 往往拥有过大权限。
典型问题： - Filesystem Server 默认可访问所有文件 - Database Server 通常拥有读写权限 - 缺乏用户级别的权限隔离 - 工具调用缺乏审批机制
缓解措施： - 路径白名单：Filesystem Server 限制在特定目录范围内 - 只读模式：生产环境中 Database Server 优先使用只读账号 - OAuth 2.1 集成：使用标准 OAuth 流程进行用户认证和授权（MCP 规范正在推进） - 人工审批：敏感操作（如删除文件、执行命令）需要用户确认 - 沙箱执行：在 Docker/沙箱环境中运行 MCP Server - 速率限制：对工具调用频率进行限制，防止滥用
| 风险类别 | 建议措施 | 优先级 |
|---|---|---|
| 提示注入 | 返回值转义 + 沙箱化 + 分层提示 | 🔴 高 |
| 数据泄露 | 网络隔离 + 脱敏 + 审计日志 | 🔴 高 |
| 权限过大 | 最小权限 + 路径白名单 + 只读模式 | 🔴 高 |
| 供应链 | 依赖审查 + lockfile + 静态分析 | 🟡 中 |
| 认证缺失 | OAuth 2.1 + Bearer Token + TLS | 🟡 中 |
| 拒绝服务 | 速率限制 + 超时设置 + 资源配额 | 🟡 中 |