MCP 协议研究：AI 上下文集成的架构与实践指南

写在前面：为什么 MCP 不是一个技术标准，而是一次架构范式转移

2024年底，Anthropic 推出了 Model Context Protocol（MCP），一个看似轻量级却暗藏巨大野心的开放协议。当我第一次深入阅读 MCP 的规范文档时，感受到的不是又一个 API 标准的诞生，而是一种与 REST、GraphQL 一脉相承的架构思维进化——只是这一次，主角从人机交互变成了 AI-系统交互。

如果说 REST 解决了 Web 服务的资源表述问题，GraphQL 解决了查询灵活性问题，那么 MCP 要回答的是：大语言模型如何安全、可控、标准化地与现实世界的工具和数据建立连接？

这篇文章不想做成 MCP 文档的中文翻译。我希望以技术和产品的双重视角，和你一起拆解 MCP 的架构设计逻辑、背后的取舍权衡、以及在实际落地中真正值得关注的坑与路。

---

第一章：理解 MCP 之前，先理解那个被忽视的问题

1.1 AI 集成的「巴别塔困境」

在 MCP 出现之前，每一个想要让 LLM 接入数据的开发者都活在同样的噩梦里。

假设你要构建一个 AI 编程助手，它需要读取代码仓库、查询 Jira 工单、搜索内部文档、调用编译命令。在传统模式下，你需要：

• 为代码仓库写一个文件读取模块
• 为 Jira 写一个 REST API 客户端
• 为内部知识库对接一个搜索 SDK
• 为 shell 命令写一个安全执行沙箱

每个模块的认证方式不同、错误处理不同、数据格式不同。更致命的是，如果某个数据源换了个 API 版本，你的 AI 应用也得跟着变。这种耦合的本质问题是：AI 应用的逻辑和它所依赖的外部上下文之间没有清晰的边界。

这就像在巴别塔建造中，每个工匠都在用各自的语言——最后塔没建成，只留下一堆互不兼容的胶水代码。

1.2 从「应用为王」到「上下文为王」

传统软件架构中，应用是中心。数据库、文件系统、第三方 API 都是围绕应用来设计的。但在 AI 时代，这个假设被颠覆了——LLM 是一个「通用推理引擎」，它需要的是灵活的上下文注入，而不是僵硬的接口绑定。

MCP 背后的核心洞察是：AI 应用不应该知道数据的来源和细节，它只需要知道「我能调用什么工具」和「我能获取什么资源」。 这是一个从「实现耦合」到「协议解耦」的跳跃，与 Unix 哲学中「一切皆文件」的思路如出一辙——只是在 AI 时代，变成了一切皆上下文。

1.3 MCP 的三大设计约束

理解 MCP 的设计，必须理解它给自己设定的三大约束：

第一，用户控制优先。 MCP 的所有交互都设计为让用户处于控制地位。工具调用可以被拦截和审批，资源访问需要用户授权，采样请求需要用户确认。这不是为了麻烦，而是为了信任——没有用户信任的 AI 系统，再强大也无法落地。

第二，传输无关性。 MCP 的消息格式是 JSON-RPC 2.0，但传输层可以自由替换。stdio 适合本地进程通信，SSE 适合远程调用，未来甚至可以有 WebSocket、gRPC 等实现。这种分层设计让 MCP 可以适应从嵌入式设备到云端集群的各种场景。

第三，能力协商。 客户端和服务端在连接初始化阶段就通过能力协商明确各自支持的功能——我支持工具调用，你支持资源订阅——然后双方在达成一致的能力边界内交互。这避免了版本地狱，也为协议的未来演进留下了空间。

---

第二章：架构拆解——MCP 的四个核心原语

MCP 定义了四个核心原语：资源（Resources）、工具（Tools）、提示词（Prompts）、采样（Sampling）。理解这四个原语的本质差异和设计哲学，是掌握 MCP 的关键。

2.1 资源：数据世界的「文件系统」

资源是 MCP 中最直观的概念——服务器暴露给客户端的数据。它可以是文件内容、数据库记录、API 响应、系统日志，甚至是一张截图。

资源的 URI 设计值得玩味。MCP 没有规定死 URI 的格式，而是留下了一个灵活的命名空间：protocol://host/path。这意味着资源不仅仅是文件系统路径，它可以指代任意抽象的数据实体。例如：

• file:///home/user/project/main.py
• postgres://database/customers/schema
• screen://localhost/display1

这种设计借鉴了 Web 的 URI 统一性，但更开放——每个 MCP 服务器都可以定义自己的 URI Scheme。关键在于，资源的 URI 要让 LLM 能够理解它的语义层级和归属关系。

资源的「应用程序控制」设计也是一个深思熟虑的决定。与工具不同，资源不是被 LLM 主动调用的，而是被客户端应用呈现给用户的。用户来决定是否以及何时将某个资源作为上下文提供给 LLM。这种设计降低了提示注入的风险——LLM 不会因为一个恶意的 prompt 就主动去读取敏感数据。

资源模板和订阅机制是容易被忽略但极其重要的特性。资源模板（RFC 6570 URI Template）允许服务器声明「我可以通过这种模式访问大量资源」，而不必预先生成所有资源的列表。订阅机制则让客户端可以监听资源的动态变化——这在实时监控、日志跟踪等场景中至关重要。

2.2 工具：LLM 的「双手」

如果说资源是 LLM 的眼睛——用来观察世界，那么工具就是 LLM 的双手——用来改变世界。

工具的设计哲学与资源截然相反。工具是模型控制的（Model-Controlled），这意味着 LLM 可以在推理过程中主动决定调用哪些工具。这看起来简单，其实是 LLM 从「对话式 AI」走向「行动式 AI」的关键一步。

一个 MCP 工具的定义包含三个要素：

• 名称：唯一标识符，LLM 通过名称来引用工具
• 描述：人类可读的自然语言说明，这是给 LLM 看的核心文档
• 输入 Schema：基于 JSON Schema 的参数定义，严格约束了工具的输入

