MCP架构总览

2936 字约 10 分钟

AIAgentMCP架构

2026-07-24

MCP 架构定义了模型应用与外部能力之间的连接方式、角色边界和数据流向。理解架构总览是设计、开发和运维 MCP 系统的前提。

一、基本定义

MCP（Model Context Protocol）采用 Host → Client → Server 三层架构，将模型应用（Host）与外部能力（Server）通过标准化协议层（Client）连接起来。

核心设计目标：

标准化：统一模型应用接入外部能力的接口
解耦：Host 不直接依赖具体外部系统实现
可扩展：新增能力只需新增 Server，不修改 Host
安全可控：明确的信任边界和权限控制

二、为什么需要这种架构

在 MCP 出现之前，每个 AI 应用都需要独立编写与外部系统的集成代码。这导致：

N 个应用 × M 个工具 = N×M 个集成
每个应用重复实现相同的连接逻辑
安全和权限处理各不相同
工具开发者需要为每个平台适配

MCP 的三层架构将这个问题简化为 N+M：

每个 Host 只需实现一个 Client 协议栈
每个外部能力只需实现一个 Server
Client 作为中间层统一管理连接、安全和路由

三、在 MCP 体系中的位置

四、核心角色与职责

Host（宿主应用）

Host 是直接面向用户的 AI 应用，例如 Claude Desktop、Cursor、或自定义 AI 应用。

职责：

管理用户交互界面
调用模型进行推理
管理一个或多个 MCP Client
将模型的工具调用意图路由到正确的 Client
处理用户授权和确认
管理上下文窗口和提示组装

不负责：

直接实现 MCP 协议通信（由 Client 完成）
直接连接外部系统（由 Server 完成）
决定工具的安全策略（由 Client + Server + 用户共同决定）

Client（协议客户端）

Client 是 MCP 协议的实现层，管理与 Server 的通信。

职责：

建立和维护与 Server 的连接
执行协议初始化与能力协商
发现 Server 提供的 Tool、Resource、Prompt
将模型的工具调用请求转换为协议消息
处理超时、重试、取消
规范化 Server 返回的结果
管理凭证和安全上下文

关键设计问题：

一个 Host 可以管理多个 Client，每个 Client 连接一个 Server
Client 是否信任 Server 的工具描述？
多个 Server 提供同名工具时如何处理？
Client 需要缓存能力列表还是每次重新发现？

Server（能力服务端）

Server 暴露外部能力，是 MCP 协议的另一端。

职责：

声明自己提供的 Tool、Resource、Prompt
处理 Client 的请求并返回结果
验证输入参数的合法性
管理对外部系统的访问
执行权限检查
返回结构化的错误信息

关键设计问题：

Server 应该保持单一职责还是聚合多种能力？
Server 应该是无状态的吗？
如何处理长时间运行的操作？
Server 如何管理对外部系统的凭证？

五、运行流程

一个典型的 MCP 交互包含以下阶段：

阶段说明

连接阶段：Host 启动时创建 Client，Client 连接 Server
初始化阶段：Client 与 Server 交换协议版本和能力声明
发现阶段：Client 查询 Server 的 Tool、Resource、Prompt 列表
调用阶段：模型决定调用工具，Host 通过 Client 发送请求
执行阶段：Server 验证参数、执行操作、返回结果
关闭阶段：Host 退出时，Client 优雅关闭与 Server 的连接

六、典型拓扑

单 Client 单 Server

最简单的拓扑，适合个人工具或单一数据源场景。

单 Client 多 Server

Host 同时连接多个 Server，聚合多种能力。

多 Agent 多 Server

多个 Agent 共享或独立使用不同的 MCP Server。

MCP Gateway（网关模式）

通过网关聚合多个 Server，对外暴露统一接口。

注意：MCP 协议本身不定义 Gateway，这是工程实现层面的模式。Gateway 需要额外处理认证传递、能力聚合和路由逻辑。

七、信任边界

MCP 架构中存在多个信任边界，每个边界需要不同的安全策略：

边界	信任关系	安全关注点
Host → Client	通常可信	Client 由 Host 管理
Client → Server	有条件信任	Server 可能返回不可信内容
Server → 外部系统	需要认证	凭证管理和权限控制
Server → Client（返回内容）	不可完全信任	资源内容可能包含提示注入
用户 → Host	可信	用户授权决定操作边界

