AI 也需要 USB-C：一文看懂 MCP 到底是什么

2024 年 11 月，Anthropic 开源发布了 MCP。到今天，它已经逐渐成为 AI Agent 生态里一个绕不开的关键词。

但对大多数人来说，Model Context Protocol（模型上下文协议） 这个名字依然有些抽象。

其实，理解 MCP 并不难。

🔌 一句话：MCP 就是一套让 AI 连接外部数据和工具的标准协议。

如果觉得“标准协议”还是太抽象，可以再换一个更直观的理解——AI 世界里的 USB-C。

---

01｜为什么 AI 需要 MCP？

今天的大模型已经很聪明：会写代码、做分析、读文档、做推理。但如果你对 AI 说：

“帮我看看昨天 GitHub 上改了什么，再结合服务器日志分析一下为什么线上报错增加了。”

问题马上就来了。AI 可能很会分析，但它默认看不到你的 GitHub，也看不到服务器日志。它拥有一个聪明的“大脑”，却不一定拥有获取真实数据和调用外部工具的能力。

过去解决这个问题，只能一个个做集成：接 GitHub 写一套，接数据库写一套，接企业系统再写一套。

AI 应用和工具一多，中间就会出现大量重复的适配工作：

🧮 5 个 AI 应用 × 10 个工具 = 最坏情况要写 50 次集成

MCP 想做的，就是把这种连接方式标准化。

以前，是每个工具各接各的：

❌ 没有 MCP：每接一个，写一套

AI ↔ GitHub
AI ↔ 数据库
AI ↔ 文件系统
AI ↔ 企业系统

MCP 希望把它统一成：

✅ 有了 MCP：只接一次，处处可用

AI ↔ MCP ↔ 各种数据和工具

这和 USB-C 的思路很像：设备本身没有变，但连接方式统一了。

---

02｜MCP 到底是什么？

MCP 的全称是 Model Context Protocol。它不是大模型，不是 Agent，也不是某一种具体工具。它更像是一套大家约定好的“沟通规则”：外部工具按照这套规则提供能力，AI 应用也按照这套规则去发现和使用这些能力。

所以，MCP 并不会让 GPT、Claude 之类的大模型突然变聪明。它解决的是另一个问题：

一个已经足够聪明的 AI，怎样方便地拿到需要的信息，并调用需要的工具？

如果把大模型比作“大脑”，那么 MCP 做的，就是帮这个大脑接上外部的眼睛和手。

👀 眼睛：读取文件、数据库、代码、业务信息

🖐️ 手：搜索、调用工具、操作软件、执行任务

最后澄清一个常见误解：

⚠️ MCP 并不是为了取代 API。

很多 MCP Server 背后调用的依然是传统 API、数据库或其他服务。MCP 真正统一的，是 AI 使用这些能力的方式。

---

03｜MCP 是怎么工作的？

理解 MCP，先搞清楚三个角色：

Host、Client、Server。

它们的基本关系是：

用户 → Host → MCP Client → MCP Server → 外部数据 / 工具

角色	负责什么	可以怎么理解
Host	承载 AI 应用，协调模型和各种工具	总指挥
Client	负责和 MCP Server 通信	联络员
Server	提供具体的数据或工具能力	服务提供方

🏠 Host：AI 的工作台

Host 是用户真正使用的 AI 应用，比如 AI 助手、AI 编程工具或 Agent。

像 Claude Code、Codex 这类产品，在通过 MCP 连接外部工具时，扮演的就是 Host 的角色。

Host 负责接收任务、调用模型、管理工具，并决定某个工具应该怎么被执行。

📞 Client：负责通信

Client 位于 Host 一侧，负责和 MCP Server 建立连接、发送请求、拿回结果。

可以简单记成一句：

Host 决定找谁办事，Client 负责去联系。

🛠 Server：真正提供能力

Server 是站在外部、提供具体能力的一方。

比如 GitHub 的 MCP Server 提供代码仓库相关能力，数据库的 MCP Server 提供数据查询，文件系统的 MCP Server 让 AI 能读取指定文件。

⚙️ 一次工具调用是怎么发生的？

搞清楚三个角色之后，还要再往前走一步：这些工具到底是怎么被模型调用的？

一个典型的流程大致是这样的。

1️⃣ 第一步：Host 先知道 Server 会什么

Host 连接一个 MCP Server 后，会先了解这个 Server 提供了哪些工具。

比如一个 GitHub MCP Server 可能提供：

• search_code（搜索代码）
• get_issue（查看某个 Issue）
• list_pull_requests（列出所有 PR）

这些工具的名称、用途和参数，会被注册到 Host 的“工具箱”里。

也就是说，不是模型自己跑到 Server 上寻找工具，而是 Host 先把“你现在可以用哪些工具”告诉模型。

2️⃣ 第二步：模型选择要用哪个工具

当用户提出任务后，大模型会根据问题和工具描述，判断自己是否需要调用工具。

比如用户说：

“帮我看看 123 号 Issue 具体是什么问题。”

模型可能判断需要调用：

get_issue(issue_number=123)

这里，大模型负责的是选择工具、给出参数，但并不负责真正执行。

3️⃣ 第三步：Host 负责路由

接下来轮到 Host。

Host 会判断这个工具来自哪里。如果是自己内置的工具，就直接调用；如果它来自某个 MCP Server，就交给对应的 MCP Client。

所以可以把这条链路理解成：

例如你问：

“帮我看看昨天上线的代码，为什么会导致线上报错。”

Host 把可用工具提供给模型，模型判断需要查看代码和日志。如果这些能力来自 MCP Server，Host 就通过对应的 Client 发起调用；Server 返回代码提交和错误日志，再交给模型继续分析。

模型本身没有变，但它获取信息和调用工具的方式变了。

这就是 MCP 最核心的工作逻辑：

Server 提供能力，Host 注册工具，模型选择工具，Client 负责调用。

---

04｜为什么 MCP 值得关注？

真正让 MCP 变得重要的，并不只是“统一接口”这件事，而是 AI 正在发生一个更大的变化：

从 Chatbot，走向 Agent。

Chatbot 和 Agent 的差别，用一张表看最清楚：

	Chatbot	Agent
🗣️ 交互方式	你问，它答	你给一个目标，它自己找信息、调用工具，把事情做完
🔌 需要外部连接吗	基本不需要	必须连得上文件、数据库、系统

但 AI 真想“干活”，光有一个聪明的大模型显然不够。所以，一个真正能工作的 AI，更像是：

🧩 大模型 + 数据 + 工具 + 工作流

而 MCP 解决的，恰恰就是其中最关键的连接问题。

🕐 过去我们最关注：这个 AI 聪不聪明？

🚀 接下来越来越重要：这个 AI 能不能真正把事情做完？

从这个角度看，MCP 的意义也就很清楚了。

---

写在最后

USB-C 并没有让电脑性能翻倍，但它让不同设备之间的连接简单了很多。

MCP 也是类似的角色。

🔌 它不负责让 AI 变聪明，而是让一个已经足够聪明的 AI，更方便地连接外部世界。

当 AI 既有一个强大的大脑，又能真正获取数据、调用工具、执行任务时，它才会从会聊天的 AI，变成能干活的 AI。

而这，或许才是 MCP 最值得关注的地方。

---

💬 如果这篇文章帮你搞懂了 MCP，欢迎点赞、在看、转发给同样需要的朋友。

关注我，持续拆解 AI 领域的原理、工具与工程实践 👋