为什么描述如此重要？因为 MCP 世界中的「用户」不仅仅是人类，还有 LLM。一个工具的描述就是 LLM 的 API 文档——写得清晰与否直接决定了 LLM 能否正确调用它。

Anthropic 的推荐实践是：在工具描述中嵌入使用示例。例如：

"获取特定股票的当前价格和近期走势数据。"
"入参 symbol 为股票代码，例如'AAPL'代表苹果公司。"
"调用示例：get_stock_price(symbol='TSLA') 返回特斯拉当前股价。"

这种「为 LLM 设计 API」的思维方式与传统的 API 文档完全不同。传统 API 文档面向的是人类的开发者，而 MCP 工具描述面向的是 LLM——它需要是确定的、无歧义的、自包含的。

工具调用的错误处理同样别具匠心。MCP 明确建议：工具层面的错误应当在结果对象内报告（通过 isError 标记），而不是作为 JSON-RPC 协议级错误抛出。为什么？因为当工具调用失败时，LLM 可以看到错误信息，并自主决定下一步动作——重试、换一种参数、或者通知用户。如果直接抛出协议级错误，LLM 就失去了纠错的机会。

2.3 提示词：可复用的「交互模式」

提示词是我认为 MCP 中最被低估的能力。本质上，提示词是一组预定义的模板化对话——可以是单条消息，也可以是多轮交互的工作流。

提示词的存在揭示了 MCP 对 LLM 交互模式的一个深刻理解：大量有价值的 LLM 交互是模式化的，而非即兴的。

想想日常使用场景：「总结这份代码」「分析这段日志」「对比两个版本的区别」——这些都是重复出现的交互模式。如果每个开发者都去自己写 prompt，不仅效率低下，还质量参差不齐。

MCP 的提示词机制让服务器可以暴露出这些经过精心设计的交互模板，客户端可以将其呈现为斜杠命令、快速操作、上下文菜单项等 UX 形态。这不是简单的 prompt 共享——它是一个生态级的交互标准化基础。

提示词天然支持动态参数和资源嵌入。一个分析代码的提示词可以接受 language 和 fileUri 参数，然后在生成对话时自动嵌入对应文件的内容。这让提示词不再是死板的模板，而是可以感知上下文的智能交互入口。

2.4 采样：一次危险的「递归」

采样是 MCP 中最具争议但也最具潜力的原语。它的核心思想是：让 MCP 服务器可以向客户端请求 LLM 生成内容。

这听起来有点绕——LLM 让 AI 应用去请求 LLM 生成内容？是的，这是一种递归式的能力。想象一个复杂的代理工作流：主 LLM 在处理一个任务时，发现需要另一个 LLM 帮忙分析一段代码——它可以通过 MCP 的采样机制向客户端发起请求，客户端再向另一个 LLM 采样补全结果。

采样的关键在于「人在环路」（Human-in-the-Loop）设计。MCP 要求客户端在向 LLM 发送采样请求之前，必须先展示给用户查看和修改的机会；在收到补全结果之后，也要展示给用户确认。这意味着采样不是一个黑盒递归，而是一个受控的、可审计的协作过程。

模型偏好（Model Preferences）是采样中的一个精致设计。服务器可以表达对成本、速度、智能的三个维度的优先级（0-1），客户端根据自己的可用模型和这些偏好来做出最终选择。这为未来的多模型协同场景铺平了道路——想象一个系统，用便宜的小模型做预处理，用昂贵的大模型做核心推理，MCP 的采样机制天然支持这种编排。

不过坦率地说，采样目前在 Claude Desktop 中尚未支持，这意味它的实际生态验证还在早期。采样虽然理论上强大，但生产级的安全性验证仍需时日。

---

第三章：传输层——从本地到全球的连接选择

3.1 stdio：最简单的往往就是最好的

MCP 的 stdio 传输非常简单：客户端启动一个子进程，通过标准输入发送 JSON-RPC 消息，从标准输出读取响应。服务端的标准错误则被用于日志输出。

这种设计看起来很朴素，但它解决了一个极其重要的问题——进程隔离与安全隔离。MCP 服务器运行在独立的进程中，拥有自己的文件系统访问权限、网络栈、和生命周期。即使某个 MCP 服务器被攻破，攻击者也无法直接访问宿主应用的内存空间或其他 MCP 服务器的数据。

这也是为什么 stdio 被推荐用于本地场景——它天然提供了操作系统级别的隔离，不需要额外的容器化或沙箱化。

3.2 SSE：通往远程世界的桥梁

当 MCP 服务器不在同一台机器上时，就需要网络传输。MCP 选择了 SSE（Server-Sent Events）作为标准远程传输方案。

SSE 的选择耐人寻味。为什么不是 WebSocket？为什么不是 gRPC？这背后是 MCP 的通信模式决定的：

• MCP 的核心交互是「客户端发起请求，服务端返回响应」
• JSON-RPC 本身就是 request-response 模式
• SSE 天然适合服务端到客户端的单向推送，而 HTTP POST 则处理反向通信

这种组合的优势在于简单、兼容性好。SSE 可以跑在任何标准 HTTP 基础设施上——负载均衡器、反向代理、CDN——都不需要特殊配置。WebSocket 虽然双向通信更优雅，但在企业网络中经常被代理和防火墙阻断。

当然，SSE 也有局限。它的单向性意味着服务端不能主动发起请求（至少在标准 SSE 中不能）。目前 MCP 的 SSE 实现中，客户端到服务端的消息通过独立的 HTTP POST 端点完成，这种非对称设计在某些高实时场景下可能成为瓶颈。我期待 MCP 社区能看到 WebSocket 传输的正式标准出现。

3.3 自定义传输：当标准不够用的时候

MCP 定义了清晰的 Transport 接口，协议层与传输层完全解耦。这意味着如果你需要自定义传输——比如通过 WebSocket、gRPC、Unix Domain Socket、甚至 RFCOMM 蓝牙串口——都可以通过实现 Transport 接口来完成。

