什么是模型上下文协议（MCP）？

E10

概念 · AI 模型与工具生态

模型上下文协议（MCP）。

让一个 AI 应用连一个工具很容易；但要手工把 M 个应用连到 N 个工具，就是一场集成爆炸，每个团队都在重复搭同一套管道。MCP（Model Context Protocol，模型上下文协议）就是那个开放标准，它把 M×N 的混乱压缩成 M+N——即"AI 的 USB-C"。本文讲清 MCP 是什么、为何存在、如何构成，以及它可能在哪里咬到你。

STEP 1

M×N 问题，以及为何一个接口就能解决。

你已经了解工具调用：你的代码把一份函数菜单交给模型，模型选哪个你就运行哪个。这行得通，但每一次集成都是定制的。假设你要做 5 个 AI 应用，每个都需要接到 8 个工具——GitHub、Slack、一个数据库、一个文件系统等等——你就得写 5 × 8 = 40 个定制连接器。每新增一个工具要多写 5 个；每新增一个应用要多写 8 个。成本随两边数量的乘积增长。这就是 M×N 问题，在 MCP 出现前，整个行业都在用重复的胶水代码为它买单。

MCP 把这道算术翻转成 M+N。大家约定一套共享协议；每个应用把客户端一侧实现一次，每个工具把服务端一侧实现一次，此后任何应用都能与任何工具对话。5 个应用 + 8 个工具变成 13 次实现，而非 40 次——而且任何人发布的一个工具，会立刻在每一个讲 MCP 的应用里可用。这正是"AI 的 USB-C"这句标语的实质：USB-C 之前，每台设备都自带一款充电器；之后，一个接口通吃一切。

这个类比在关键之处是精确的。USB-C 并没有让设备变得更强，它让设备可互操作。MCP 不给模型新能力——那是工具调用早已做到的。它标准化的是任何应用如何接到任何工具，好让这层连接不再是定制工作。

STEP 2

引擎盖下：客户端、服务端、三种原语。

MCP 是一套客户端/服务端协议，用 JSON-RPC 2.0 通话——那是一套朴素、久经沙场的约定，意思是"用这些参数调用这个方法，拿回一个结果"。三种角色：

宿主（host）是用户直接打交道的 AI 应用——一个 IDE、一个聊天客户端、一个智能体。
宿主内部跑着一个 MCP 客户端（client），负责开启并维护一条双向连接。
每一项外部能力都是一个 MCP 服务端（server）——一个暴露单个工具或数据源的小程序（一个 GitHub 服务端、一个文件系统服务端、一个数据库服务端）。一个客户端可以同时连到多个服务端。

一个服务端可以提供三种原语（primitive），而每种"由谁做主"各不相同——把这点分清很有用：

Tools（工具）——模型可调用的可执行函数（由模型主导）。这就是寻常的工具与动作，如今通过一套标准变得可被发现。
Resources（资源）——为提供上下文而暴露的数据或内容，比如文件或数据库记录（由应用主导）。
Prompts（提示）——可复用、可参数化的模板或工作流（由用户主导）。

最后是传输（transport）——字节实际怎么走。stdio 用于本地服务端：客户端把服务端作为子进程启动，二者通过 stdin/stdout 交换 JSON-RPC，不涉及网络。Streamable HTTP 是当前的远程传输：一个单一的 HTTP 端点，用 POST 加上可选的 Server-Sent Events（SSE）做流式传输，在 2025-03-26 规范修订中引入。它取代了更早的双端点 HTTP+SSE 传输，后者现已弃用。作为初学者你很少亲手碰线上格式——SDK 会处理 JSON-RPC 的封装——但了解 Streamable HTTP 的形状会有帮助，正是它让远程托管的服务端变得可行。

STEP 3

MCP 为何胜出——以及它不是的两件事。

协议只有在人人都讲时才有意义，所以转折点是跨厂商的采纳。Anthropic 于 2024 年 11 月 25 日推出 MCP（最初由 David Soria Parra 与 Justin Spahr-Summers 开发）。随后 OpenAI 在 2025 年 3 月采纳，Google 与 Microsoft 跟进——使 MCP 成为一个共享的、事实上的互操作标准，而非某一家公司的格式。2025 年 12 月，治理权移交至 Linux Foundation，纳入 Agentic AI Foundation（AAIF），由 Anthropic、Block 与 OpenAI 共同发起——把它坐实为中立的基础设施。（那份捐赠公告提到截至 2025 年 12 月有超过 10,000 个活跃的公开 MCP 服务端——这是一个时点数字，但足以说明生态成长之快。）

有两个误解值得澄清：

"MCP 是 Claude 专属的东西。"错。Anthropic 推出了它，但它是一个开放标准：OpenAI、Google 与 Microsoft 都已采纳，如今由 Linux Foundation 治理。
"MCP 不过是函数调用/又一个 API。"也不对，而且更微妙。函数调用是某个应用私有的机制，让一个模型去调用一组函数。MCP 是环绕其上的协议层——一套在整个生态里发现、连接、描述工具的标准，好让一个别人写的服务端能在一个别人写的应用里工作。想看接线细节，见 MCP 架构深入解析。

STEP 4

它可能在哪里咬你：服务端是不可信代码。

MCP 的超能力——插上任何服务端就能用——同样是它最锋利的一面。服务端往往是你没写过的代码，而模型会读它提供的文本。最要紧的是两种失效模式：

经工具描述发起的提示词注入（"工具投毒"，tool poisoning）。恶意服务端可以把指令藏进模型会读的工具名称与描述里，诱导它泄露数据或滥用其他工具——因为模型把这些元数据当作可信。过度授权或被过度信任的服务端。服务端可能索取宽泛的权限；一个被攻陷或本就恶意的服务端能外泄数据或采取破坏性动作。这就是"混淆代理人"（confused deputy）问题：你信任的应用被骗，替攻击者行事。

解法是一种心态，而非一个开关：把每个服务端都当作不可信代码。具体而言——只给服务端它真正需要的访问权限（最小权限）；在安装前审查一个服务端做什么，优先选你或可信方已审核过的；对有后果的动作（付款、删除、发送）要求人工确认，好让被颠覆的提示词依然无法擅自行动。这些与寻常的提示词注入防御是同一套直觉，如今用到了一个第三方服务端的集市上；而工具投毒与安全反模式两篇深入解析，正好把它们如何出错逐一列清。

当你准备真刀真枪地构建或加固服务端时，本 wiki 的 MCP 深入解析组接手往下讲：实战构建服务端与工具设计讲"怎么做"，再加上鉴权与生产运维，讲如何在规模化时把它们跑得安全。