M+N干掉M×N：解码MCP协议内核

导语：为什么每一个 AI 应用都该懂 MCP

如果你在过去一年写过任何 AI 应用，你大概率踩过同一个坑：让大模型连一下数据库、读一下 GitHub、查一下公司内部知识库。听起来简单，实际上是一场灾难——每接一个新工具，你就要为 Claude、GPT、Gemini 各写一遍适配代码；每换一个模型，原本能用的工具又得重新接线。这是 M × N 的组合爆炸：M 个模型乘以 N 个工具，等于 M×N 条脆弱的定制胶水代码。

2024 年 11 月，Anthropic 开源了一个叫 MCP（Model Context Protocol，模型上下文协议） 的东西，目标只有一个：把这堵 M×N 的墙拆成 M+N——每个模型实现一个客户端，每个工具实现一个服务端，中间用一套标准协议说话。它被叫做"AI 界的 USB-C"。Tina Huang 这支 26 分钟的视频，是中文圈/英文圈少有的把 MCP 从"是什么"讲到"协议长什么样"的完整入门，正好可以作为我们解剖这个协议内核的切入点。本文不再搬运视频，而是顺着它打开的那扇门，把 MCP 的接线内核一层层剥开给你看。

视频背景卡片

核心内容拆解

一、M×N 地狱：MCP 要解决的真问题

理解 MCP，先要理解它要消灭的敌人。视频一开始就点明了那张经典的 M×N 矩阵图：横轴是各家 AI 应用（Claude Desktop、Cursor、ChatGPT、自研 Agent），纵轴是各路数据源和工具（GitHub、Slack、Postgres、Notion、本地文件系统）。没有标准时，要让 N 个工具对 M 个应用可用，你需要 M × N 条互不兼容的私有集成。每一条都是手搓的认证、手搓的 schema、手搓的错误处理，任何一边升级都可能让另一边崩掉。

这个问题的解法在软件行业其实早有范本——LSP（Language Server Protocol）。在 LSP 出现前，编辑器（VS Code、Vim、Sublime）和语言（Python、Go、Rust）也是 M×N 的死结；微软在 2016 年开源 LSP 后，它被一刀切成 M+N：每个编辑器实现一个 LSP 客户端，每种语言实现一个 LSP 服务端，中间用 JSON-RPC 通信。今天你能在任何编辑器里获得任何语言的智能补全，就是因为这套协议。MCP 就是 LSP 的"AI 复刻版"，连核心抽象都几乎照搬——这也是为什么 Tina 在视频里反复强调"它不像一个新发明，更像一个早就该有的标准"。（以上 M×N→M+N 框架为视频核心论点与公开资料的共识；LSP 类比部分为延伸分析。）

二、JSON-RPC 2.0：藏在协议底层的通用语

MCP 的连线层（wire layer）选的是 JSON-RPC 2.0——一个 2013 年的轻量级远程调用规范。这个选择看似平庸，实则精明。JSON-RPC 2.0 只有三种消息：请求（带 id，期望回复）、响应（带对应 id，含 result 或 error）、通知（不带 id，单向、无需回复）。它的关键特性是双向对称：客户端能给服务端发请求，服务端也能反过来给客户端发请求。

这条对称性是 MCP 区别于普通"函数调用 SDK"的根本。普通 SDK 里，工具永远是被动的——模型喊一句"执行 query_db"，工具就执行。但 MCP 里，服务端可以主动向客户端发起 sampling（采样）请求，意思是"借你宿主的大模型用一下，帮我补全一段文本"。这让一个 MCP 服务端可以自身成为一个微型 Agent，而不只是被调用的工具集。此外，JSON-RPC 的通知机制天然支持流式进度上报、取消（cancellation）、心跳，省掉了另起一套传输层协议的麻烦。（JSON-RPC 2.0 三类消息为规范事实；"双向对称支撑 sampling"为基于规范机制的延伸解读。）

三、Host / Client / Server：三角色架构

MCP 的架构里有三个角色，新手最容易把 Client 和 Host 搞混。Host（宿主） 是用户真正接触的 AI 应用，比如 Claude Desktop、Cursor、Cline——它负责管理连接、控制权限、向用户征求同意（consent）。Client（客户端） 是 Host 内部的一个连接器，它与一个且仅一个 Server 维持 1:1 的会话。Server（服务端） 是轻量级程序，负责把某个工具或数据源的能力暴露出来。

