工程Mar 28, 2026

MCP 如何成为 AI 集成的 USB-C——技术深度分析

Engineering Team

N x M 集成问题

在 Model Context Protocol 出现之前，将 AI 模型连接到外部工具是一个组合爆炸的练习。每个 AI 应用程序（Claude、GPT、Gemini、Copilot）都需要为每个工具（Slack、Jira、GitHub、数据库、API）进行自定义集成。对于 M 个 AI 应用程序和 N 个工具，行业需要 M x N 个自定义适配器——每个都有自己的身份验证流程、数据格式、错误处理和维护负担。

考虑规模：到 2025 年，大约有 20 个主要 AI 应用平台和数百个企业工具。数学是不可持续的。每个新的 AI 平台都必须从头开始重建集成。每个新工具都必须为每个 AI 平台编写适配器。这与硬件行业在 USB 之前面临的问题相同：每个设备都有自己的专有连接器，每台计算机都需要不同的端口。

MCP 以 USB-C 解决连接器问题的方式解决了这个问题：标准化接口。使用 MCP，每个 AI 应用程序实现一个 MCP client，每个工具实现一个 MCP server。M x N 问题变为 M + N。一个协议，通用兼容性。

协议架构：JSON-RPC、Capabilities 和三个原语

MCP 构建在 JSON-RPC 2.0 之上，这是支持每个现代代码编辑器的 Language Server Protocol (LSP) 使用的同一轻量级 RPC 协议。这是一个深思熟虑的设计选择：JSON-RPC 简单、广为人知、与语言无关且经过实战检验。

JSON-RPC 基础

每个 MCP 消息都是一个 JSON-RPC 对象：

// Request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "sql": "SELECT * FROM users LIMIT 10"
    }
  }
}

// Response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "[{\"id\": 1, \"name\": \"Alice\"}, ...]"
      }
    ]
  }
}

三种消息类型：request（期望响应）、response（回答请求）和 notification（即发即忘）。这清晰地映射到 MCP 的通信模式。

Capability 协商

initialize 握手是 client 和 server 就其支持的功能达成一致的地方。这是优雅降级的设计。简单的只提供 tools 的服务器不需要实现 resources 或 prompts。不支持 sampling 的 client 只需省略该 capability。双方都适应对方所支持的内容。

三个原语

MCP 定义了服务器可以公开的三种能力类型：

1. Tools —— 模型控制的函数

Tools 是最常用的原语。它们代表 AI 模型可以调用的操作。模型根据用户请求决定何时以及如何调用它们。

2. Resources —— 应用程序控制的数据

Resources 提供由 host 应用程序（而非模型）决定包含在上下文中的数据。它们由 URI 标识并以各种 MIME 类型返回内容。

3. Prompts —— 用户控制的模板

Prompts 是用户可以选择的可重用模板。它们提供将指令与动态数据相结合的特定领域工作流。

这种三原语设计涵盖了 AI 工具交互的完整范围。Tools 处理操作，resources 处理数据，prompts 处理工作流。

与替代方案的比较

MCP 并非在真空中出现。在 MCP 之前，已存在几种将 AI 连接到工具的方法。理解差异解释了为什么 MCP 胜出。

MCP vs Function Calling

方面	Function Calling	MCP
工具定义	每请求，在 prompt 中	持久的，来自服务器
发现	静态，开发者定义	动态，服务器宣布工具
执行	应用代码处理	MCP server 处理
可重用性	项目间复制粘贴	一个服务器服务所有 client
有状态会话	否	是
标准协议	否（厂商特定）	是（开放规范）
多模型支持	厂商锁定	通用

MCP vs OpenAPI / REST API

方面	OpenAPI / REST	MCP
协议	HTTP（请求/响应）	JSON-RPC（双向）
流	有限（SSE、WebSocket）	原生（通知、进度）
AI 专用功能	无	Resources、prompts、sampling
Capability 协商	无	内置
会话管理	默认无状态	有状态会话

MCP vs LangChain / LlamaIndex Tools

方面	框架工具	MCP
框架依赖	锁定到一个框架	框架无关
语言依赖	Python（主要）	任何语言
部署	进程内	独立进程/服务
共享	导入库代码	连接到运行的服务器
安全边界	同一进程	进程/网络隔离

采用时间线：从 Anthropic 实验到行业标准

MCP 从单一公司的实验上升为行业标准的速度超出了所有人的预期。

2024：发布

