第2章 架构总览：Host-Client-Server 模型

任何协议的生命力都取决于它的架构设计。HTTP 的 client-server 模型造就了 Web 的繁荣，LSP 的双向通信架构让 VS Code 的插件生态爆发。MCP 选择了一条不同于以往的路径——它在 client 和 server 之间插入了一个 host 层，形成了独特的三层架构。这并不是过度设计，而是对 AI 应用场景的深刻洞察：当一个 AI 应用需要同时连接文件系统、数据库、外部 API 等多种上下文源时，必须有一个中心化的协调者来管理安全边界、聚合上下文、控制权限。

本章将从规范原文出发，逐层拆解 Host、Client、Server 三个核心组件的职责划分，理解 MCP 的四大设计原则如何塑造了这套架构，深入能力协商机制的运作细节，并通过 TypeScript SDK 中的真实代码来验证这些设计理念是如何落地的。

2.1 为什么需要三层架构

在讨论 MCP 的具体设计之前，先来思考一个问题：为什么传统的两层 client-server 模型不够用？

考虑一个典型场景：Claude Desktop 作为 AI 应用，需要同时访问本地文件系统、Git 仓库、PostgreSQL 数据库和 GitHub API。如果采用传统的两层模型，应用程序直接作为 client 连接每个 server，那么：

• 谁来决定哪些文件可以暴露给 AI？
• 当数据库查询结果和 Git 历史都返回时，谁来聚合这些上下文？
• 如果一个 server 请求 AI 生成一段代码，谁来控制这个 AI 调用的权限？
• 如何确保文件系统 server 看不到数据库 server 的数据？

这些问题的核心矛盾在于：多个独立的上下文源需要一个中心化的协调者。这个协调者不是任何一个 server，也不是简单的 client——它需要更高层次的控制权。MCP 的 host 层正是为此而生。

2.2 三个核心组件

MCP 规范在 Architecture 章节开篇即明确："The Model Context Protocol follows a client-host-server architecture where each host can run multiple client instances." 这句话包含了整个架构的骨架。

2.2.1 Host：容器与协调者

Host 是整个架构的中枢。规范将其定义为"container and coordinator"，具体职责包括：

1. 创建和管理多个 Client 实例：Host 决定启动哪些 Client，每个 Client 连接哪个 Server。以 Claude Desktop 为例，用户在配置文件中声明了三个 MCP Server，Claude Desktop 作为 Host 就会创建三个 Client 实例分别与之连接。

2. 控制连接权限和生命周期：Client 何时创建、何时销毁、是否允许连接某个特定的 Server，都由 Host 决定。这意味着 Server 无法主动"入侵"Host，连接的发起权完全在 Host 一侧。

3. 执行安全策略和用户授权：当 Server 请求调用一个工具（比如删除文件），Host 负责弹出确认对话框让用户决定。安全决策的最终裁定权在 Host。

4. 协调 AI/LLM 集成与采样：当 Server 需要 AI 能力时（比如让 AI 分析一段代码），请求通过 Client 传递到 Host，由 Host 决定使用哪个模型、传入多少上下文、是否需要用户确认。

5. 跨 Client 的上下文聚合：Host 从多个 Client 收集到的工具列表、资源列表、提示模板，统一呈现给 AI 模型。AI 模型看到的是一个完整的能力集合，而不需要知道这些能力分别来自哪个 Server。

Host 的角色可以类比为操作系统中的内核——它不直接提供功能，但它管理着所有功能的访问权限和生命周期。

2.2.2 Client：隔离的通信管道

Client 是 Host 和 Server 之间的桥梁，但它不是一个简单的消息转发器。规范强调 Client 的核心特征是隔离性——每个 Client 维护一个独立的会话，与其他 Client 完全隔离。

Client 的职责包括：

1. 建立有状态会话：每个 Client 与一个 Server 建立一对一的有状态连接。这里的"有状态"意味着双方在初始化阶段协商好的能力、订阅的资源变更通知等，在整个会话生命周期内都保持有效。

2. 协议协商与能力交换：Client 在连接建立时向 Server 声明自己支持哪些能力（如 Sampling、Roots、Elicitation），同时接收 Server 声明的能力（如 Tools、Resources、Prompts）。这个过程决定了整个会话中双方可以使用哪些功能。

