若你正在为 Claude、GPT、Gemini 分别写 CRM / 数据库 / API 适配层，或在 Cursor 里反复配置各不相同的工具接入——你正身处 AI 世界的「互联网诞生前」：N 个模型 × M 个工具 = N×M 次定制集成。本文面向开发者与架构师，用 TCP/IP→HTTP 的历史类比解释 MCP（Model Context Protocol） 为何在 2026 年成为行业标准；含 REST 对比表、JSON-RPC 架构、四大厂商入局时间线与六步落地清单，并衔接远程 Mac 常驻 MCP Server 的生产建议。
1970 年代，ARPAnet、Ethernet 各自为政，每次互联都要定制翻译层——直到 TCP/IP 统一通信规则，HTTP 再在其上构建万维网。2024 年前的 AI 生态，正处于同一种混沌：LLM 训练数据有截止、无法访问实时信息、无法执行操作；给 AI 接上「手脚」后，碎片化反而更严重。
N×M 定制集成：ChatGPT Plugins、OpenAI Function Calling、Claude Tool Use、各 IDE 插件格式互不兼容——N 个 AI 模型 × M 个外部工具意味着 N×M 套适配代码；换模型供应商就要推倒重来。
企业 CRM 三重开发：同一套 CRM 需为 Claude、GPT、Gemini 分别写接入层，维护成本随模型数量线性膨胀。
IDE 助手各玩各的：访问文件系统、数据库、API 的方式在 Cursor、VS Code 扩展、JetBrains 插件间无法复用。
Agent 框架孤岛：LangChain、CrewAI 等编排框架的工具定义无法跨框架复用，编排逻辑与工具层紧耦合。
REST API 的 Agent 盲区：传统 API 静态文档、无状态请求、不可自描述——AI 无法在运行时自主发现「自己能调用什么」。
类比 USB 接口混乱期：Mini-USB、Micro-USB、Lightning 各据一方；MCP 要做的是 AI 工具集成领域的 USB-C——设备无需关心对方是谁，插上就能通信。
「REST API 解决的是『能不能调用』；MCP 解决的是『AI 如何发现、选择并正确调用工具』——这才是 Agent 时代的核心命题。」
下表从问题、解决方案到开放性，把 MCP 与 HTTP 的类比落到可对比的维度；并说明为何「直接用 REST」无法根治 N×M 问题。
| 维度 | 互联网时代（TCP/IP + HTTP） | AI Agent 时代（MCP） |
|---|---|---|
| 核心问题 | 不同网络协议互不兼容 | 不同 AI 工具集成方式各异 |
| 解决方案 | 统一通信语言，设备互联 | 统一工具接口，AI 互联 |
| 开放性 | 开放标准，任何人实现 | 开源协议，任何人实现 Server/Client |
| 应用层生态 | Web、Email、FTP | AI 应用生态正在成型 |
| 能力 | 传统 REST API | MCP |
|---|---|---|
| 工具发现 | 开发者读文档、硬编码 | 运行时 tools/list 动态获取清单 |
| 会话状态 | 无状态，上下文需手动传递 | 持久连接，支持多步骤工作流 |
| 自描述 | API 不告诉 AI 参数含义与副作用 | 每个工具附带 JSON Schema |
| 通信方向 | 单向请求-响应 | 双向：Server 可反向请求 LLM 推理或向用户追问 |
Model Context Protocol（模型上下文协议）由 Anthropic 于 2024 年 11 月正式开源，定义 AI 模型（客户端）与外部工具/数据（服务端）之间的统一通信规范。核心思想：把「AI 能发现哪些工具、如何调用它们」标准化。
| 传输方式 | 适用场景 | 特点 |
|---|---|---|
| STDIO | 本地子进程 | 零依赖、启动快、隔离性好（详见站内 stdio vs HTTP 对照篇） |
| HTTP + SSE | 远程/云端服务 | 跨网络调用、水平扩展（需注意 session affinity） |
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "query_database",
"arguments": { "sql": "SELECT * FROM users LIMIT 10" }
},
"id": 1
}
底层基于 JSON-RPC 2.0：tools/list 运行时发现工具、resources/read 读取数据、tools/call 执行操作——与 REST 的「先读文档再硬编码」形成鲜明对比。
2024 年 LLM 能力突破阈值，Agent 成为主流范式，工具调用碎片化已极度尖锐——MCP 在正确的时间提供了正确的抽象。以下为 2026 年可引用的生态时间线与落地步骤。
| 时间 | 里程碑 |
|---|---|
| 2024 年 11 月 | Anthropic 开源 MCP 规范 |
| 2025 年 | Cursor、Zed、Continue 等 IDE 原生支持 |
| 2026 年 Q1 | OpenAI 宣布采用 MCP（1 月） |
| 2026 年 Q2 | Google DeepMind CEO 宣布 Gemini 支持 MCP（2 月）；Microsoft 完成支持 |
| 2026 年 Q2 | 治理权移交 Linux Foundation 旗下 Agentic AI Foundation（AAIF） |
截至 2026 年，MCP 生态已有超过 10,000 个 MCP Server——每新增一个 Server，所有兼容 Client 立即可用；每新增一个 Client，所有已有工具立即可被调用。这正是 HTTP 奠定 Web 生态时的网络效应。
选定传输模式：本地开发优先 stdio（子进程隔离）；团队共享或云端部署选 HTTP + SSE，并规划 session 亲和与鉴权。
在 Host 中启用 MCP Client：Cursor Settings → MCP、Claude Desktop claude_desktop_config.json，或 OpenClaw Gateway 侧注册（参见 网关白名单篇）。
配置 MCP Server 入口：声明 command/args（stdio）或 URL（HTTP）；版本升级时锁定 Server 版本，避免 schema 漂移。
验证 tools/list：启动后确认 Agent 能动态发现工具清单与 JSON Schema，而非依赖硬编码函数名。
沙箱试跑 tools/call：用只读工具（如文件浏览、查询）验证参数解析与副作用描述；生产前加白名单与 OAuth（2026 路线图重点）。
生产部署到独占执行节点：多 MCP Server 并行 + 长会话 Agent 建议放在远程 Mac 上 7×24 运行，避免笔电睡眠与子进程 OOM（参见 stdio 子进程治理篇）。
与 A2A 的分工：Google 的 Agent-to-Agent（A2A） 协议定义 Agent 之间的横向通信；MCP 负责 AI ↔ 工具/数据的垂直集成——两者互补，共同构成 Agent 互联网的协议栈。
边界提醒：MCP 尚未完善统一「服务器注册表」（类比无 DNS 的互联网）；约 1,000 个 MCP Server 处于暴露且未授权状态，间接提示注入攻击已被记录——生产务必加鉴权与网络隔离。
以下数据与结论可直接引用至技术选型文档；来源为 Anthropic 公开规范、行业分析与 2026 年生态报道。
在笔电上跑通一两个 stdio MCP Server 不难，但多 Server 并行、stdio 子进程堆积、HTTP SSE 长连接会让 16GB 内存机器频繁 swap；廉价 Linux VPS 又无法承载需要 macOS 工具链的构建类 Server。纯本地或通用云 VM 在长会话稳定性、Keychain 隔离、合盖不中断上往往力不从心。
对需要把 MCP 作为生产基础设施、同时跑 Cursor / Claude Code Agent 与 iOS CI 的团队，在协议层完成「写一次、到处跑」之后，把 MCP Server 与 Agent 宿主放在可独占的云端 Mac 上，通常比把所有负载押在本地笔电更可控。NodeMini Mac Mini 云端租赁可作为 MCP + Agent 的 7×24 执行层：换底层 LLM 时 SSH 节点与 Server 配置保持不变。规格见 租赁价格说明，接入见 帮助中心。
「HTTP 没有发明浏览器，但没有 HTTP 就没有浏览器生态；MCP 没有发明 AI Agent，但它正在成为 Agent 生态能够存在的基础设施。」
REST 解决「能不能调用」——静态文档、无状态、需硬编码。MCP 解决「AI 如何发现、选择并正确调用」——运行时 tools/list、有状态会话、JSON Schema 自描述与双向通信。详见 租赁价格说明 了解 Agent 长会话硬件建议。
Anthropic 于 2024 年 11 月开源 MCP。2026 年 OpenAI（1 月）、Google Gemini（2 月）、Microsoft 均已支持；Cursor、Zed 等 IDE 原生集成。治理权已移交 Linux Foundation AAIF。
轻量 stdio Server 可在本地子进程运行；多 Server 并行 + 长会话 Agent 建议用独占远程 Mac 7×24 承载，避免笔电睡眠与子进程 OOM。接入步骤见 帮助中心，与站内 stdio 子进程治理 篇配合阅读。