一文讲清楚 MCP 三层架构：Host、Client、Server 到底是什么？LLM 和 MCP Host 又是什么关系？

摘要

MCP，全称是 Model Context Protocol，可以理解为一种让 AI 应用标准化连接外部工具和数据源的协议。

在学习 MCP 的时候，最容易混淆的就是几个概念：

• MCP Host 是不是 LLM？
• MCP Client 到底有什么作用？
• MCP Server 已经能暴露工具了，为什么还需要 Client？
• 用户让 AI 查看项目文件时，完整调用流程到底是什么样的？
• LLM、Host、Client、Server 之间到底是什么关系？

本文会围绕 MCP 的三层结构：Host、Client、Server 进行详细讲解，并结合“用户让 AI 查看本地项目文件并总结文档”的例子，把完整调用链路讲清楚。

---

一、MCP 是什么？

MCP 全称是：

Model Context Protocol

可以理解为：

MCP 是一种让 AI 应用安全、标准化地连接外部工具和数据源的协议。

大模型本身只负责理解和生成文本，它并不能天然访问：

本地文件
GitHub 仓库
数据库
日志系统
监控系统
工单系统
天气 API
公司内部接口

比如用户问：

帮我查看一下我的项目文件，并总结文档。

如果没有工具能力，大模型其实不知道你的项目文件里有什么内容。

它不能凭空读取你的本地文件，也不能直接访问你的电脑目录。

这时候就需要 MCP。

MCP 的作用就是让 AI 应用通过统一协议连接外部工具，比如：

读取文件工具
查询 GitHub 工具
查询数据库工具
查询日志工具
查询监控工具
查询工单工具

---

二、MCP 为什么要出现？

在没有 MCP 之前，如果一个 AI 应用想接入外部工具，通常需要自己写很多适配逻辑。

比如一个 AI 应用想接入这些能力：

本地文件读取
GitHub 查询
数据库查询
日志查询
监控查询
工单查询

那么它可能要分别写：

文件系统适配代码
GitHub API 适配代码
数据库连接代码
Elasticsearch 查询代码
Prometheus 查询代码
工单系统 API 适配代码

如果多个 AI 应用都要接这些工具，那么每个应用都要重复开发。

比如：

Cursor 要接 GitHub，写一套适配
Claude Desktop 要接 GitHub，也写一套适配
VS Code 插件要接 GitHub，还要写一套适配
公司内部智能助手要接 GitHub，又要写一套适配

这会变成：

N 个 AI 应用 × M 个工具 = N * M 次适配

成本非常高。

MCP 的思想是：

工具提供方只需要实现一个 MCP Server，任何支持 MCP 的 AI 应用都可以通过 MCP Client 连接它。

也就是说：

GitHub MCP Server 实现一次
Cursor 可以用
Claude Desktop 可以用
VS Code 插件可以用
公司内部 AI 助手也可以用

这样工具接入就被标准化了。

---

三、MCP 的三层架构

MCP 主要可以分成三层：

MCP Host
MCP Client
MCP Server

如果再往下看，MCP Server 后面还会连接真实的数据源，比如文件系统、数据库、GitHub API、日志系统等。

整体结构可以画成这样：

用户
 ↓
MCP Host
 ↓
MCP Client
 ↓
MCP Server
 ↓
真实数据源

如果只讲 MCP 的三层，重点就是：

Host：AI 应用层
Client：连接工具层
Server：工具服务层

可以用一句话先记住：

Host 负责调度，Client 负责连接，Server 负责执行。

---

四、MCP Host 是什么？

MCP Host 是用户真正使用的 AI 应用。

比如：

Cursor
Claude Desktop
VS Code AI 插件
公司内部智能助手
智能 OnCall Agent 平台

很多人一开始会误以为：

MCP Host 是不是 LLM？

答案是：

MCP Host 不是 LLM。

更准确地说：

MCP Host 是承载 LLM 的 AI 应用，LLM 是 Host 调用的大模型能力。

也就是说：

MCP Host = AI 应用本身
LLM = Host 调用的大模型

比如你在 Cursor 里和 AI 对话：

帮我分析这个 Java 项目的登录流程。

这里：

Cursor 是 MCP Host
GPT / Claude / DeepSeek 这类模型是 LLM

Host 负责组织整个流程，LLM 负责理解用户问题和生成回答。

---

