MCP 架构：Host、Client、Server 三角色

MCP 架构：Host、Client、Server 三角色

基础概念

MCP 的整体设计是一个客户端-服务端架构，但和你平时理解的"浏览器-服务器"不太一样——它中间多了一个"Host"的角色。一共三个角色：Host（宿主）、Client（客户端）、Server（服务端）。

先用一个生活类比帮你建立直觉：

把 MCP 想象成一家餐厅。Host 是餐厅经理，负责协调一切；Client 是服务员，每个服务员对接一个厨房窗口；Server 是厨房，每个厨房专门做一类菜。当客人（用户）说"我想吃牛排"，经理判断该去哪个厨房，派对应的服务员去下单，厨房做好菜之后通过同一个服务员端回来。

三者之间的核心关系：一个 Host 管多个 Client，一个 Client 对应一个 Server，Client 和 Server 是一对一的专线连接。

核心要素

三角色关系图

关键理解：Client 不是一个独立的应用程序，它是 Host 内部的一个组件。当你在 Claude Desktop 配置里写了 3 个 Server，Host 启动时会在内部创建 3 个 Client 实例，分别和对应的 Server 建立连接。用户看到的只有 Host（Claude Desktop 窗口），Client 完全是幕后工作。

Host 到底干了什么

Host 是整个 MCP 交互的"总指挥"，它的工作比你想象的要多：

1. 创建 Client：读取配置，知道要连哪些 Server，为每个 Server 创建一个 Client
2. 生命周期管理：启动时让每个 Client 和 Server 完成初始化握手（能力协商），关闭时通知 Server 断开
3. 工具路由：大模型决定要调用某个工具时，Host 要知道这个工具属于哪个 Server，交给对应的 Client 去执行
4. 安全管控：决定是否允许模型调用某个工具、是否需要用户确认，这都是 Host 层面的职责
5. 上下文合并：从多个 Server 拿回的 Resources 和工具结果，统一整理后送进模型的上下文窗口

本地 Server vs 远程 Server

MCP 里的"Server"不一定跑在远方的云服务器上。实际上大多数日常用的 Server 都是本地进程：

连接的生命周期

每个 Client-Server 连接都有一个明确的生命周期：

初始化阶段有一个能力协商的步骤：Client 告诉 Server "我支持 Sampling 和 Elicitation"，Server 告诉 Client "我提供 Tools 和 Resources"。协商结果决定了这个连接可以做哪些事。后续的调用不会超出协商范围。

基础用法

理解了三角色之后，最直观的实践就是在 Claude Desktop 里同时配多个 Server，看它们如何协同工作。

下面是一个配置了 3 个本地 Server 的 claude_desktop_config.json：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxx"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb"
      }
    }
  }
}

启动 Claude Desktop 后，Host 做了这些事情：

1. 读取配置，发现有 3 个 Server
2. 为每个 Server 创建一个 Client 实例
3. 分别 spawn 3 个子进程（npx @modelcontextprotocol/server-xxx）
4. 每个 Client 和对应的 Server 完成能力协商
5. 从 3 个 Server 收集所有可用的 Tools，合并成一个统一工具列表
6. 用户提问时，大模型从这个统一列表里选择要调用的工具

当你对 Claude 说"帮我把 GitHub 上 my-repo 的 README 下载到本地 projects 文件夹"，Claude 可能会先调 GitHub Server 的 get_file_contents 读取内容，再调 Filesystem Server 的 write_file 写入本地，两个 Server 各司其职、互不干扰。

同类工具对比

MCP 的 Host-Client-Server 架构和其他"让 AI 用工具"的方案相比，差异在哪？

核心区别：

• MCP：工具在独立进程里运行，通过标准协议暴露，支持运行时动态发现和更新
• OpenAI Assistants：工具定义嵌在 API 调用里，和 OpenAI 平台绑定
• LangChain：工具是 Python 对象，和框架代码混在一起，没有进程隔离

常见误区

优劣势分析

思考题

参考资料

1. 官方架构文档：https://modelcontextprotocol.io/docs/concepts/architecture（查询日期 2026-04-11）
2. 官方 Server 概念：https://modelcontextprotocol.io/docs/concepts/server-concepts
3. 官方 Client 概念：https://modelcontextprotocol.io/docs/concepts/client-concepts
4. MCP 协议规范（生命周期部分）：https://modelcontextprotocol.io/specification/latest/basic/lifecycle
5. Anthropic 发布公告：https://www.anthropic.com/news/model-context-protocol
6. 官方 Reference Server 仓库：https://github.com/modelcontextprotocol/servers