一个 Host 可以同时跑很多个 Client（比如 Claude Desktop 同时连了 GitHub Server、文件系统 Server、数据库 Server），但每个 Client 只盯一个 Server。这种"一对 Host 内嵌多个 1:1 Client"的设计，是为了隔离故障与权限——一个 Server 崩了不会拖垮别的 Server，一个 Server 拿不到越权数据。这跟 LSP 里"一个编辑器开多个 language server 进程"是同一个思路。视频用一个清楚的图把这三个角色画了出来，并强调了一个常被忽略的点：真正持有 API key、决定模型能不能调用某个工具的，是 Host，而不是 Server。Server 只是"申报能力"，能不能用、要不要弹窗问用户，权力在 Host 手里。（三角色定义为规范事实；权限归属 Host 的强调为结合安全模型的延伸分析。）

四、三大原语：Tools、Resources、Prompts

这是 MCP 最值得记住的设计，也是视频花最多笔墨的部分。MCP 用三类原语（primitives） 把"AI 能从服务端拿什么"分成了三档，对应三种不同的控制权归属：

• Tools（工具）：模型控制（model-controlled）。这是最像 function calling 的部分——LLM 自己决定要不要调用、传什么参数，比如 send_email、query_database、create_issue。它通常是会产生副作用的动作。
• Resources（资源）：应用控制（application-controlled）。这是数据，用 URI 标识，比如 file:///report.pdf、postgres://users/schema。由应用（或用户）决定把哪些资源塞进上下文，模型不能擅自拉取。
• Prompts（提示词模板）：用户控制（user-controlled）。这是预置的工作流模板，用户从一个菜单里主动挑选，比如"总结这个 PR"或"按公司规范生成 commit message"。

这条"控制权光谱"是 MCP 比 OpenAI function calling 高明的地方。function calling 只有一档（全是模型决定的 tools），结果就是模型动不动就乱发邮件、乱删数据。MCP 用三档把谁能拍板这件事结构化了：动作给模型，数据给应用，流程给用户。（三原语及其控制权归属为规范定义；"控制权光谱优于纯 function calling"为延伸评价。）

五、能力协商握手：初始化那 0.1 秒里发生了什么

Client 和 Server 建立连接后，第一件事不是干活，而是握手。Client 发一个 initialize 请求，里面带上自己支持的协议版本和能力清单（capabilities）：比如"我支持 roots、支持 sampling、支持 elicitation"。Server 回一个 InitializeResult，声明自己有哪些能力：比如"我有 tools、有 resources、有 prompts，以及一个 logging 服务"。

这个握手直接复刻了 LSP 的 initialize 流程，目的是版本协商 + 能力发现。协议版本（目前如 2025-06-18、2025-11-25）如果不匹配，握手就会失败或降级，避免一边用了新特性另一边听不懂。握手成功后才进入"已初始化"状态，之后才能 tools/list、resources/list、prompts/list 去动态发现服务端到底提供什么。这种"先谈条件再开工"的设计，让协议可以平滑演进——新加一个特性，老服务端不认也没事，只要不声称支持就不会被调用。（initialize 握手与版本协商为规范机制；平滑演进的解读为延伸分析。）

六、传输层：stdio 与 Streamable HTTP 的分工

MCP 把"协议说了什么"和"协议怎么传"解耦了。目前主流两种传输方式：

• stdio（标准输入输出）：Host 把 Server 当一个本地子进程启动，靠子进程的 stdin/stdout 收发 JSON-RPC 消息。零配置、零网络、天然安全（数据不出本机），是绝大多数本地工具（文件系统、Git）的默认选择。
• Streamable HTTP：这是 2025-03-26 规范引入的远程传输，用单个 HTTP 端点完成双向通信——客户端 POST 请求，服务端可以选择普通 JSON 响应，也可以用 SSE（Server-Sent Events）流式推送多条消息。配合 OAuth 2.1 + PKCE 做认证，让 Server 可以托管在云端。

为什么不用老的 HTTP+SSE？因为老方案需要开两个连接（一个 POST 上行、一个 SSE 下行），状态同步极其别扭。Streamable HTTP 把它压成一个端点，服务端按需"升级"成流式，简单得多。这一改动直接引爆了远程 MCP 生态——从 2025 下半年起，托管型 MCP Server 数量飙升，这也是为什么 2026 年市场上已有上万（公开资料提到向 18,000 量级逼近）个 MCP Server。（传输机制为规范事实；SSE 双连接痛点与生态规模为结合规范演进史与公开数据的延伸分析。）

