垦荒学园
  • 中文

      • 架构与角色

      本章说明 MCP 的参与者、本地 / 远程部署，以及数据层与传输层如何叠在一起。细节以官方 Architecture overview 为准。

      三个参与者

      MCP 是 客户端—服务器 架构。一个 Host（宿主） 是用户面对的 AI 应用；它为 每一个 Server 创建 一个 Client。Client 与对应 Server 保持专用连接，并把上下文交给 Host 使用。

      角色是什么例子
      Host协调多个 Client 的 AI 应用Claude Code、Cursor、VS Code、ChatGPT、Codex
      ClientHost 内部、一对一连一台 Server 的组件VS Code 为 Sentry MCP 实例化的那个连接对象
      Server向外提供上下文的程序本地 filesystem、远程 Sentry / GitHub

      「Server」指 提供上下文的程序，与它跑在本机还是云端无关。

      graph TB
    subgraph "MCP Host（AI 应用）"
        Client1["MCP Client 1"]
        Client2["MCP Client 2"]
        Client3["MCP Client 3"]
        Client4["MCP Client 4"]
    end

    ServerA["Server A · 本地<br/>例如 Filesystem"]
    ServerB["Server B · 本地<br/>例如数据库"]
    ServerC["Server C · 远程<br/>例如 Sentry"]

    Client1 ---|"专用连接"| ServerA
    Client2 ---|"专用连接"| ServerB
    Client3 ---|"专用连接"| ServerC
    Client4 ---|"专用连接"| ServerC

      同一台远程 Server 可以被多个 Client（甚至多个 Host）同时访问；本地 Stdio Server 通常只服务启动它的那一个 Client。

      本地 vs 远程

      本地 Server远程 Server
      典型传输StdioStreamable HTTP
      进程Host 拉起子进程，走标准输入 / 输出独立 HTTP 服务，常在云端
      客户端数量通常 1 个通常很多个
      网络无网络开销走 HTTP，建议 OAuth 拿令牌
      例子官方 filesystem、你自己的 server.py厂商托管的文档 / 工单 MCP

      Claude Desktop 启动 filesystem 时，Server 与 Host 在同一台机器上，这就是常说的 本地 MCP。官方 Sentry Server 跑在 Sentry 平台上，用 Streamable HTTP，这就是 远程 MCP。

      选型很简单：能力必须碰本机磁盘或内网、且只有你自己用 → Stdio；能力要给团队或公网 Host 共享 → Streamable HTTP。

      两层结构

      MCP 分两层。概念上 数据层在内、传输层在外：

      ┌──────────────────────────────────────────┐
│  传输层：Stdio / Streamable HTTP /（遗留 SSE）│
│  建连、帧、鉴权、取消                       │
├──────────────────────────────────────────┤
│  数据层：JSON-RPC 2.0                      │
│  发现、Tools / Resources / Prompts、通知     │
└──────────────────────────────────────────┘

      数据层 规定消息长什么样、语义是什么：

      • 发现：server/discover 查询对方支持的协议版本、能力与身份
      • Server 能力：Tools（动作）、Resources（数据）、Prompts（模板）
      • Client 能力：向用户要补充信息（elicitation）。Sampling 自 2026-07-28 起弃用
      • 实用能力：进度、取消、可选的订阅通知

      传输层 只负责字节怎么走。同一套 JSON-RPC 消息可以跑在 Stdio 或 HTTP 上，见 传输层。

      无状态与发现

      现行规范把协议核心做成 无状态：每个请求在 _meta 里携带协议版本、客户端身份与能力，服务器可以单独处理这一条。需要「先摸清对方」时发送 server/discover；它 不是 每个调用的前置必选，但每个 Server 都必须实现。

      这对运维的意义：远程 Server 可以放在普通轮询负载均衡后面，不必再为 Mcp-Session-Id 做粘性会话。若业务仍要跨调用记住状态，应在 Tool 返回值里给出 显式句柄，让模型下次当作参数传回来——比把状态藏在传输层更清晰。

      旧版客户端仍可能走 initialize 握手。官方 SDK 会按连接协商时代；你写新 Server 时按现行 API 即可。

      Host 内部发生了什么？

      1. 用户在 Host 里配置若干 Server（命令行或 URL）
      2. Host 为每个 Server 建一个 Client
      3. Client 发现 Tools / Resources / Prompts，登记到 Host 的工具表
      4. 模型决定调用某个 Tool 时，Host 走对应 Client 发 tools/call
      5. 结果回到对话上下文；用户应能在 UI 里看到并 审批 危险调用

      MCP 不管 第 4 步里模型怎么选工具。那是 Host 的 Agent 循环。

      下一步

      评论