核心概念
MCP 是什么
MCP (Model Context Protocol) 标准化数据总线 是 Anthropic 开源的一套标准化协议
用于建立客户端、主机和服务器之间的通用对话方式
核心特征：
- 统一接口：任何支持 MCP 的 AI 都能访问遵循 MCP 标准的数据源
- 即插即用：实现一次，到处通用
- 标准化通信：基于 JSON-RPC 协议
理解”标准化”问题
每个数据源都说”方言”
| 因素 | 说明 |
|---|---|
| 没有通用标准 | GitHub、Slack、Google Drive 由不同公司在不同年份开发 |
| 各自的设计目标 | 每个服务解决的是不同的问题 |
| 通信方式差异 | API 设计完全不同：请求格式、认证方式、返回数据结构都不一样 |
| 数据源 | 需要做的事情 |
|---|---|
| GitHub | GET /commits + Authentication 头 + 读 message 字段 |
| Slack | POST /conversations.history + Bot Token + 读 text 字段 |
| Google Drive | GET /drive/files + OAuth2 认证 + 读 name 字段 |
关键点：指令完全不同，数据格式也不同
为 GitHub 写的代码对 Slack 完全无用
AI 也说”方言”
1
2
3
4
5
6
7
8
9
10
11
OpenAI (GPT-4)：
└─ 数据必须包装成 messages 列表
└─ Function Calling 需要特定的 JSON Schema 格式
Anthropic (Claude)：
└─ API 结构不同
└─ System Prompt 位置要求不同
└─ 工具定义格式在细节字段上不兼容
本地模型 (Llama 3)：
└─ 需要特定的提示词模板格式
N × M 复杂度问题
场景：
- 数据源：3 个（GitHub、Slack、本地数据库）
- AI 客户端：3 个（Claude Desktop、Cursor、Dify）
旧模式的工作量：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
总工作量 = 数据源数量 × AI 数量
= 3 × 3 = 9 组适配器代码
GitHub ──┬─→ Claude 适配器
├─→ Cursor 适配器
└─→ Dify 适配器
Slack ───┬─→ Claude 适配器
├─→ Cursor 适配器
└─→ Dify 适配器
DB ──────┬─→ Claude 适配器
├─→ Cursor 适配器
└─→ Dify 适配器
MCP 模式的工作量：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
总工作量 = 数据源数量 + AI 数量
= 3 + 3 = 6 次标准适配
数据源方（Server）：
└─ GitHub 实现一个 MCP Server
└─ Slack 实现一个 MCP Server
└─ DB 实现一个 MCP Server
AI 方（Client）：
└─ Claude 学会 MCP 协议
└─ Cursor 学会 MCP 协议
└─ Dify 学会 MCP 协议
结果：任何组合都能自动工作
理解”解耦”的价值
MCP 出现前的紧耦合
假设你开发了一个 AI 助手来查看 GitHub 仓库：
1
2
3
4
5
6
7
8
9
// 你的 AI 应用代码（紧耦合）
func fetchGitHubData() {
// GitHub API 的细节被硬编码在这里
response := http.Get("https://github.com/api/v3/repos/...")
// 特定的鉴权方式
req.Header.Set("Authorization", "token " + token)
// 特定的数据解析逻辑
data := response.JSON["items"][0]["message"]
}
后果：
- 你的 AI 软件和 GitHub 绑死了
- 如果 GitHub 改了接口 → 你的 AI 软件就挂了
- 如果你想换成 GitLab → 代码得完全重写
MCP 如何解耦
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
┌─────────────────────────────────────────────────┐
│ AI 客户端 │
│ (Claude Desktop / Cursor / Dify) │
│ └─ 只说"普通话"（标准 MCP 指令） │
└─────────────┬───────────────────────────────────┘
│ (标准 MCP 协议)
│
┌─────────────▼───────────────────────────────────┐
│ MCP Server（翻译官） │
│ ┌──────────────────────────────────────────┐ │
│ │ 左侧：听 AI 说普通话 │ │
│ │ 右侧：跟 GitHub 说"方言" │ │
│ │ 作用：隔离变化，防止数据源变动影响客户端 │ │
│ └──────────────────────────────────────────┘ │
└─────────────┬───────────────────────────────────┘
│ (GitHub 特定 API)
│
┌─────────────▼───────────────────────────────────┐
│ GitHub API（数据源） │
└─────────────────────────────────────────────────┘
| 维度 | 前 | 后 |
|---|---|---|
| 耦合方式 | 点对点紧耦合 | 通过标准协议解耦 |
| 变化隔离 | GitHub 改 API → AI 挂了 | GitHub 改 API → 只改 Server |
| AI 端影响 | 需要改代码 | 无需改代码 |
| 防腐效果 | ❌ 无防护 | ✅ 完全隔离 |
维护成本对比
场景：GitHub 修改了底层 API
旧模式（没有 MCP）：
1
2
3
4
5
6
7
GitHub API 变更通知 ↓
Claude Desktop 里的连接器 → 坏了 → 需要修 1 次
Cursor 编辑器 里的插件 → 坏了 → 需要修 1 次
Dify 平台 里的模块 → 坏了 → 需要修 1 次
总修改次数：3 次
维护成本：高
新模式（有 MCP）：
1
2
3
4
5
6
7
8
GitHub API 变更通知 ↓
git-mcp-server 代码 → 修改 1 处
↓
所有 AI 客户端自动获得修复
总修改次数：1 次
维护成本：✅ 低
所有客户端是否需要改代码？❌ 都不需要
