什么是 MCP（模型上下文协议）？它到底在解决什么麻烦

假设你公司用了十个 SaaS，每个都要和 AI 接一遍。A 平台接了飞书，B 平台又得重写一遍飞书对接；换个大模型，前面写的全废。这就是 MCP（Model Context Protocol，模型上下文协议）出现前的日常：每家各搞一套，重复劳动爆炸。

这篇先讲清楚”它之前乱成什么样”，再说”MCP 怎么治这个毛病”，最后把架构、工作流程、三种能力原语，以及它和 Function Calling 到底差在哪，一并讲透。配了几张图，方便你顺着看。

一、它之前乱成什么样：N×M 的集成地狱

早先每个 AI 平台要接一个外部系统，就得单独写一套对接代码。工具少的时候还好，工具一多，情况就失控：同一个日历，十个平台写十遍；模型一换，又得重接。做集成的人大半时间花在”重复接线”，而不是做有价值的事。我见过一个小团队，光是把内部五个系统接进两个不同的 AI 工具，就耗了两周，还没算后面维护。

这在工程上叫 N×M 问题：N 个模型要对接 M 个工具/数据源，理论上要写 N×M 次对接。模型和数据源每多一个，工作量就乘着涨，而不是加上涨。

✅ MCP：M+N 次适配 AI 模型 × N 个 MCP 标准一处写处处用工具 / 数据源 × M 个 5+2 = 7 次适配，换模型直接复用

图 1：传统点对点集成是「N 个模型 × M 个工具」的乘法关系；MCP 把它变成「M+N」——工具接一次标准，所有模型共享。

二、MCP 怎么治这个毛病：给插头定国标

它把”AI 连工具”这件事标准化成一套统一协议。工具方按协议做一次适配，所有支持 MCP 的 AI 就能直接拿来用，不用再为每家平台单独写。以前每个电器都得配专属插座，MCP 相当于给插头定了国标，插座不用再为每台电器改接口。

关键点：MCP 管的是”怎么连、怎么传”，不负责”连上之后能干嘛”。干活的还是 Skill 和 Agent，MCP 只是让它们少写一堆重复代码。同样五个系统，按 MCP 适配一次，换个 AI 工具也能直接用，那两周的活能压到一两天。

三、MCP 到底是什么：Host / Client / Server 三层

MCP 由 Anthropic 在 2024 年 11 月正式开源。它的设计灵感常被比作 USB-C：就像 USB-C 用统一接口接各种设备，MCP 给 AI 应用一个”即插即用”的上下文框架。技术上，它把模型与外部系统的通信抽象成客户端—服务器架构，用基于 JSON-RPC 的标准消息来传上下文、调工具。

整个体系围绕三个角色转：

Host（宿主）：承载 AI 交互环境的应用，比如 Claude Desktop、Cursor、VS Code。它负责把用户、模型和外部能力撮合到一起，并在内部运行 MCP Client。
Client（客户端）：跑在 Host 里面的组件，专职和某个 MCP Server 建立连接、收发请求，是 Host 与外部资源之间的桥。
Server（服务器）：轻量程序，把具体能力和数据按标准暴露出来，让模型能调用。一个 Host 可以连多个 Server。

图 2：MCP 三层架构。Host 内跑 Client，Client 通过标准协议连 Server；Server 把 Tools / Resources / Prompts 三种能力开放给模型，再由这些能力去碰外部数据。

四、它怎么工作：客户端 → 协议 → 服务器

MCP 的运行可以拆成三层来看，理解这三层，自己写个 MCP 客户端/服务器就不虚了。

1）客户端：发起请求的起点

Client 或 Host 是整个交互的起点，负责把”用户/模型想要什么”变成标准请求发出去。任何想把 AI 接到数据库、API、文件系统的程序，都能当客户端。

2）通信层：标准协议这个纽带

这一层用 JSON-RPC 规定请求和响应的统一结构，好比互联网里的 HTTP——不管你用 Claude 还是 LLaMA，不管对面是飞书还是内部库，双方都说”同一种语言”。它顺带管了认证、错误处理和数据格式，保证通信稳。

3）服务器端：能力与数据的供给方

