你以为 MCP 是 AI 插件,其实它是连接现实世界的“通用接口”

很多人第一次看到 MCP，是在 AI 产品的设置页里。

旁边常常还站着几个更熟悉的词：插件、连接器、API、Skill。它们挤在一起，很容易让人产生一种朦胧印象：

“哦，MCP 大概就是给 AI 装插件吧。”

这个理解不能说完全错，但只说到了表面。

MCP 真正重要的地方，不是多了某一个插件，而是它试图解决一个更底层的问题：

当 AI 想读取外部资料、调用工具、完成现实任务时，大家能不能用同一种方式沟通？

大模型能解释概念、写文章、分析代码，是因为它擅长处理进入上下文的信息。

但“知道很多”不等于“看得见你此刻的数据”，更不等于“有权替你做事”。

如果你让一个没有任何外部连接的 AI：

它可能知道这些工具是什么，却拿不到里面的数据，也无法真正操作它们。

这就像你请来一位能力很强的助理，却把他留在一间没有门、没有电话、没有门禁卡的房间里。助理并没有变笨，只是够不到现实世界。

过去，每接一个系统，开发者都要单独做一套连接：日历一套、数据库一套、设计工具又一套。不同 AI 应用还可能各做一遍。接得越多，适配、维护和权限管理就越复杂。

MCP 正是从这里切入。

 概念场景：聪明的 AI 因缺少连接而够不到日历、知识库、设计画板和项目任务

MCP 的全称是 Model Context Protocol，中文常译为“模型上下文协议”。

官方定义很克制：它是一套连接 AI 应用与外部系统的开放标准。外部系统可以是本地文件、数据库、搜索引擎、计算器，也可以是一整套业务工作流。

你可以先把“协议”理解成一套共同遵守的沟通规则。

就像 USB-C 规定了设备如何连接、传输和供电，MCP 规定了 AI 应用如何发现外部能力、传递参数、获得结果。

但这个类比有一个边界：MCP 不是一根线，更不是某个具体工具。它是“插头和插座应该怎样配合”的规则。

遵守这套规则后，一个支持 MCP 的 AI 应用，就更容易连接不同的 MCP Server；开发者也不必为每一种 AI 客户端重新发明一套接法。

MCP 的架构里，经常会出现三个词：Host、Client、Server。

先别被英文吓到，用一次“让 AI 查看日历”的请求就能看懂。

Host，是你正在使用的 AI 应用。

比如 Codex、ChatGPT，或者某个企业内部助手。它负责理解你的目标、组织上下文，也负责权限和安全决策。

Client，是 Host 里面负责连接的那一层。

它像一位联络员，与某个 MCP Server 建立会话，确认双方支持什么能力，再来回传递消息。通常一个 Client 对应一个 Server。

Server，是把外部能力暴露出来的一方。

日历服务可以提供“查询日程”的能力，知识库可以提供“读取文档”的能力，项目管理系统可以提供“创建任务”的能力。Server 可以在本地运行，也可以是远程服务。

于是，一次请求大致会这样流动：

你提出目标 → Host 判断需要外部能力 → Client 联系对应 Server → Server 返回数据或执行结果 → Host 结合上下文给你答案。

真正负责“想”的主要还是 AI；MCP 负责让它用一种标准方式去“够到”外部世界。

— 架构图：Host 内含 Client，Client 与 MCP Server 双向连接

从普通用户角度看，MCP Server 最值得记住的是三类能力：

1. Resources：给 AI 看的资料

Resources 可以理解为可读取的上下文，例如一份文件、一条数据库记录、一段知识库内容。

它解决的是“AI 需要看到什么”。

2. Tools：让 AI 使用的动作

Tools 是可调用的操作，例如搜索、计算、查询订单、创建任务、发送请求。

它解决的是“AI 可以做什么”。

3. Prompts：可复用的任务模板

Prompts 是服务端提供的提示模板或工作流入口，帮助用户或 AI 用更稳定的方式发起某类任务。

它解决的是“这件事通常应该怎么开始”。

可以把三者记成一句话：

Resources 提供材料，Tools 提供动作，Prompts 提供起手式。

三分类图：Resources 提供资料、Tools 提供动作、Prompts 提供起手式

不是每个 MCP Server 都必须同时提供三种能力。一个只读知识库可能主要提供 Resources；一个自动化服务可能主要提供 Tools。

这三个词经常一起出现，但它们不是同一层的东西。

API 像某一家餐厅自己的后厨窗口。

它规定这家服务能做什么、请求怎么发、结果怎么回。日历、数据库、支付平台，原本就可能各自拥有 API。

MCP 像商场统一的点单规则。

它让 AI 客户端用相对一致的方式发现和调用不同服务。MCP Server 的背后，往往仍然会调用原有 API。换句话说，MCP 通常不是消灭 API，而是在 AI 与许多 API 之间增加一层标准化接口。

Skill 像一份工作手册。

它告诉 AI：面对某类任务，先做什么、后做什么、使用哪些资料、怎样检查结果。

所以，三者可以这样分工：

 协作关系图：API 提供服务、MCP 负责标准连接、Skill 提供工作手册

例如，“每周一整理项目周报”这个 Skill，可以要求 AI 先通过 MCP 读取项目任务，再读取会议记录，最后按模板生成周报。MCP 提供手和眼，Skill 提供做事章法。

流程图：读取项目任务、读取会议记录、整理模板、生成周报

看到这里，有人会担心：既然 AI 能连接邮箱、日历和数据库，它是不是可以随便读取，甚至随便操作？

答案是：连接能力不等于拥有全部权限。

Host 仍然要管理连接、授权、用户同意和安全策略；Server 也只能暴露自己声明的能力。实际产品还可以限制允许使用的工具，并对敏感动作要求人工审批。

更重要的是，MCP Server 本身可能由第三方提供。它可能接触你发送的数据，也可能执行真实动作。因此，选择服务器时至少要问四个问题：

安全检查清单：谁维护、看什么、能做什么、是否审批

OpenAI 的官方文档也特别提醒了提示注入、第三方数据处理和工具行为变化等风险。对陌生 Server，谨慎授权；对删除、发送、付款等敏感动作，保留审批，是更稳妥的习惯。

所以，“接上 MCP”不该被理解成把万能钥匙交给 AI，而应该理解成：给 AI 开了一扇有门禁、有权限范围、最好还有操作记录的门。

如果你只是偶尔让 AI 改一段文字、解释一个概念，你完全不必先研究 MCP。

当你的需求开始出现下面这些特征时，它才会变得重要：

换句话说，MCP 的价值不在一次漂亮的回答，而在于让 AI 从“只会聊天”，逐步走向“能够在边界内办事”。

如果只记住一句话，我建议记住：

MCP 是 AI 连接外部数据、工具和工作流的一套通用沟通标准。

它不负责让模型变聪明，也不替代 API，更不自动赋予权限。它做的是一件朴素但关键的事：让 AI 应用和外部系统不必每次从零学习如何握手。

上篇文章里，我们把 Skill 比作 AI 的“工作手册”。到了这里，两块拼图刚好可以合上：

Skill 决定怎么做事，MCP 决定能连接什么、能调用什么。

当 AI 既有做事章法，又能在清晰权限下连接现实世界，它才真正开始从聊天工具变成工作伙伴。

如果你觉得今天这篇有收获，欢迎点赞、在看、转发，我们下篇见。

谢谢你读到这里。

点赞 · 在看 · 转发

THANKS FOR READING