一文讲透MCP背后的原理：AI时代的

显示全部楼层

写在前面

还记得以前写代码调接口有多痛苦吗？

现在AI时代来了，想让大模型帮你干活、连接各种工具，调接口这件事反而变得更重要了。

好消息是，有一个叫MCP的东西横空出世，它就像给AI世界定了一套"普通话"，让所有工具都能跟AI顺畅沟通。

第一章：MCP到底是个啥？

先来个灵魂拷问

MCP究竟是什么玩意儿？

简单说，MCP全称是Model Context Protocol，翻译过来就是"模型上下文协议"。

它干的事情就一句话：规定AI客户端和数据服务之间怎么"说话"。

打个比方，你家的智能音箱想控制空调、电视、窗帘，每个设备都有自己的遥控器，乱七八糟的。MCP就像制定了一个统一的"万能遥控器协议"，只要设备厂商按这个协议来做，智能音箱就能一把梭哈全搞定。

💡划重点：MCP的本质就是让AI助手和各种工具之间有了"共同语言"，工具开发者和AI开发者从此各干各的，互不打扰。

三个角色，一台戏

MCP的世界里有三个主角：

角色	职责	生活中的类比
MCP Client	发请求、收结果	你手里的手机
MCP Server	处理请求、返回数据	餐厅后厨
MCP Host	调度全局、串联流程	餐厅的服务员

整个流程就像点外卖：

你（Host）打开美团想吃炒饭

手机（Client）把订单发给餐厅

后厨（Server）做好菜、打包送出

跟传统的function call有啥区别？

有人会问：大模型不是早就有function call了吗？MCP有啥不一样？

区别可大了！

以前的function call，每个AI平台都有自己的一套玩法。你给A平台写的工具，到B平台就废了，得重新来一遍。

MCP的出现就像Type-C充电口一样——以前安卓用Micro USB，苹果用Lightning，现在统一用Type-C，一根线走天下。

同样的道理，有了MCP：

你只需要把工具封装成MCP Server

任何支持MCP的AI平台都能直接调用

再也不用为每个平台单独适配

🎯核心价值：工具开发和AI开发彻底解耦，一次开发、处处可用。

第二章：MCP底层用了哪些技术？

别慌，虽然听起来高大上，但MCP底层其实就用了两个你可能已经听过的技术。

技术一：SSE——服务器"主动推消息"的神器

SSE全称是Server-Sent Events，翻译过来就是"服务器发送事件"。

传统的HTTP请求是"你问我答"模式——客户端发请求，服务器返回结果，完事儿。

但SSE不一样，它建立的是一条长连接，服务器可以源源不断地往客户端推数据，就像开了一条水管，水一直流。

这有什么用呢？

想象一下ChatGPT打字的效果，回答是一个字一个字蹦出来的对吧？这就是SSE在起作用——服务器边生成边推送，而不是等全部生成完再一次性返回。

SSE的格式超级简单，就4个字段：

字段	作用
`data`	真正的数据内容
`id`	消息编号，断线重连时用得上
`event`	事件类型，方便前端区分处理
`retry`	断线后多久重新连接（毫秒）

HTTP头部设置：

Content-Type: text/event-stream

Cache-Control: no-cache

Connection: keep-alive

消息体格式：

field: value\n\n

每条消息以两个换行符结束，就这么简单。

🔧在MCP里：SSE负责Server到Client的单向数据推送，解决"怎么传"的问题。

技术二：JSON-RPC 2.0——消息格式的"普通话"

如果说SSE解决了"怎么传"，那JSON-RPC 2.0就解决了"传什么"。

它规定了Client和Server之间消息必须长什么样，就像写信要有固定格式一样——开头写称呼、中间写正文、结尾写署名。

JSON-RPC的消息骨架，只需要记住4个字段：

字段	是否必填	类型	作用
`jsonrpc`	✅	固定值"2.0"	协议版本号
`method`	✅	string	你想调用的方法名
`params`	❌	object/array	传给方法的参数
`id`	❌	string/number/null	请求编号，无id视为通知，不期待回复

响应时，要么返回result（成功），要么返回error（失败），二选一。

请求长这样：

{"jsonrpc":"2.0","method":"get_weather","params":{"city":"北京"},"id":1}响应长这样（成功时）：{"jsonrpc":"2.0","result":{"temp":"26℃","weather":"晴"},"id":1}响应长这样（失败时）：{"jsonrpc":"2.0","error":{"code":-1,"message":"城市不存在"},"id":1}

💬一句话总结：在MCP里，Client和Server永远只交换这种"四字段"消息，简单统一，谁都看得懂。

第三章：MCP协议是怎么工作的？

有了SSE和JSON-RPC这两块砖，MCP就可以盖房子了。

MCP协议本身定义了三件事：

Client和Server怎么建立连接

连上之后怎么交换信息

聊完了怎么断开连接

📌一句话结论：MCP就是"客户端先拉一条SSE长连接收通知，再用HTTP POST发请求到服务端；双方必须先发initialize打招呼，才能调工具，最后关SSE就通信结束了"。

双通道：一条用来听，一条用来说

MCP设计了两条通道：

通道	作用	通道类型	方向
SSE通道 (`GET /sse`)	服务器→客户端推送事件	Server-Sent Events	单向
HTTP POST通道	客户端→服务器发起调用	HTTP	双向请求-响应

为什么要两条？因为SSE只能单向传输（服务器→客户端），客户端想说话还得靠传统的HTTP POST。

服务器启动时必须同时暴露这两个端点，缺一不可。

五步走：从连接到断开

整个MCP通信流程可以概括为**"连、取、握、用、断"**五个步骤：

1️⃣ 连

客户端发送GET /sse请求，跟服务器建立SSE长连接，为后续接收数据做准备。

2️⃣ 取

服务器通过SSE推送一条event: endpoint消息，告诉客户端："后面要发请求，往这个地址发"（POST端点的URL）。

3️⃣ 握

客户端向该URL发送initialize请求，双方交换各自的"能力清单"（我支持什么功能、你支持什么功能），类似于见面握手交换名片。

服务器返回同样id的响应，宣告双方能力，即可进入正式会话。

4️⃣ 用

握手完成，开始正式干活：

调用tools/list（可选）查看有哪些工具可用

调用tools/call执行具体工具

服务器随时通过SSE流里推送状态更新

5️⃣ 断

任务完成，任意一方关闭SSE连接，会话结束。

服务器收到后，会返回自己的能力清单（id相同），双方对上眼了，就可以愉快地合作了。