1. 引言：每接一个新东西，就要重新连一遍

上一篇《RAG》的结尾，我留了一个问题：模型到这一步已经够全能了——会说话、看得懂长文、记得住上下文、能表示语义、能伸手调工具。可每次让它干一件新事，我都要单独给它写一套连接：接一个天气工具，写一套；接一个文件工具，又写一套；想让某套内部资料能被它查到，还得专门搭一套检索。

工具和资料成千上万，难道每来一个，就要重新连一遍？

我的答案是：不必。现在已经有了一个统一标准，叫 MCP——Model Context Protocol，模型上下文协议。一句话说清它是干什么的：它是所有工具的「USB-C 接口」。

这个系列走到最后一篇。前面七篇拆的是它的脑子，这一篇讲它怎么用一只统一的手，接上全世界。

2. MCP 解决什么：一个插口，连所有

先说痛点到底痛在哪。你把模型接给一个工具，要写「模型怎么表达意图、工具怎么理解、结果怎么传回来」这一整套对接。模型有 M 个，工具有 N 个，传统做法是每个模型 × 每个工具单独对接一次——M 乘 N 套连接。模型多几个、工具多几个，这个矩阵就爆了。

MCP 把乘法变成加法。

做法不玄乎：规定一套公共语言。模型这边按这套语言说「我要调用一个叫 XX 的工具，参数是 YY」；工具那边按同一套语言回「调用结果长这样」。谁都不用迁就谁的特殊格式。M 个模型、N 个工具，各自只对接一次标准，总共 M 加 N 次，完事。

你想想 USB-C 干了什么。十年前，充电线有 Micro-USB、Lightning、各种私有接口，一台设备一根专用线。USB-C 出现后，同一根线能充手机、充平板、传数据、接显示器。它没发明任何新功能——充电和传数据早就有了——它只是把「怎么连」统一了。MCP 要干的是同一件事。

接上前面两篇的痛点。本系列第 6 篇《Function Calling》讲过，模型伸手调工具的能力早就有了，但每接一个新工具，就要单独写一套对接；上一篇《RAG》讲过，查外部知识的能力也早就有，但每套资料要单独接一套检索。工具、资料、提示，各自为政，各连各的。MCP 要统一掉的，正是这种各连各的。

3. 架构：插座、插头、线缆

回到引言那个问题：有没有统一标准？有。MCP 不发明新功能，它只统一「怎么连」——工具的「USB-C 接口」。它自己，就两样东西加一条线。

MCP client 和 MCP server，两个角色。 类比：插座和插头。client 是插座，站在模型这一侧；server 是插头，站在工具那一侧。工具要接入，就实现一个 MCP server——把「这个工具有什么能力、怎么调」按标准格式声明出去；模型要连工具，就通过 client 去发现、去调用。两端按同一个插座规格造，插上就能用。

中间那条线叫 transport，传输方式。 2026 年的主流是 Streamable HTTP：模型这一侧发一个 HTTP 请求，一次 POST 就通，工具那一侧回响应。本地跑的工具还能走 stdio，直接跟子进程说话，不占网络。

模型连外部世界，能插三样东西——MCP 管这叫三类能力：

• tools：能执行的工具。本系列第 6 篇《Function Calling》里那种「伸手调工具」，MCP 给它一个统一的声明格式：工具名、参数、描述，一次说清。
• resources：能被读取的资源——文件、数据库记录、网页内容。上一篇《RAG》里讲「查外部知识」，传统是每套资料单独写检索；MCP 把「可读的资料」也标准化成资源，模型按统一方式去读。
• prompts：可复用的提示模板。把「怎么让模型干某类活」的常用套路封装成标准提示，跨应用共享。

一句话收：tools 是手，resources 是资料库，prompts 是招式。三类东西以前各连各的，现在都插同一个口。架构讲完，下面看它跑一遍的样子。

4. 一次调用走通：从问句到答案的全程

