MCP 是什么：从碎片化到标准化
在 MCP 出现之前，AI Agent 与外部工具的对接是一片混乱：每个 LLM 厂商有自己的 Function Calling 规范，每个 IDE 有自己的插件协议，每个 Agent 框架有自己的工具注册机制。结果是——写一次工具逻辑，换个模型就得重写一遍。
MCP 的核心定位是做一个统一的标准接口，让任何 LLM 客户端都能以同一套协议连接任何工具服务器——就像 USB 让任何电脑都能连接任何外设一样。
Model Context Protocol（MCP）是一个开放标准协议，定义了 AI 客户端与外部工具/数据源之间的通信规范。它使得工具开发者只需写一次，所有支持 MCP 的 AI 客户端即可使用——"Write once, connect everywhere"。
| 维度 | MCP 之前 | MCP 之后 |
|---|---|---|
| 标准 | 每家厂商私有协议 | 统一开放标准 |
| 复用性 | 换模型重写工具 | 写一次，到处连 |
| 生态 | 封闭/私有 | 社区驱动，可共享 |
| 调试 | 每家各搞一套 | 统一 Inspector 工具 |
| 典型类比 | 每台电脑不同的外设接口 | USB 统一接口 |
三层架构：Client-Protocol-Server
MCP 采用经典的客户端-服务器架构，但增加了协议层作为中间标准：
| 层级 | 角色 | 职责 | 示例 |
|---|---|---|---|
| AI 客户端 | MCP Client | 发现、连接、调用 MCP Server 暴露的能力 | Claude Code、Cursor、VS Code+Continue |
| 协议层 | MCP Protocol | 定义消息格式、原语类型、传输规范、生命周期 | JSON-RPC 2.0 消息格式 |
| 工具服务器 | MCP Server | 包装外部资源，以标准接口暴露能力 | 数据库查询、API 调用、文件系统 |
架构关键设计决策：
- 进程隔离：MCP Server 以独立进程运行，与 AI 客户端解耦——即使 Server 崩溃也不影响客户端
- JSON-RPC 2.0：消息格式基于成熟的 JSON-RPC 2.0 规范，易于实现和调试
- 能力声明：Server 启动时声明自身能力（支持哪些 Tools/Resources/Prompts），Client 据此构建可用能力面板
- 模型无关：协议不绑定任何特定 LLM，任何 AI 客户端均可实现 MCP Client 接口
三大原语：Tools、Resources、Prompts
MCP 定义了三种能力原语，每种服务于不同的交互模式：
Tools（工具）— 可调用的函数
Tools 是 Agent 可以主动调用的函数，是 MCP 最核心的原语。
| 属性 | 说明 |
|---|---|
| 定义方式 | 装饰器（如 @mcp.tool()）或 JSON Schema |
| 参数类型 | 支持类型化参数和默认值 |
| 返回值 | 字符串（通常 Markdown 格式） |
| 描述要求 | 面向 AI 撰写，非人类——描述质量直接影响调用准确率 |
| 典型示例 | 查询数据库、发送邮件、调用 API |
Tool 的描述是给 AI 看的，不是给人类看文档用的。一个清晰、场景化的 Tool 描述能将调用准确率提升 30-50%；而模糊描述则是 Agent "工具选错"的首要原因。
Resources（资源）— 可读的数据源
Resources 是 Agent 可以读取的数据源，通过 URI scheme 标识：
| 属性 | 说明 |
|---|---|
| 定义方式 | URI scheme 装饰器（如 @mcp.resource("schema://tables")） |
| 读取方式 | AI 客户端主动拉取，非推送 |
| 典型示例 | 数据库 schema、配置文件、项目结构 |
| 与 Tools 的区别 | Resources 是"读"，Tools 是"做"；Resources 无副作用，Tools 可能有 |
Prompts（提示模板）— 可复用的对话模板
Prompts 是预定义的提示模板，让常见任务可以一键触发：
- 减少重复的 Prompt 编写
- 标准化团队内部的最佳实践
- 降低 AI 工具的使用门槛
传输机制：stdio 与 Streamable HTTP
MCP 支持两种传输机制，分别适用于不同场景：
| 传输方式 | 模式 | 适用场景 | 状态 |
|---|---|---|---|
| stdio | 本地子进程 | 单人本地开发 | ✅ 当前稳定 |
| Streamable HTTP | 远程 HTTP 服务器 | 团队共享、远程部署 | ✅ 当前推荐（2026） |
| SSE（旧） | Server-Sent Events | 旧版远程连接 | ❌ 已弃用 |
stdio 传输（本地）
MCP Server 作为本地子进程运行，通过标准输入/输出通信。这是最简单的模式：
- 零网络配置，开箱即用
- Server 生命周期由 AI 客户端管理（启动、停止）
- 适合个人开发者的本地工具链
Streamable HTTP 传输（远程）
将 MCP Server 部署为远程 HTTP 服务，团队成员共享：
- 支持负载均衡和水平扩展
- 可添加认证层（API Key、OAuth）
- 客户端通过
--transport http --url连接
MCP 规范已从 SSE 迁移至 Streamable HTTP。任何使用 --transport sse 的教程均已过时。如果你在 2025 年的文档中看到 SSE 传输，请替换为 Streamable HTTP。
安全模型：信任边界与攻击面
MCP 的安全模型目前是有限但有意识的——安全主要在单个 Server/Tool 层面实现，而非协议级别的全局框架：
| 安全层面 | 当前实现 | 局限 |
|---|---|---|
| SQL 注入防护 | Server 端校验（仅允许 SELECT） | 依赖每个 Server 自行实现 |
| 结果限制 | 查询上限（如 50 行） | 无协议级强制 |
| API Key 管理 | 通过 --env 显式注入 |
不从 Shell 环境继承，需手动配置 |
| 权限控制 | Server 声明只读/读写 | 无细粒度 RBAC |
| 认证/授权 | 依赖 Server 自行实现 Bearer Token | 无协议级认证框架 |
| 审计日志 | 无标准规范 | 各 Server 自行记录 |
已知的 MCP 特有攻击面：
- 恶意 MCP 工具投毒：攻击者发布伪造的 MCP Server，诱导 Agent 连接并执行恶意指令（OWASP ASI04 供应链漏洞的 MCP 特化版）
- MCP 数据泄露通道：MCP 引入的 Tools/Resources 接口可能成为 Agent 泄露源代码、密钥、用户文件的隐蔽通道
- 能力越权：一个本应只读的 MCP Server 通过 Tool 链实现了写操作
MCP vs 传统 Function Calling
| 维度 | 传统 Function Calling | MCP 协议 |
|---|---|---|
| 标准化 | 每家厂商自有规范 | 统一开放标准 |
| 复用性 | 换模型需重写 | 写一次，到处连 |
| 生态 | 封闭/私有 | 社区驱动，Servers 可共享 |
| 调试 | 各厂商各搞一套 | 统一 Inspector 工具 |
| 运行时加载 | 通常编译时绑定 | 动态发现、运行时加载 |
| 进程隔离 | 工具通常嵌入主进程 | Server 独立进程，崩溃隔离 |
| 适用范围 | 单模型应用 | 多模型、多客户端场景 |
| 学习曲线 | 低（内置于 SDK） | 中（需理解协议概念） |
MCP 不是要取代 Function Calling，而是在其之上增加了一个标准化的发现和通信层。Function Calling 解决的是"模型如何调用函数"，MCP 解决的是"如何统一管理和暴露函数"。两者互补而非替代。
2026 路线图：四大优先级
MCP 2026 路线图从基于发布里程碑的规划转变为基于优先级领域的规划，由工作组（Working Groups）驱动：
| 优先级 | 方向 | 核心内容 | 状态 |
|---|---|---|---|
| 🚀 P1 | 传输演进 | 无状态会话、Server Discovery（.well-known）、会话模型明确化 | 活跃开发 |
| 🤖 P2 | Agent 通信 | Tasks 原语（SEP-1686）迭代：重试语义、过期策略、生命周期补全 | 实验特性 |
| 🏛️ P3 | 治理成熟 | 贡献者阶梯、委托模型（WG 可自主接受 SEP）、Core Maintainer 战略监督 | 规划中 |
| 🏢 P4 | 企业就绪 | 审计追踪、SSO 集成认证、网关行为、配置可移植性 | 定义中（最模糊） |
关键路线图细节
- 不增加新传输：本周期刻意保持传输集精简，专注改进现有 Streamable HTTP
- 无状态会话：解决有状态会话与负载均衡器的摩擦，让 Server 可以水平扩展
- Server Discovery：通过
.well-known标准元数据格式，无需活跃连接即可发现 Server 能力 - 企业工作：大部分以扩展（Extensions）形式落地，不加重核心协议——这是刻意的设计决策
- 地平线提案：SEP-1932（DPoP）、SEP-1933（Workload Identity Federation）等安全增强
企业就绪是四大优先级中定义最模糊的——目前尚无企业工作组，正在积极寻求领导者。如果你的组织正在部署 MCP，现在是参与标准定义的最佳窗口。
生态现状与兼容矩阵
| AI 客户端 | MCP 支持 | 备注 |
|---|---|---|
| Claude Code | ✅ 原生 | 最佳体验，配置最简 |
| Claude Desktop | ✅ 支持 | 通过配置文件 |
| Cursor | ✅ 支持 | IDE 集成 |
| VS Code + Continue | ✅ 支持 | 开源方案 |
| OpenClaw | ✅ 支持 | 通过 Skills 机制 |
| Windsurf | ✅ 支持 | IDE 内置 |
| ChatGPT/GPT-5 | ⚠️ 部分支持 | 从 GPT-5 开始引入 |
SDK 生态：
- Python：FastMCP（
mcp[cli]），⚠️ v2.0 开发中有 Breaking Changes，务必锁定版本pip install "mcp[cli]>=1.25,<2" - TypeScript：官方
@modelcontextprotocol/sdk - 社区：Go、Rust、Java 等语言均有社区 SDK
Server 数量：截至 2026 年 3 月，ClawHub 索引的 MCP Server 已超过 19,831 个，月度增长约 15%。
实战：5 分钟写一个 MCP Server
最简 MCP Server（Python）
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("my-tools")
@mcp.tool()
def check_api_balance(service: str = "openai") -> str:
"""查询指定 API 服务的余额"""
# 实际实现中调用真实 API
return f"**{service}** 余额: $42.50"
@mcp.resource("config://api-keys")
def get_api_config() -> str:
"""返回当前 API 配置信息"""
return "已配置: openai, anthropic, deepseek"
if __name__ == "__main__":
mcp.run() # 默认 stdio 传输部署为远程服务
# 远程模式启动
mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)
# 客户端连接
# claude mcp add my-tools --transport http --url https://your-server:8000/mcp关键注意事项
- 环境变量必须通过
--env显式传递，不会从 Shell 环境继承 - Tool 描述面向 AI，务必具体、场景化
- 验证命令：
claude mcp list - Python SDK 务必锁定版本号，避免 v2.0 Breaking Changes