2024 年 11 月：Anthropic 将 MCP 规范作为开放协议发布。TypeScript 和 Python 的初始 SDK。
2024 年 12 月：Claude Desktop 随 MCP 支持发布。开发者为文件系统、数据库和网页搜索构建首批 MCP server。

2025：生态系统增长

2025 Q1：Cursor、Windsurf 和其他 AI 代码编辑器采用 MCP。开发者工具生态系统爆发式增长。
2025 Q2：OpenAI 宣布在其 Agents SDK 中支持 MCP。Google DeepMind 将 MCP 集成到 Gemini tools。
2025 Q3：Microsoft 在 Copilot Studio 中添加 MCP 支持。Streamable HTTP transport 被添加到规范中。
2025 Q4：企业采用加速。Salesforce、ServiceNow 和 Atlassian 为其平台发布官方 MCP server。

2026：行业标准

2026 Q1：Gartner 将 MCP 列为 AI agent 的“关键使能技术“。MCP Registry（MCP server 公共目录）上线，列出 2,000+ 个服务器。
2026 年 3 月：Linux Foundation 宣布将托管 MCP 治理。Java、Kotlin、C# 和 Swift SDK 达到 1.0 版本。
预测：到 2026 年底，40% 的企业应用程序将包含 AI agent 能力，MCP 将成为工具集成的主导协议。

使采用成为可能的协议设计决策

几个特定的设计选择使 MCP 在先前标准失败的地方取得了成功：

1. Transport 无关性

通过将协议与 transport 分离，MCP 随处可用。相同的服务器逻辑通过 stdio（本地）、SSE（web）或 Streamable HTTP（生产）运行。

2. 渐进式复杂性

最小的 MCP server 只需 20 行代码。您可以逐步添加 resources、prompts、身份验证和多租户支持。

3. LSP 传承

构建在 JSON-RPC 2.0 之上——与 Language Server Protocol 相同的基础——使 MCP 在开发者工具团队中获得即时信誉。

4. 双向通信

与 REST（仅 client 发起）不同，MCP 支持 server 到 client 的通知。这支持实时更新、进度报告和 capability 变更公告，无需轮询。

5. 安全设计

MCP 包含 OAuth 2.0 集成、capability 范围界定和敏感操作的人在环确认。

未来：Agent 间通信和企业 MCP Gateway

通过 MCP 实现 Agent 间通信

MCP 的下一个前沿是 agent 间通信。今天，MCP 将 AI 模型连接到工具。明天，MCP server 本身将成为 AI agent，创建 AI 驱动的服务链。

企业 MCP Gateway

大型组织将部署 MCP Gateway——管理所有 MCP 流量的集中式基础设施：

发现：所有内部 MCP server 及其能力的注册表。
身份验证：统一的 SSO 集成。
授权：细粒度的 RBAC 策略。
速率限制：全局和按用户限制。
审计：每次工具调用的完整审计跟踪。
版本管理：MCP server 的蓝绿部署，自动 client 路由。

常见问题

问：MCP 是 REST API 的替代品吗？ 答：不是。MCP 是现有系统之上的一层。大多数 MCP server 内部调用 REST API。MCP 添加了 REST 原生不提供的 AI 专用能力（工具发现、resources、prompts、双向通信）。

问：为什么选择 JSON-RPC 而不是 gRPC 或 GraphQL？ 答：JSON-RPC 是可用的最简单的双向 RPC 协议。它不需要代码生成（不像 gRPC），不需要 schema 自省（不像 GraphQL），并且适用于任何可以解析 JSON 的语言。简单性推动了采用。

问：MCP 可以离线工作吗？ 答：可以。使用 stdio transport，MCP 完全在本地工作，无需网络访问。AI 模型和 MCP server 在同一台机器上运行，通过进程管道通信。

问：MCP 如何处理版本冲突？ 答：initialize 握手包含协议版本协商。如果 client 和 server 支持不同的协议版本，它们协商最高的互相支持版本。

问：MCP server 在会话中间崩溃会怎样？ 答：Client 检测到连接丢失并可尝试重连。使用 Streamable HTTP transport，会话状态存储在外部（Redis、数据库），因此新的服务器实例可以恢复会话。

问：MCP 消息有大小限制吗？ 答：协议本身没有大小限制。实际限制取决于 transport 和基础设施。对于生产部署，将单个工具响应保持在 10 MB 以下，对大数据集使用分页或流。

标签

AI Rust