上面是架构，下面是它实际跑一遍的样子。我拿一个真实的场景举例。

你对模型说：「帮我把这周 GitHub 上 star 涨得最快的 AI 项目找出来，整理成三条，发到我的邮箱。」这句话里有两件事要调工具：查 GitHub 仓库排行，发邮件。模型自己不会连 GitHub，也不会发邮件——它连的是 MCP。

拆开看这几步。模型收到你的话，先判断「这需要调用工具」，于是对 client 说：我要调一个叫 search_repos 的工具，参数是「按本周 star 增长排序」。client 拿着这句话去找对应的 server——这个例子里是 GitHub 的 server——用 JSON-RPC 格式发一个 tools/call 请求。

server 收到后去调 GitHub 的真实接口，拿到仓库列表，再把结果包成统一格式传回来。模型拿到结果，组织成你看到的那段话。

注意一个细节：模型全程说的是「我要调工具 X，参数是 Y」，它不知道也不关心 GitHub 接口长什么样、认证怎么搞、返回怎么解析——这些全在 server 里。换一个工具，只换一个 server，模型那边一行不用改。这就是「统一插口」的实际含义。

这里也接上第 6 篇《Function Calling》讲的循环：模型负责「说」和「再说」，真正「做」的是 server 里的外部代码。MCP 没改这个分工，它只是把「模型怎么找到工具、怎么发请求」这一段标准化了。

5. 2026 进展：第五版规范、中立治理、厂商入场

回到开头那句话：统一标准已经有，而且它在 2026 年实实在在成了气候。先列我核实过的事实，再讲为什么值钱。

规范在 2026-07-28 出了第五版，最大改动是把协议改成默认无状态。 旧版要握手、要建会话、要记住「上次对话到哪了」——服务端得存状态，负载均衡也麻烦，一个请求只能路由到那个存着它会话的实例上。

新版把会话层整个去掉：每个请求自包含，带上协议版本、客户端身份、能力声明，发给哪个实例都能处理。MCP server 因此能部署到无服务器环境（AWS Lambda、Cloudflare Workers 这类），任意实例接任意请求，水平扩展不再是问题。用插座类比说：以前是「每个插头都得记住上次插过哪个插座」，现在是「谁接都行，不用记住上一次是谁」。

治理在 2025 年 12 月中立化了。 Anthropic 把 MCP 捐给了 Linux 基金会旗下的 Agentic AI Foundation（AAIF），跟 OpenAI 的 AGENTS.md、Block 的 goose 一起当创始项目。

AAIF 成立不到一年，从 49 家创始成员长到 250 多家，铂金级会员里 AWS、Anthropic、Block、Bloomberg、Cloudflare、Google、Microsoft、OpenAI 全在——罕见地凑齐了主要云厂商和模型实验室。2026 年 8 月 20 日，Google 的 A2A 协议也进了 AAIF，把「Agent 之间协作」和「模型连工具」这两层标准放到了同一把伞下。

厂商全部入场。 OpenAI 在 2025 年 3 月给 Agents SDK 和 Responses API 加了 MCP 支持，9 月进了 ChatGPT 桌面端；Google 在 2025 年 4 月确认 Gemini 支持 MCP，还上了托管 server（Analytics、Looker、BigQuery 那批）；微软的 GitHub Copilot、VS Code 支持 MCP，Dynamics 365 等产品也有官方 server。

到 2026 年，Anthropic、OpenAI、Google、Microsoft、AWS 全部原生支持 MCP。

生态数字（截至 2026-08-23 核实）。 公开的 MCP server 目录索引到约 1.7 万到 2 万个条目——官方 registry 约 1.7 万个，mcp.so 等社区目录更高，跨目录去重后估算唯一 server 在 1.5 万到 2 万之间。SDK 月下载量在 2026 年 7 月官方披露时已超过 4 亿次，一年涨了四倍；TypeScript 和 Python 两个 SDK 各自累计下载都破了 10 亿。

