如果你听说过 MCP，但始终没搞懂它和 Function Calling 的区别，这篇文章就是为你写的。
先说结论
很多人一开始会有这样的误解：
- MCP Server 就是墨迹天气、高德地图这些第三方 API？——错
- MCP 出来了，Function Calling 是不是要被淘汰了？——也错
正确的理解是：MCP 是一套标准化协议，它没有取代任何东西，而是让 AI 应用接入外部工具变得更简单、更统一。
一个生活类比
你家里有很多电器：台灯、风扇、手机充电器……
以前每个电器的插头形状都不一样，每买一个新电器就要专门配一个插座，麻烦死了。
后来大家统一了一个标准——USB 接口，所有设备都支持，插上就能用。
MCP 就是 AI 世界的"USB 接口标准"。
- 电器 = 各种外部工具（天气、地图、数据库）
- 插座 = AI 应用（千问、Claude、Cursor）
- USB 标准 = MCP 协议
MCP 和 Function Calling 是什么关系？
很多人以为 MCP 是 Function Calling 的替代品，其实不是。
Function Calling 是 AI 的"手"，MCP 是"手套的标准尺码"。
手还是那双手，但戴上标准尺码的手套之后，什么东西都能抓——不用每次都量手型重新做手套。
用调用链路来说就是：
没有 MCP 时：
LLM --> 自己写代码对接 --> 天气 API
LLM --> 自己写代码对接 --> 地图 API
LLM --> 自己写代码对接 --> 数据库
（每个工具都要单独开发，改一个牵一发动全身）
有了 MCP 之后：
LLM --> MCP Client --> MCP Server --> 天气 API
LLM --> MCP Client --> MCP Server --> 地图 API
LLM --> MCP Client --> MCP Server --> 数据库
（中间协议统一了，换工具就像换插头一样简单）
四层架构，一次说清楚
MCP 体系里有四个角色，每个各司其职。
flowchart TD
A[用户提问] --> B[MCP Host\n运行 LLM 的应用]
B --> C[MCP Client\n协议连接器]
C --> D[MCP Server\n工具适配器]
D --> E[第三方 API\n真正的数据源]
style A fill:#f0f4ff,stroke:#7c9ef5
style B fill:#dbeafe,stroke:#3b82f6
style C fill:#dcfce7,stroke:#22c55e
style D fill:#fef9c3,stroke:#eab308
style E fill:#fce7f3,stroke:#ec4899
逐层解释：
第一层 MCP Host（应用层） 就是你用的 AI 软件，比如千问 App、Claude Desktop、Cursor 编辑器。它负责跑 LLM，接收你的问题，决定调用什么工具。
第二层 MCP Client（协议层） 相当于一个翻译官。Host 说"我要查天气"，Client 负责把这个请求翻译成符合 MCP 协议的格式，发给对应的 Server。
第三层 MCP Server（适配层） 这是容易搞混的地方——它不是天气 API 本身，而是封装了天气 API 的一个适配程序。它懂 MCP 协议，也懂怎么调天气 API，负责中间的翻译工作。
第四层 第三方 API（数据源） 这才是真正提供数据的地方，比如墨迹天气、高德地图、你公司的业务数据库。
用一次查天气来走一遍流程
你问："上海今天天气怎么样？"
sequenceDiagram
participant 用户
participant Host as MCP Host（千问）
participant Client as MCP Client
participant Server as MCP Server（天气）
participant API as 墨迹天气 API
用户->>Host: 上海今天天气怎么样？
Host->>Client: 调用"查天气"工具，城市=上海
Client->>Server: 发送 MCP 协议请求
Server->>API: HTTP 请求墨迹天气
API-->>Server: 返回 {temp: 13, 天气: 小雨}
Server-->>Client: 格式化为 MCP 响应
Client-->>Host: 返回结果
Host-->>用户: 上海今天13度，小雨，记得带伞
你会发现：Host 完全不知道也不关心数据是从哪里来的，它只管发请求、拿结果。这就是分层的意义。
用微服务来类比，程序员秒懂
如果你做过后端开发，一定用过 OpenFeign 或者 gRPC 这类 RPC 框架，MCP 的思路和它一模一样。
flowchart LR
subgraph MCP 世界
direction TB
A1[MCP Host] --> B1[MCP Client] --> C1[MCP Server] --> D1[墨迹天气]
end
subgraph 微服务世界
direction TB
A2[商品服务] --> B2[OpenFeign] --> C2[库存服务] --> D2[菜鸟物流]
end
style A1 fill:#dbeafe,stroke:#3b82f6
style B1 fill:#dcfce7,stroke:#22c55e
style C1 fill:#fef9c3,stroke:#eab308
style D1 fill:#fce7f3,stroke:#ec4899
style A2 fill:#dbeafe,stroke:#3b82f6
style B2 fill:#dcfce7,stroke:#22c55e
style C2 fill:#fef9c3,stroke:#eab308
style D2 fill:#fce7f3,stroke:#ec4899
对照关系一目了然：
| MCP 世界 | 微服务世界 | 干什么的 |
|---|---|---|
| MCP Host | 商品服务 | 核心业务，发起调用 |
| MCP Client | OpenFeign | 协议层，统一通信方式 |
| MCP Server | 库存服务 | 封装逻辑，对外暴露接口 |
| 墨迹天气 | 菜鸟物流 | 真正的数据提供方 |
唯一的区别是：MCP Client 是一个独立运行的本地进程，而 OpenFeign 是一个 SDK，嵌在代码里。原因也很简单——AI 应用经常要访问本地文件、本地数据库，必须有个独立进程来干这件事。
为什么会有 MCP？它解决了什么问题？
这个问题可以和微服务的演进类比着看：
flowchart LR
A[单体应用\n数据写死] -->|扩展需求增加| B[点对点集成\n耦合严重] -->|维护成本爆炸| C[OpenFeign + 微服务\n标准化解耦]
D[只有 LLM\n靠训练数据] -->|需要实时数据| E[硬编码对接工具\n每个都要单独写] -->|工具越来越多| F[MCP 标准协议\n即插即用]
style A fill:#fce7f3,stroke:#ec4899
style B fill:#fef9c3,stroke:#eab308
style C fill:#dcfce7,stroke:#22c55e
style D fill:#fce7f3,stroke:#ec4899
style E fill:#fef9c3,stroke:#eab308
style F fill:#dcfce7,stroke:#22c55e
两条演进路径几乎一模一样：
- 一开始能跑就行，简单粗暴
- 业务变复杂，开始各自点对点对接，耦合严重
- 实在维护不下去，搞一套标准协议，统一规范
MCP 出现的原因和微服务出现的原因，本质上是同一件事——系统大了，就需要解耦。
总结
- Function Calling 是 LLM 调用工具的底层能力，没被取代
- MCP 是在它上面加了一层标准协议，让工具对接变得统一
- MCP Server 是适配器，不是数据源本身
- 整个体系分四层：Host（应用）> Client（协议）> Server（适配）> API（数据）
- 理解不了？想想 USB 接口，或者想想 OpenFeign + 微服务，是一回事