五、MCP Host 负责什么？

MCP Host 负责整个 AI 应用的调度流程。

它主要负责：

接收用户输入
维护对话上下文
调用 LLM
管理 MCP Client
获取可用工具列表
把工具描述提供给 LLM
接收 LLM 返回的 tool call
通过 Client 调用 Server
把工具结果交给 LLM
展示最终答案

也就是说，Host 不是只负责把用户问题转发给大模型。

它还要负责：

工具管理
上下文管理
权限控制
调用调度
结果展示

所以 Host 更像是：

AI 应用的外壳 + 调度中心。

---

六、LLM 和 MCP Host 的关系

LLM 和 MCP Host 不是同一个东西。

可以这样理解：

LLM = 大脑
MCP Host = 身体 + 调度系统
MCP Client = 手上的连接器
MCP Server = 外部工具
真实数据源 = 工具背后的数据

LLM 负责：

理解用户问题
判断是否需要调用工具
生成工具调用请求
根据工具返回结果继续分析
生成最终回答

但是 LLM 本身通常不直接做这些事情：

不直接读取本地文件
不直接连接数据库
不直接调用 GitHub API
不直接查询日志系统
不直接访问 MCP Server

这些事情是由 Host 调度 MCP Client 和 MCP Server 完成的。

所以更准确地说：

LLM 负责“想清楚要做什么”，Host 负责“把这件事真正调度起来”。

---

七、MCP Client 是什么？

MCP Client 是 Host 内部的一个组件。

它不是用户客户端，也不是浏览器前端。

它的作用是：

帮 MCP Host 连接 MCP Server，并负责工具发现、工具调用转发和结果接收。

可以理解成：

MCP Client = Host 内部的工具连接器

比如 Cursor 想读取本地项目文件，它自己不会直接读文件，而是通过内部的 MCP Client 连接 Filesystem MCP Server。

结构如下：

Cursor Host
   ↓
Filesystem MCP Client
   ↓
Filesystem MCP Server
   ↓
本地项目文件

MCP Client 主要负责：

1. 连接 MCP Server
2. 获取 Server 暴露的工具列表
3. 获取每个工具的参数格式
4. 把工具描述交给 Host
5. 转发 LLM 产生的工具调用请求
6. 接收 Server 返回的工具执行结果
7. 处理超时、失败、取消、连接断开等问题

Client 自己不真正执行工具逻辑。

比如文件读取场景中：

Client 不负责真正读取文件
Server 才负责真正访问文件系统

Client 只是连接和转发。

---

八、MCP Server 是什么？

MCP Server 是工具能力的提供方。

它负责把某种外部系统包装成 MCP 标准工具。

比如：

Filesystem MCP Server：封装本地文件读写能力
GitHub MCP Server：封装 GitHub API 能力
Database MCP Server：封装数据库查询能力
Log MCP Server：封装日志查询能力
Metric MCP Server：封装监控查询能力
Ticket MCP Server：封装工单系统能力

MCP Server 主要负责：

1. 声明自己有哪些工具
2. 声明工具需要什么参数
3. 接收 MCP Client 的调用请求
4. 校验参数是否合法
5. 做权限控制
6. 访问真实数据源
7. 返回工具执行结果

比如一个 Filesystem MCP Server 可以暴露这些工具：

list_directory(path)：列出目录
read_file(path)：读取文件
search_files(path, keyword)：搜索文件
write_file(path, content)：写入文件

一个 Log MCP Server 可以暴露：

search_logs(serviceName, keyword, timeRange)：查询日志
get_trace(traceId)：查询链路
aggregate_errors(serviceName, timeRange)：聚合异常

Server 的核心作用是：

把真实外部能力封装成 AI 可以调用的标准工具。

---

九、MCP 三层职责总结

层级	作用	类比
MCP Host	AI 应用本身，负责用户交互、调用 LLM、管理工具	Cursor、Claude Desktop、智能助手
MCP Client	Host 内部连接 Server 的组件，负责工具发现和调用转发	连接器、驱动、HTTP Client
MCP Server	工具服务，负责暴露工具、执行工具、访问真实数据源	工具适配器、后端服务

一句话总结：

Host 负责组织整个 AI 应用流程；
Client 负责连接和调用工具 Server；
Server 负责提供和执行工具能力。

---

十、为什么有了 Server，还需要 Client？