6. 为什么是趋势：标准值钱在背书

数字摆完，回到引言那句判断。2026 年它真的成气候了吗？成了——而且正在理论上翻新。先说凭什么成，翻新翻出什么争议，下一章说。

光有技术，成不了气候。好协议多了去了，没人用就是废纸。MCP 的协议本身不复杂，JSON-RPC 套个壳，聪明不到哪去。值钱的是另一件事。

标准值钱不在协议本身，在被厂商背书的共识——大家都有激励去实现它。 这句话是这篇的判断。

拆开看。OpenAI、Google、Microsoft、AWS 全在自己产品里原生支持 MCP，意味着什么？意味着一个开发者写一个 MCP server，Claude 能用、ChatGPT 能用、Gemini 能用、Copilot 能用。写一次，到处能插。

这就是从「每个工具单独接」到「统一插口」的闭环。本系列第 6 篇《Function Calling》讲过，模型伸手调工具的能力早就有，但每接一个工具要单独写一套；上一篇《RAG》讲过，查外部知识的能力也早就有，但每套资料要单独接一套。MCP 把这两个痛点一起解了：工具和资料都做成标准接口，接一次，所有模型通用。

厂商为什么愿意背书？因为激励一致。模型厂商想让自己的模型能用更多工具，工具厂商想让自己的工具能被更多模型调用——标准一统一，双方各自省掉海量对接成本。大家都按同一个插座规格造插头，谁都能插谁的。

但「被背书」不意味着「没问题」。2026 年 7 月那版 stateless 重写，把两个老问题翻到了台面上——安全委托，和「这不就是个 REST API 吗」的质疑。先卖个关子，下一章逐个兑现。

7. 安全与争议：保险丝焊在谁身上

现在兑现那个关子。先说安全。

规范不内置安全，委托实现方执行。 MCP 协议本身只管「怎么连」，不管「连上之后能干什么、是不是被授权」。权限校验、工具白名单、沙箱隔离，全靠实现方自己上。这个委托不是空话，是有真实事故的。

CVE-2025-49596，CVSS 9.4，2025 年 6 月公开：Anthropic 官方的 MCP Inspector——一个调试工具的浏览器界面——在 0.14.1 之前，client 和代理之间没有鉴权。恶意网页能借浏览器漏洞链上 CSRF，在你机器上执行任意命令，高危 RCE。

CVE-2025-6514，CVSS 9.6，2025 年 7 月公开：官方 mcp-remote 包在 OAuth 流程里把 authorization_endpoint 直接拼进 shell 命令，恶意 server 返回一个精心构造的 URL 就能远程执行代码。

更阴的是触发链路：攻击者先在一篇文档里埋 prompt injection，模型被诱导去连一个恶意 server，server 返回恶意 URL，直接 RCE。这个包被下载了近 50 万次——连一个不信任的 server，机器就可能失守。

这两个 CVE 都不是协议本身的 bug，是实现方的漏洞。但「委托实现方」的意思是：安全这道保险丝，得由每一个接 MCP 的厂商、每一个跑 server 的团队自己焊。焊没焊好，看 CVE 列表就知道。

再说争议。2026 年 7 月 stateless 化之后，社区吵翻了：这不就是个 REST API 吗？

原话更狠。有人翻旧账：「我们发明了一个有状态协议，发现状态难扩展，把它剥掉，最后得到了『就发一个 POST 请求』。REST 党已经得意地等了 20 年。」Perplexity 的 CTO 在 3 月公开说内部弃用 MCP，改用纯 REST API 和 CLI。

也有人骂它 context bloat——一个带 106 个工具的数据库 server，光初始化就把 5.4 万个 token 塞进上下文，一半窗口没了。

我站哪边？协议像 REST，我不反驳——stateless 化之后，MCP 跟一个 REST API 长得确实像。但「长得像」和「是同一个东西」是两回事。一个 REST API 是你自己写的，只有你自己用；MCP 是 OpenAI、Google、Microsoft 全在实现的同一个标准——你的 server 写完，所有模型都能插。