3. 双向路由协议消息：Client 既将 Host 的请求（如调用工具、读取资源）转发给 Server，也将 Server 的请求（如请求 AI 采样）转发给 Host。

4. 管理订阅与通知：当 Server 的资源列表或工具列表发生变化时，Server 通过通知机制告知 Client，Client 再将变化传递给 Host。

5. 维护 Server 间的安全边界：Client 确保一个 Server 的数据不会泄漏到另一个 Server。这不仅仅是逻辑隔离，而是架构层面的强制保障——每个 Client 是一个独立的协议实例，物理上就不存在跨 Server 的数据通道。

注意一个关键的数量关系：一个 Host 管理多个 Client，每个 Client 连接一个 Server。这是一对多再到一对一的扇出模型。这意味着 Host 可以通过不同的 Client 同时与多个 Server 交互，但每个 Server 只能看到自己对应的那个 Client。

2.2.3 Server：专注的能力提供者

Server 是实际提供上下文和能力的一方。规范对 Server 的定位非常明确——它应该是轻量的、专注的、易于构建的。

Server 的职责包括：

1. 通过 MCP 原语暴露能力：Server 通过 Resources（资源）、Tools（工具）、Prompts（提示模板）三种原语向外暴露能力。这三种原语分别对应不同的控制层级。

2. 独立运作，职责聚焦：每个 Server 专注于一个特定领域。文件系统 Server 只管文件操作，数据库 Server 只管数据查询。这种单一职责的设计使得 Server 极易构建和维护。

3. 通过 Client 接口请求 AI 采样：Server 自身没有 AI 能力，但它可以通过协议向 Client 请求 AI 采样。比如一个代码审查 Server 可以请求 AI 分析一段代码的质量——这个请求会经过 Client 传递到 Host，由 Host 控制的 AI 模型来处理。

4. 遵守安全约束：Server 必须在 Host 和 Client 划定的安全边界内运作，不能越权访问资源。

5. 可以是本地进程或远程服务：Server 的部署形态是灵活的，可以是本地的 stdio 进程，也可以是远程的 HTTP 服务。

2.3 四大设计原则

MCP 规范明确列出了四条设计原则。这些原则不是空泛的口号，它们直接塑造了协议的每一个设计决策。

2.3.1 Server 应该极易构建

"Host applications handle complex orchestration responsibilities. Servers focus on specific, well-defined capabilities."

这条原则的含义是：把复杂性推给 Host，让 Server 保持简单。Host 负责管理多个连接、聚合上下文、处理安全策略、协调 AI 调用——这些复杂的编排工作由专业团队（如 Anthropic、Cursor 的开发者）来实现。而 Server 的开发者只需要专注于自己领域的功能，用几十行代码就能实现一个可用的 MCP Server。

这个设计决策直接影响了 MCP 的生态发展。当构建一个 Server 的门槛足够低时，社区中就会涌现大量的 Server 实现。

2.3.2 Server 应该高度可组合

"Each server provides focused functionality in isolation. Multiple servers can be combined seamlessly."

可组合性来自两个层面：一是每个 Server 提供独立的、聚焦的功能；二是共享的协议使得不同 Server 可以无缝组合。用户可以同时启用文件系统 Server、数据库 Server、GitHub Server，它们各自独立运作，但通过 Host 的聚合，AI 模型可以在一次对话中同时使用所有 Server 提供的能力。

2.3.3 Server 不能窥视对话和其他 Server

"Servers receive only necessary contextual information. Full conversation history stays with the host."

这是 MCP 最重要的安全原则。Server 只能接收到完成当前请求所需的最少信息，完整的对话历史始终保留在 Host 侧。每个 Server 连接维护隔离，跨 Server 的交互由 Host 控制。

这个原则的实际意义在于：当你连接一个第三方 MCP Server 时，你不需要担心它能读取你和 AI 之间的所有对话内容，也不需要担心它能访问你连接的其他 Server 的数据。

2.3.4 功能可渐进式添加

"Core protocol provides minimal required functionality. Additional capabilities can be negotiated as needed."

MCP 的核心协议非常精简——只需要支持 JSON-RPC 消息的收发和基本的初始化流程。在此基础上，Server 和 Client 可以通过能力协商逐步添加更多功能。一个最简单的 Server 可以只提供一个工具，随着需求增长再逐步添加资源、提示模板等功能。

