1.2 MCP 的前世今生——从 LSP 灵感到开放标准
小周发现了 MCP，但他很好奇：这个协议是怎么来的？为什么是 Anthropic 发起的？
MCP 诞生前夜
在 MCP 出现之前，AI 工具集成经历过几次失败的尝试：
MCP 的关键洞察：与其在每个 AI 工具里为每个外部系统写适配器，不如定义一个标准协议——就像 USB-C 统一了充电接口一样。
LSP 的启示
MCP 的设计灵感来自一个成功的先例：Language Server Protocol (LSP)。
LSP 解决的问题
2015 年之前，每给一个编辑器加一种语言支持，都要写一套插件：
VS Code + Python → 写一套插件
Vim + Python → 写一套插件
Emacs + Python → 写一套插件
Sublime + Python → 写一套插件
再加 Go 语言？→ 4 × 2 = 8 个插件微软在 2015 年发布了 LSP，定义了编辑器和语言服务之间的标准协议：
语言实现一次 Language Server
VS Code、Vim、Emacs、Sublime...都通过同一个协议连接
加 N 种语言？N 个 Language Server
加 M 种编辑器？M 个 Client
总计 M + N，而不是 M × NMCP 的类比
MCP 做了同样的事，只是把场景从「编辑器 + 编程语言」换成了「AI 应用 + 外部系统」：
两者都使用 JSON-RPC 2.0，都有 Client-Server 架构，都通过标准协议解决 M×N 集成问题。
时间线
交给社区
MCP 的一个关键决策是移交 Linux Foundation 管理。这意味着：
- 不属于任何一家公司：Anthropic 发起了 MCP，但它现在是开放标准
- OpenAI 也支持：ChatGPT 已经支持 MCP，尽管 MCP 是竞争对手发起的
- 社区驱动演进：任何人都可以参与规范制定和 SDK 开发
为什么交给基金会重要？
如果 MCP 只属于 Anthropic，其他 AI 公司不会支持它。交给 Linux Foundation，MCP 成为「AI 行业的 USB-C」而非「Anthropic 的私有协议」。
MCP 的 10 种官方 SDK
MCP 目前有 10 种官方 SDK，按成熟度分为三个层级（Tier 1 由核心团队维护，Tier 2 由社区维护且功能完整，Tier 3 为早期阶段）：
本课程的代码示例以 Python 和 TypeScript 为主（Tier 1 SDK，最稳定）。
本节核心要点
- MCP 的设计灵感来自 LSP——都是用标准协议解决 M×N 集成问题
- 两者都使用 JSON-RPC 2.0 和 Client-Server 架构
- MCP 从 v1（2024.11）发展到 v4（2025.11），逐步加入 HTTP 传输、授权、任务管理等能力
- MCP 已移交 Linux Foundation，是开放标准而非 Anthropic 私有协议
- 10 种官方 SDK，本课程以 Python + TypeScript 为主
思考题：为什么 Anthropic 选择 JSON-RPC 2.0 而不是 REST 作为 MCP 的消息格式？（提示：想想双向通信的需求）
参考思路
关注"双向通信"——MCP 中 Server 可以反过来向 Client 发请求（Sampling、Elicitation），REST 是单向的请求-响应模式，无法支持这种能力。同时 JSON-RPC 2.0 的通知机制也让 Server 可以推送事件。