这种设计对嵌入式、IoT、边缘计算场景尤其有价值。想象一个在智能家居边缘节点上运行的 MCP 服务器，通过轻量级的本地 IPC 与中心服务器通信——标准的 HTTP/SSE 栈可能太重了，但自定义传输可以做到。

---

第四章：连接的生命周期——一场优雅的握手

4.1 初始化：能力协商的艺术

MCP 的连接初始化是我认为设计得最精巧的部分之一。它不是一个简单的「连接-握手-就绪」三步走，而是一个双向能力协商的过程。

客户端发送 initialize 请求时，会携带自己的协议版本和支持的功能列表。服务端响应时，也会声明自己的能力和协议版本。关键的是，如果双方支持的协议版本不匹配，协商就失败——这在早期协议演进中尤为重要。

初始化完成后，客户端发送 initialized 通知作为确认。从这时开始，正常消息交换才能进行。这个设计确保了：在双方明确确认能力和版本之前，没有任何业务消息会意外触发。

4.2 消息交换：请求、响应与通知

MCP 的消息交换基于 JSON-RPC 2.0，支持三种消息类型：

• 请求（Request）：需要对方响应，携带唯一的 id
• 响应（Response）：对请求的成功响应或错误响应，通过 id 关联
• 通知（Notification）：不需要响应的单向消息

这个模型简单但不简陋。通知机制让服务端可以主动推送事件——资源变更、工具列表更新、错误告警——而客户端不需要轮询。

有一个容易被忽略的设计细节：JSON-RPC 的通知没有 ID。这意味着它们不需要回复，但也意味着发送方无法知道通知是否被收到。这在可靠性敏感的场景下需要额外处理——比如为关键通知自行实现确认机制。

4.3 终止：优雅的告别

MCP 的终止可以是主动关闭（调用 close()），也可以是被动断开（传输层断开）。设计上的关键点在于资源清理——当连接终止时，协议层应确保所有进行中的请求被正确取消，所有资源被释放，所有订阅被清理。

这在生产环境中非常重要。一个 MCP 服务器可能服务于多个客户端连接，如果一个客户端异常断开，服务器必须确保不会留下孤儿进程或未释放的文件句柄。

---

第五章：使用场景全景——从开发者体验到企业级集成

5.1 开发者工具：MCP 的原生场景

MCP 最成功的使用场景目前集中在开发者工具领域。Claude Desktop 通过 MCP 协议集成文件系统、GitHub、数据库等工具，让 AI 编程助手不再只是一个聊天的盒子。

在代码生成场景中，MCP 的能力链是这样运作的：

1. LLM 需要读取项目结构 → 通过文件系统资源工具获取目录树
2. LLM 需要理解现有代码 → 通过资源读取具体文件的代码内容
3. LLM 需要查询 API 文档 → 通过 MCP 服务器访问内部 API 文档库
4. LLM 需要执行命令验证代码 → 通过工具执行编译或测试命令
5. LLM 发现了代码问题 → 通过工具创建 GitHub Issue

整个过程没有硬编码任何数据源，没有重复造任何轮子。MCP 服务器是插件式的——你想加一个 ESLint 检查工具？写一个 MCP 服务器，注册到配置中，LLM 就能用了。

5.2 企业级集成：身份与权限的战场

在企业场景中，MCP 的价值被放大，挑战也随之而来。

价值在于标准化。 一个大型企业可能有几十个内部系统——CRM、ERP、HR 系统、知识库、监控平台、CMDB。如果每个系统都要为 AI 集成单独开发，成本将难以估计。通过暴露 MCP 服务器，所有系统都通过同一个协议向 AI 层提供服务。

挑战在于安全。 企业级 MCP 部署必须解决几个核心问题：

• 身份认证：每个 MCP 请求必须携带用户身份，确保操作可审计
• 权限控制：用户只能访问其被授权访问的资源和工具
• 数据隔离：多租户场景下，不同用户的数据必须在 MCP 服务器层面隔离
• 审计日志：所有 AI 发起的操作都必须有完整的轨迹

目前的 MCP 协议在传输层安全（TLS）和身份验证方面有明确建议，但更细粒度的授权模型仍属于实现者的责任范围。这意味着在企业落地时，需要在 MCP 服务器内部实现一套独立的 RBAC/ABAC 机制。

5.3 智能体编排与多智能体系统

MCP 采样原语虽然尚未广泛支持，但它为多智能体编排打开了一扇门。

考虑一个多智能体客服系统：用户提出一个复杂的技术问题 → 主智能体（客户助手）判断需要后端工程师协助 → 通过采样机制请求辅助智能体 → 辅助智能体查询知识库 + 检查日志 → 返回分析结果 → 主智能体整合信息回复用户。

通过 MCP 的采样，不同智能体之间的通信不再是点对点的定制集成，而是通过一个统一的协议层完成。更重要的是，这种通信始终处于用户的可见范围内——人在环路的控制意味着每一次子智能体调用都是可审计、可追溯的。

5.4 AI 驱动的自动化工作流

MCP 的工具和资源原语天然适合构建自动化工作流。与传统 RPA（机器人流程自动化）不同，MCP 的工作流是事件驱动的、动态规划的——LLM 在运行时根据上下文决定调用哪些工具和以什么顺序调用。

例如，一个 IT 工单自动处理流程：

1. 收到新的工单 → 资源更新通知触发
2. LLM 读取工单内容 → 通过资源读取
3. LLM 查询 CMDB 获取服务信息 → 通过工具调用
4. LLM 搜索知识库寻找解决方案 → 通过资源搜索
5. LLM 执行临时修复命令 → 通过工具执行
6. LLM 自动回复工单并关闭 → 通过工具操作

整个过程不需要预定义固定的流程路径——LLM 根据具体问题动态决策。对于那些「知道怎么做但不想亲自做」的日常任务，MCP 提供了一条高效路径。

---

第六章：深入最佳实践——来自一线的经验和教训

6.1 工具设计：为 LLM 设计 API

精准的命名规范。 工具名称是 LLM 选择的依据之一。好的命名是自描述的——calculate_sum 好于 calc1，github_create_issue 好于 issue。动词+名词的命名风格让 LLM 更容易理解工具的用途。

