AI 很能干，但一到正事就束手无策：数据库看不了，文件读不了，业务系统调不动。它缺的不是聪明，是连接。
一、MCP 到底解决什么问题
MCP 解决的其实是个很朴素的工程问题：连接的重复建设。
假设有 M 个 AI 应用（Claude、Cursor、自己写的 Agent），N 个外部系统（数据库、日历、搜索、业务 API）。没有统一协议，最坏情况就是 M × N 套对接代码------每个应用为每个系统单独适配一遍，系统升级了还得跟着改。
有了 MCP，这个数字变成 M + N：AI 应用只需要实现一次客户端，外部系统只需要实现一次服务端，中间用统一协议对话。
官方文档给的定义是：MCP（Model Context Protocol，模型上下文协议）是一个连接 AI 应用与外部系统的开源标准，让 AI 能访问数据、调用工具、执行工作流。官方的比喻是"AI 应用的 USB-C 接口"。
我的理解更朴素：**它是一根万用转接线，把不同的应用接到手边------文件、库、业务系统，AI 都能直接用。**官方比喻强调"接口形状统一"，这根线强调的是"外面的东西接进来就能用"，后者才是使用者的真实视角。
不过，接线只是第一步。线两头还得说同一种语言才能真正通话------MCP 靠什么对话，第三节展开。
二、三个角色：Host、Client、Server
MCP 的世界里只有三个角色，一张表先看清楚：
| 角色 | 定位 | 谁在扮演 |
|---|---|---|
| Host（宿主） | AI 应用本体，负责创建和管理 Client | Claude Desktop、Cursor、VS Code |
| Client（连接器） | Host 内部的组件，一个 Client 只伺候一个 Server | Host 程序的一部分，对使用者不可见 |
| Server（服务程序） | 为 AI 模型提供能力的服务器 | 每个数据源或工具对应一个 |
三个都展开说几句。
**Host 是摆在明面上的那个 AI 应用。**它在架构里是"总调度"：接入几个 MCP 服务，Host 就在内部创建几个 Client，一对一管起来。官方文档举的例子是 VS Code：当它连上 Sentry 的错误监控服务时，运行时会实例化一个 Client 专管这条连接；随后再连本地文件系统服务，就再实例化一个新的 Client。两条连接互不干扰。
**Client 是 Host 里的专职连接器。**它存在的意义就一条：伺候好自己那一个 Server，把 Server 的能力取回来交给 Host 用。使用者永远不需要直接操作它。
**Server 是为 AI 模型提供能力的服务器，也是整个 MCP 里最值得琢磨的角色。**它可本地中转，也可远程部署：跑在本机时，AI 通过本地进程访问它，由它再去调真正的数据源；部署在远程时，AI 通过 HTTP 访问它。
我的理解是，Server 更重要的角色是个汇聚桥接器------把已有的各种 API（数据库、日历、搜索、内部系统）桥接封装成 AI 能直接用的标准接口。能力不用重新造：已有系统包一层 MCP，手头的 AI 就多了一门手艺。Server 生态这两年长得飞快，原因也在这里：包一层就能接入，成本太低了。
三、两层结构：说什么，和怎么送达
还记得第一节的伏笔吗？线两头要说同一种语言。MCP 把这件事拆成了两层，各管各的：
-
数据层------管"说什么"。
MCP 的母语是 JSON-RPC 2.0，一种约定好格式的远程调用消息。Client 和 Server 之间飞来飞去的所有消息，都是这个格式。
-
传输层------管"怎么送达"。
同样的消息，可以走两种通道：
-
stdio（标准输入输出）
：本机进程直连。Server 就跑在本机，Host 拉起它的进程，通过标准输入输出跟它说话，没有网络开销。本地的 Server 通常只服务一个 Client。
-
Streamable HTTP
：走 HTTP 请求，支持 OAuth、API Key 等主流认证方式。远程 Server 用这条路，同时服务很多 Client。
一个类比：数据层是"普通话"，不管打电话还是写信，说的都是同一种话；传输层是"电话还是信件"，决定消息走什么通道。两层解耦，互不掺和。
四、三类原语：谁能做主，谁被护栏
Server 能给 AI 提供的能力，官方规范里定为三类，分类标准只有一条：谁能做主。
| 原语 | 谁做主 | 是什么 | 例子 |
|---|---|---|---|
| Tools（工具） | 模型做主 | AI 自己决定调用的动作，会改变外部状态 | 发邮件、查订单、写文件 |
| Resources（资源） | 应用做主 | 注入给 AI 的只读上下文，模型只能看不能动 | 文件内容、数据库记录 |
| Prompts（提示模板） | 用户做主 | 用户主动触发的预置流程 | 斜杠命令、菜单选项 |
这张表来自官方规范的"控制层级"（control hierarchy），是 MCP 从设计之初就长在骨子里的东西，不是后来的补丁。
我的理解是，它同时是 MCP 安全设计的核心："谁做主"决定护栏的强度------模型做主的动作有副作用，所以通常要过用户批准这道闸；应用做主的只读不写，不需要闸；用户做主的本来就是用户自己点的，天然放心。要是三类混在一起，"哪些操作该自己做主、哪些要等确认"就成了一笔糊涂账，AI 的行为会变糟。
五、一次调用的完整旅程
把前面的概念串起来，看一次真实的调用怎么走。以下报文摘自官方文档（2026-07-28 版规范）：
第一步，认识一下 。Client 向 Server 发出 server/discover 请求，问清对方是谁、支持什么版本、有什么能力：
{
"jsonrpc": "2.0",
"id": 1,
"method": "server/discover",
"params": {
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {
"name": "example-client",
"version": "1.0.0"
},
"io.modelcontextprotocol/clientCapabilities": {
"elicitation": {}
}
}
}
}第二步，看看菜单 。通过 tools/list 拉回 Server 提供的全部工具清单，每个工具的名字、用途、参数写得明明白白。
第三步，下单 。模型决定用某个工具后，Client 发出 tools/call：
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "weather_current",
"arguments": {
"location": "San Francisco",
"units": "imperial"
},
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {
"name": "example-client",
"version": "1.0.0"
},
"io.modelcontextprotocol/clientCapabilities": {
"elicitation": {}
}
}
}
}Server 查完天气，把结果按同样格式包好送回来，模型拿到结果继续干活。全程就是一来一回的 JSON 消息，没有魔法。
细看报文会发现：里面没有"先登录、建立会话"的影子，每个请求都自带身份和版本信息。这不是笔误，正是下一篇要讲的大改版。
结尾：明天能用的，和了解即可的
明天就能用的：在 Claude Desktop、Cursor 这类支持 MCP 的工具里添加现成的 Server------配置文件里填几行，AI 就多接一个数据源。数据库、浏览器、开发者工具都有现成的，不用写一行代码。
了解即可的：自己开发 Server，把自家 API 包成 MCP 服务。等真有这个需求，再回来看第二节也不迟。
MCP 拆开看就两样东西：一根万用转接线，一套对话规则。转接线负责把外面的能力接到手边，对话规则负责让两头说得清楚、分得清谁做主。
