面经策

MCP 架构包含哪些核心组件？ ​

  • 标签：大模型、AI、MCP、系统架构

🏛 业务架构师 ​

MCP 架构是经典的客户端-服务端三层结构：

  • MCP Host（宿主应用）：面向用户的 AI 应用本体——Claude Desktop、Cursor、IDE 插件或企业自研 Agent。它承载模型和业务逻辑，决定"何时用什么工具"。
  • MCP Client（客户端）：宿主内的协议连接器，与 Server 保持一对一会话，负责 JSON-RPC 消息的封包解包、能力协商。开发者通常不直接感知它。
  • MCP Server（服务端）：工具/数据的提供方，暴露三类能力——Tools（可执行的操作，如"创建工单"）、Resources（可读取的数据，如配置文件、数据库记录）、Prompts（预置的提示模板）。比如 Filesystem Server 提供文件读写，GitHub Server 提供 PR 管理。
  • 传输层：本地走 stdio（子进程通信），远程走 HTTP+SSE / Streamable HTTP，2026 年远程部署已成主流（便于集中管控和鉴权）。

业务视角的价值：这个分层把"用工具的"（Host）和"供工具的"（Server）解耦成两个生态——业务系统团队只管把能力封装成 Server 发布，AI 应用团队按需订阅组合。企业落地时，MCP Server 就是"AI 能力资产"的登记单元：谁提供、谁审批、什么权限、调用量多少，治理抓手非常清晰。

🏗 系统架构师 ​

MCP 采用Host-Client-Server 三角架构，我按职责拆：

  • Host：承载 LLM 的应用程序（Claude Desktop、IDE、Agent 平台）——用户入口，拥有最终决定权（工具调用需 Host 批准）；
  • Client：Host 内部为每个 Server 维护的有状态协议连接器，负责 JSON-RPC 消息编解码、能力协商、请求关联——一个 Host 挂 N 个 Client，1:1 对应 Server；
  • Server：能力提供方，暴露三类原语——Tools（可执行动作，如查库、发邮件）、Resources（可读数据，文件/记录）、Prompts（可复用提示模板）。数据库、GitHub、Slack 都可以包成 Server。

两个关键协议机制：

  • 能力协商：初始化握手时双方交换 protocolVersion 与 capabilities，Client 与 Server 只使用交集能力——这是典型的向前兼容设计；
  • 传输与原语分层：JSON-RPC 2.6 消息层 + stdio（本地子进程）/ Streamable HTTP（远程，SSE 流式）两种传输，原语语义与传输解耦。

架构师点评：Client/Server 分离让"工具进程"与"应用进程"隔离运行（故障隔离、权限最小化）；但它也把治理问题留给了生态——N 个 Server 的鉴权、审计、性能参差，生产上通常要加一层 MCP 网关统一收口。

💻 全栈开发专家 ​

MCP 架构三个核心角色 + 三类服务原语：

角色：

  • Host：跑 LLM 的应用本体（Claude Desktop、Cursor、我们的 Agent 服务），负责聚合、决策和向用户请求授权；
  • Client：协议连接器，内嵌在 Host 里，与一个 Server 保持 1:1 连接，负责 JSON-RPC 消息编解码；
  • Server：能力提供方，进程内（stdio）或远程（Streamable HTTP）运行，封装数据源/工具。

服务原语（Server 能暴露什么）：

  • Tools：模型可调用的函数（查库、下单），Server 端执行的副作用动作；
  • Resources：可读数据（文件、表结构），类比 GET；
  • Prompts：预置提示模板，面向人的复用。

Client 能力（反向能力协商）：sampling（Server 请求 Host 帮忙调一次 LLM）、roots（Host 告知可访问的文件边界）、elicitation（Server 向用户请求补充信息）。

初始化握手时双方交换 capabilities，只启用都支持的特性。开发经验：本地工具用 stdio 传输（npx/uvx 拉起，stdout 通信，零网络配置）；对外服务用 Streamable HTTP + OAuth 2.1；一个 Host 可挂多个 Client 连不同 Server，工具太多时注意上下文膨胀——每个 tool schema 都占 token。