为什么需要 MCP — 从胶水 fatigue 到标准插口
这一章讲三件事: 作者在全书开篇先不写任何代码,而是回答一个更根本的问题—— 为什么 2024 年底会突然需要一个新协议;他给出的答案是一条历史线和一句大白话论点; 以及 MCP 到底是什么、已经有了哪些现成的服务器。 这是全书唯一一章「纯动机」,后面每一章的技术细节都挂在这章的问题上。
1. 先看现象:费劲的不是「调大模型」,是「把能力粘进来」
你现在要做一个带 AI 功能的应用。比如一个电商后台,你希望它对运营人员说一句话就能干活:「把上周没发货的订单整理出来,给客户发一封安抚邮件。」
拆开看,这句话需要三个能力:查订单数据库、调物流接口、发邮件。 「理解这句话」那部分,今天一个大语言模型就能做—— 大语言模型(LLM)就是那种读了海量文字、能按你的要求生成文字的模型,ChatGPT、Claude 都是。 真正费劲的是另一半:这三个能力各有各的 API—— API(应用程序接口)就是一个程序专门留给别的程序来调用的入口, 你的程序想用上「订单数据库」的功能,就得照它的 API 的规矩来—— 各有各的认证方式、各有各的数据格式,你得挨个写代码把它们接进你的应用。
而且接一次还不算完。明天你又做了一个命令行工具、一个 IDE 里的助手,它们也想用这三个能力—— 同样的胶水,你再和一遍。
作者在这一章的开篇就说,这件事的痛点不在「能不能做」,而在「做着值不值」1。
没有标准时:
电商后台 ──┬─ 订单数据库的胶水
├─ 物流接口的胶水
└─ 邮件服务的胶水
IDE 助手 ──┬─ 订单数据库的胶水(又写一遍)
├─ 物流接口的胶水(又写一遍)
└─ 邮件服务的胶水(又写一遍)
图说:2 个应用 × 3 个能力 = 6 套胶水。
应用和能力各加一个,胶水不是加二,是加五行。
这张图就是本章的主走查。 记住这「6 套胶水」,下面每一节都在回答: 历史上的办法省掉了其中哪几套、MCP 又是怎么把它压到「2+3=5 件工作」的。
2. 这不是新烦恼:接口「怎么描述自己」已经进化了四代
作者没有直接抛答案,而是先带你走一遍他自己的从业记忆—— 「机器和机器之间怎么说话」这件事,业界已经折腾了二十多年2。
第一代是 SOAP。 它用 XML(一种带尖括号标签的文本格式)把请求和响应包得严严实实, 规则完备,但「非常复杂,感觉很重」2。你可以把它理解成一份措辞严密的合同: 什么都能约定,但签一份要费很大劲。
第二代是 REST。 它改走轻路线:直接借用网页本身的那套协议(HTTP), 数据用 JSON——一种「大括号包键值对」的文本格式,人眼就能读。 到今天它仍然是主流,作者特意强调「REST 没什么本质问题」3。
第三代是 GraphQL。 REST 时代前端团队常常干等后端把接口做完。 GraphQL 让调用方自己声明「我要哪几个字段」——字段就是数据里的一个个格子, 订单的「金额」「日期」各是一个字段——不必等后端为每个页面单做接口。
但它带来了自己的麻烦,最有名的一个叫 N+1 问题: 拿一份订单列表(1 次请求),发现每行还要再查一次客户详情(N 次请求), 一来一回把延迟(请求发出去到回答回来之间的等待时间)堆了上去4。
第四代是 gRPC。 谷歌出的高性能方案,数据压成二进制、走 HTTP/2, 适合数据中心里大量服务互相调用;代价是「搭起来和用起来都比较复杂」5。
把这四代摆在一起,作者真正想让你看的不是编年史,而是那条贯穿的线:
每一代方案,都在让「这个应用会什么、怎么调用它」这件事更容易被说清楚。 说清楚了,别人(和别的程序)才能不写胶水就接上。
3. 作者的论点:我们太会编程了,这才是问题
历史线讲完,作者给出全章最核心的一句判断,值得原样记住:
作为开发者,我们几乎「太会」编程了——什么都粘得起来,所以我们真去粘。6
把任何系统包一层 REST 接口、再写一段转换代码,接到任何别的系统上—— 这件事一个熟练工程师总能做到。能做到,和应该做,是两回事。 作者的账是这么算的:每粘一次,你就要付出理解对方接口、写转换、长期维护三份成本; 而公司里这样的「两两连接」有多少条?应用一多,是平方级地涨6。
与此同时,另一件事发生了:用户开始习惯用「提示词」跟应用说话—— 提示词(prompt)就是你发给大语言模型 的那段自然语言指令, 比如开头那句「把上周没发货的订单整理出来」。 作者由此抛出一串问题:既然用户用自然语言提需求, 那「听懂需求」的部分(大模型)和「干活」的部分(订单库、物流、邮件), 为什么还要焊死在同一个应用里?如果拆开,各归其位,会发生什么7?
他的回答是:拆开之后,干活的那些能力就可以被别人做的服务器提供, 你的应用只管理解和调度——这就是所谓的智能体**(英文 agent, 指那种不只是聊天、还会调用工具去完成任务的 AI 应用)时代7。
而拆开的前提是:两边得说同一种话。这就是要一个标准的全部理由。
4. MCP 是什么:一个插口,不是又一个框架
于是主角登场。MCP(模型上下文协议,Model Context Protocol)是一套开放协议, 用来标准化「应用怎么向大语言模型提供上下文」—— 这里的「上下文」就是模型回答问题时能用到的外部信息:数据、可调用的功能、预制的话术模板。 注意它的身份:它不是一个库、不是一个框架,是一份「约定」—— 约定消息长什么样、谁先开口、怎么报自己会什么。只要两边都遵守这份约定, 谁写的软件都 能互相对话8。
官方给它找的比方,作者照引了:AI 应用的 USB-C 接口8。 USB-C 是那个小小的椭圆形插口——充电、传数据、接显示器,一个口全包; 你买设备时不再需要关心它配哪种线。MCP 想做的是同一件事: 你的应用有一个「MCP 口」,任何按协议写的「能力服务器」插上就能用。
具体到开发者手上,这个「插上」的动作朴素得惊人:
在一个叫 mcp.json 的配置文件里列出你要用的服务器,你的客户端就接上了它们——
这里要先立住一对全书用到底的词:把能力提供出来的那一方叫服务器(server),
来连它、使用能力的那一方叫客户端(client)——
服务器本地跑的和远在天边的都行。作者说,就这么一个文件,
你的应用「几乎不费力气就变得像个智能体了」9。
有了 MCP 之后:
┌─ 订单 MCP 服务器 ─┐
电商后台 ────┤ 物流 MCP 服务器 ─├──── 各写一次,处处可用
IDE 助手 ────┤ 邮件 MCP 服务器 ─┘
(双方都只说 MCP 这一种话)
图说:回到第 1 节那张图。6 套胶水变成 3 个服务器 + 2 个客户端各实现一次协议 = 5 件工作;
更重要的是,第 4 个能力出现时,两个应用都零改动。
这就是主走查的落点:M×N 套胶水,被压成 M+N 份协议实现—— 我们协议书架的规范拆解把这句话称作 MCP 的头号卖点,本书作者是同一个意思10。
5. 已经有人把服务器写好了
标准能不能立起来,看的是生态。作者举的例子今天仍然好用:
- Blender(一款主流的 3D 建模软件)有人做了 MCP 服务器。 原本要花几十小时学建模,现在你用一句话描述想要什么模型,客户端替你去驱动 Blender11;
- GitHub、Playwright(浏览器自动化)、Google Maps 都有各自的 MCP 服务器12;
- 官方还维护着一份服务器清单,持续有人往里加12。
作者用电影《黑客帝国》收了个尾:Neo 被直接灌入格斗技能后说「我会功夫了(I know Kung Fu)」—— 「如果你会写提示词,你就是 Neo」13。这句话的重点不在炫技,而在换了一个分工: 「会不会用 Blender」这种具体技能,正在变成「会不会把需求说清楚」。
当然,这是作者站在 2025 年的热情展望,第 6 节我们会给它降降温。
6. 作者的判断与证据
把书里「有证据的」和「作者个人认为的」分开摆:
有证据的(书内可直接核到):
- SOAP/REST/GraphQL/gRPC 各自的特征(各自的设计特点、各自长什么样)与痛点,是作者的个人经历叙述,但与行业共识一致2345;
- Blender/GitHub/Playwright/Google Maps 的 MCP 服务器存在,作者给了仓库地址1112;
- 「USB-C」这个比方不是作者自创,是 MCP 官方网站的自我描述8。
作者个人的判断(书里没给证据,是主张):
- 「我们太会编程了,所以需要一个标准」——这是一句修辞化的论点, 他没有给任何行业数据(比如「集成成本占开发量几成」)来支撑,靠的是你认同自己的亲身经验6;
- 「知道怎么写提示词,一大堆 MCP 服务器就都是你的」——这是展望,不是承诺。 第 06 章我们自己会写客户端走一遍,到时你能判断这句话打了几折。
判断(我们的,不是书里的): 这一章真正的价值不在历史线(那条线任何一本 API 教材都有), 而在作者把 MCP 定位成「接口自我描述」这条二十年长链的最新一环,而不是「AI 圈凭空的新发明」。 这个定位直接决定了怎么学它:它是工程学,不是玄学。 如果错,会错在: 如果 MCP 最终被证明只是 Anthropic 一家推动的过渡方案、没能成为跨厂商标准, 那「长链最新一环」的说法就拔高了——但到本书写作时,OpenAI、微软、谷歌都已接入,这个风险比作者落笔时又小了一些(这是不在书里的补充,来自通用知识)。
7. 边界与局限
- 这一章没有任何代码,也没有解释协议本身——「消息长什么样」全部留给第 02 章。 急着动手的读者可以直接跳过去,作者自己也这么说;
- 历史线是高度压缩的。比如 REST 的约束、GraphQL 的缓存(把取过的结果暂存起来、下次直接用,省得再查一遍)难题都没展开—— 它服务的只是「为什么需要标准」这一个论点,别拿它当 API 设计教材;
- 「endless possibilities(无限可能)」的说法是 2025 年初的乐观口吻。 现实里,MCP 服务器质量参差、安全模型当时还很弱(第 10 章专门讲安全, 我们协议书架的规范拆解里也有一整章安全红线14),「什么都能接」的另一面是「什么都敢接」的风险;
- 这一章没有回答「为什么是 Anthropic 提出来的协议能成标准」——书里通篇没谈治理与竞争格局。
8. 可带走的
- 判断一个集成方案值不值,先数胶水:应用数 × 能力数。乘积越大,标准化的收益越大;
- 「我能粘起来」不是「我该粘起来」——这是作者全章最值钱的一句话,适用于一切集成决策;
- MCP 是协议(一份约定),不是框架——这决定了它跨语言、跨厂商;我们书架上 TypeScript SDK 的拆解就是它的一种实现15;
- 它管的是「应用怎么向大语言模型提供上下文」,不管模型本身——模型在客户端那边,服务器只提供能力;
- USB-C 这个比方可以用来向非工程师解释 MCP:一个插口,什么设备都能插;
mcp.json是「安装服务器」的全部——这句话到第 07 章会展开成一整章;- 读 MCP 材料时先问一句:**这说的是客户端这一侧还是服务器那一侧?**本书从第 03 章起,这个区分无处不在。
9. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 为什么需要标准化 | Introducing the Model Context Protocol | text/03-fm-introducing-the-model-context-protocol.txt:17(搜「Standardization means that everything looks the same」) |
| SOAP→REST→GraphQL→gRPC | 同上 | text/03-fm-introducing-the-model-context-protocol.txt:55(搜「How we got here」)· :109(搜「N+1 problem is a common performance issue」) |
| 「太会编程」与胶水代价 | 同上 | text/03-fm-introducing-the-model-context-protocol.txt:167(搜「too good at programming」)· :183(搜「wrap anything into a REST API」) |
| 提示词成为新交互、拆开的设想 | 同上 | text/03-fm-introducing-the-model-context-protocol.txt:143(搜「accustomed to using prompts」)· :151(搜「easily consume servers built by others」) |
| mcp.json 与「变得智能体化」 | 同上 | text/03-fm-introducing-the-model-context-protocol.txt:203(搜「client can talk to a number of MCP servers」) |
| MCP 官方定义与 USB-C | 同上 | text/03-fm-introducing-the-model-context-protocol.txt:329(搜「USB-C port for AI applications」) |
| Blender 与 Neo | 同上 | text/03-fm-introducing-the-model-context-protocol.txt:249(搜「Due to Blender's MCP server」)· :265(搜「If you know how to prompt」) |
| 服务器清单 | 同上 | text/03-fm-introducing-the-model-context-protocol.txt:287(搜「modelcontextprotocol/servers」) |