这是 MCP 最容易被问到的问题。

很多人会想：

Server 已经能暴露工具了，为什么还需要 Client？

答案是：

Server 只是工具能力的提供方，但 Host 要真正使用这些能力，还需要 Client 来连接、发现、调用和接收结果。

Server 解决的是：

外部系统如何被包装成标准工具？

Client 解决的是：

AI 应用如何连接并使用这些标准工具？

举个例子，一个 GitHub MCP Server 暴露了这些工具：

list_issues
search_code
get_pull_request
create_issue

这只能说明：

GitHub MCP Server 有这些能力。

但是 Cursor 或 Claude Desktop 要使用它，还需要：

1. 连接这个 MCP Server
2. 获取它有哪些工具
3. 获取工具参数格式
4. 把工具描述提供给 LLM
5. 当 LLM 要调用工具时，把请求发给 Server
6. 接收 Server 返回结果
7. 把结果交给 LLM 继续分析

这些事情就是 MCP Client 做的。

所以：

Server 负责“我能做什么”
Client 负责“我怎么调用你”

---

十一、用 HTTP 类比 MCP Client 和 Server

可以用普通后端开发来理解。

假设有一个用户服务：

User Server

它提供接口：

GET /user/1
POST /user

那是不是有 Server 就够了？

不是。

调用方还需要 HTTP Client，比如：

OkHttp
HttpClient
RestTemplate
FeignClient

服务端负责：

我提供接口。

客户端负责：

我发请求、接收响应、处理异常。

MCP 也是一样：

MCP Server：提供 MCP 工具接口
MCP Client：调用 MCP 工具接口

如果没有 MCP Client，Host 也可以自己写一段连接 MCP Server 的代码。

但这段代码本质上就是 Client。

所以 Client 不是多余的一层，而是把“工具连接和协议通信逻辑”单独抽象出来。

---

十二、完整调用流程：用户让 AI 查看项目文件并总结

下面用一个具体场景讲清楚。

用户在 Cursor 或某个 AI 应用里输入：

帮我查看一下我的项目文件，并总结文档。

假设系统配置了 Filesystem MCP Server。

对应关系如下：

Cursor / AI 应用 = MCP Host
Host 内部的连接组件 = MCP Client
Filesystem MCP Server = MCP Server
本地项目文件夹 = 真实数据源
GPT / Claude / DeepSeek = LLM

完整流程如下。

---

1. Host 启动并连接 MCP Server

很多情况下，Host 启动时就会读取 MCP 配置。

比如配置了一个文件系统 Server：

{
  "mcpServers": {
    "filesystem": {
      "command": "filesystem-server",
      "args": ["/Users/xxx/project"]
    }
  }
}

Host 启动后：

1. 读取 MCP 配置
2. 创建 MCP Client
3. MCP Client 连接 Filesystem MCP Server
4. Client 向 Server 获取工具列表

Filesystem MCP Server 可能返回：

list_directory(path)
read_file(path)
search_files(path, keyword)

此时 Host 就知道：

当前可以使用文件读取工具。

---

2. 用户请求进入 Host

用户输入：

帮我查看一下我的项目文件，并总结文档。

这个请求首先进入 MCP Host。

也就是：

Cursor
Claude Desktop
VS Code 插件
公司内部 AI 助手

不是直接进入 LLM，也不是直接进入 MCP Server。

Host 会组织一次 LLM 调用。

---

3. Host 把问题和工具列表发给 LLM

Host 会把下面信息发送给 LLM：

1. 用户当前问题
2. 最近对话上下文
3. 系统提示词
4. 当前可用工具列表

工具列表大概是：

你可以使用以下工具：
- list_directory(path)：列出目录
- read_file(path)：读取文件
- search_files(path, keyword)：搜索文件

LLM 看到用户问题后，会判断：

用户要我查看项目文件并总结，我需要先读取项目目录。

---

4. LLM 返回 tool call

LLM 不会直接读取文件。

它会返回一个工具调用请求，比如：

{
  "tool": "list_directory",
  "arguments": {
    "path": "/project"
  }
}

这一步的本质是：

LLM 告诉 Host：我想调用 list_directory 工具。

注意：

LLM 不直接调用 Server
LLM 不直接访问文件系统
LLM 只是生成 tool call

---

5. Host 通过 Client 调用 Server

