在 MCP(Model Context Protocol)出现前,每个 AI 应用要接 M 个工具、每个工具要适配 N 个应用,行业在做一道 N×M 的积分题。MCP 把它变成 N+M:应用实现一次 Client,工具实现一次 Server,中间是标准协议——**这就是"AI 界的 USB"**这个比喻的由来。

三层架构

  flowchart LR
    subgraph Host [Host 应用:如 Claude / IDE]
        A1[MCP Client] --- A2[MCP Client]
    end
    A1 --stdio / HTTP--- S1[MCP Server<br/>文件系统]
    A2 --stdio / HTTP--- S2[MCP Server<br/>数据库 / API]
    S1 --> R1[(本地资源)]
    S2 --> R2[(远程服务)]
  • Host:承载模型的终端应用(Claude Desktop、IDE、自研 Agent)
  • Client:Host 内部的协议端点,与 Server 一一对应,负责消息路由
  • Server:能力的提供方,暴露三类原语——tools(可调用的函数)、resources(可读取的数据)、prompts(可复用的提示模板)

关键理解:Client-Server 是 Host 内部的连接,不是用户到云端。一个 Host 可以同时挂任意多个 Server,模型看到的是它们能力的并集。

协议要点

JSON-RPC 2.0 消息。三种消息类型:请求(期待响应)、通知(单向)、响应。工具调用 = Host 把用户意图发给模型 → 模型返回 tool_use → Client 转发给对应 Server → 结果回填对话 → 模型继续推理。循环的主导权在模型侧,这是 Agent 自主性的来源。

能力协商。初始化握手时双方交换能力清单(client 支持 sampling、server 提供 tools),后续消息不得超出协商范围——版本演进时不至于硬崩。

传输两层:本地 stdio(子进程,零网络开销,适合本地工具)与远程 Streamable HTTP(带会话管理,适合共享服务)。选型原则:数据不出本机用 stdio,团队共享的内部服务用 HTTP。

工程视角的三个提醒

  1. 安全边界在 Host:Server 只是能力声明,要不要调用、结果可不可信,审查责任在 Host 侧的权限设计(参考 Claude Code 的权限分级)
  2. Server 不是越全能越好:一个 Server 暴露 50 个工具,模型的选择准确率会下降——工具越多,描述质量要求越高(这是上下文预算问题,见本博客上下文工程板块)
  3. 诊断从握手开始:MCP 连不通,先看 initialize 能力交换是否成功,再看具体消息——协议分层清晰是它最好调试的地方

MCP 的价值不在技术创新,在生态收敛:就像 USB 之后外设爆发,标准化接入层之后,工具生态的边际成本趋近于零。判断一个 Agent 产品的工程成熟度,看它怎么管理 MCP Server 的权限与生命周期,是个不错的捷径。