引言
1996 年之前，电脑的外设世界是一团混乱：键盘用 PS/2 接口，打印机用并口，鼠标用串口，调制解调器用另一个串口……每个设备都需要自己专用的连接器和驱动程序。如果你想连 5 种设备，你需要 5 种不同的接口和 5 套驱动。
然后 USB 出现了。一个接口，统一所有。键盘、鼠标、打印机、U 盘——全插同一种口。
2024 年的 AI 工具世界，正处于 USB 出现前的混乱状态。你有 N 个工具和 M 个模型，就需要 N × M 个集成适配器。Anthropic 提出的 MCP（Model Context Protocol），就是要成为 AI 工具世界的 USB。
2023.6OpenAI 发布 Function Calling，GPT-4 首次支持
2023.11支持并行工具调用和 tool_choice 控制
2024.1Claude 支持 tool_use，与 OpenAI 格式略有不同
2024.6Gemini 支持 Function Calling
2024.11Anthropic 发布 MCP 协议，开源
2025MCP 生态快速发展，社区贡献数百个 MCP Server
N × M 问题
没有统一标准时的困境
工具 × 模型的集成矩阵：
GPT-4 Claude Gemini DeepSeek
文件读取 适配器₁ 适配器₂ 适配器₃ 适配器₄
数据库查询 适配器₅ 适配器₆ 适配器₇ 适配器₈
搜索引擎 适配器₉ 适配器₁₀ 适配器₁₁ 适配器₁₂
代码执行 适配器₁₃ 适配器₁₄ 适配器₁₅ 适配器₁₆
N 个工具 × M 个模型 = N × M 个集成
每增加一个新工具或新模型，需要写新的适配器各家的工具调用格式差异
python
# OpenAI 的格式
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取天气",
"parameters": {"type": "object", "properties": {"city": {"type": "string"}}}
}
}]
# Claude 的格式（相似但不同）
tools = [{
"name": "get_weather", # 没有 "function" 嵌套层
"description": "获取天气",
"input_schema": { # 不叫 "parameters" 叫 "input_schema"
"type": "object",
"properties": {"city": {"type": "string"}}
}
}]
# Gemini 的格式
tools = [{
"function_declarations": [{ # 又一层嵌套
"name": "get_weather",
"description": "获取天气",
"parameters": {...}
}]
}]核心概念相同（JSON Schema 定义工具），但实现细节不同。这就像每个国家用不同的电源插头——功能一样，但互不兼容。
MCP：Model Context Protocol
什么是 MCP？
MCP 是 Anthropic 在 2024 年 11 月开源的一个协议，目标是标准化 AI 模型与外部工具/数据的连接方式。
MCP 的核心类比：
USB 统一了硬件接口
MCP 统一了 AI 工具接口
USB 之前：
每个设备需要自己的接口和驱动
USB 之后：
所有设备用同一个标准
MCP 之前：
每个工具需要针对每个模型写适配器
MCP 之后（愿景）：
所有工具用同一个协议，所有模型都支持MCP 架构
MCP 架构：
┌─────────────┐
│ AI 应用 │ ← Host（如 Claude Desktop, Cursor, VS Code）
│ │
│ MCP Client │ ← 管理与 Server 的连接
└──────┬──────┘
│ MCP 协议（JSON-RPC）
│
┌──────┴──────┐
│ MCP Server │ ← 提供具体工具能力的进程
│ │
│ 工具: │
│ - 文件读写 │
│ - 数据库查询│
│ - API 调用 │
└─────────────┘
关键：
Host 运行 MCP Client，Client 通过标准协议连接 MCP Server
MCP Server 封装了具体的工具实现
任何 AI 应用都能通过 MCP 协议使用同一个 ServerMCP 的三种能力
| 能力 | 说明 | 例子 |
|---|---|---|
| Tools | 模型可以调用的函数 | 文件操作、API 调用、代码执行 |
| Resources | 模型可以读取的数据 | 文件内容、数据库记录、API 响应 |
| Prompts | 预定义的提示词模板 | 常用任务的标准提示词 |
一个简单的 MCP Server 示例
python
# 使用 Python MCP SDK
from mcp.server import Server
server = Server("weather-server")
@server.tool()
async def get_weather(city: str) -> str:
"""获取指定城市的天气信息"""
# 实际实现：调用天气 API
return f"{city}: 晴天, 28°C"
@server.resource("weather://forecast/{city}")
async def weather_forecast(city: str) -> str:
"""获取城市天气预报"""
return f"{city} 未来三天: 晴、多云、晴"
# 启动 Server
# 任何支持 MCP 的 AI 应用都可以使用这个 Server 的工具MCP 的生态
MCP 的生态现状（2025 年初）：
官方 Server：
├── filesystem — 文件系统操作
├── postgres — PostgreSQL 数据库
├── github — GitHub API
├── puppeteer — 浏览器自动化
└── brave-search — 网页搜索
社区 Server（数百个）：
├── 数据库：MySQL, MongoDB, Redis...
├── API：Slack, Notion, Jira...
├── 开发工具：Git, Docker, Kubernetes...
└── 各种垂直领域工具
Host 支持：
├── Claude Desktop — 原生支持
├── Cursor — 集成 MCP
├── VS Code (Copilot) — 支持 MCP
└── 其他 IDE 和工具陆续接入超越 OpenAI：各家如何处理 Tool Calling
对比表
| 维度 | OpenAI | Claude | Gemini |
|---|---|---|---|
| 工具定义 | tools.function.parameters | tools.input_schema | function_declarations |
| 并行调用 | 支持 | 支持 | 支持 |
| 工具选择 | auto/none/required/指定 | auto/any/指定 | auto/none/指定 |
| 流式 | 支持 | 支持 | 支持 |
| MCP | 通过社区实现 | 原生支持 | 实验性 |
抽象层：跨模型统一接口
python
# 使用 LiteLLM 等统一 SDK
from litellm import completion
# 同一份代码，切换不同模型
# OpenAI
response = completion(model="gpt-4o", messages=messages, tools=tools)
# Claude
response = completion(model="claude-sonnet-4-20250514", messages=messages, tools=tools)
# Gemini
response = completion(model="gemini/gemini-2.5-pro", messages=messages, tools=tools)
# LiteLLM 自动处理格式差异本节小结
| 概念 | 要点 |
|---|---|
| N × M 问题 | N 个工具 × M 个模型 = N × M 个集成适配器 |
| MCP | Anthropic 2024.11 开源的统一协议，AI 工具的 USB |
| MCP 架构 | Host → MCP Client → MCP Server，标准化的工具连接 |
| 格式差异 | 各家 API 格式略有不同，但核心概念一致（JSON Schema） |
| 趋势 | MCP 生态快速发展，跨模型统一接口正在形成 |
思考题
- MCP 能否真正成为所有 AI 模型的统一标准？有哪些阻力？
- MCP 和传统软件中的 API 网关有什么异同？
- 如果你是一个 SaaS 产品的开发者，你会为你的产品开发 MCP Server 吗？为什么？