MCP（Model Context Protocol）架构全解：5 大原语 + JSON-RPC 2.0 通信 + 企业落地 5 个坑

这道题在 2025 年底开始的高频 AI Agent 面试中几乎是「必考」。面试官不在考你会不会调 OpenAI 的 function calling，而在考一件事——当模型层 API 与应用层协议分家，Agent 工程到底由谁负责？

一、为什么这道题在 2025 年开始变得高频

MCP 是 Anthropic 在 2024 年底提出、2025 年捐赠给新成立的 Agentic AI Foundation 的开放协议。短短一年，OpenAI Agents SDK、Microsoft Copilot Studio、Cloudflare/Docker/Replit 等先后宣布支持。各 Agent 框架的「工具接入」层开始收敛到跨厂商事实标准。

面试官问「MCP 核心架构与五大原语」，考察的是：

• 协议层 vs 模型层边界（Function Calling 是模型 API，MCP 是应用层协议）
• 进程隔离给企业合规带来的实际价值
• 可发现性 / 热插拔对工具生态扩展的意义

很多候选人只答「MCP 是 Anthropic 推的协议」，说不清 Resources 和 Tools 边界、为什么 Sampling 是反向调用——这些细节才是面试官想要的。

二、MCP 的整体架构：Host / Client / Server 三层

MCP 沿用经典 client-server 模型，但加了一层 Host 表示「运行 Agent 的宿主进程」：

┌──────────────────────────────────┐
│ Host (Claude Desktop, Cursor…)    │  ← 用户面向的应用
│  ┌────────────────────────────┐  │
│  │ MCP Client                 │  │  ← 与每个 Server 一对一长连接
│  └────────────────────────────┘  │
└────────────┬─────────────────────┘
             │ JSON-RPC 2.0 (stdio / Streamable HTTP)
             ▼
┌──────────────────────────────────┐
│ MCP Server (GitHub MCP, FS MCP…) │  ← 暴露 Resources / Prompts / Tools
└──────────────────────────────────┘

关键约束：

• Host 可跑多个 Client，每个 Client 与 Server 一对一长连接
• Host 负责用户授权 + UI + 跨 Server 编排；Client 负责协议握手 + 能力协商（capability negotiation）；Server 负责把「真实世界的资源」封装成协议可调接口
• 传输层支持 stdio（本地进程）、HTTP + SSE（早期远程方案）、Streamable HTTP（2025 规范升级，单端点双向流）

2.1 握手与能力协商时序

Client 连上 Server 第一件事是能力协商：

关键点：客户端能力含 roots / sampling（声明文件边界、支持反向 Sampling）；服务端能力含 tools / resources / prompts。握手不通过（如协议版本不兼容）则 Client 直接断开。

三、五大原语：Resources / Prompts / Tools / Roots / Sampling

面试题的高频踩坑区——很多候选人只答得出 Tools 和 Resources，分不清 Prompts 和 Sampling。语义边界如下：

• Resources（资源）：Server 暴露的、可被 Client 读取的具名数据（类似 REST GET，但支持 subscribe 主动推送）。场景：文件、数据库行、GitHub Issue 列表。关键词：「读 + 订阅」。
• Prompts（提示模板）：Server 预定义的、可被 User 选择的提示词模板，带参数。关键词：「人机协作的预设剧本」。Claude Desktop 的 / 斜杠菜单里命令多来自各 MCP Server 注册的 Prompts。
• Tools（可调用工具）：模型可调用的函数，定义在 Server 端。关键词：「LLM 主动发起的副作用」。与 Resources 区别：Resources 是「读」，Tools 是「写 + 副作用」。
• Roots（文件系统根目录边界）：Client 启动时显式声明给 Server 的文件系统访问范围。关键词：「安全边界 + 权限收缩」。越界调用必须拒绝。
• Sampling（服务端采样能力）：Server 反向调用 Client 让 LLM 做一次补全——与传统 client-server 协议最大的区别。关键词：「Server→LLM 的反向通道」。一个没有 LLM 凭证的 Server 可通过 Sampling 请求 Client 代为调用。

flowchart LR
    H[Host<br/>用户应用] -->|stdio/HTTP| C[MCP Client]
    C -->|JSON-RPC 2.0| S[MCP Server<br/>GitHub MCP]
    S -->|Sampling: create_message| C
    C -->|LLM 补全| H
    H -->|补全结果| C
    C -->|返回 Sampling 结果| S

一句话总结：Resources 读 / Prompts 模板 / Tools 写 / Roots 边界 / Sampling 反向 LLM——五者构成 MCP 的能力契约，缺一不算完整 MCP server。

四、MCP vs Function Calling：协议层 vs 模型层的本质差异

候选人最爱混淆的概念。两者边界可以这样记：