详尽的输入 Schema。 JSON Schema 不仅是参数校验的工具，更是 LLM 理解工具输入的语言。每一个属性的描述、类型、取值范围、默认值都应该清晰标注。对于枚举类型的参数，将所有可能值列出是必要的。

工具粒度的权衡。 工具太粗——一个工具做太多事情——LLM 难以理解和使用。工具太细——每次调用只做一小件事——会增加 LLM 的调用次数和上下文消耗。我的经验是：一个工具完成一个原子操作，但如果多个原子操作总是同时出现，考虑合并。

错误消息即人性。 MCP 的错误不是吐给开发者的堆栈跟踪，而是吐给 LLM 的自然语言。一个好的错误消息应该告诉 LLM：发生了什么、为什么发生、以及接下来可以怎么做。例如，「错误：查询超时，建议重试或检查网络连接」胜于「Error: E11000 timeout」。

6.2 资源设计：告诉 AI 世界长什么样

URI 的语义化。 资源的 URI 是它在 MCP 世界中的地址。一个好的 URI 应该让 LLM 在查看 URI 时就能大致知道资源的性质——比如 file:///project/src/main.py 显然是一段 Python 源码，而 database://customers/active 明显是客户数据。

资源描述的完整性。 每个资源都应该有完整的 name 和 description。LLM 通过 resources/list 获取所有资源的概览后，会根据这些描述决定哪些资源值得读取。描述含糊的资源会被 LLM 忽略。

动态资源模板。 对于大量结构相似的资源，使用 URI 模板而非枚举。例如，一个日志服务器可以暴露模板 logs://{service}/{date}，而不是为每个服务每天生成一个静态资源。

6.3 提示词设计：模板化的 AI 交互

参数化是灵魂。 纯静态的提示词价值有限。真正有用的提示词模板应该通过参数接受动态输入，然后在生成对话时将参数值嵌入到合适的位置。

多轮对话是杀手锏。 静态的单条消息很容易写，但真正的交互价值在于多轮对话模板。例如，一个「辅助调试」提示词可以初始化为一个完整的调试对话框架——包含系统指导、代码上下文、以及引导性的提问。

资源嵌入增强感知。 提示词支持嵌入资源内容作为上下文。这意味着一个「代码审查」提示词可以自动包含 file:///project/ 下多个文件的内容，让 LLM 拥有完整的代码上下文感知。

6.4 错误处理：让 LLM 能够自救

MCP 的错误处理哲学与传统的 REST API 截然不同。传统 API 中，错误意味着任务终止——客户端需要处理异常。MCP 中，错误是 LLM 工作流的一部分。

不要在协议层面吞掉错误。 使用 isError: true 标记将错误信息返回给 LLM，而不是在服务器内部静默处理。

给 LLM 回头看的能力。 错误消息应该包含 LLM 做出下一步决策所需的信息。不仅仅是「失败了」，而是「失败原因是什么，可选的替代方案是什么」。

不要暴露敏感的内部信息。 这个安全原则同样适用于错误处理——LLM 可以知道操作失败了，但不应该知道具体的栈追踪或 SQL 查询内容。

---

第七章：高级用法——超越入门级别的 MCP 实践

7.1 组合多个 MCP 服务器构建智能管道

单个 MCP 服务器可能能力有限——它只知道自己领域的数据和工具。真正的魔力在于将多个 MCP 服务器组合成一个智能管道。

考虑一个「安全事件响应」管道：

• 安全监控 MCP 服务器：暴露威胁告警资源和查询工具
• 资产管理 MCP 服务器：暴露 CMDB 资源和主机查询工具
• 知识库 MCP 服务器：暴露标准操作流程（SOP）提示词
• 工单系统 MCP 服务器：暴露创建和更新工单的工具
• 脚本执行 MCP 服务器：暴露安全的命令执行工具

当安全监控服务器推送一条告警时，主 LLM 可以通过多个 MCP 服务器协作完成响应：查询受影响资产 → 匹配 SOP → 执行隔离命令 → 创建跟踪工单。整个过程是动态编排的，不需要预设的 playbook。

7.2 动态工具注册与运行时演进

MCP 支持工具列表的动态变更。服务器可以通过 notifications/tools/list_changed 通知客户端工具列表发生了变化。这意味着工具可以在运行时按需注册和注销。

这种能力在以下场景中特别有价值：

• 插件系统：用户在运行时安装/卸载插件，每个插件注册一组工具
• 租户隔离：根据当前用户的租户身份动态暴露不同的工具集
• 灰度发布：新工具先在部分用户侧启用，观察效果后再全量推送
• 负载感知：高负载时注销计算密集型工具，低负载时重新激活

7.3 资源订阅驱动的实时智能场景

传统 AI 交互是「用户提问 → AI 回答」的拉取模式。MCP 的资源订阅机制为推送模式打开了大门。

设想一个实时代码审查助手：当开发者在 IDE 中修改代码文件时，MCP 服务器监控文件变更并通过 notifications/resources/updated 推送给客户端。预置的代码审查提示词自动获取变更内容，LLM 在后台完成审查并将建议以代码注释或诊断信息的形式呈现。

这个过程不需要用户显式触发——资源的动态变化本身就是事件的触发器。

7.4 跨 MCP 服务器的采样编排

当采样功能就绪后，一个更高级的使用场景是跨服务器的采样编排：

1. 服务器 A（数据分析）分析了一个报表，发现数据异常
2. 服务器 A 通过采样请求客户端调用 LLM 来分析异常原因
3. LLM 判断需要查询服务器 B（业务系统）来获取更多上下文
4. 客户端将服务器 B 的上下文包含在采样请求中
5. LLM 完成分析，将结果返回给服务器 A
6. 服务器 A 根据分析结果自动生成报告

这种编排模式下，MCP 服务器不再是孤立的工具提供者，而是形成了一个分布式的智能网络——每个服务器贡献自己的数据和能力，LLM 作为推理中枢贯穿其中。