2.4 能力协商机制

能力协商（Capability Negotiation）是 MCP 架构中最精妙的设计之一。它发生在 Client 和 Server 建立连接的初始化阶段，双方通过声明各自支持的能力来确定整个会话中可以使用哪些功能。

2.4.1 Server 端能力

在 TypeScript SDK 的 schemas.ts 中，ServerCapabilitiesSchema 完整定义了 Server 可以声明的所有能力：

// 来自 mcp-typescript-sdk/packages/core/src/types/schemas.ts
export const ServerCapabilitiesSchema = z.object({
  experimental: z.record(z.string(), JSONObjectSchema).optional(),
  logging: JSONObjectSchema.optional(),
  completions: JSONObjectSchema.optional(),
  prompts: z.object({
    listChanged: z.boolean().optional()
  }).optional(),
  resources: z.object({
    subscribe: z.boolean().optional(),
    listChanged: z.boolean().optional()
  }).optional(),
  tools: z.object({
    listChanged: z.boolean().optional()
  }).optional(),
  tasks: ServerTasksCapabilitySchema.optional(),
  extensions: z.record(z.string(), JSONObjectSchema).optional()
});

每个能力字段的含义：

能力	含义	典型场景
prompts	Server 提供提示模板	代码审查提示、SQL 生成提示
resources	Server 提供可读资源	文件内容、数据库表结构
tools	Server 提供可调用工具	执行命令、发送 HTTP 请求
logging	Server 支持向 Client 发送日志	调试信息、操作记录
completions	Server 支持补全功能	参数自动完成
tasks	Server 支持异步任务	长时间运行的操作

其中 listChanged 字段表示 Server 是否会在列表变化时主动发送通知——这是一个渐进式能力的典型例子。一个简单的 Server 可以不支持 listChanged，Client 就不会期待收到列表变更通知；而一个更高级的 Server 可以声明支持，让 Client 能实时感知到工具或资源的增减。

resources 中的 subscribe 则表示 Server 是否支持资源订阅。如果支持，Client 可以订阅特定资源的变化，当资源内容更新时 Server 会主动通知。

2.4.2 Client 端能力

ClientCapabilitiesSchema 定义了 Client 可以声明的能力：

// 来自 mcp-typescript-sdk/packages/core/src/types/schemas.ts
export const ClientCapabilitiesSchema = z.object({
  experimental: z.record(z.string(), JSONObjectSchema).optional(),
  sampling: z.object({
    context: JSONObjectSchema.optional(),
    tools: JSONObjectSchema.optional()
  }).optional(),
  elicitation: ElicitationCapabilitySchema.optional(),
  roots: z.object({
    listChanged: z.boolean().optional()
  }).optional(),
  tasks: ClientTasksCapabilitySchema.optional(),
  extensions: z.record(z.string(), JSONObjectSchema).optional()
});

Client 端的三大核心能力：

Sampling（采样）：Client 声明支持采样后，Server 就可以请求 Client 调用 AI 模型。这是一个反向调用——通常是 Client 请求 Server，但采样允许 Server 主动请求 Client。采样能力内部还有细分：context 表示是否支持上下文包含，tools 表示是否支持在采样中使用工具。

Roots（根目录）：Client 声明支持根目录后，Server 可以查询 Client 暴露的文件系统根目录列表。这让 Server 知道自己可以在哪些目录范围内操作。规范明确指出："Roots define the boundaries of where servers can operate within the filesystem."

Elicitation（用户交互）：Client 声明支持用户交互后，Server 可以请求 Client 向用户展示表单或引导用户访问 URL 来收集信息。比如一个部署 Server 可能需要用户输入目标环境的配置参数。

2.4.3 协商过程

初始化的请求-响应结构如下：

Client 发送 initialize 请求：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "sampling": {},
      "roots": { "listChanged": true },
      "elicitation": {}
    },
    "clientInfo": {
      "name": "claude-desktop",
      "version": "1.0.0"
    }
  }
}

Server 响应：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": true, "listChanged": true },
      "prompts": { "listChanged": true },
      "logging": {}
    },
    "serverInfo": {
      "name": "filesystem-server",
      "version": "2.0.0"
    },
    "instructions": "This server provides file system access..."
  }
}