• Function Calling 属模型层 API（OpenAI / Anthropic SDK 返回 tool_calls 字段），MCP 属应用层协议（Host ↔ Server 通信契约）。
• 谁定义工具：Function Calling 由调用方在请求体里传 tools=[...]；MCP 由 Server 在握手时通过 list_tools 暴露，动态可发现。
• 进程隔离：Function Calling 通常与 LLM 调用同进程；MCP Server 可独立进程甚至跨机器部署，天然适合企业安全边界。
• 跨模型兼容：Function Calling 绑死特定厂商（OpenAI tools ≠ Anthropic tools）；MCP 与模型无关，GPT / Claude / Gemini 都可消费同一 Server。
• 安全审计：Function Calling 由应用代码自己实现；MCP Server 自带 Roots / 鉴权 / 审计日志契约。

关键认知：Function Calling 是「模型怎么调工具」，MCP 是「怎么把工具给模型」——前者是 SDK 行为，后者是生态契约。

五、企业自建 MCP Server 的 5 个真实坑

候选人如果答出"我们在公司部署了 MCP server"，面试官几乎一定追问"踩过哪些坑"。生产环境最常见的 5 个：

5 个坑的工程含义：

1. Roots 越权：Server 不强制 Client 声明 Root 时，工程师随手 Path("/") 让 Server 能读整台机器。正确做法：Client 显式传 Root，Server 校验越界。

2. 鉴权缺失：stdio 默认信任本地用户，远程部署必须加 OAuth 2.1 / API Key。Anthropic 2025 规范在 Streamable HTTP 引入 Bearer Token。

3. Sampling 黑盒：Server 反向让 LLM 补全时，审计日志常漏记实际 prompt 和响应。GDPR / 等保场景必须补全日志。

4. Tool 描述抽象：list_tools 的 description 是 LLM 决策唯一依据。"search the web" 不如 "search the web for a query string and return top-5 URLs with snippet"。

5. 协议升级：2024 用 HTTP+SSE，2025 升级到 Streamable HTTP。老 Client 不升级会连不上新 Server。

六、面试答题模板（生产工程师视角）

面试最后通常让候选人反问或谈设计思路。建议 4 段答：

1. 定位：MCP 是「Agent-工具应用层协议」，不是 OpenAI 替代品。

2. 架构：Host → Client → Server 三层 + JSON-RPC 2.0 + Streamable HTTP。

3. 五大原语：Resources / Prompts / Tools / Roots / Sampling——每条配一个企业场景。

4. 落地坑：Roots 越权 + 鉴权缺失 + Sampling 黑盒 + Tool 描述抽象 + 协议升级兼容性，至少展开 2 个。

5. 对比：明确 Function Calling（模型层）vs MCP（应用层）边界。

时长 3-4 分钟，每个原语配具体例子比抽象描述分高。

参考资料：

官方文档

• Anthropic: Introducing the Model Context Protocol - MCP 首次发布公告（2024-11）
• MCP 官方规范 modelcontextprotocol.io - 协议介绍页
• MCP Specification 2025-06-18 - 最新规范（Streamable HTTP）
• Anthropic Docs: Connectors / MCP - Claude 接入 MCP 官方指南
• Anthropic: Donating MCP to Agentic AI Foundation - MCP 捐赠给新成立的基金会（治理结构升级）

开源项目

• modelcontextprotocol/servers GitHub - 官方参考 Server 集合（GitHub / Filesystem / Google Drive 等）
• modelcontextprotocol/python-sdk - 官方 Python SDK
• modelcontextprotocol/typescript-sdk - 官方 TypeScript SDK
• punkpeye/fastmcp GitHub - TypeScript 高层封装
• microsoft/playwright-mcp GitHub - 微软官方浏览器自动化 MCP Server
• upstash/context7 GitHub - Upstash 官方文档实时检索 MCP Server
• lastmile-ai/mcp-agent GitHub - 在 MCP 之上构建可观测 Agent 框架
• ahujasid/ableton-mcp GitHub - Show HN：MCP 接入 Ableton Live 案例

行业报道

• AWS: Model Context Protocol - AWS 官方对 MCP 架构的解读
• IBM: What is Model Context Protocol - IBM 对 MCP 与 Function Calling 边界的分析
• Stephen Diehl: Adventures in Symbolic Algebra with MCP - MCP 用于符号代数的实战案例

社区讨论

• HN Search: Model Context Protocol - HN 长期聚合讨论入口
• 掘金搜索: MCP 协议 - 中文社区 MCP 解读合集

对比基准

• MCP 官方仓库 README - 协议版本演进 + 各 SDK 兼容性矩阵

本文由 AI 生成。内容基于公开资料整理，可能存在事实偏差，引用链接请以原始来源为准。