MCP 架构图：Host、Client、Server 与传输方式

你的编码智能体会读取代码仓库、检查构建，并在问题跟踪器里提交 issue。这类架构的典型示意图，只在模型和工具之间画一个标着「MCP」的方框。然后安全评审者会问：哪个进程能读取你的主目录，哪个令牌能访问跟踪器，创建 issue 的那次调用是谁批准的。这个方框回答不了。

Model Context Protocol（MCP）有一套明确的架构，而它的 2026-07-28 修订版改变了其中一部分。本文介绍参与方、协议分层、传输方式、功能、一次工具调用、远程授权和信任边界，并附有一张可以直接复制的图。

Host、Client 与 Server

在 MCP 出现之前，每个 AI 应用都要为每个工具单独写适配器：5 个应用加 20 个工具，最多需要 100 个集成。有了 MCP，25 个实现（每个应用一个 Client，每个工具一个 Server）就能覆盖所有组合。

Host 为每个 Server 创建一个 Client，每个 Client 只与一个 Server 通信。模型从不自己调用 Server：它请求一次工具调用，由 Host 决定是否执行，以及由哪个 Client 发送。Server 之间保持隔离：它们不应看到完整的对话，也不应看到彼此。

两层结构，以及 2026-07-28 的变化

数据层是 JSON-RPC 2.0：请求（id 绝不为 null）、结果、错误和单向通知。传输层负责搬运这些消息，并处理分帧、取消和授权。

2026 年 7 月 28 日发布的 2026-07-28 规范让 MCP 变成了无状态。早期修订版在每个连接开头进行 initialize 握手，以确定版本和能力，HTTP Server 还可以用 Mcp-Session-Id 固定一个会话。现在每个请求都在 _meta 中携带协议版本和 Client 能力，因此它可以落到普通轮询负载均衡器后面的任何 Server 实例上。

基于旧版 SDK 构建的 Server 仍然期待握手，因此兼容两个时代的 Client 会先探测，再回退到 initialize。只支持 2026-07-28 的 Client 无法使用仅支持旧版的 Server。变更日志列出了每一项不兼容变更。

传输方式：stdio 与 Streamable HTTP

Streamable HTTP 在 2025-03-26 取代了 HTTP+SSE 传输（一个 GET 流加一个单独的 POST 端点）；HTTP+SSE 现已正式弃用。网关可以依据 Mcp-Method 和 Mcp-Name 路由和限流，而无需解析请求体，Server 会拒绝头与请求体不一致的请求。HTTP Server 必须校验 Origin 头以防范 DNS 重绑定，本地 Server 应绑定到 127.0.0.1。

Server 功能与 Client 功能

Elicitation 的表单模式绝不能索要密码、API 密钥或令牌；URL 模式则会把用户引导到 Client 之外的页面。Sampling、roots 和 Server 日志在 2026-07-28 中已被弃用，最早要等到 2027 年 7 月 28 日当天或之后发布的第一个修订版才能移除。

一次工具调用，逐步拆解

模型通过远程 Server 提交一个 issue：

1. Client 可以先调用 server/discover 获取版本和能力。
2. Client 调用 tools/list。Host 合并所有 Server 的列表，给重名的工具加上前缀，然后交给模型。
3. 模型请求 create_issue。Host 展示这次调用，用户批准。
4. Client 发送 tools/call，如下所示。
5. 如果 Server 需要确认，它会返回带有 elicitation 请求的 input_required。Client 询问用户，并带着答案和 Server 的不透明 requestState 重试。
6. 结果以 complete 形式到达。工具失败时会设置 isError: true，让模型可以自行纠正。
7. 在 subscriptions/listen 流上，notifications/tools/list_changed 会通知 Client 重新列出工具。

POST /mcp HTTP/1.1
Host: mcp.tracker.example
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_issue

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "create_issue",
  "arguments": {"title": "Login fails on Safari"},
  "_meta": {"io.modelcontextprotocol/protocolVersion": "2026-07-28",
   "io.modelcontextprotocol/clientInfo": {"name": "my-ide", "version": "1.4.0"},
   "io.modelcontextprotocol/clientCapabilities": {"elicitation": {}}}}}

{"jsonrpc": "2.0", "id": 7, "result": {"resultType": "complete",
 "content": [{"type": "text", "text": "Created issue #482"}], "isError": false}}

远程 Server 与授权

远程 MCP Server 是一个 OAuth 资源服务器；它的令牌来自同一厂商运营的授权服务器，或来自独立的身份提供商。首次连接时：

1. Client 不带令牌发起调用并收到 401，通常附带一个 WWW-Authenticate 头，指向该 Server 的受保护资源元数据（RFC 9728）。
2. 该文档（或作为后备的 /.well-known/oauth-protected-resource）会指明授权服务器，Client 读取它的元数据；如果没有声明支持 PKCE，Client 就会停止。
3. Client 使用预先注册的客户端 ID、Client ID Metadata Document（以 HTTPS URL 作为客户端 ID）或动态客户端注册，其中动态客户端注册在 2026-07-28 中被弃用。
4. Client 运行带 PKCE（S256）的授权码流程，并带上指明该 MCP Server 的 resource 参数（RFC 8707）。用户在浏览器中登录并同意，Client 会检查响应中的 iss（RFC 9207）。
5. 每个请求都带有 Authorization: Bearer。带 insufficient_scope 的 403 会触发升级授权（step-up）。