七、sampling、roots、elicitation：被低估的三个反直觉能力

这三个能力是视频一笔带过、但理解了会让你对 MCP 彻底改观的部分：

• Sampling（采样）：服务端反向请求客户端的 LLM。也就是说，一个工具可以"借用"宿主的大脑来完成自己的子任务。这是 MCP 真正实现"双向对称"的地方，也是安全上最敏感的——所以规范要求所有 sampling 请求默认要经过人类确认（human-in-the-loop）。
• Roots（根）：客户端告诉服务端"你只能碰这几个目录/这几个项目"，画出明确的文件系统边界。这是给本地 Server 套上的沙箱。
• Elicitation（征询）：2025-06-18 规范新增，允许服务端通过客户端 UI 向用户要输入——比如工具缺一个参数，直接弹窗问用户，而不是瞎猜。

这三个能力合在一起，把 MCP 从"函数调用协议"升级成了"Agent 间协作协议"。一个 Server 不再只是被动工具，它可以借模型（sampling）、可以受限访问资源（roots）、可以和人对话（elicitation）。这也是为什么有人开始把 MCP 称为"Agent 的毛细血管"。（三个能力为规范定义；"升级为 Agent 间协作协议"为延伸评价。）

八、生态抢跑：为什么 OpenAI、Google 全都上车

到 2026 年，MCP 已经不是一个 Anthropic 私有标准，而是事实标准。OpenAI 在 ChatGPT、Agents SDK 里原生支持了 MCP；Google 把它接进了 Gemini 生态；Microsoft、Cursor、Sourcegraph、Replit、Cline 一众玩家全部跟进。一个 2024 年底才开源的协议，18 个月内完成行业级统一——速度堪比当年的 USB-C。

这背后的经济学是网络效应：服务端越多，每个客户端越有价值；客户端越多，越值得为每个工具建服务端。Anthropic 的策略很聪明——它没有把 MCP 锁死在自己手里，而是推动标准化、开放生态，自己则靠"最早、最完整的客户端实现（Claude Desktop / Claude Code）"拿到先发优势。这跟当年微软推 LSP 是一个剧本：赢协议层的人，比赢某个具体产品的人吃得更久。对开发者来说，结论很现实：现在学 MCP，等于在押注这个时代的"HTTP"。（行业采纳情况为公开资料；网络效应与策略分析为延伸判断。）

知识结构图

flowchart TB
    subgraph Host["🖥️ Host 宿主 (Claude Desktop / Cursor)"]
        Client["MCP Client 连接器<br/>1:1 会话 · 权限控制"]
        LLM["大模型 / 用户"]
    end

    subgraph Wire["📡 连线层 = JSON-RPC 2.0"]
        Dir["请求 · 响应 · 通知<br/>双向对称"]
        Shake["initialize 握手<br/>版本 + 能力协商"]
    end

    subgraph Trans["🚚 传输层"]
        Stdio["stdio 本地子进程<br/>零网络 · 安全"]
        HTTP["Streamable HTTP<br/>2025-03-26 + OAuth 2.1"]
    end

    subgraph Server["⚙️ MCP Server 服务端"]
        Prim["三大原语"]
        Prim -->|模型控制| Tools["Tools 工具<br/>send_email / query_db"]
        Prim -->|应用控制| Res["Resources 资源<br/>file:// / postgres://"]
        Prim -->|用户控制| Prompts["Prompts 模板<br/>工作流菜单"]
        Extra["反向能力"]
        Extra --> Samp["Sampling 借模型"]
        Extra --> Root["Roots 沙箱边界"]
        Extra --> Elic["Elicitation 问用户"]
    end

    Host --> Wire
    Wire --> Trans
    Trans --> Server
    Client -->|"tools/call<br/>resources/read"| Server
    Server -.->|"sampling<br/>elicitation"| Client

    classDef host fill:#e8f4f8,stroke:#2b7a9e,stroke-width:2px;
    classDef wire fill:#fff4e6,stroke:#d97706,stroke-width:2px;
    classDef trans fill:#f0fdf4,stroke:#16a34a,stroke-width:2px;
    classDef server fill:#fef2f2,stroke:#dc2626,stroke-width:2px;
    class Host host;
    class Wire wire;
    class Trans trans;
    class Server server;