---

第八章：生产环境中的实战考量

8.1 性能指标与基准测试

首次连接延迟。 MCP 连接的初始化涉及能力协商和握手。对于 stdio 传输，初始化通常在 50-200ms 内完成（取决于服务器启动时间）。对于 SSE 传输，需要额外考虑网络延迟和 TLS 握手时间，建议目标控制在 500ms 以内。

工具调用延迟。 从客户端发起工具调用到收到响应的端到端延迟，由传输层延迟 + 服务器处理时间组成。本地 stdio 场景下，简单工具（如数值计算）的调用延迟应 < 50ms。远程 SSE 场景下，受网络影响，建议目标控制在 200ms 以内。

并发性能。 MCP 当前没有官方的并发基准测试数据，但从架构分析来看：

• stdio 模式：每个服务器进程处理一个连接，并发能力取决于进程管理策略
• SSE 模式：一个服务器可以处理多个连接，但需要注意连接数的上限
• 单服务器的推荐初始设置为支持 50-100 个并发连接

吞吐。 消息吞吐量主要受限于 JSON-RPC 消息序列化/反序列化开销和传输层带宽。对于大多数使用场景，MCP 的吞吐瓶颈不在协议层，而在 LLM 的响应速度和工具自身的处理能力。

8.2 安全性与零信任架构

传输层安全。 远程 MCP 连接必须使用 TLS 加密。这是一个不可妥协的安全基线。同时建议实现双向 TLS（mTLS）来实现客户端证书认证。

输入验证的纵深防御。 MCP 服务器必须对所有输入进行验证，不能依赖客户端或 LLM 的善意。关键防线包括：

• 参数 Schema 校验（JSON Schema validation）
• 路径穿越防护（../.. 攻击）
• 命令注入防护
• SQL 注入防护
• 大小/范围限制

限流与防滥用。 MCP 服务器应实现基于用户/客户端/IP 的多维度限流策略。对于计算密集型的工具调用，建议使用令牌桶算法控制调用频率。

审计。 所有通过 MCP 发起的操作都需要有完整的审计记录。至少应包括：时间戳、用户身份、操作类型、参数摘要、执行结果、执行时长。

8.3 可靠性工程

连接稳定性。 MCP 连接可能因网络波动、服务器重启、进程崩溃等原因断开。客户端应实现自动重连机制，建议采用指数退避策略（Initial=1s, Max=60s, Backoff=2x）。

超时管理。 不同的工具调用可能有不同的预期执行时长。为每个工具设置独立的超时阈值，并在超时时优雅地返回错误，而不是静默挂起。

优雅降级。 当一个 MCP 服务器不可用时，系统应该能够优雅降级，而不是整体崩溃。例如，当文件系统 MCP 服务器宕机时，LLM 应被告知「文件系统暂不可用」，但仍然可以使用其他 MCP 服务器提供的工具和资源。

健康检查。 实现 MCP 服务器的健康检查端点，让监控系统可以定期验证服务器状态。健康检查应该覆盖：服务器进程状态、传输层连通性、关键资源可达性。

8.4 监控与可观测性

日志体系。 MCP 服务器的日志应该分层：

• 传输层日志：连接建立/断开、消息收发
• 协议层日志：请求/响应/通知的方法和参数
• 业务层日志：工具执行、资源读取、采样请求的具体业务数据

指标收集。 应该追踪的关键指标包括：

• 活跃连接数（随时间变化的曲线）
• 消息吞吐量（每秒请求数）
• 工具调用成功率/失败率
• 平均响应延迟（P50/P95/P99）
• 资源读取频率
• 错误率分布（按错误类型）

分布式追踪。 在多 MCP 服务器协作的场景中，一个完整的用户请求可能涉及多个 MCP 服务器。建议在日志中引入请求 ID（correlation ID），贯穿所有相关的 MCP 交互，以便进行端到端的性能分析。

---

第九章：MCP 的生态位——与同类协议的关系

9.1 MCP vs Function Calling

OpenAI 的 Function Calling 是一种内置于 API 中的工具调用机制，而 MCP 是一个开放协议。两者的核心区别在于：

• 耦合度：Function Calling 与 OpenAI API 紧密绑定；MCP 是供应商中立的
• 协议深度：Function Calling 只解决「LLM 如何调用工具」的问题；MCP 还涵盖了资源暴露、提示词管理、采样等多个层面
• 生态开放性：任何实现了 MCP 的客户端都可以使用任何 MCP 服务器；Function Calling 的生态仅限于 OpenAI API 的消费者

但从另一个角度看，Function Calling 简单直接，无需额外的服务器运维，在单场景集成中比 MCP 更轻量。我认为两者的关系不是替代而是互补：OpenAI 生态内用 Function Calling，多云/多模型生态中用 MCP。

9.2 MCP vs A2A (Agent-to-Agent)

Google 推出的 Agent-to-Agent 协议（A2A）和 MCP 看似相似，实则解决不同层面的问题。

MCP 解决的是「LLM 如何与系统和数据交互」的问题——是 AI 与世界的接口层。A2A 解决的是「AI 与 AI 如何通信」的问题——是 AI 之间的协作层。

两者不是竞争关系，而是层次关系。一个典型的架构可以是：智能体 A 通过 A2A 协议与智能体 B 通信，智能体 B 通过 MCP 协议访问数据库、文件系统等底层资源。MCP 是智能体的「手和眼」，A2A 是智能体的「社交能力」。

9.3 MCP vs 传统 API 网关

有人会将 MCP 类比为 AI 时代的 API 网关。这种类比有一定的道理——两者都是标准化抽象层。但差异也是显著的：

• API 网关是同步的、请求-响应模式的；MCP 支持同步和异步模式（通知+订阅）
• API 网关面向人类开发者；MCP 面向 LLM ——描述信息、输入 Schema、错误消息都需要为 LLM 优化
• API 网关通常只有一个后端；MCP 可以在客户端同时连接多个完全异构的服务器

