MCP 底层原理深度图解：一次工具调用是怎么走完的，10 张原理图拆到底

关于 MCP你大概率已经听过那句类比它是 AI 世界的 USB-C。类比很好但它只解释了「为什么要有」没解释「它怎么跑」。真到动手那一刻问题全在细节里一条消息长什么样、模型到底能不能自己调工具、Server 和模型之间隔着几层、状态放在哪儿。这篇不讲类比讲机制。10 张原理图从一句话怎么变成一次真实的工具调用开始一层层拆到传输、鉴权和安全边界。规格全部按2026-07-28 现行版——这一版把协议改成了无状态握手和会话都删了按去年教程写的远程 Server 有好几处已经不在规范里。看完你应该能自己画出来也能判断手上那个 Server 该动几刀。这一篇会拆开的十件事全景一句话怎么变成一次真实的工具调用它解决的是一道很土的工程题M×N 变 MN三个角色谁管谁消息层说到底只有三种消息服务端三原语谁按下按钮一次 tools/call 的全链路两根管子stdio 与 Streamable HTTP无状态握手没了状态往哪放头即路由让网关不拆 body安全边界四类风险四道防线▍ 一、全景一句话怎么变成一次真实的工具调用先看这张全景后面九张都是把它某一段放大。你说「把这周的工单导出来」这句话进的是Host——你正在用的那个 AI 应用Claude Desktop、IDE 插件、你自己写的应用。Host 装配上下文交给模型。模型在这里只做一件事决定调哪个工具、传什么参数。它甚至看不见 Server只看得见一份工具清单。剩下的全在模型外面Client 把这次调用发出去有副作用的Host 先让你点头经传输层送到 ServerServer 去碰真实的数据库或工单系统结果原样回填进上下文模型带着新结果再想一轮。模型不执行任何东西——这是理解 MCP 的第一块地基。校验、鉴权、执行、回填每一步都在你的代码和 Host 里。▍ 二、它解决的是一道很土的工程题MCP 不是「又一个 AI 概念」它解的是集成爆炸M 个应用 × N 个工具没有标准就要写 M×N 份专用对接。图上左边 3 个应用配 4 个工具就是 12 份。工具方升级一次接口三个应用各改一遍漏一个就是一处线上问题。右边是有标准之后工具方写一个 Server应用方做一个 Client集成量从 3×4 塌缩成 34。工具升级只改一个地方。这就是它全部价值的根。我自己是这么读它的跟当年 JDBC、ODBC 干的是同一件事——给「应用 ↔ 工具」定一层接口标准。所以别把它当新玩意儿背当成一次接口层设计来读很多细节自然就通了为什么消息要带 id 配对、为什么把传输和消息格式分开、为什么能力要能被发现。▍ 三、三个角色谁管谁三个角色一句话说清各自的边界Host是你用的那个应用管权限、管用户同意、管上下文装配和调模型。Client只管一条连接的收发一个 Client 只连一个 Server。Server只暴露能力——它不认识模型也不知道谁在用它。那个 1:1 不是设计洁癖它是权限边界一条连接出问题炸不到别的 Server要给某个 Server 单独限权、单独审计也有地方下手。反过来看这张图还有一条更重要的信息模型不直接碰 ServerServer 也不认识模型。中间隔着 Host 和 Client 两层才有地方插用户同意和审计。做安全的人应该先看这张图。▍ 四、消息层说到底只有三种消息MCP 没有自创消息格式它建在 JSON-RPC 2.0 上。抓包看到的所有东西都是这三种之一Request有id等回执Response用同一个 id回Notification****没有 id不需要回也不许回。差别就这一件事。看懂 id你就能读懂抓包里的每一行。通知这边有条分界必须记清不然会白等请求级的通知不走订阅那条流。notifications/progress进度和notifications/message日志只在它们所属那个请求自己的响应流上出现而「工具列表变了」「资源更新了」这类广播走的是subscriptions/listen—— 一个普通的 POST响应是一条不关的 SSE 流客户端要显式勾选自己要哪几类。日志还有条反向硬约束值得抄进代码请求没在_meta里带io.modelcontextprotocol/logLevel的服务端 MUST NOT 给它发notifications/message——想要日志就得逐请求要。▍ 五、服务端三原语谁按下按钮Server 能暴露三样东西。它们的分类维度容易被看错——不是按「是什么」分是按「谁按下按钮」分Tools · 模型控制——模型自己决定要不要调tools/list/tools/call。查订单、写文件、发消息都属于这一类。 有副作用的执行前必须让用户点头。Resources · 应用控制——由应用决定塞哪些进上下文resources/list/resources/read。文件内容、数据库记录、日志。只读不该有副作用。Prompts · 用户控制——用户显式选中才用prompts/list/prompts/get。斜杠命令、预置工作流模板。模型不会自己去挑它。**选错原语读者体验就错位**该用户点的做成模型自动调模型就会在不该动的时候动手该模型自动用的做成 Prompts它就永远躺在那儿没人点。▍ 六、一次 tools/call 的全链路这张是全篇密度最高的一张建议点开看。模型说「我要调export_tickets」客户端先自查这个工具在不在清单里——不在就拒绝执行把错误当结果回填回去模型下一轮通常就会改用真实存在的那个。在就 POST 一条 JSON-RPC 消息带上三个必带头第九节讲Server 真的去查库、写文件然后返回结果。关键在返回这一步所有结果现在都必须带resultType。complete正常结果回填进上下文这一轮结束。input_required还差东西Server 在inputRequests里列清楚它要什么客户端去凑齐问用户、取目录、调模型然后带着inputResponses把原来那次调用重发一遍。这叫多轮往返请求MRTR是 2026-07-28 新版的机制以前服务端是反过来向客户端发一个请求那需要一条一直开着的双向流无状态之后那条路没了改成「返回一个还差东西的结果」。这个改动的味道很像 HTTP 的 401 加重试把一次有状态的对话拆成两次自包含的请求。兼容规则也写死了老 Server 的结果里没有resultType字段的客户端 MUST 当成complete。▍ 七、两根管子stdio 与 Streamable HTTP选哪根不由你喜好定由 Server 跑在哪儿定。本地 → stdio客户端把 Server 当子进程拉起来一条消息一行消息内部不能有换行。这里有新手最常见的死法服务端 MUST NOT 往stdout写任何不是 MCP 消息的东西——你随手一句print(debug)客户端解析当场崩。日志一律走stderr而且规范明确写了客户端不该把 stderr 有输出当成出了错。**远程 → Streamable HTTP**单端点每条消息一个 POST响应可以是一条 SSE 流。2026-07-28 起会话、GET 长连、断线重放全没了第八节讲。有个差别特别容易在迁移时漏掉取消这件事两根管子走两条路。stdio 上仍然发notifications/cancelledHTTP 上则是——你把那条响应流关掉本身就是取消信号不用也不该再发通知。规范给的理由很干净每个请求有自己独立的响应流所以「断开」这个动作不存在歧义。▍ 八、无状态握手没了状态往哪放这是理解现行 MCP 最反直觉的一节。前四版协议共享同一个前提连接是有状态的——客户端先发initialize握手协商版本和能力服务端可以回一个Mcp-Session-Id之后每个请求都带着它。2026-07-28把这个前提整个抽掉了。官方给的动因很实在让 Server 能跑在标准的、可水平扩展的基础设施上不必再管理会话或长连接。那版本和能力往哪放跟着每一条请求走——放在params._meta里protocolVersion这条请求用哪版协议、clientCapabilities我支持什么、clientInfo我是谁SHOULD。服务端在每个结果的_meta里回一个serverInfo。想提前知道对面支持什么有个新方法server/discover——服务端 MUST 实现一次拿到支持的版本列表、能力和身份。它在 stdio 上还兼当「这台是新是旧」的探针规范把三种结果写死了回DiscoverResult新版回一个认得出的现代错误也是新版、只是版本不匹配此时不要退回initialize回其他错误或超时不回 老版退回握手。那跨调用的状态怎么办规范的答案是服务端自己铸一个句柄当成普通的工具参数传来传去。差别在责任归属以前状态挂在「连接」上是协议层替你记现在挂在「参数」上是你的业务层自己记。做过后端的人对这个转变应该毫不陌生——这就是把有状态服务改成无状态服务那件事只不过这次改的是协议本身。▍ 九、头即路由让网关不拆 body无状态之后中间层网关、负载均衡、观测系统要按方法或工具名做路由和限流就得不解 JSON body 也能看出来。所以新版把几个 body 字段镜像进了 HTTP 头MCP-Protocol-Version来自_meta的 protocolVersion所有 POST 必带、Mcp-Method来自 body 的 method所有请求必带、Mcp-Name来自params.name或params.uri。服务端还能在工具的inputSchema里用x-mcp-header注解把指定参数镜像成Mcp-Param-{名字}——比如把region提到头上网关就能按区域路由。这里藏着最容易踩的新坑而且性质是安全的头和 body 必须一致body 是唯一真相源。对不上服务端 MUST 回400加 JSON-RPC 错误码-32020HeaderMismatch。规范把理由直接写了出来网关按头路由、而 Server 按 body 执行两边的真相源就分叉了——那正是漏洞的形状。还有条实现细节别漏值不是纯 ASCII 时比如中文资源名MUST 用?base64?编码内容?这个哨兵格式包起来服务端比对前先解码。▍ 十、安全边界四类风险四道防线MCP 让工具接入变简单了也把「你装了什么」这件事变成了攻击面。四类风险工具投毒工具描述里藏指令骗模型去做别的事、Rug Pull装的时候是好的之后偷偷换掉行为、混淆代理借你的身份去调它自己够不着的东西、Token 泄露凭证存在 Server 侧被顺走就是全权。四道防线在图上一一对着挡只装可信 Server、Host 把关 用户同意、OAuth 2.1 做远程授权、凭证按签发方绑定。2026-07-28在授权侧又收紧了三条共同点是把「这个凭证到底是谁发的」钉死iss参数 MUST 校验RFC 9207、动态注册必须声明application_type、换了授权服务端就得重新注册不许拿旧凭证接着用。顺带记住这一版的弃用清单Roots、Sampling、Logging加上旧的 HTTPSSE 传输和动态客户端注册DCR——还能用但新项目别再上。比清单更值得记的是这次立的治理规矩弃用窗口至少十二个月并且维护一张公开的已弃用特性登记表。改版不再是突然袭击你可以按季度排迁移而不是被动救火。回到这四类风险的共同点模型看到的是「描述」而描述是 Server 说了算的。所以接一个 MCP Server等于把它的工具描述接进了模型的决策链——这件事值得像加一个依赖一样审。如果只带走一句MCP 定的不是「AI 怎么变聪明」是**「应用和工具之间那层接口长什么样」**。看懂了这一层你会发现它每一个设计——三角色、三原语、id 配对、无状态——都不是为 AI 发明的新东西而是后端十几年里已经吵明白过的老问题。你要是也在接 MCP把这篇转给那个还停在「它是 AI 的 USB-C」那句类比上的人——类比让人点头图才让人动手。持续把 AI 落地里这些绕不过的底层机制一个一个拆成图。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】