Host 收到 tool call 后，会找到对应的 MCP Client。

调用链路是：

MCP Host
 ↓
MCP Client
 ↓
Filesystem MCP Server

Client 把请求转发给 Server：

list_directory("/project")

---

6. Server 访问真实项目文件

Filesystem MCP Server 收到请求后，真正访问本地项目目录。

比如项目目录是：

/project
  ├── README.md
  ├── pom.xml
  ├── src/
  ├── docs/
  └── deployment.md

Server 返回：

README.md
pom.xml
src/
docs/
deployment.md

结果返回链路是：

本地项目文件夹
 ↓
Filesystem MCP Server
 ↓
MCP Client
 ↓
MCP Host

---

7. Host 把工具结果交给 LLM

Host 拿到目录列表后，会把结果继续交给 LLM。

LLM 看到结果后，可能会继续判断：

我要总结文档，应该读取 README.md、docs 目录和 deployment.md。

然后 LLM 继续返回 tool call：

{
  "tool": "read_file",
  "arguments": {
    "path": "/project/README.md"
  }
}

Host 再次通过 Client 调用 Server。

这个过程可能循环多次。

---

8. 多轮工具调用

LLM 可能继续调用：

read_file("/project/README.md")
list_directory("/project/docs")
read_file("/project/docs/architecture.md")
read_file("/project/docs/api.md")
read_file("/project/deployment.md")

每次调用都是：

LLM 产生 tool call
 ↓
Host 接收 tool call
 ↓
Client 转发请求
 ↓
Server 执行工具
 ↓
Server 返回结果
 ↓
Host 把结果交给 LLM

直到信息足够。

---

9. LLM 生成最终总结

当 LLM 读取了足够的项目文件后，会生成最终回答。

比如：

这个项目是一个 Spring Boot 后端项目，主要包含用户模块、订单模块和鉴权模块。
项目使用 Maven 管理依赖，入口类位于 src/main/java 下。
README 中描述了项目启动方式，docs 目录包含接口文档和部署说明。
整体项目结构清晰，适合按照 controller、service、mapper 三层架构进行理解。

最后 Host 把最终总结展示给用户。

---

十三、完整流程图

可以画成这样：

用户
 ↓
MCP Host
 ↓
Host 调用 LLM，并提供用户问题 + 工具列表
 ↓
LLM 判断需要调用工具
 ↓
LLM 返回 tool call
 ↓
MCP Host
 ↓
MCP Client
 ↓
MCP Server
 ↓
真实数据源
 ↓
MCP Server
 ↓
MCP Client
 ↓
MCP Host
 ↓
Host 把工具结果交给 LLM
 ↓
LLM 继续分析或继续调用工具
 ↓
LLM 生成最终答案
 ↓
MCP Host 展示给用户

更简化的一句话是：

用户请求进入 Host，Host 调用 LLM，LLM 决定调用工具，Host 通过 Client 调用 Server，Server 访问真实数据源并返回结果，Host 再把结果交给 LLM，最后 LLM 生成答案，由 Host 返回给用户。

---

十四、智能运维 Agent 中的 MCP 三层例子

如果是智能 OnCall 运维系统，也可以这样理解。

用户问：

订单服务最近 10 分钟接口超时率升高，帮我分析原因。

对应关系：

智能 OnCall 平台 = MCP Host
Log MCP Client / Metric MCP Client / Ticket MCP Client = MCP Client
Log MCP Server / Metric MCP Server / Ticket MCP Server = MCP Server
Elasticsearch / Prometheus / 工单系统 = 真实数据源
LLM = 负责分析和生成结论的大模型

结构如下：

智能 OnCall Host
   ├── Metric MCP Client -> Metric MCP Server -> Prometheus
   ├── Log MCP Client -> Log MCP Server -> Elasticsearch
   ├── Ticket MCP Client -> Ticket MCP Server -> 工单系统
   └── CMDB MCP Client -> CMDB MCP Server -> 服务依赖数据库

完整过程：

用户问订单服务超时
 ↓
Host 调用 LLM
 ↓
LLM 判断需要查监控
 ↓
Host 通过 Metric Client 调用 Metric Server
 ↓
Metric Server 查询 Prometheus
 ↓
返回 P99、错误率、QPS
 ↓
Host 把结果交给 LLM
 ↓
LLM 判断还需要查日志
 ↓