更好的类比是：MCP 是 AI 时代的「文件描述符」——它把各种异构的系统资源抽象为一个统一的操作接口，让 LLM 可以像操作系统管理文件一样管理上下文。

---

第十章：面向未来的思考——MCP 的演进方向

10.1 协议成熟度展望

MCP 目前还是一个年轻的协议，它的成熟需要几方面的进步：

标准化进程。 目前 MCP 由 Anthropic 主导，但作为开放协议，它需要一个中立的标准组织来治理。社区版本的分支和兼容性问题将是早期的主要挑战。

SDK 生态的完善。 当前官方 SDK 主要支持 TypeScript 和 Python。Rust、Go、Java、Kotlin 等主流语言的 SDK 需求强烈，尤其是在企业级后端场景中。

安全模型的标准化。 MCP 目前对安全模型的建议是「最佳实践」级别的，而不是「规范」级别的。随着企业采用率的提升，一个标准化的安全模型——包括身份认证、授权、审计的协议级支持——将成为刚需。

10.2 值得关注的演进趋势

多模态扩展。 当前 MCP 支持文本和图片内容类型。随着多模态 LLM 的普及，音频、视频、3D 模型等更丰富的内容类型的协议级支持将变得重要。

流式工具调用。 当前的工调用是「请求-响应」模式——调用后等待完整结果。对于长时间运行的密集型计算任务，流式工具调用（逐块返回结果）将大大改善用户体验。

双向传输标准化。 当前 SSE 传输的客户端→服务端通信机制虽然可行，但不够优雅。一个基于 WebSocket 的正式传输标准将会更好地支持双向实时通信。

联邦资源发现。 在一个大型组织中可能有数百个 MCP 服务器。如何让客户端自动发现可用的服务器和它们的能力——一个 MCP 的服务注册与发现层——将是生态扩张的关键基础设施。

10.3 MCP 对 AI 产品架构的长期影响

MCP 代表了一种新的 AI 产品架构范式：插件化的上下文架构。

在这种架构中，AI 应用的核心不是与系统的直接集成，而是运行时的工具发现和动态编排。这不仅降低了开发成本，更重要的是创造了一个开放的 MCP 服务器生态——任何人可以开发一个 MCP 服务器，任何兼容的 AI 应用都可以使用它。

类比 App Store 对智能手机生态的影响，MCP 服务器市场可能会成为 AI 时代的「应用商店」。开发者不再需要等待 AI 应用集成他们的服务——只需要开发一个 MCP 服务器，就能被所有 MCP 兼容的 AI 应用发现和使用。

在这个视角下，MCP 不只是一个协议——它可能成为 AI 时代的基础设施之一，就像 HTTP 之于 Web、SQL 之于数据库、POSIX 之于操作系统一样，成为一个时代的兼容层。

---

写在结尾：MCP 与我

作为一名长期关注 AI 基础设施的产品从业者，MCP 带给我的最大震撼不是技术本身，而是它背后的设计理念——让 AI 与世界交互的方式像操作系统的文件描述符一样标准化。

这让我想起 Linus Torvalds 说过的一句话："Unix is user-friendly — it's just picky about who its friends are." MCP 某种程度上也是——它对集成的友好不是通过消除约束，而是通过定义清晰、一致的约束来实现的。

MCP 还远未完美。它的安全模型需要完善，采样机制需要更多验证，生态规模仍在早期。但方向是对的——在 AI 从对话走向行动的转折点上，我们需要一个开放的、标准化的协议来连接 AI 和世界。MCP 是目前最有希望成为这个标准的候选者。

如果你正在搭建 AI 产品和系统，我的建议是：从今天开始关注 MCP，从小场景开始探索它。不是因为它是完美的，而是因为当开放生态的大门打开时，站在里面的机会成本远比站在外面的低得多。

未来不是 AI 学会使用我们的工具，而是我们的工具学会以 AI 能够理解的方式展示自己。MCP 就是这个转变的第一步。

重大更新：基于 2026-07-28 RC 的协议演进分析

本文撰写时，MCP 官方仓库刚刚发布了 2026-07-28 RC（Release Candidate）版本。这是一个关键的时间节点——它标志着 MCP 从早期的概念验证阶段迈向了生产级协议的标准化阶段。以下是最新版本的核心变化及其背后的设计思考。

无状态化：MCP 协议史上最重要的架构决策

核心变更

2026-07-28 RC 最根本的变化是协议从「隐含有状态」正式转为「显式无状态」。这意味着：

• 每个请求都自包含完整元数据。协议版本（io.modelcontextprotocol/protocolVersion）、客户端信息（clientInfo）、客户端能力（clientCapabilities）现在都通过 _meta 字段显式携带在每个请求中
• 服务器不得依赖连接状态来处理请求。同一连接上的先后请求之间没有任何隐含的上下文
• 连接不再是对话或会话的边界。客户端可以在同一 stdio 进程上交织多个无关请求

为什么这个决策如此重要？

在 2025-11-25 版本之前，MCP 的初始化流程是：连接建立 → 能力协商 → 开始交互。服务器依赖初始化阶段协商好的能力来理解后续请求。这在本地、单连接场景下工作得很好，但当 MCP 开始走向企业级部署——负载均衡、连接池、请求分发——这种「隐式状态」就成了架构瓶颈。

想象一个场景：MCP 服务器运行在 Kubernetes 集群中，前面挂了负载均衡器。客户端通过 stdio 发送一个初始化请求建立双向通道，但如果网络波动导致连接断开重建，之前协商的能力就丢失了。或者更糟：两个不同的客户端通过同一个传输通道发送请求，服务器无法区分它们分别支持什么能力。

无状态化直接解决了这些问题。现在每个请求都告诉服务器「我是谁」「我的协议版本」「我支持什么」，服务器不需要记住任何东西。这对水平扩展、负载均衡、请求复用来说是质的飞跃。

实现细节

新规范引入了一个关键的 _meta 字段约定：

_meta: {
  "io.modelcontextprotocol/protocolVersion": "2026-07-28",  // 必须
  "io.modelcontextprotocol/clientInfo": { name, version },   // 可选
  "io.modelcontextprotocol/clientCapabilities": {...},       // 必须
  "progressToken": "..."                                      // 可选，用于进度追踪
}