Server 接收客户端请求，执行具体操作（查库、调工具、读文件），再把结果按标准格式回给模型。它很轻、可定制，从简单取数到复杂工作流都能扛。

图 3：一次典型调用。实线是请求方向，虚线是结果原路返回。Client 与 Server 之间走的都是统一的 JSON-RPC 消息。

五、Server 能开放哪三种能力：Tools / Resources / Prompts

MCP 把”能给模型什么”归成三类原语。记住这三者，基本就能判断一个 MCP Server 在干嘛。

🛠

Tools（工具）

让模型”动手”——执行具体操作，比如查数据库、跑代码、发消息、调 API。是模型语言能力的落地出口。

📦

Resources（资源）

把数据”喂”给模型——数据库内容、云盘文件、实时 API 数据。增强上下文感知，让输出基于最新信息。

💡

Prompts（提示）

可复用的提示模板与工作流，帮开发者固化标准交互，适合客服、内容生成这类要批量迭代的场景。

六、MCP 和 Function Calling、传统 API 差在哪

最容易混的是 MCP 和 Function Calling。一句话区分：Function Calling 是”模型会不会叫函数”的能力，MCP 是”函数怎么被标准地接进来、被各家模型共用”的协议。一个是模型侧的能力，一个是集成侧的规范。一个 Server 写的工具，能被所有支持 MCP 的模型通过 Function Calling 来用——它俩是互补，不是替代。

维度	MCP（协议）	Function Calling（能力）	传统点对点 API
解决什么	统一的”连接标准”	模型发起工具调用的机制	具体系统间的接口
复用性	高：一处适配，多模型共享	中：常绑定某家模型	低：每对组合重写
集成成本	M+N	依赖各模型实现	N×M
典型形态	Host + Client + Server	模型返回 function_call	手写对接代码
关系	MCP 用标准协议把工具暴露出来，模型通过 Function Calling 去调用这些工具；传统 API 是 MCP 所取代的”乱接”状态。

七、和你们站点的 Connector / Skill / Agent 是什么关系

这部分是运营GO 自己的口径，和上面不冲突，只是换了层视角：

Connector 是具体那根线，MCP 是这根线”该长什么样”的标准。
Skill 可以建在 MCP 之上，平台按标准去拿能力，不用自己重写。
Agent 负责编排多个 Skill / 工具去完成任务；MCP 让它少写一堆重复接线。
对普通用户，MCP 最大的甜头是：同一个工具，换一家 AI 也能接着用，不被绑死。

八、一个具体的前后对比

拿前面那个小团队说：五个内部系统要接进两个不同的 AI 工具，按老办法是 5×2=10 次对接，每次还跟着模型升级重做，前后花了两周多，养着一堆容易过期的代码。按 MCP，五个系统各做一份标准适配，两个 AI 工具直接复用，一天多就完事，后面换模型也不用重接。

图 4：集成工作量对比。工具从 5 个涨到 10 个时，传统对接从 10 次涨到 20 次；MCP 只从 7 次涨到 12 次，而且这些适配能被所有模型反复复用。

九、它的发展时间线

2024-11

Anthropic 正式开源 MCP，发布规范与 Python / TypeScript SDK，并开源 Google Drive、GitHub 等预置 Server。

设计灵感

借鉴 USB-C（统一接口）与 LSP（语言服务器协议）——LSP 把”编辑器 × 语言”的 N×M 问题变成 M+N，MCP 想对 AI 生态做同一件事。

2025 起

社区与厂商陆续接入，Host（Claude Desktop、Cursor 等）和各类 Server 快速增长，互操作生态成形。

十、小结

一句话收尾：MCP 不是又一种”让模型变强”的魔法，而是给”AI 怎么连外部世界”定的统一标准。它把 N×M 的重复接线，压成 M+N 的一次适配；用 Host / Client / Server 三层 + JSON-RPC，把 Tools / Resources / Prompts 三种能力开放给任意模型。对做集成的人是省工，对用 AI 的人是”换个工具也不丢能力”。

如果你想看它落地，可以从一个现成的 MCP Server（比如连本地文件或某个 API）起步，跑通那条调用链，再考虑自己写 Server。