《AI不是魔法》

写给软件工程师的AI工程课

第六堂：MCP到底是什么？

这一篇适合谁：

如果你听说过MCP、想知道它为什么突然这么火、以及它和Function Calling到底有什么区别——那么这一篇值得看完。

上一堂课，我们知道：

LLM负责决策，Tool负责执行。

这一堂课，我们继续回答：

当工具越来越多，AI世界为什么需要一套统一接口？

一个团队做了个AI运维助手。第一版只接了一个天气API，很顺。

第二版要接入：订单系统、CRM、邮件系统、数据库、工单系统、Jenkins、GitLab、Jira。

问题来了：

• 用OpenAI，工具定义写一遍

• 换Claude，工具定义再写一遍

• 换Gemini，又要写一遍

• 换国产模型，还要写一遍

一开始只有两个模型、三个工具，大家觉得重写一下也没关系。

可随着模型越来越多、工具越来越多，重复适配开始占据开发的大部分时间。

真正需要维护的，不再是AI，而是一堆连接AI和工具的胶水代码。

最后团队发现：

他们不是在开发AI应用。

他们是在给每个模型手搓一堆转接头。

这时MCP的价值就出来了：

能不能有一种统一接口，让工具只接一次，所有模型都能用？

这就是MCP。

一、Function Calling解决了什么，又留下了什么问题？

第五篇我们说过：Function Calling让AI能调用工具了。

但它留下一个新问题：工具调用没有统一标准。

你可以想象一下没有USB之前的充电线时代：

• Micro USB、Lightning、Type-C、圆口……各管各的

• 借充电器第一句永远是：“你这个口能充我的手机吗？”

今天的AI工具生态，就是这个状态：

模型A ↔ 工具1（OpenAI格式）
模型A ↔ 工具2（OpenAI格式）
模型B ↔ 工具1（Anthropic格式）
模型B ↔ 工具2（Anthropic格式）
模型C ↔ 工具1（Google格式）
模型C ↔ 工具2（Google格式）

如果有10个模型、100个工具，就要写1000次适配。

Function Calling解决的是“AI能不能调用工具”。MCP要解决的是“所有AI和所有工具怎么统一连接”。

二、MCP的核心思想：AI世界的USB-C

MCP其实很简单。

它就是AI世界的一套统一插座标准。

官方名称叫Model Context Protocol（模型上下文协议），是由 Anthropic 提出的一个开放协议/标准，目的是让AI应用和外部系统之间有一套统一的连接方式。

用一句话类比：

Function Calling是插头。MCP是插座标准。

更准确一点：

• Function Calling：一次具体调用（“我要查订单”→调get_order）

• MCP：插座标准（所有工具按这套标准做插头，所有模型按这套标准做插座）

配合一张图：

没有MCP时：
模型A ── 适配器1 ── 工具1
模型A ── 适配器2 ── 工具2
模型B ── 适配器3 ── 工具1
模型B ── 适配器4 ── 工具2

有MCP时：
模型A ─┐
模型B ─┤
模型C ─┘
       ↓
    MCP Client
       ↓
    MCP Server
       ↓
    文件 / 数据库 / API / 工具（GitLab、Jira、Jenkins、本地FS……）

MCP没有改变LLM。它甚至没有增加任何新的Context。

它只是让外部世界，更容易变成LLM当前能够看到的Context。

三、MCP和Function Calling到底什么区别？

这是整篇最容易被混淆的地方，必须讲清楚。

Function Calling 和 MCP 的区别：

• 层级不同：

  Function Calling 是单次调用能力；

  MCP 是连接标准。

• 解决的问题不同：

  Function Calling 解决“能不能调用”；

  MCP 解决“怎么统一调用”。

• 归属不同：

  Function Calling 由各家模型自己定义；

  MCP 是开放协议。

• 范围不同：

  Function Calling 一次调用一个工具；

  MCP 是工具生态的整体接入。

• 类比不同：

  Function Calling 像插头；

  MCP 像插座标准。