Server 只接受签发给自己的令牌，并且绝不透传：调用上游 API 要使用另一个令牌。OAuth 2.0 流程图讲解了 PKCE，授权规范给出了完整规则，它建立在 OAuth 2.1 草案之上。

信任边界在哪里

stdio 传输不是沙箱：MCP 的本地 Server 安全指南指出，stdio Server 以 Client 的权限运行，隔离要靠 Host 和运行这台机器的人。无状态 Server 签发的状态句柄也不是凭据；要把它绑定到已认证的用户。威胁建模数据流图展示了如何用 STRIDE 逐一检查这些边界。

MCP 架构图

这张图的读法如下：

• 绿色框架是一个信任域：Host、它的三个 Client 和两个 stdio Server 都以开发者的操作系统用户身份运行。
• 每个 Server 一个 Client。 Client 1 和 2 使用 stdin 和 stdout；Client 3 使用 Streamable HTTP。
• 从模型出发的灰色边是由 Host 路由的工具调用；Server 永远不会直接访问模型。
• 蓝色表示携带 Bearer 令牌穿过网络。紫色虚线是 OAuth 流程，仅在 Client 没有有效令牌时才会运行。
• 青色表示远程 Server 用自己的令牌调用它的 API：不做透传。
• Markdown 块总结了 2026-07-28 修订版。

把 MCP 架构图画清楚

• 每个 Server 一个 Client。 只画一个「MCP」方框，会掩盖每个 Server 能看到什么。
• 在边上标注传输方式和载荷：stdin 和 stdout、带 Bearer 令牌的 POST、OAuth 流程、示例工具名。
• 用框架画出信任边界：机器、Host、每个厂商。标出放在沙箱里的 Server。
• 给授权服务器和上游 API 各自单独的节点，这样令牌的来源和不透传的规则才看得见。
• 标明协议修订版。 2026-07-28 的图里没有握手，也没有会话 ID。
• 省略 SDK 内部细节、完整的工具列表，以及模型提供方的基础设施。

AI 智能体架构图介绍了围绕这些调用的智能体循环。

在 Archboard 中构建

1. 用 Google 或 GitHub 登录并创建一个图表。
2. 为开发者机器添加一个来自基础包的框架，并在其中为 Host 添加一个来自 C4 Model 包的容器边界。
3. 在边界内，添加一个来自 ML 包的模型，再为 Client 添加三个来自 C4 Model 包的组件节点，技术分别填 stdio、stdio 和 Streamable HTTP。
4. 为本地 Server 添加两个来自 C4 Model 包的容器节点，用「stdin / stdout」边连接，再添加一个来自同一包的人员并连到模型。
5. 在框架之外，添加一个来自 C4 Model 包的系统边界，其中放一个代表远程 Server 的容器、一个代表其 API 的外部系统，以及一个来自安全包的身份提供商，然后画出 Bearer 令牌、虚线 OAuth 和「own token」这几条边。
6. 添加一个来自基础包的 Markdown 块，写上协议要点，并用基础包的文本注释标注各个边界。

目前没有任何免费工具能读取 MCP Client 的配置文件，所以请自己画出各个 Server，或者把一张 Mermaid 流程图（例如 MCP 规范中的那张）粘贴到 Mermaid 转可编辑图表工具里。

截至撰写本文时（2026 年 11 月），Archboard 本身就是位于 https://getarchboard.app/mcp 的远程 MCP Server：使用 Streamable HTTP，由它自己的授权服务器提供 OAuth 2.1，带 PKCE（S256），并以该 URL 作为资源指示符，客户端注册通过 Client ID Metadata Document 或动态客户端注册完成。MCP Server 文档列出了它的工具，AI 智能体页面介绍了如何连接你的应用。

这个示例共用 14 个图表节点，在 Free 套餐的限制之内。

常见问题

MCP 的 Host、Client 和 Server 有什么区别？ Host 是 AI 应用，例如 IDE。它为每个 Server 创建一个 Client，每个 Client 与一个 Server 保持专用连接，由该 Server 对外提供工具、资源和提示词。

MCP 现在是无状态的吗？ 是的，从 2026-07-28 修订版开始：没有 initialize 握手，没有会话 ID，每个请求都携带自己的版本和能力。使用旧修订版的 Server 仍然使用握手。

MCP 支持哪些传输方式？ 两种标准方式：本地 Server 用 stdio，远程 Server 用 Streamable HTTP。HTTP+SSE 已弃用，自定义传输必须保持 JSON-RPC 的消息格式。

本地 MCP Server 需要 OAuth 吗？ 不需要。规范规定 stdio Server 应从环境中获取凭据。给每个 Server 一个权限范围狭窄的令牌，并把第三方 Server 放进沙箱。

MCP 中的令牌透传是什么？ 指 MCP Server 接受并非签发给自己的令牌，或把 Client 的令牌转发给另一个 API。规范禁止这样做；调用上游需要 Server 自己的令牌。

免费开始 — 1 个席位，无需信用卡。