MCP 的架构是怎样的？Host、Client、Server 分别是什么？

详细解析#

三个角色#

Host（IDE、桌面 AI 客户端、自研 Agent）
 │ 管理对话、调用大模型、权限确认、汇总各 Server 的能力
 ├─ Client A ── stdio ─────────── Server：本地文件系统
 ├─ Client B ── stdio ─────────── Server：本地 Git
 └─ Client C ── Streamable HTTP ── Server：远程工单系统 → 工单系统 API

规范里有一条关键的设计原则：Server 看不到完整的对话，也看不到其他 Server。对话历史留在 Host，Server 只收到完成请求所需的信息，跨 Server 的协作由 Host 控制。这样来源不同、可信度不同的 Server 被互相隔离。另外，MCP 只规定上下文和能力怎么交换，不规定 AI 应用怎么使用大模型。基础概念见 MCP 是什么。

数据层和传输层#

• 数据层：基于 JSON-RPC 2.0，定义消息结构和语义。消息分三种：请求（带 id，要求响应）、响应（结果或错误）、通知（不带 id，不需要响应）。各种能力对应具体的方法，如 tools/list、tools/call
• 传输层：负责建立连接、消息分帧和认证，同一套 JSON-RPC 消息可以跑在不同的传输方式上

stdio 模式下 Server 的 stdout 只能输出协议消息，日志要写到 stderr，见 怎么开发一个 MCP Server。远程传输早期用的是 HTTP + SSE（两个端点加一条长连接），已被 Streamable HTTP 取代并标记为弃用。

版本和能力协商#

双方要对齐两件事：用哪个协议版本；各自支持哪些能力，比如 Server 是否提供工具、工具列表变化时会不会通知，Client 是否支持向用户索取信息。

2025-11-25 及更早的版本：连接建立后先握手，握手完成前一般不发送其他请求。

Client → Server  initialize（客户端支持的协议版本、clientInfo、客户端能力）
Server → Client  响应（选定的协议版本、serverInfo、服务端能力）
Client → Server  notifications/initialized
之后才开始 tools/list、tools/call 等正常请求

2026-07-28 版规范：取消了握手和协议层的会话，协议变成无状态的。

• 每个请求在 _meta 里携带协议版本和客户端能力（Streamable HTTP 下还要在 MCP-Protocol-Version 请求头里带上同一个版本号），Server 独立处理每个请求，不依赖之前的请求
• Server 必须实现 server/discover，Client 可以先调用它，一次拿到 Server 支持的版本、能力和身份信息
• 版本不支持时，Server 返回 UnsupportedProtocolVersionError 并列出支持的版本，Client 换一个版本重试
• 需要跨请求保存的状态（如购物车），由 Server 生成一个显式的句柄，作为普通的工具参数在后续调用中传入

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "search_tickets",
    "arguments": { "keyword": "退款" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "my-ide", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

无状态的好处是远程 Server 更容易水平扩展：任何一个实例都能处理任何请求，不需要粘性会话，也不需要在实例之间共享会话数据。

面试官可能追问#

易错点#

• 把 Client 理解成"用户用的客户端软件"。用户用的是 Host，Client 是 Host 内部和某个 Server 一对一连接的组件
• 认为 MCP Server 都在远程。本地 stdio 是很常见的用法，这时 Server 以用户的权限运行在本机上
• 认为只有 Client 能发起交互。Server 可以发通知，也能在处理请求时要求 Client 补充用户输入，见 MCP 的 Tools、Resources 和 Prompts 有什么区别