关键安全原则

Server 的工具描述不可自动信任：恶意 Server 可能通过工具描述诱导模型执行非预期操作
Resource 内容不可自动信任：Resource 返回的内容可能包含提示注入
Tool 结果不可自动信任：Server 返回的结果可能包含误导性内容
本地 Server ≠ 可信 Server：本地运行的 Server 仍然可能有漏洞或被篡改

八、控制面与数据面

MCP 架构可以区分控制面和数据面：

控制面（Control Plane）

连接建立和管理
能力协商和发现
协议版本协商
生命周期管理
健康检查和心跳

数据面（Data Plane）

Tool 调用请求和响应
Resource 读取请求和响应
Prompt 获取请求和响应
通知和日志消息
进度更新

分离控制面和数据面的意义：

控制面的变更不应影响正在进行的数据面操作
数据面的高负载不应影响控制面的稳定性
可以独立扩展和监控两个面

九、设计原则

Server 职责单一：每个 Server 专注一个领域或数据源
Client 对 Server 保持审慎信任：验证返回内容，不自动执行高风险操作
Host 统一管理用户体验：授权确认、结果展示、错误处理
协议层与业务层分离：MCP 负责连接，不负责业务逻辑
最小权限：Server 只暴露必要的 Tool 和 Resource
可观测性：每个环节都应该可以被监控和调试

十、MCP 不做什么

明确 MCP 的职责边界同样重要：

MCP 不负责	应由谁负责
Agent 规划和推理	Host / Agent 框架
记忆管理	Host / Agent 框架
用户认证	Host / 认证服务
业务权限逻辑	Server / 业务系统
工作流编排	工作流引擎 / Agent
数据转换和清洗	Server / 业务逻辑
模型选择和路由	Host
上下文窗口管理	Host

MCP 是连接模型应用与外部能力的标准化协议层，不等于 Agent 本身，也不负责替代业务系统、权限系统和工作流引擎。

十一、与其他架构模式的关系

模式	与 MCP 的关系
REST API	MCP 可以封装 REST API 为 Tool
gRPC	MCP Server 内部可以使用 gRPC 通信
微服务	MCP Server 可以作为微服务的 AI 接入层
事件驱动	MCP 目前以请求-响应为主，不直接支持事件
插件系统	MCP 是开放协议，插件通常依赖具体平台
Agent Framework	MCP 为 Agent 提供外部能力接入

十二、常见误区

混淆 Host 和 Client：Host 是面向用户的应用，Client 是协议实现
认为 Server 必须独立进程：Server 可以嵌入到应用中
认为 MCP 管理 Agent 状态：MCP 只负责能力连接
忽视信任边界：不是所有 Server 都同等可信
认为本地 Server 自动安全：本地运行的 Server 也可能有安全问题
把所有能力塞进一个 Server：应该按职责拆分

十三、实践检查清单

十四、与其他概念的关系

MCP基础：MCP 的基本定义和核心概念
MCP Client设计：Client 的详细设计
MCP Server设计：Server 的详细设计
MCP协议生命周期：协议运行的完整生命周期
MCP通信与传输：传输层的详细设计
MCP安全边界：安全相关的详细设计

十五、适用边界

MCP 三层架构适用于：

需要连接多个外部能力的 AI 应用
需要标准化工具接入的平台
需要跨应用共享工具的场景
需要明确安全边界的系统

不适用于：

单一固定功能的 AI 应用
不需要外部能力的纯模型推理
实时流式数据处理（MCP 以请求-响应为主）
需要复杂状态机管理的场景

十六、延伸思考

当 Server 数量增长到数十个时，Client 如何高效管理能力发现和路由？
如何在保持协议简洁性的同时支持更复杂的交互模式？
Gateway 模式是否会成为大规模 MCP 部署的标准拓扑？
如何在协议层面支持 Server 能力的动态组合和编排？

十七、参考资料

MCP 官方规范 - https://modelcontextprotocol.io/specification
MCP 官方文档 - https://modelcontextprotocol.io/
MCP GitHub - https://github.com/modelcontextprotocol