协商完成后，Client 发送 notifications/initialized 通知，标志会话正式建立。

协商结果具有约束力：双方必须在整个会话期间遵守协商的能力。如果 Server 没有声明 tools 能力，Client 就不应该向它发送 tools/call 请求；如果 Client 没有声明 sampling 能力，Server 就不应该向它发送 sampling/createMessage 请求。在 TypeScript SDK 中，这种约束通过 enforceStrictCapabilities 选项来实现强制检查。

2.5 安全边界

安全性是 MCP 架构设计中最核心的考量之一。三层架构的一个重要目的就是建立清晰的安全边界。

2.5.1 Server 的隔离性

Server 无法看到对话历史：完整的用户-AI 对话历史始终保留在 Host 侧。当 Host 需要调用某个工具时，它只向对应的 Server 发送工具调用所需的参数，而不是整个对话上下文。Server 接收到的是最小必要信息。

Server 无法访问其他 Server：每个 Client-Server 连接是独立的。文件系统 Server 无法知道同一个 Host 还连接了数据库 Server，更无法读取数据库 Server 提供的数据。跨 Server 的信息流动只能通过 Host 来协调——Host 可以将一个 Server 返回的结果作为上下文传递给 AI 模型，模型可能据此向另一个 Server 发起请求，但这是 Host 控制下的间接关联，而非 Server 之间的直接通信。

在上面的图中，三个 Server 之间用叉号标记了连线，表示它们之间不存在任何直接通信通道。每个 Server 都处于自己的隔离域中，只能通过各自的 Client 与 Host 通信。

2.5.2 Host 的安全职责

Host 承担着最终的安全把关责任：

• 用户授权决策：当 Server 请求执行敏感操作时，Host 应该将决策权交给用户。
• 采样请求审查：当 Server 请求 AI 采样时，规范明确要求"there SHOULD always be a human in the loop with the ability to deny sampling requests"。Host 应提供 UI 让用户审查采样请求中的提示词，并在发送前允许编辑。
• 上下文过滤：Host 决定将多少上下文信息传递给 Server，确保不会过度暴露。

2.5.3 传输层安全

MCP 的安全设计不仅在协议层，也体现在传输层。本地 Server 通过 stdio 传输通信，数据不离开本机；远程 Server 则可以使用 HTTP + OAuth 2.1 认证。这些传输机制将在后续章节详细讨论。

2.6 TypeScript SDK 中的 Protocol 类

理论讲完，来看代码。TypeScript SDK 中的 Protocol 类（位于 packages/core/src/shared/protocol.ts）是整个协议栈的基石。Server 类和 Client 类都继承自它。

2.6.1 类的核心结构

// 来自 mcp-typescript-sdk/packages/core/src/shared/protocol.ts
export abstract class Protocol<ContextT extends BaseContext> {
  private _transport?: Transport;
  private _requestMessageId = 0;
  private _requestHandlers: Map<string, (request: JSONRPCRequest, ctx: ContextT) => Promise<Result>> = new Map();
  private _requestHandlerAbortControllers: Map<RequestId, AbortController> = new Map();
  private _notificationHandlers: Map<string, (notification: JSONRPCNotification) => Promise<void>> = new Map();
  private _responseHandlers: Map<number, (response: JSONRPCResultResponse | Error) => void> = new Map();
  private _progressHandlers: Map<number, ProgressCallback> = new Map();
  private _timeoutInfo: Map<number, TimeoutInfo> = new Map();

  // ...
}

这段代码揭示了 Protocol 类的内部机制：

• _transport：底层传输层，可以是 stdio、SSE 或 Streamable HTTP。Protocol 不关心具体的传输方式，这体现了分层设计。
• _requestMessageId：递增的消息 ID 计数器，用于 JSON-RPC 的请求-响应匹配。
• _requestHandlers：按方法名注册的请求处理器。当收到 tools/call 请求时，从这个 Map 中查找对应的处理函数。
• _responseHandlers：按消息 ID 注册的响应处理器。发出请求时注册，收到响应时匹配并调用。
• _notificationHandlers：通知处理器，处理单向消息（如 notifications/cancelled、notifications/progress）。
• _progressHandlers：进度回调，用于跟踪长时间运行的请求。