_meta 的键名有一套完整的命名规范——采用「前缀/名称」的双段结构，前缀使用反向 DNS 表示法。前缀中第二个标签为 modelcontextprotocol 或 mcp 的被保留给官方使用。

对实践者的影响

如果你正在开发 MCP 客户端或服务器，最需要关注的变化是：不要在服务器端做任何基于连接状态的数据缓存或假想。每次工具调用、资源读取都应该是无副作用的——如果需要跨请求状态，使用显式标识符（如任务 ID、会话 token）在请求参数中传递。

这个变化也简化了客户端实现：客户端不再需要维护「一个连接 = 一个会话」的映射，可以在单个 stdio 进程上高效地多路复用请求。

废弃三项原语：当「正确的事」不等于「流行的事」

Roots、Sampling、Logging 正式废弃

2026-07-28 RC 中，MCP 正式将 Roots（根目录）、Sampling（采样）、Logging（日志记录）标记为废弃。根据 MCP 的功能生命周期政策，它们将在至少 12 个月后进入可移除阶段。

这意味着：新实现不应采用这三项功能，已有实现应规划迁移路径。

为什么废弃 Roots？

Roots 的设计意图是让客户端告知服务器「哪些资源是工作区的一部分」。但在实践中，Roots 的定位有些尴尬：

• 它不是访问控制机制——协议明确声明服务器可以忽略 Roots 边界
• 它不是必需的——大多数场景下，工具参数和资源 URI 可以完成同样的事
• 它在无状态协议中难以优雅实现——Roots 的查询是通过 MRTR（Multi Round-Trip Request）模式在单个请求的上下文中完成的，而 Roots 原本存储在其他地方

SEP-2577 的迁移建议是：将目录或文件路径直接通过工具参数或资源 URI 传递，或者使用服务器配置来固定工作目录。

为什么废弃 Sampling？

Sampling 曾是 MCP 最有野心的原语——让服务器请求客户端从 LLM 采样补全。但它在实践中面临几个问题：

• 「人在环路」的安全审查虽然正确，但严重影响了用户体验——每次采样都要弹出用户确认
• Claude Desktop 从未真正支持 Sampling，导致它缺乏生产级验证
• 更简洁的模式——MRTR（Multi Round-Trip Requests）——提供了更好的替代方案

新范式：MRTR 模式

废弃 Roots 和 Sampling 后，MCP 引入了一个更通用的替代模式：Multi Round-Trip Requests（MRTR）。

MRTR 的工作原理是：

1. 客户端发送请求
2. 服务器在处理请求过程中，发现需要客户端提供额外信息
3. 服务器返回一个 resultType: "input_required" 的 InputRequiredResult，包含 inputRequests 列表
4. 客户端根据 inputRequests 补充所需信息（这些信息可以来自用户输入、采样、或客户端本地数据）
5. 客户端携带 inputResponses 和 requestState 重新发送请求
6. 服务器用补充信息完成原始请求

客户端 → 服务端：工具/调用（id: 1）
服务端 → 客户端：InputRequiredResult（需要根目录列表）
客户端 → 服务端：工具/调用（id: 2，附带根目录响应 + requestState）
服务端 → 客户端：最终结果

MRTR 比旧的采样机制更灵活——它不规定「额外信息」的来源。可以是用户手动输入、可以是客户端本地查询、也可以是 LLM 采样。这意味着客户端可以根据场景选择最适合的补充方式，而不是被强制绑定在某一模式上。

resultType 多态

MRTR 模式的一个关键基础设施是 resultType 字段。2026-07-28 RC 中，MCP 的所有结果响应现在都要求包含一个 resultType 字符串，用于指示结果类型：

• 「complete」：请求成功完成，结果包含最终内容
• 「input_required」：请求不完整，需要额外输入
• 扩展可以定义额外的 resultType 值

这个设计为协议未来的多态响应模式打开了空间。向后兼容方面，不支持 resultType 的旧服务器响应被客户端视为 "complete"。

新的传输选项：Streamable HTTP

超越 SSE 的新选择

2026-07-28 RC 在原有 stdio 和 SSE 传输之外，正式定义了 Streamable HTTP 传输。这不是对 SSE 的简单替代，而是对远程传输场景的重新思考。

Streamable HTTP 的核心是 请求-响应的流式化。与 SSE 的双通道模式（SSE 推送 + HTTP POST 反向）不同，Streamable HTTP 在一个统一的 HTTP 连接上处理所有消息，通过分块传输编码（chunked transfer encoding）实现流式返回。

优势在哪里？

• 统一的连接模型：不再需要维护 SSE 连接 + HTTP POST 两条通道
• 更好的代理友好性：标准 HTTP 流式处理，不需要特殊的 SSE 代理支持
• 更简洁的负载均衡：每个请求可以独立路由，不需要粘性会话
• 自然的请求关联：流式响应通过同一个 HTTP 请求/响应对处理

三种传输的选型建议

• stdio：本地进程间通信，安全隔离性好，延迟最低。优先选用
• SSE：需要远程访问但可以容忍双通道复杂度。适合已有 SSE 基础设施的团队
• Streamable HTTP：远程场景首选。特别是涉及负载均衡、容器化部署、API 网关的情况

扩展系统：MCP 的「插件化能力层」

Extensions 正式化

2026-07-28 RC 最大亮点之一是 Extensions 系统 的正式化。如果说核心原语是 MCP 的基础设施，那么 Extensions 就是 MCP 的应用层。

Extensions 完全是可选、按需协商的——双方在初始化时通过能力声明明确是否支持某个扩展。官方目前已定义了几个重要的扩展：

Tasks：异步长任务执行

传统 MCP 的工具调用是同步的——发送请求，等待结果。但对于需要几分钟甚至几小时执行的任务（数据分析管道、代码编译、图像渲染……），同步等待是不现实的。

Tasks 扩展提供了：