实战启示：你该怎么用 MCP

如果你是应用/Agent 开发者，第一件事不是写 Server，而是先用现成客户端（Claude Desktop、Cursor、Cline）跑通几个官方 Server，比如 filesystem、github、fetch。亲手配一次 claude_desktop_config.json，观察 initialize 握手和 tools/list 的实际报文（开 debug 日志就能看到原生 JSON-RPC），你会比看十篇文章都懂得快。

如果你在为企业/团队造内部工具，优先把你们最高频的内部系统（工单、知识库、CRM）包成一个 MCP Server。这是性价比最高的一步——包一次，所有支持 MCP 的客户端都能用，未来换模型/换 IDE 不用重接。注意三件事：把查询类做成 Tools，把只读数据做成 Resources，把标准 SOP做成 Prompts；远程部署务必上 OAuth 2.1 + PKCE；本地工具优先用 stdio，避免无谓的网络暴露。

对学习者最大的认知升级：别再把"AI 接工具"理解成 function calling 那种单车道。MCP 教给你的是控制权的分层——动作归模型、数据归应用、流程归用户。这套思想哪怕你一行 MCP 代码不写，也能直接搬到你设计任何 Agent 时的权限模型上。Tina 这支视频最大的价值，正是把这套抽象用一个可上手的小例子讲透了：它没把你淹在规范里，而是让你先建立"Host-Client-Server + 三原语"的骨架，剩下的细节你自然知道去哪查。

一个现实提醒：MCP 还在快速演进，spec 半年一更（2025-03-26、2025-06-18、2025-11-25），不少早期教程已经过时（尤其传输层，老的 HTTP+SSE 例子现在基本作废）。学的时候一定要对着 modelcontextprotocol.io 的最新规范核对，别拿半年前的博客当真理。

延伸学习路径

1. 官方规范与 SDK — modelcontextprotocol.io：协议的源头真相，Python/TypeScript/Java/Go SDK 全在这。
2. dev.to 完整指南 — Complete Guide to MCP in 2026：架构与企业落地路线图，适合想搞清楚选型的人。
3. LSP 对照阅读 — microsoft/language-server-protocol：读懂 LSP，你等于读懂了 MCP 一半的设计基因。
4. OAuth 2.1 + PKCE 实战 — MCP OAuth 2.1 Guide：远程 Server 的认证细节，部署云端的必读。
5. Awesome MCP Servers — GitHub 上的社区 Server 清单，挑几个跟你工作相关的本地跑通，比读文档快十倍。

一句话总结

MCP 用 JSON-RPC 把"AI 接工具"从 M×N 的手搓地狱压成 M+N 的标准协议，靠"Host-Client-Server + Tools/Resources/Prompts 三原语"把控制权结构化——这是 AI 时代的 USB-C，也是你绕不开的下一层基础设施。

参考来源

1. MCP In 26 Minutes (Model Context Protocol) — Tina Huang — 本文分析的核心视频
2. Introducing the Model Context Protocol — Anthropic 官方公告 — 协议诞生背景与设计意图
3. MCP Specification 2025-03-26 — 传输层与 OAuth 规范事实来源
4. Complete Guide to MCP in 2026 — dev.to — 架构与企业落地详解
5. MCP 2025-11-25 Deep Dive: Streamable HTTP, Async Tasks — 最新规范演进与生态规模数据

   本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

完成摘要

2. 下一步计划（What's next） - Round 3 对应 business（商业与创业） 分类，建议届时优先选 2026 年新出现的商业模式案例 - 若需要更精确的视频播放量数据，可改用浏览器自动化（web-access skill）抓取 YouTube 页面 - 当前 MCP 主题可在未来用于延伸：MCP Server 实战搭建、MCP 安全攻击面分析

3. 注意事项 - 视频播放量字段使用保守的"10万+"（Tina Huang 视频合理下限），未编造精确数字；如需精确值建议实抓 - 规范版本号（2025-03-26 / 2025-06-18 / 2025-11-25）均来自公开资料交叉验证 - 文章已严格遵守：无对话性前置语、首四行注释格式正确、含 Mermaid、3000 字以上、未触碰敏感话题

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。