几年前出门，包里常常要塞好几根充电线：手机一种接口，耳机又是另一种。后来接口逐渐统一，一根线就能给大多数设备充电，谁也不想再回到「一把线」的日子。
AI 接工具，也经历过类似的「一把线」时代。前面讲过，AI 可以通过工具调用去查数据、做操作。可现实是：想让一个 AI 应用读你的日历，要写一套对接代码；换一个 AI 应用，又得重写一遍；再想接网盘、接数据库，还得各写各的。MCP 就是为解决这个问题而出现的：它是 AI 连接外部工具和数据的一种「统一接口」。
没有统一接口时的麻烦
假设有 5 个 AI 应用、20 种常用工具。如果每个应用都要和每个工具单独对接，最多要做 5 × 20 = 100 套对接；而且每个工具一升级，相关的对接都可能要跟着改。
有了统一标准，情况就变了：每个 AI 应用只需支持一次标准，每个工具也只需按标准做一次，总共 5 + 20 = 25 份工作，而且彼此都能接上。这和充电接口统一是一个道理：标准本身不发电，但它让充电器和设备可以自由搭配。
没有统一标准：应用和工具两两对接，数量相乘
AI 应用 A ── 日历、网盘、数据库……（各写一套）
AI 应用 B ── 日历、网盘、数据库……（再写一套）
AI 应用 C ── 日历、网盘、数据库……（又写一套）
有了 MCP：双方各自只对接一次标准
AI 应用 A、B、C
↕ 都讲 MCP 这门「通用语」
日历服务器、网盘服务器、数据库服务器……MCP 是什么
MCP 是 Model Context Protocol 的缩写，中文可以叫「模型上下文协议」。它由 Anthropic 于 2024 年 11 月提出并开源，之后陆续得到多家厂商和开发工具的支持。
为什么叫「上下文」协议？因为它要解决的核心问题，就是怎么把模型干活需要的信息和能力（也就是「上下文」），从各种外部系统里规范地送到模型面前。
「协议」听起来很技术，其实就是一套双方约定好的沟通规矩：工具怎么介绍自己有哪些功能，AI 应用怎么发出请求，结果用什么格式返回。只要双方都守这套规矩，就能互相听懂，不用再一对一地商量。
它和前面讲的工具调用是什么关系？可以这样理解：工具调用是 AI「会用插头」的能力，MCP 是「统一的插座规格」。前者让模型能用工具，后者让各种工具能用同一种方式接进各种 AI 应用。两者是配合关系，不是替代关系。
三个角色：主机、客户端、服务器
MCP 的架构里有三个角色，用电脑和 U 盘来类比最直观：
| 角色 | 是什么 | 类比 |
|---|---|---|
| 主机（Host） | 你直接使用的 AI 应用，比如 AI 对话软件、AI 编程工具 | 电脑 |
| 客户端（Client） | 主机内部负责和某个服务器保持连接的模块，一个服务器对应一个 | 电脑上的 USB 口 |
| 服务器（Server） | 把某个工具或数据源按 MCP 标准包装好的程序，比如日历服务器、文件服务器 | U 盘、打印机等外设 |
服务器可以运行在你自己的电脑上，比如读取本地文件；也可以运行在远端，通过网络连接，比如对接某个在线服务。注意这里的「服务器」指的是一个提供能力的程序，不一定是机房里的一台机器。
服务器能提供什么
一个 MCP 服务器主要可以向 AI 提供三类东西：
- 工具（Tools）：AI 可以调用的动作，比如「创建日程」「查询数据表」「发送消息」。
- 资源（Resources）：AI 可以读取的数据，比如文件内容、数据库记录、文档。
- 提示模板（Prompts）：预先写好的任务模板，比如「生成周报」「审查合同条款」，用户可以直接选用。
连接建立时，AI 应用会先问服务器：「你都能做什么？」服务器回一份带说明的能力清单，AI 就知道自己多了哪些本事。这就像插上 U 盘，电脑自动识别出一个新磁盘。
一次完整的使用过程大致是这样的：
① 你在 AI 应用里说：「把明天下午两点和王经理的会议记到日历里。」
② AI 应用已连接「日历 MCP 服务器」，知道它提供 create_event 工具
③ 模型决定调用：create_event(title="与王经理开会", time="明天 14:00")
④ AI 应用弹出确认：「是否允许在日历中创建该日程？」你点「允许」
⑤ 日历服务器完成创建，返回「创建成功」
⑥ 模型回复你：「已添加到明天 14:00 的日程。」留意第 ④ 步：要不要弹出确认、哪些操作需要确认，通常由你使用的 AI 应用来把关。所以选择 AI 应用时，权限和确认机制设计得是否清楚，也是一个重要的考量。
对个人和企业意味着什么
- 对个人：像给手机装 App 一样，给 AI 应用接上需要的服务器，它就能读你的文件、查你的日程、操作你常用的软件。同一个服务器，在支持 MCP 的不同应用里都能用。
- 对企业：把内部系统（客户管理、工单、知识库等）包装成 MCP 服务器做一次，就能接入多个 AI 应用；权限和操作日志也能在服务器这一层统一管理。
- 对开发者：做一次适配，就能被多个 AI 应用使用，不必为每个平台各写一遍。
如果你在公司负责推动 AI 落地，可以先盘点一下：员工每天在哪几个系统之间来回复制粘贴？那些地方往往最值得接入。起步时优先选择官方或可信团队维护的服务器，从只读的查询类能力开始。
但也别把它神化：MCP 只是接口标准。它不会让模型变得更聪明，也不会自动保证安全。AI 用工具用得好不好，仍然取决于模型能力、工具说明和权限设计。
用 MCP 要守的安全规矩
MCP 让接入变得容易，也意味着风险更容易被「接进来」：
- 只装可信来源的服务器：运行在你电脑上的服务器，可能拥有读写文件、访问网络的权限。来路不明的，不要装。
- 权限按需开放：能只读就别给写，敏感系统用单独的、权限受限的账号。
- 保留人工确认：写入、删除、发送类操作，不要为了省事关掉确认弹窗。
- 警惕藏起来的指令：服务器返回的内容，甚至工具说明本身，都可能夹带恶意指令，应把它们当作数据而不是命令。
- 定期清理：不再使用的连接及时断开，别让它们一直挂着。
错误示范：为了省事，装了一个来路不明的「万能服务器」，
开放整台电脑的读写权限，还开启了「自动执行所有操作」。
正确示范：只连接当下需要的两三个服务器，从只读权限开始，
写入和发送类操作逐次确认，用不到的连接及时断开。本节要点
- 没有统一标准时，AI 应用和工具要两两对接，工作量成倍增长。
- MCP（模型上下文协议）由 Anthropic 于 2024 年 11 月提出并开源，之后得到多家厂商和工具的支持。
- 架构里有主机、客户端、服务器三个角色，服务器可以向 AI 提供工具、资源和提示模板。
- 工具调用是 AI 会用工具的能力，MCP 是把工具统一接进来的标准，两者相互配合。
- MCP 不自动保证安全：只装可信的服务器，按需授权，保留人工确认。
