夜雨聆风一个由 Anthropic 在 2024 年底开源的小协议，如今被它最大的竞争对手 OpenAI、被 Google、被微软同时采纳，最后被三家联手捐进了同一个中立基金会。这在科技史上并不常见。小赛想带你拆开看看：MCP 到底解决了什么、它的协议长什么样、为什么会变成一场「协议之战」，以及它撕开了哪一道新的安全口子。
01一、先看痛点：M×N 的集成地狱
大模型本身只会算概率、吐 token，它不会查你的数据库、不会读你公司的 Wiki、更不会替你下单发邮件。要让模型「干活」，就得把它接到外部的工具和数据上——查天气的 API、读文件的接口、操作数据库的函数。这件事的术语叫「工具调用」（tool use / function calling）。
问题出在「接」这个动作上。
假设市面上有 M 个模型或 AI 应用（Claude、ChatGPT、某个 IDE 里的助手、某个自研 Agent……），有 N 个工具或数据源（GitHub、Slack、Postgres、内部订单系统……）。在没有统一标准的世界里，每一个应用要用上每一个工具，都得单独写一套对接代码。M 个应用 × N 个工具，就是 M×N 套互不复用的胶水代码。
这就是集成爆炸：换个模型，N 套对接全部重写；新加一个工具，M 个应用各接一遍。工具方和应用方都被锁死在两两配对的笛卡尔积里。
MCP（Model Context Protocol，模型上下文协议）的解法，本质上是软件工程里最经典的那一招——在中间插一层标准接口。工具方只需按协议实现一次 server，所有兼容 MCP 的应用都能用；应用方只需实现一次 client，就能接入所有 MCP server。M×N 的对接量被压成了 M+N。
Anthropic 给它起的官方比喻是「AI 应用的 USB-C 接口」。这个类比很贴切：USB-C 出现之前，每个设备一种充电口、一种数据线，抽屉里塞满了互不通用的线缆；USB-C 统一了物理接口之后，一根线插所有设备。MCP 想干的，就是给「模型↔工具」这件事定义一个统一的「口」。
图1：MCP 的核心价值，是把工具集成从笛卡尔积（M×N）压成加法（M+N）。
02二、协议结构：三个角色、三类能力、一层传输
要把 MCP 讲透，得拆成三层来看：谁和谁说话（角色）、说什么（能力）、怎么传（传输）。这三层是 MCP 官方规范里明确定义的，不是小赛的概括。
2.1 三个角色：host / client / server
- ●Host（宿主）：用户直接面对的那个 AI 应用本体，比如 Claude 桌面端、ChatGPT 客户端、或某个 IDE 里的助手。它持有大模型，负责和用户对话、决定要不要调工具。
- ●Client（客户端）：由 host 内部创建，是协议的「连接器」。一个 client 对应一个 server，是一对一的连接关系。host 想接几个 server，就在内部开几个 client。
- ●Server（服务端）：一个独立进程或服务，负责把某一类外部能力（一个数据库、一个 API、一组文件操作）按 MCP 规范暴露出来。
为什么要把 client 和 host 分开？因为这层隔离正是安全边界所在——后面第四节会讲到，外部 server 是不可信的，host 通过 client 这层去和它打交道，而不是让模型直接「裸连」外部系统。
图2：Host 持有模型与对话；每个 Client 一对一连一个 Server；Server 是外部能力的标准化封装。
2.2 三类能力：tools / resources / prompts
一个 server 能向 host 暴露三类东西，这是 MCP 规范里 server 能力的三大支柱：
- ●Tools（工具）：可被模型调用的「动作」，比如「查询订单」「发送消息」「执行 SQL」。这是模型主导的——模型根据对话判断该不该调、传什么参数。工具是 MCP 里风险最高的一类，因为它能产生副作用（改数据、花钱、发东西）。
- ●Resources（资源）：可被读取的「数据」，比如一个文件、一段数据库记录、一个网页内容。资源是只读、由应用主导的上下文，模型把它当背景信息读进来，原则上不产生副作用。
- ●Prompts（提示）：预先写好的、可复用的提示模板或工作流，由用户主导触发，比如「帮我审一遍这段代码」背后那套结构化提示。它让 server 方能把「最佳用法」固化下来交给用户选用。
记住这三者的「主导方」差异——tools 偏模型自主、resources 偏应用注入、prompts 偏用户触发——这对理解权限设计很关键。
2.3 一层传输：stdio 与 Streamable HTTP
角色之间怎么传消息？MCP 底层用的是 JSON-RPC 2.0 这套成熟的远程调用格式，外面套一层「传输」：
- ●stdio：server 作为本地子进程跑，通过标准输入输出和 host 通信。适合本地工具（读本机文件、操作本地 Git），延迟低、不走网络。
- ●Streamable HTTP：走 HTTP 的远程传输，适合云端部署的 server。这里有个值得讲清楚的演进：MCP 最初（2024-11-05 规范）的远程传输叫「HTTP + SSE」，用两个端点——一个 POST 发消息、一个 SSE 长连接收事件。这套设计在 2025-03-26 规范里被 Streamable HTTP 取代并标记为弃用：新方案改成单端点，客户端 POST 一个 JSON-RPC 请求，服务端可以直接回一个 JSON，也可以按需升级成 SSE 流来处理长任务。改动的核心动机是无状态、可水平扩展——老的 SSE 要维持长连接，新方案能放在负载均衡后面跑多实例。这条演进在 2025 年 11 月的规范修订里被保留。
如果你今天要新写一个远程 server，官方的指引很明确：直接上 Streamable HTTP，不要再用老的 HTTP+SSE。
图3：模型只负责「决定调什么」，真正的执行发生在 Server 一侧，结果再回填给模型续推。
把这三层拼起来，就是一张完整的 MCP 拓扑：一个 host 内部开多个 client，每个 client 连一个 server，每个 server 各自暴露自己的 tools / resources / prompts。
图4：接一次协议，host 就能像插 USB 设备一样即插即用地挂载任意多个 server。
03三、协议之战：一年从开源到「行业默认」
MCP 真正的看点，不是技术多新（用 JSON-RPC 包工具调用并不稀奇），而是它的采纳速度和政治意味。小赛按公开报道梳理一条时间线（具体日期见文末事实清单）：
图5：从 2024-11 开源，到 OpenAI、Google、微软先后采纳，再到 2025-12 捐入 Linux 基金会旗下 Agentic AI Foundation。
- ●2024 年 11 月 25 日，Anthropic 开源 MCP，发布 Python / TypeScript SDK，并附带了 Google Drive、Slack、GitHub、Git、Postgres、Puppeteer 等一批预置 server。这是「自家发布」。
- ●2025 年 3 月，剧情陡转：OpenAI 宣布在自家 Agents SDK、Responses API 乃至 ChatGPT 桌面端支持 MCP。CEO Sam Altman 公开表态「大家都喜欢 MCP，我们很高兴在产品里加上它」。一家头部 AI 公司，采纳了由其最直接竞争对手提出的开放标准——这在行业里是标志性事件。
- ●2025 年 4 月，Google DeepMind 跟进，表示 Gemini 及相关 Agent SDK 将支持 MCP。
- ●2025 年（年中），微软、GitHub 等深度集成 MCP，并进入了协议的治理 / 指导委员会层。
- ●2025 年 12 月 9 日，Anthropic 将 MCP 捐给新成立的 Agentic AI Foundation（AAIF）——这是 Linux 基金会下的一个定向基金，由 Anthropic、Block、OpenAI 联合发起，Google、微软、AWS、Cloudflare、Bloomberg 等提供支持。MCP 成为该基金会的创始项目之一。治理上采用两级结构：基金会理事会管战略 / 预算 / 新项目，而 MCP 项目本身保留对技术方向和日常运作的自主权，原有维护者结构不变。
把这条线连起来看，「协议之战」的看点就清楚了：
第一，标准之争往往不是技术之争，而是网络效应之争。 谁的协议被更多人实现，谁就掌握生态入口。OpenAI 选择采纳而非另起炉灶，说明在「工具集成层」这件事上，重复造一个不兼容的轮子代价太大——这一层更适合做成中立公地，让大家在上面的模型和应用层去竞争。
第二，它和 function calling 不是替代，是分层。 OpenAI 早就有 function calling，本质是「在单次 API 调用里告诉模型有哪些函数可调」。但 function calling 只规定了「模型怎么表达它想调函数」，没规定「这个函数从哪来、怎么发现、怎么连」。MCP 补的正是后半段：工具的发现、连接、复用标准。所以现实是 OpenAI 用 MCP 来喂自己的工具生态，两者叠在一起用，而不是二选一。
第三，捐给中立基金会是「去 Anthropic 化」的关键一步。 一个标准如果永远姓「某一家」，竞争对手就有理由不采纳、有动机另立门户。捐进 Linux 基金会式的中立治理（和 Kubernetes、PyTorch、Node.js 同一套托管逻辑），是把「这是大家的协议」这件事做实，换取长期的广泛采纳。
需要诚实分层的是：以上是已发生的现实（采纳、捐赠都有公开报道）。但「MCP 会不会成为长期稳定的事实标准」属于前瞻判断——历史上被广泛采纳又最终碎片化的协议并不少。一个可证伪的观察点是：未来若出现各家在 MCP 之上「各加私有扩展、互不兼容」的分裂迹象，就是标准开始裂解的信号。
04四、安全：把外部系统敞开给一个会被骗的模型
这是 MCP 最被低估、也最该讲清楚的一面。
MCP 的便利，本质是把外部系统通过标准协议、以「模型可自主调用」的方式敞开。可大模型有两个天生的脆弱性：它会犯错，而且它会被提示注入（prompt injection）操纵——也就是攻击者把恶意指令藏在模型读到的内容里，诱导模型执行非预期动作。当你把「会被骗的大脑」接上「能产生真实副作用的工具」，就等于开辟了一整片新的攻击面。
具体到 MCP，已经被披露和归类的风险至少有这几类：
1. 工具投毒（Tool Poisoning）。 这是 MCP 特有的攻击。一个恶意或被攻陷的 server，可以把恶意指令写进工具的描述（description）或 schema里——而这些描述会原封不动地进入模型的上下文，被模型当成可信输入。毒不在代码里，在「说明书」里。OWASP 已专门把它列为 MCP 风险清单（MCP Top 10）中的一项（MCP03:2025 Tool Poisoning），与之并列的还有「上下文载荷里的提示注入」（MCP06:2025）。2025 年也出现了被归到工具投毒类的具体编号漏洞（如 CVE-2025-54136，影响某些 MCP 客户端对工具定义的处理）。
2. 真实的远程代码执行漏洞。 最值得点名的是 CVE-2025-6514：这是开源工具 `mcp-remote`（一个让客户端连接远程 MCP server 的桥接器）里的 OS 命令注入漏洞，CVSS 评分高达 9.6 / 10（Critical），由 JFrog 安全团队发现并披露。成因是 `mcp-remote` 在 OAuth 流程初始化时，对从 server 返回的 `authorization_endpoint` URL 处理不当——当客户端连上一个恶意 server，server 回一个精心构造的 URL，就能在运行 `mcp-remote` 的机器上执行任意系统命令，导致完整的系统沦陷。受影响版本为 0.0.5 至 0.1.15，修复版本是 0.1.16。据公开报道，该工具的下载量级在 43 万次以上。它的意义在于：这是「连一个不可信 server 就被打穿」的活体证明，把第二节里「为什么要有 client 隔离层、为什么默认不能信任 server」从理论变成了现实。
3. 权限过宽与缺乏审批留痕。 很多 MCP server 部署时图省事，给的是「全量权限」——一个本该只读的工具拿到了写权限，一个本该限定范围的操作拿到了 ambient authority（环境级别的默认权限）。一旦模型被骗，这些过宽的权限就是放大器。再叠加上「调用没有人工审批、没有完整审计日志」，出了事连追溯都难。
工程上的应对方向也已经清晰：只连可信 server、走 HTTPS（CVE-2025-6514 的官方缓解建议就是这两条加升级版本）；对高副作用的 tools 加人工审批环节；最小权限授权；对工具描述 / schema 做完整性校验，不无条件信任 server 给的「说明书」；以及在 host 和外部之间放一层网关 / 沙箱做隔离与留痕。
一句话总结这一节：MCP 把「集成」标准化了，但没有、也不能替你把「信任」标准化。协议规定了怎么连，没规定连过来的是不是好人——信任边界得由部署方自己守。
05五、对开发者：现在该不该上，坑在哪
抛开宏大叙事，落到一个具体的工程师身上，MCP 到底意味着什么？
最实在的红利：接一次，复用所有兼容客户端。 如果你做的是一个工具 / 数据服务（一个内部系统、一个 SaaS 的能力），把它实现成一个 MCP server，那么所有支持 MCP 的客户端——Claude、ChatGPT、各类 IDE 助手、自研 Agent——都能直接挂载你的能力，你不用为每一家单独适配。这就是 M+N 的红利落到个体身上的样子，也是典型的网络效应：兼容客户端越多，你这个 server 的价值越大。
该不该现在就上？ 小赛的判断分两种情况：
- ●如果你在做 Agent / AI 应用产品，工具集成是核心，那么基本是「不上也得上」——主流模型厂商已经统一在这套协议上，逆着生态走的成本只会越来越高。
- ●如果你只是想给自己的小工具加个 AI 入口，可以先观望成本：MCP 引入了额外的进程 / 服务和运维复杂度，对一个简单场景，直接用某一家的原生 function calling 可能更轻。
*坑在哪，提前说三个：*
- 1安全是默认的坑，不是可选项。 别把任意第三方 server 拿来就连（CVE-2025-6514 就是教训），别给 server 过宽权限，高危操作务必留人工审批和日志。这一节第四部分讲透了。
- 2规范还在演进。 传输层一年内就从 HTTP+SSE 切到了 Streamable HTTP（2025-03-26）。你今天写的 server，要做好跟着规范修订迭代的准备，新项目直接用最新传输方式，别基于已弃用的设计起步。
- 3生态成熟度参差。 「有 1 万个 server」不等于「有 1 万个能用的 server」——质量、维护状态、安全审计水平差异极大。选型时把「谁在维护、是否可信」放在「功能多不多」前面。
06结语
MCP 的故事，本质是软件工程一条老规律在 AI 时代的重演：当集成成本变成 M×N 的爆炸，行业迟早会逼出一个 M+N 的标准接口。 USB-C 在硬件世界证明过一次，MCP 想在「模型↔工具」这一层再证明一次。
它已经赢得了罕见的共识——连竞争对手都来采纳、最后一起捐进中立基金会。但「统一接口」从来都是一把双刃剑：它把便利标准化的同时，也把攻击面标准化了。对开发者来说，真正的功课不在于学会怎么写一个 server——那是一两天的事；而在于想清楚，当你把一个会犯错、会被骗的模型，通过一根「USB-C」插进你的真实系统时，你愿意让它碰什么，又守住了哪条线。
• • •
作者：小赛。本文为协议机制与生态分析，不构成任何安全或投资建议；文中标注的时间、版本号、CVE 编号与采纳方均依据公开报道整理，关键事实清单见配套核验文档。