2.6.2 connect 方法：建立连接

async connect(transport: Transport): Promise<void> {
    this._transport = transport;
    this._transport.onclose = () => { this._onclose(); };
    this._transport.onerror = (error: Error) => { this._onerror(error); };
    this._transport.onmessage = (message, extra) => {
        if (isJSONRPCResultResponse(message) || isJSONRPCErrorResponse(message)) {
            this._onresponse(message);
        } else if (isJSONRPCRequest(message)) {
            this._onrequest(message, extra);
        } else if (isJSONRPCNotification(message)) {
            this._onnotification(message);
        }
    };
    await this._transport.start();
}

connect 方法体现了 MCP 基于 JSON-RPC 的消息分发机制。所有进入的消息被分为三类：响应（匹配之前发出的请求）、请求（需要处理并返回结果）、通知（单向消息，无需响应）。这种分类是 JSON-RPC 2.0 规范定义的，MCP 在此基础上构建了自己的协议语义。

2.6.3 request 方法：发送请求并等待响应

request<M extends RequestMethod>(
    request: { method: M; params?: Record<string, unknown> },
    options?: RequestOptions
): Promise<ResultTypeMap[M]> {
    const resultSchema = getResultSchema(request.method);
    return this._requestWithSchema(request as Request, resultSchema, options);
}

request 方法有几个值得注意的设计：

1. 类型安全：通过泛型 M extends RequestMethod，方法名和返回类型在编译期就绑定了。调用 tools/call 方法一定返回 CallToolResult 类型。

2. 能力检查：在内部实现 _requestWithSchema 中，如果启用了 enforceStrictCapabilities，会在发送请求前检查远端是否声明了处理该请求的能力。

3. 超时与取消：支持通过 AbortSignal 取消请求，支持配置超时时间，支持通过进度通知重置超时。

2.6.4 抽象方法：由子类实现的能力断言

protected abstract assertCapabilityForMethod(method: RequestMethod): void;
protected abstract assertNotificationCapability(method: NotificationMethod): void;
protected abstract assertRequestHandlerCapability(method: string): void;

这三个抽象方法是能力协商的运行时执行点。Server 子类和 Client 子类各自实现这些方法，检查对方声明的能力是否支持当前操作。比如 Server 的 assertCapabilityForMethod 会检查 Client 是否声明了 sampling 能力，才允许发送采样请求。

2.6.5 Server 类的初始化实现

在 packages/server/src/server/server.ts 中，Server 类继承 Protocol 并实现了初始化逻辑：

export class Server extends Protocol<ServerContext> {
  private _clientCapabilities?: ClientCapabilities;
  private _clientVersion?: Implementation;
  private _capabilities: ServerCapabilities;

  constructor(
    private _serverInfo: Implementation,
    options?: ServerOptions
  ) {
    super(options);
    // ... 注册 initialize 请求处理器
  }
}

Server 类在构造时接收 ServerCapabilities，在收到 Client 的 initialize 请求时，将自己的能力返回给 Client，同时记录 Client 声明的能力。这就完成了能力协商的 Server 侧逻辑。

2.7 与其他架构模型的对比

MCP 的 Host-Client-Server 模型并非凭空产生。理解它与其他常见架构的异同，有助于深化对其设计决策的理解。

2.7.1 vs 插件模型（Plugin Model）

传统的插件模型（如 WordPress 插件、jQuery 插件）采用宿主直接加载插件代码的方式。插件运行在宿主进程内部，共享宿主的内存空间和权限。

维度	插件模型	MCP
隔离性	无隔离，插件共享宿主内存	强隔离，每个 Server 独立进程
安全性	插件可访问宿主所有数据	Server 只能访问协议允许的数据
通信方式	函数调用	JSON-RPC 消息
语言限制	通常必须与宿主相同语言	任何语言均可实现 Server
崩溃影响	插件崩溃可能导致宿主崩溃	Server 崩溃不影响 Host

MCP 用进程隔离换来了安全性和语言无关性，代价是通信开销——每次调用都需要序列化和反序列化 JSON-RPC 消息。但对于 AI 应用场景，这个代价是值得的：AI 模型的推理延迟远大于 JSON-RPC 的通信延迟，序列化开销几乎可以忽略。

2.7.2 vs 微服务架构

