过去二十年，软件架构经历了几次非常明显的范式迁移（Paradigm Shift，范式转移）：

单体应用
→ API
→ RPC
→ 微服务（Microservice）
→ 云原生（Cloud Native）
→ Agent Runtime（智能体运行时）
→ MCP

很多人第一次接触 MCP（Model Context Protocol，模型上下文协议）时，会有一种强烈的既视感：

它像 RPC，
又像插件系统，
还像 IDE 的 LSP。

这种感觉并没有错。

因为 MCP 本身，就是建立在过去几十年软件工程思想上的“AI Native（AI 原生）协议层”。

而理解 MCP，最好的方式，不是单独看 MCP，而是从：

RPC
→ LSP
→ Semantic Code Intelligence
→ Agent Runtime
→ MCP

这条技术演进路线去看。

---

一、RPC：分布式时代的“函数调用”

RPC（Remote Procedure Call，远程过程调用）是现代分布式系统最重要的基础设施之一。

它解决的问题非常简单：

如何像调用本地函数一样调用远程服务？

例如：

userService.getUser(123)

程序员写起来像本地调用，但实际上背后可能发生了：

序列化（Serialization）
→ 网络传输（Network Transport）
→ 服务执行
→ 返回结果

典型 RPC 技术包括：

• gRPC
• Apache Dubbo
• Apache Thrift
• JSON-RPC

---

RPC 的本质

RPC 的核心思想：

“程序调用函数”

调用方必须明确知道：

• 调哪个接口
• 参数是什么
• 返回值是什么
• 服务地址在哪里

因此 RPC 的核心是：

Function-Oriented Architecture（面向函数架构）

它适合：

• 微服务（Microservice）
• 后端系统
• 企业服务治理
• Service Mesh（服务网格）

但 RPC 有一个天然局限：

它是“人类编排”的系统。

程序员必须提前写好逻辑。

---

二、LSP：IDE 时代的能力解耦

后来软件工程遇到了另一个问题：

编辑器越来越多，
编程语言越来越多。

于是出现了经典的：

N × M 问题

例如：

编辑器	语言支持
VSCode	Java/Python/Go/Rust
Vim	Java/Python/Go/Rust
Emacs	Java/Python/Go/Rust

意味着：

每个编辑器
都要单独实现：
自动补全
跳转定义
错误检查
类型推导

复杂度爆炸。

---

于是微软提出了 LSP

Language Server Protocol

中文：

语言服务器协议

它的核心思想非常重要：

编辑器不需要懂编程语言。

架构变成：

Editor（编辑器）
    ↓
LSP
    ↓
Language Server（语言服务器）

例如：

• Pyright
• gopls
• rust-analyzer
• jdtls
• clangd

---

LSP 的革命性意义

LSP 本质上是：

“代码语义能力标准协议”

编辑器只负责：

• UI
• 光标
• 文本编辑

真正理解代码的是：

Language Server（语言服务器）

它负责：

• AST（Abstract Syntax Tree，抽象语法树）
• Type System（类型系统）
• Symbol Index（符号索引）
• Definition（定义跳转）
• Reference（引用分析）
• Semantic Analysis（语义分析）

---

LSP 为什么对 AI Coding 极其重要？

因为 AI 最大的问题之一：

上下文窗口有限。

AI 不可能一次性阅读整个大型代码仓库。

于是必须依赖：

Semantic Navigation（语义导航）

而 LSP 正好提供：

• definition
• references
• symbols
• call graph
• type inference

这使 AI 开始真正“理解代码”。

---

三、代码检索的演进：从 grep 到 Semantic Graph

过去代码检索基本依赖：

grep

本质是：

字符串匹配

能力非常有限。

---

第一代：文本检索

例如：

• grep
• ripgrep

只能搜索：

字符串

不知道：

类
函数
类型
调用关系

---

第二代：AST 检索

后来出现：

• tree-sitter
• ctags

开始理解：

Function
Class
Import

但仍然缺乏完整语义。

---

第三代：LSP 语义检索

这时：

代码开始“可理解”

AI 能理解：

• 类型系统（Type System）
• 引用关系（Reference）
• 调用链（Call Chain）
• 继承关系（Inheritance）

这已经进入：

Semantic Code Intelligence（语义代码智能）

阶段。

---

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

再进一步：

Repo Graph（仓库图谱）

开始出现。

例如：

Controller
 → Service
   → Repository
     → Database

AI 不再只是理解代码片段。