协议可以像 REST，值钱的是「大家都认这个插口」这件事。有人反对，有人赞同，这题留给你们在评论区吵。

8. 技术深挖（可跳过）

这节写给想看机制细节的开发者，跳过不影响主线。

transport 演进：SSE → Streamable HTTP → stateless

MCP 刚开源（2024 年 11 月）时，HTTP 传输用的是 HTTP+SSE：客户端发一个 POST 请求，服务端开一条 Server-Sent Events 长连接持续推消息。双向性靠「一条推送流 + 一个请求端点」拼出来，实现别扭，也难扩展。

2025 年 6 月出的 Streamable HTTP 传输把它换了：请求和响应都走普通 HTTP，一次 POST 就通，能直接复用已有的负载均衡、网关、缓存。2026 年 7 月的第五版把会话层去掉后，整个传输完全无状态，老式 HTTP+SSE 走入了弃用流程（官方给了 12 个月的过渡期）。

JSON-RPC 消息

MCP 的消息格式是 JSON-RPC 2.0——「方法名 + 参数 + 返回结果」那套标准。模型侧想调工具，发 tools/call；想列出工具，发 tools/list；资源和提示同理。新版本还加了几个路由用的 HTTP 头（Mcp-Method、Mcp-Name），网关不用解析 JSON 就能做路由和限流。

MRTR：服务器也能发起请求了

旧版协议里，server 想反过来问客户端要东西——比如要用户确认一个危险操作——得靠一条常开的流。stateless 之后没有流了，MRTR（Multi Round-Trip Requests）接管：server 返回「我需要额外输入」，把问题打包成 inputRequests，客户端收集回答后再带着结果重试原请求。确认、多轮索取信息，都能在不持流的情况下完成。

extensions 框架：官方扩展三类

第五版引入了版本化的扩展框架，三个一等官方扩展：MCP Apps（server 渲染交互界面，图表、表单、选择器直接在对话里显示）、Tasks（长时任务，异步执行 + 轮询，AWS 贡献的）、EMA（企业托管鉴权，接 Okta 这类企业身份提供商）。

9. 收束：七篇拆机器，这篇接世界

最后一篇，把整个系列的地图摊开。

Part A，模型「能说、能看懂」：

• 本系列第 1 篇《LLM 是什么？》——token 自回归，它能说话；
• 本系列第 2 篇《训练三阶段——从会接龙，到会听话，到会思考》——它是怎么被教出来的，这是地基；
• 本系列第 3 篇《Transformer 与注意力》——它看得懂长文；
• 本系列第 4 篇《上下文窗口的边界》——它记得住上下文。

Part B，模型「能连上世界」：

• 本系列第 5 篇《Embedding 与向量》——它把语义表示成向量；
• 本系列第 6 篇《Function Calling》——它伸手调工具，但每接一个工具要单独写一套；
• 上一篇《RAG》——它查外部知识，但每套资料要单独接一套；
• 本篇 MCP——它用一个统一插口，接上全世界。

一个会说话、看得懂、记得住、懂语义的大模型，是空有内功的。要它真正干活，得让它连上外部的工具和资料。前面七篇讲的是它脑子的能力，这一篇讲的是它跟世界打交道的那只手——而 MCP 让这只手不再是每个工具配一只手套，而是一只手配一个通用接口。

这个系列到此收官。八篇，从「它为什么能说话」到「它怎么连上世界」，一条线拉下来。

如果你还没上手，给你一个行动：下次看到任何 AI 产品宣传「支持 MCP」，你知道它说的是什么了——能插统一插口的工具，接一次，处处能用。可以去翻翻产品文档里那个「MCP」段落，看它到底接了什么工具。

这个系列八篇全在这里。想收藏的话，整个系列存一份——Part A 讲它怎么说话思考，Part B 讲它怎么连上世界。