Host 通过 Log Client 调用 Log Server
 ↓
Log Server 查询 Elasticsearch
 ↓
返回 inventory-service timeout 日志
 ↓
LLM 综合分析
 ↓
生成排障结论

最终回答可能是：

订单服务 P99 延迟升高，同时日志中大量出现 inventory-service timeout。
结合服务依赖关系，初步判断订单服务超时可能由库存服务响应慢导致。
建议继续排查 inventory-service 的监控、慢 SQL 和最近发布记录。

---

十五、MCP 三层面试回答

如果面试官问：

MCP Host、Client、Server 分别是什么？

可以这样回答：

MCP Host 是 AI 应用本身，比如 Cursor、Claude Desktop 或公司内部智能助手，负责接收用户请求、调用 LLM、维护上下文、管理工具调用流程。

MCP Client 是 Host 内部的连接组件，负责连接 MCP Server、发现工具、获取工具参数 schema、转发 LLM 的 tool call，并接收 Server 返回结果。

MCP Server 是工具服务层，负责把外部系统封装成 MCP 标准工具，比如文件系统、GitHub、数据库、日志系统、监控系统等。Server 接收 Client 的调用请求，访问真实数据源并返回结果。

---

十六、MCP Host 和 LLM 的关系面试回答

如果面试官问：

Host 是不是 LLM？

可以这样回答：

不是。MCP Host 不是 LLM。MCP Host 是 AI 应用本身，LLM 是 Host 调用的大模型能力。

Host 负责接收用户问题、维护上下文、管理 MCP Client、获取工具列表、调用 LLM、处理 LLM 返回的 tool call，并最终展示结果。

LLM 负责理解用户意图、判断是否需要调用工具，以及基于工具返回结果生成最终回答。

所以可以理解为：LLM 是大脑，Host 是承载大脑并调度工具的应用。

---

十七、为什么需要 Client 的面试回答

如果面试官问：

既然 Server 已经能暴露工具，为什么还需要 Client？

可以这样回答：

MCP Server 只是工具能力的提供方，它解决的是“外部系统如何被包装成标准工具”的问题。

但是 AI 应用要真正使用这些工具，还需要一个协议组件来连接 Server、发现工具、获取工具描述、转发工具调用请求并接收结果，这就是 MCP Client。

Client 位于 Host 内部，负责工具消费和协议通信。如果没有 Client，Server 虽然暴露了工具，但 Host 没有标准通道去发现和调用它。如果把这些逻辑都写在 Host 里面，那么 Host 里面这部分逻辑本质上也就是 Client。

---

十八、MCP 三层一句话总结

最终可以这样记：

Host 是 AI 应用；
Client 是 Host 内部的工具连接器；
Server 是外部工具的标准化封装层。

再完整一点：

用户请求进入 Host，Host 调用 LLM，LLM 判断是否需要工具；
如果需要，Host 通过 MCP Client 调用 MCP Server；
Server 访问真实数据源并返回结果；
Host 再把结果交给 LLM；
最后由 LLM 生成答案并通过 Host 返回给用户。

---

十九、记忆口诀

Host：谁在用 AI？
Client：Host 怎么连接工具？
Server：工具怎么暴露给 AI？

或者：

Host 负责调度；
Client 负责连接；
Server 负责执行。

再简单一点：

LLM 是大脑；
Host 是调度中心；
Client 是连接器；
Server 是工具服务。

---

二十、总结

MCP 的核心不是让大模型直接访问外部系统，而是通过分层架构实现安全、标准化、可复用的工具接入。

三层职责非常清晰：

MCP Host：AI 应用，负责用户交互、LLM 调用和整体调度。
MCP Client：Host 内部连接组件，负责连接 Server、发现工具、转发调用和接收结果。
MCP Server：工具服务，负责暴露工具、执行工具、访问真实数据源。

LLM 和 MCP Host 也不是同一个东西。

LLM 负责理解和生成；
Host 负责调用 LLM 并调度整个工具执行流程。

所以当用户说：

帮我查看项目文件并总结文档。

完整链路是：

用户 -> MCP Host -> LLM -> tool call -> MCP Host -> MCP Client -> MCP Server -> 项目文件 -> MCP Server -> MCP Client -> MCP Host -> LLM -> 最终总结 -> 用户

这就是 MCP 三层架构在真实场景中的完整调用过程。