一句话区分：

Function Calling解决“AI怎么调用一个工具”。MCP解决“所有AI和所有工具怎么统一连接”。

没有MCP，AI也能调用工具（靠Function Calling）。但有了MCP，调用工具的成本大幅降低，生态才能爆发。

四、一个真实的工程案例

一个公司有多个AI应用：客服机器人、代码助手、数据分析师、运维Agent。

每个应用都要调用相同的内部工具：GitLab、Jenkins、Jira、Confluence、订单数据库。

没有MCP时：

• 客服机器人用OpenAI → 工具适配写一遍

• 代码助手用Claude → 工具适配再写一遍

• 数据分析师用Gemini → 工具适配又写一遍

• 运维Agent用国产模型 → 工具适配还写一遍

四个应用，每加一个工具就要写四次适配。维护成本翻四倍。

有MCP后：

• 所有工具各自实现一次MCP Server

• 所有模型/AI应用通过MCP Client调用同一套工具

• 新增工具时，只需实现MCP，所有应用自动可用

• 新增模型时，只需支持MCP，所有工具自动可用

以前：开发工具 → 适配OpenAI、适配Claude、适配Gemini……

后来：开发工具 → 实现MCP → 所有模型直接使用

工具真正复用的，从来不是代码。而是接口标准。

一个一分钟思维实验

想象一下：今天Cursor、Claude Desktop、OpenAI、国产模型都支持MCP。

你开发了一个GitLab工具，实现了MCP Server。

那么：

• 这个工具需要为每个模型重写适配吗？——不需要。

• 换了一个新模型，这个工具还能用吗？——能，只要新模型支持MCP。

• 如果以后有100个模型，这个工具需要改吗？——不需要，一次实现，永久可用。

这个思维实验让你理解MCP的核心价值：模型不需要关心工具怎么实现的，工具也不需要关心模型是哪家的。双方只需要遵守同一套协议。

工程师容易踩的坑

🚫 错误做法：
看到MCP Server就随便装，直接给它本地文件、数据库、终端权限。

为什么错：
MCP Server本质上是外部工具入口。一旦权限过大，AI或恶意工具就可能读到敏感文件、执行危险操作。

✅ 正确做法：
最小权限、白名单、隔离环境、只读优先、生产操作必须人工确认。

今天记住这一句话

MCP不是工具，它是AI连接工具的统一插座。

如果今天只带走一个观点，那就是：MCP没有改变LLM，它只是让外部世界更容易变成LLM当前能够看到的Context。

系列阶段总图（到这里，世界观完整了）

走到第六篇，我们可以把前六篇全部串起来，画出整本书最完整的一张图：

用户
    ↓
Prompt ──────────┐
                  │
RAG ── Knowledge ─┼─→ Context ──→ LLM ──→ Prediction ──→ Answer
                  │                    ↑
Function Calling ─┤                    │
                  │                    │
MCP ──────────────┴─→ Tool ──→ Tool Result ──┘
（MCP负责连接Tool，让Tool Result更容易流进Context）

你会发现：

• 第一篇：Prediction（AI在预测Token）

• 第二篇：Prompt → Context

• 第三篇：Transformer让Prediction更高效

• 第四篇：RAG → Knowledge → Context

• 第五篇：Function Calling → Tool Result → Context

• 第六篇：MCP让Tool Result更容易流进Context

Prompt、RAG、Function Calling、MCP，它们从来不是四种能力。

它们只是让Context不断流动的四种方式。

真正重要的，从来不是LLM本身有多强，而是它能够连接多少真实世界。

下一篇预告：

当AI能够：

• 查资料（RAG）

• 调工具（Function Calling）

• 通过标准接口连接任何工具（MCP）

• 再根据结果继续思考，然后再次决定下一步……

它开始形成一个循环。

这，就是Agent。

下一篇，我们聊 AI Agent：为什么 AI 开始不只是回答问题，而是自己规划、执行和反馈？