微服务架构中，各服务通过 API 网关或服务发现机制互相通信。服务之间可以直接调用。

维度	微服务	MCP
服务间通信	服务可直接互调	Server 之间完全隔离
协调者	API 网关（可选）	Host（必须）
发现机制	服务注册中心	Host 配置文件
会话状态	通常无状态	有状态会话
协议	REST/gRPC	JSON-RPC

MCP 与微服务的核心差异在于 Server 之间不能直接通信。在微服务中，订单服务可以直接调用库存服务；但在 MCP 中，文件系统 Server 无法直接调用数据库 Server——所有跨 Server 的协调必须经过 Host。这种设计牺牲了灵活性，换来了更强的安全保障。

2.7.3 vs 浏览器扩展模型

浏览器扩展（如 Chrome Extension）与 MCP 有一些有趣的相似之处：

维度	浏览器扩展	MCP
权限声明	manifest.json 中声明权限	初始化时声明 capabilities
隔离机制	每个扩展独立的执行环境	每个 Server 独立的进程/连接
宿主角色	浏览器管理扩展生命周期	Host 管理 Client/Server 生命周期
通信方式	chrome.runtime.sendMessage	JSON-RPC over transport
用户授权	安装时请求权限	Host 在运行时控制授权

两者在架构理念上非常接近——都通过权限声明和进程隔离来保证安全性。MCP 可以说是 AI 领域的"扩展模型"。但 MCP 更进一步：浏览器扩展在安装时就确定了权限，而 MCP 在每次会话初始化时动态协商能力，这使得同一个 Server 在不同 Host 环境中可以呈现不同的功能集合。

2.8 架构的实际运行流程

将前面的概念串联起来，看一个完整的实际运行流程。假设用户在 Claude Desktop 中说："帮我看看项目里有没有安全漏洞"。

1. Host 处理用户输入：Claude Desktop（Host）将用户消息发送给 AI 模型。

2. AI 决策：模型分析后决定需要读取项目文件（来自文件系统 Server）和检查依赖（来自 npm Server）。

3. Host 分发请求：Host 通过 Client 1 向文件系统 Server 调用 tools/call（读取 package.json），通过 Client 2 向 npm Server 调用 tools/call（检查已知漏洞数据库）。

4. Server 独立处理：文件系统 Server 读取 package.json 返回内容；npm Server 查询漏洞库返回结果。两个 Server 互不知道对方的存在。

5. Host 聚合上下文：Host 收集两个 Server 的响应，将它们作为上下文传递给 AI 模型。

6. AI 生成分析：模型综合两方面信息，生成安全分析报告。

7. Host 呈现结果：Claude Desktop 将报告展示给用户。

在整个过程中，文件系统 Server 不知道用户的完整对话内容，不知道 npm Server 的存在，不知道 AI 模型的类型和参数。它只知道：有人请求读取 package.json，我返回内容。这就是三层架构和安全隔离原则的实际效果。

2.9 本章小结

MCP 的 Host-Client-Server 三层架构不是对传统 client-server 模型的简单扩展，而是对 AI 应用场景需求的深思熟虑的回应。它的核心设计智慧可以归纳为三个词：隔离、协商、聚合。

隔离——每个 Server 在独立的连接中运作，无法窥视对话历史，无法访问其他 Server，安全边界由架构本身保障而非依赖开发者的自律。

协商——Client 和 Server 在初始化时声明各自的能力，协商结果决定了整个会话的功能集合。这种机制让协议具备了渐进式扩展的能力，新功能可以通过新的 capability 字段引入，而不会破坏已有实现。

聚合——Host 将多个 Server 提供的工具、资源、提示模板聚合为统一的能力集合，呈现给 AI 模型。模型不需要知道这些能力来自哪些 Server，它看到的是一个完整的上下文空间。

在 TypeScript SDK 中，Protocol 抽象类通过 JSON-RPC 消息分发、请求-响应匹配、能力断言等机制，将这些架构理念转化为可执行的代码。Server 和 Client 类继承 Protocol，分别实现各自的能力声明和检查逻辑，完成了从设计到实现的完整闭环。

理解了架构之后，下一章我们将深入传输层——MCP 的三种传输机制（stdio、SSE 和 Streamable HTTP）如何在不同的部署场景中承载这套协议。