在讨论 MCP（Model Context Protocol，模型上下文协议）的时候，一个很常见的问题是：

它是不是一种 RPC（Remote Procedure Call，远程过程调用）升级版？

如果只从“调用远程功能”这个角度看，答案似乎是“是”。

但如果稍微往下再看一层，会发现它们根本不在同一个设计层级。

更准确的说法是：

RPC、LSP（Language Server Protocol，语言服务器协议）、MCP，其实是“抽象层级不断上移”的三个阶段。

---

一、软件系统的核心其实一直是“抽象”

软件工程里最核心的思想其实很简单：

把复杂性隐藏起来，只暴露可使用的能力。

这就是“抽象（Abstraction）”。

比如：

• 文件系统让你不用关心磁盘结构
• 数据库让你不用关心索引和缓存
• HTTP 让你不用关心 TCP 细节

抽象的本质只有一句话：

你只需要知道“能做什么”，不需要知道“怎么做”。

---

二、RPC：把“远程调用”变成本地函数

RPC 的目标非常直接：

让远程服务像本地函数一样被调用。

比如：

userService.getUser(123)

表面上是函数调用，实际上背后可能发生：

• 网络通信
• 序列化与反序列化
• 服务发现
• 负载均衡
• 重试与超时控制

这些复杂性都被隐藏了。

---

RPC 的抽象层级

RPC 本质是在做一件事：

把“网络调用”抽象成“函数调用”。

它的核心关注点是：

• 接口（Interface）
• 参数（Parameters）
• 返回值（Return Value）

所以 RPC 可以理解为：

“函数级别的抽象（Function Abstraction）”

但有一个限制很明显：

谁调用、调用什么、调用逻辑，仍然是人写死的。

---

三、LSP：把“代码能力”抽象出来

接下来是一个完全不同的问题。

在 IDE 世界里，问题不是“调用远程函数”，而是：

如何让编辑器理解代码？

于是出现了 LSP：

Language Server Protocol

它解决的是一个很现实的问题：

不同语言 + 不同编辑器 = 爆炸式复杂度

---

传统问题

如果没有 LSP：

• 每个 IDE 要实现一套 Java 支持
• 再实现一套 Python
• 再实现一套 Go
• 每个语言重复开发

成本极高。

---

LSP 的思路

LSP 做了一个非常关键的拆分：

编辑器（Editor）
只负责 UI

语言服务器（Language Server）
负责理解代码

例如：

• Go → gopls
• Python → pyright
• Rust → rust-analyzer

---

LSP 的本质抽象

LSP 抽象的不是“函数”，而是：

“代码理解能力（Code Intelligence Capability）”

包括：

• 跳转定义
• 查找引用
• 自动补全
• 类型推导
• 语义分析

所以 LSP 可以理解为：

“语义能力的标准化接口”

---

一个关键变化

RPC 是：

人决定调用什么函数

LSP 是：

编辑器通过协议获取“理解代码的能力”

抽象层级开始上升了。

---

四、代码检索的演进：从字符串到语义

理解 LSP，可以顺便理解代码检索的演进。

---

第一阶段：grep（字符串搜索）

只能做：

匹配文本

不知道语义。

---

第二阶段：AST（语法树）

可以识别：

• 函数
• 类
• import

但还不理解“关系”。

---

第三阶段：LSP（语义理解）

开始具备：

• 定义关系
• 引用关系
• 类型关系
• 调用关系

进入“语义级理解”。

---

第四阶段：Code Graph（代码图谱）

开始理解：

Controller → Service → Repository → DB

整个系统结构变得可分析。

---

这一阶段，是现代 AI 编程工具的基础。

---

五、MCP：从“函数调用”走向“能力调用”

最后是 MCP。

MCP（Model Context Protocol，模型上下文协议）表面看起来像 RPC：

• request / response
• tool call
• JSON schema

但它真正解决的问题完全不同。

---

MCP 解决的问题不是“调用函数”

而是：

AI 如何使用外部世界的能力？

例如：

• 搜索
• 文件操作
• 数据库查询
• Git 操作
• 浏览网页
• 调用系统工具

---

关键变化

传统系统：

人写代码 → 调用函数

MCP 系统：

AI 决定使用什么能力 → 自动组合执行路径

---

MCP 的核心抽象

MCP 抽象的不是：

• function（函数）
• service（服务）

而是：

capability（能力）

也就是：

“系统能做什么”

而不是：

“系统有什么接口”

---

六、RPC vs LSP vs MCP：抽象层级变化

可以用一个简单对比理解：

层级	抽象对象	谁在决定
RPC	函数（Function）	人类
LSP	代码能力（Code Capability）	编辑器
MCP	系统能力（System Capability）	AI

---

RPC

我调用哪个函数，是我写死的

---

LSP

编辑器帮我理解代码

---

MCP

AI 自己选择使用哪些能力完成任务

---

七、MCP 本质上是一种“能力抽象”

如果用一句话总结：

MCP 是一种“能力抽象层（Capability Abstraction Layer）”

它隐藏的不是代码，而是：

• 工具实现方式
• 服务部署方式
• API 细节
• 系统结构

只暴露一件事：

“你能做什么”

---

八、从设计模式角度看 MCP

MCP 并不是单一设计模式，而是多个模式的组合：

• Adapter（适配器）：封装不同工具
• Facade（外观模式）：统一接口
• Strategy（策略模式）：AI 决定使用哪个工具
• Proxy（代理模式）：中间层执行调用
• Dependency Injection（依赖注入）：动态注入上下文
• Plugin System（插件系统）：能力扩展机制

但这些都只是表层。

更深层是：

从“接口驱动”变成“能力驱动”。

---

九、真正的变化：从 Function 到 Capability

过去软件系统的核心单位是：

函数（Function）

现在 AI 系统的核心单位变成：

能力（Capability）

区别在于：

• Function：人定义调用方式
• Capability：系统描述“能做什么”，AI 自己组合

---

十、一个更本质的理解

如果把整个演进压缩成一句话：

---

RPC

把网络调用变成本地函数

---

LSP

把代码能力变成标准接口

---

MCP

把系统能力变成 AI 可以自由组合的资源

---

十一、结论

如果从抽象设计的角度看：

MCP 并不是 RPC 的升级版，而是抽象层级的跃迁。

它的意义不在“调用方式”，而在：

系统第一次开始以“能力”而不是“接口”对外表达。

---

最后一句话

如果说：

• RPC 是“函数抽象”
• LSP 是“语义抽象”

那么：

MCP 是“能力抽象（Capability Abstraction）”，也是 AI Native（AI 原生）系统的起点。