而是开始理解：

整个工程系统。

这也是现代 AI IDE（智能 IDE）真正强大的原因。

例如：

• Cursor
• GitHub Copilot
• Windsurf
• Zed

底层都高度依赖：

LSP
+
Semantic Index（语义索引）
+
Code Graph

---

四、MCP：AI Agent 时代的“能力协议”

接下来，事情发生了根本变化。

以前：

人类决定调用什么 API。

现在：

AI 决定调用什么 Tool（工具）。

于是传统 RPC 开始不够用了。

因为 AI 不只是需要：

Function Call（函数调用）

它更需要：

• Tool Discovery（工具发现）
• Context Management（上下文管理）
• Resource Access（资源访问）
• Prompt Injection（提示注入）
• Multi-Step Planning（多步规划）
• Memory（记忆）
• Capability Reasoning（能力推理）

于是：

MCP（Model Context Protocol，模型上下文协议）

出现了。

---

MCP 本质是什么？

一句话：

MCP 是 AI 世界的“能力协议”。

它不再关注：

调用哪个函数

而关注：

“当前系统有哪些能力？”

这是非常巨大的架构变化。

---

RPC vs MCP

RPC：

Function-Oriented（面向函数）

MCP：

Capability-Oriented（面向能力）

---

RPC 世界

程序员明确写：

weather_service.get_weather()

---

MCP 世界

AI 收到：

“帮我分析今天适不适合无人机航拍”

然后：

1. 自动发现天气工具
2. 查询风速
3. 查询无人机规则
4. 分析能见度
5. 综合输出建议

这是：

Autonomous Tool Orchestration（自主工具编排）

---

五、MCP 到底借鉴了什么？

MCP 并不是凭空出现。

它融合了多个时代的软件思想。

---

1. 借鉴 LSP

MCP 和 LSP 极其相似。

LSP：

IDE ←→ Language Server

MCP：

LLM ←→ MCP Server

核心思想都一样：

Capability Decoupling（能力解耦）

---

2. 借鉴 RPC

MCP 的通信模型明显继承：

• Request / Response
• Method
• Params
• JSON Schema

这些典型 RPC 思想。

---

3. 借鉴 Unix Philosophy（Unix 哲学）

Unix 哲学：

Do One Thing Well
（一个工具只做好一件事）

MCP 工具也类似：

• Filesystem MCP
• GitHub MCP
• Search MCP
• Browser MCP

然后由 Agent 自动编排。

非常像：

AI Shell Pipeline（AI 管道系统）

---

4. 借鉴 Plugin Architecture（插件架构）

MCP 本质很像：

AI Plugin System（AI 插件系统）

类似：

• Chrome Extension
• VSCode Extension
• JetBrains Plugin

区别在于：

传统插件：

人类点击使用

MCP：

AI 自动选择使用

---

5. 借鉴 OpenAPI

MCP Tool Schema（工具描述）大量参考：

OpenAPI Specification

因为 AI 必须理解：

• 参数
• 返回值
• 调用方式
• 能力描述

这本质是：

Machine Readable Capability（机器可读能力）

---

六、MCP 为什么像“AI 操作系统”？

这是最关键的理解。

传统操作系统：

程序
 → syscall（系统调用）
   → OS Capability（操作系统能力）

例如：

open()
read()
write()

---

MCP 世界

AI：

search()
browse()
fetch()
code()

调用外部能力。

因此：

MCP 很像 AI Runtime（AI运行时）的系统调用层。

很多人因此认为：

MCP 正在成为 AI OS（AI 操作系统）的标准接口。

并不是夸张。

---

七、未来的软件架构正在变化

未来系统可能会变成：

AI Agent
    ↓ MCP
Agent Runtime
    ↓ gRPC
Microservices
    ↓ Database

也就是说：

• MCP 负责 AI 能力层
• RPC/gRPC 负责底层高性能通信
• LSP 负责代码语义
• Code Graph 负责仓库理解
• Agent Runtime 负责自主规划

---

八、真正的趋势：从“函数”到“能力”

过去的软件架构核心：

Function（函数）

未来的软件架构核心：

Capability（能力）

这是整个 AI Native（AI 原生）时代最大的变化。

因为 AI 并不真正关心：

函数名是什么

AI 真正关心的是：

“我现在拥有哪些能力来完成目标？”

这就是：

Capability-Oriented Architecture（面向能力架构）

而 MCP，正是这个时代的第一代标准协议。