• 异步执行：提交任务后立即返回一个句柄（handle），客户端可以稍后轮询状态
• 持久化：任务句柄在服务器重启后仍然有效（需要服务器支持持久化）
• 中途输入：任务在执行过程中可以向客户端请求额外的输入（通过 MRTR 模式）
• 进度报告：任务可以持续报告进度

这是 MCP 从「短操作工具」走向「长操作工作流」的关键一步。

MCP Apps：交互式 UI 渲染

MCP Apps 是扩展中最令人兴奋的一个。它允许 MCP 服务器在对话中渲染交互式 UI 组件——图表、表单、视频播放器、数据表格。

从产品视角看，MCP Apps 解决了 LLM 交互中的一个根本矛盾：文本是 LLM 最擅长的输出格式，但人类对信息的理解常常需要可视化呈现。一个数据分析 MCP 服务器，如果只能返回「平均销售额是 X，同比增长 Y%」的文字描述，远不如直接渲染一个折线图来得直观。

MCP Apps 的实现机制是通过标准化的 UI 描述（由宿主客户端渲染），而不是传输像素。这意味着 MCP 服务器不需要关心终端用户的屏幕大小、操作系统或 UI 框架——它可以专注于数据和交互逻辑。

Skills over MCP：结构化的 Agent 指令

Skills over MCP 是一个 Working Group 的成果，旨在通过 MCP 发现和消费结构化的 Agent 指令。简单来说，它让 MCP 服务器不仅可以提供工具和数据，还可以提供「指导 LLM 如何完成任务」的结构化知识。

这有点像 MCP 的提示词系统的升级版——提示词是静态模板，而 Skills 是带有执行逻辑、条件分支、状态管理的完整 Agent 工作流。对于一个构建 AI 编码助手的开发者来说，Skills over MCP 意味着「我的助手不需要被告知如何写代码——它直接从 MCP 服务器获取编码最佳实践和流程指导」。

MCP Registry：生态基础设施的里程碑

注册中心是什么？

MCP Registry 是官方推出的 MCP 服务器发现市场。开发者可以发布自己的 MCP 服务器，任何 MCP 兼容的客户端都可以发现和安装。

在 2026-07-28 版本中，Registry 支持：

• 多种包类型（npm、PyPI 等）
• 版本管理和语义化版本控制
• 聚合器（Aggregator）机制——第三方平台可以聚合和分发 MCP 服务器
• GitHub Actions 自动化发布
• 审核与节制政策

Remote Servers 发布也得到了明确的支持——这意味 MCP 服务器可以作为网络服务注册，而不仅仅是本地安装的包。

对我来说，MCP Registry 的出现远比任何技术更新重要。生态系统的生命力不在于协议本身多么优雅，而在于它有多少可用的实现。Registry 提供的不是一个简单的目录——它是 MCP 生态的「应用商店」。

治理与标准化：从一人主导到社区共建

SEP 流程标准化

2026-07-28 RC 对应的不仅是代码层面的变更，更是社区治理结构的成熟。MCP 引入了完整的 Specification Enhancement Proposal（SEP） 流程——任何人可以提交一份 SEP 来提议协议变更，经过社区讨论、审查、最后进入规范。

目前已有超过 50 个 SEP 被提出，涵盖了从错误码标准化到 SDK 层级系统的各个方面。几个值得关注的 SEP：

• SEP-2575：Make MCP Stateless——无状态化的提案本身
• SEP-2577：Deprecate Roots, Sampling, and Logging——废弃这三者的提案
• SEP-1865：MCP Apps——交互式 UI 扩展
• SEP-2322：MRTR (Multi Round-Trip Requests)——多轮往返请求模式
• SEP-1613：JSON Schema 2020-12 作为默认方言
• SEP-1686/2663：Tasks 扩展

Working Groups 和 Interest Groups

MCP 社区形成了多个聚焦不同方向的 Working Groups 和 Interest Groups：

• Auth Interest Group：专注于授权和安全标准化
• Security Interest Group：安全攻防与最佳实践
• Financial Services Interest Group：金融行业特定需求
• Skills over MCP Working Group：Agent 技能标准化
• Registry Working Group：注册中心运营
• Triggers and Events Working Group：事件驱动模式
• SDK Working Group：SDK 标准化和层级系统
• Interceptors Working Group：请求拦截与中间件

这些 Groups 的成立表明 MCP 正在从一个由 Anthropic 主导的开源项目，转变为一个由社区共同治理的标准。

SDK 层级系统

2026-07-28 RC 伴随的另一个重要更新是 SDK 层级系统（SDK Tiering System）。不同的 SDK 被分为不同的层级，标明了它们对协议功能的完整度：

• Tier 1：全功能 SDK，支持所有核心功能
• Tier 2：次级支持，覆盖大部分功能
• Tier 3：基础支持

这个层级系统帮助开发者快速判断一个 SDK 是否满足他们的需求，也激励 SDK 维护者不断提高覆盖度。

关于更新的总结性思考

回过头来看 2026-07-28 RC 的整体特征，我看到了一个协议正在经历从「优雅的早期设计」到「生产级打磨」的蜕变。

无状态化 是一个痛苦的但正确的架构决定。它让协议失去了初始化握手的「仪式感」，但获得了水平扩展和生产部署的自由。

废弃 Roots 和 Sampling 展现了协议设计中「减去比增加更需要勇气」的道理。两者在理论上都很有吸引力，但在实践中要么被更好的模式取代（MRTR），要么缺乏足够的生态验证。

Extensions 和 Registry 标志着 MCP 从「一个协议」走向「一个平台」的转变。协议本身可能已经接近收敛——核心原语基本稳定——但协议之上的生态系统才刚刚开始生长。

对于正在观望 MCP 的团队，我的最新建议是：2026-07-28 RC 是开始认真投入的合适时机。 协议的核心变更已经趋于稳定，Extensions 提供了足够丰富的扩展能力，Registry 使得 MCP 服务器的交付和分发工具链已经可用。当然，仍然需要注意它还是 RC 版本，生产部署前建议等待正式 release。