如果你在 2026 年做 AI 应用开发还没听过 MCP，大概率已经在某个产品里间接用到它了。Model Context Protocol（模型上下文协议）由 Anthropic 在 2024 年 11 月开源，2025 年 12 月捐赠给 Linux 基金会旗下的 Agentic AI Foundation，到 2026 年初生态规模已经超过 10000 个在生产环境运行的 MCP Server、500 多个 MCP 客户端，SDK 月下载量逼近 1 亿次——增长曲线超过了 React 发布后的前三年。

2026 年 7 月 28 日，MCP 正式发布新版规范（RC 版本于 5 月 21 日公布），这是协议诞生以来最大的一次架构升级。本文讲清楚它到底改了什么，以及为什么这些改动决定了 MCP 能不能走出开发者的笔记本电脑。

先回顾：MCP 解决的 N×M 问题

没有统一协议之前，AI 应用接外部系统是典型的 N×M 困境：N 个模型/客户端（Claude、ChatGPT、Cursor、VS Code……）对接 M 个工具/数据源（GitHub、数据库、Slack、Notion……），两两适配需要写 N×M 个连接器，换个框架就要重写一遍。

MCP 把 N×M 变成 N+M：工具方写一次 MCP Server，所有支持 MCP 的客户端都能调用。它常被比作"AI 世界的 USB-C 接口"。协议基于 JSON-RPC 2.0，定义了三类核心原语：

  • Tools（工具）：让 Agent 执行操作，如创建 issue、提交代码，每个工具有明确的 input schema；
  • Resources（资源）：让 Agent 读取结构化数据，如数据库表、文件内容、API 返回；
  • Prompts（提示模板）：预定义的交互模板，让外部系统"教会"模型如何与自己协作。

传输层支持两种模式：本地进程通信用 stdio（零网络开销），远程服务用 Streamable HTTP。

核心变化一：协议转向 Stateless 无状态

早期 MCP 是明显的"会话式"设计：客户端和服务器建立 Session 并保持状态。这在本地桌面场景天经地义——Claude Desktop 连一个本地 Server，进程活着会话就在。

但上了云端，会话状态立刻变成负担。一个 MCP Server 后面挂 100 个实例做负载均衡时，基于 Session 的请求必须回到同一个实例（Sticky Session），于是需要会话存储、状态同步、复杂的负载均衡策略。

2026 新规范把协议核心改为 Stateless：每个请求尽量携带完成本次调用所需的全部信息，普通的 Round-Robin 负载均衡就能把请求分发给任意实例。这对大规模云部署是决定性的改变——无状态意味着水平扩容、故障转移、弹性伸缩都回到了 Web 服务最成熟的那套实践上。

核心变化二：Header-based Routing 让网关能"看懂" Agent

新版把 Method 和 Tool Name 放进 HTTP 请求头（如 Mcp-Method、Mcp-Name）。以前企业网关要知道 Agent 在调什么工具，得解析整个请求 Body；现在网关层直接读 Header 就能完成：

  • 路由分发（数据库工具走专用实例集群）
  • 权限控制（这个用户有没有调该工具的权限）
  • 审计与限流（谁在什么时间调了什么）

企业部署 Agent 真正担心的从来不是"模型能不能调工具"，而是调用能不能被管控。Header 路由把 MCP 流量变成了网关可观测、可治理的标准流量。

核心变化三：工具列表缓存，直接省钱

Agent 每次连接 Server 都要调 tools/list 拉取工具清单。当一个企业 Server 提供几十上百个工具时，每次全量拉取有两个坏处：网络与服务器开销；更隐蔽的是工具定义会被放进模型上下文，工具顺序或内容频繁变化会导致 Prompt Cache / KV Cache 失效——Token 成本和响应延迟双双上升。

新规范允许 tools/list 返回结果携带 Cache Hint 和确定性顺序。看似小改动，实际直接影响推理成本：工具清单稳定后，上下文缓存命中率显著提高。

核心变化四：Extensions 框架与 MCP Apps

2026 版正式确立 Extensions Framework，MCP 不再只描述"模型调用一个函数"。最值得关注的方向是 MCP Apps：传统工具调用返回一个 JSON 结果，但真实任务往往需要 UI——数据分析工具返回可交互图表、审批工具返回操作按钮、CRM 工具返回客户卡片。未来的 MCP Server 可以返回 Agent 直接展示给用户的交互界面。Tasks、长任务交互、企业授权扩展也都在这个框架下推进。

MCP 会取代 REST API 吗

不会，两者是互补关系。MCP 解决的是"Agent 动态发现工具、协商能力、跨平台复用"的问题：tools/list 支持运行时工具发现，initialize 握手支持能力协商，一套 Server 全平台可用。而 REST 依然是面向人类开发者和普通系统集成的主力。实际架构里，MCP Server 往往就是现有 REST API 的一层薄封装——把内部能力以 Agent 可理解的方式暴露出去。

开发者现在该关注什么

  • 选型：本地工具链用 stdio 传输，SaaS 化的远程 Server 用 Streamable HTTP 并按无状态设计；
  • 工具设计：input schema 写清楚描述和枚举值，工具列表保持确定性顺序以命中缓存；
  • 生产准备：协议目前仍缺少身份传播（identity propagation）、自适应超时预算、结构化错误语义这三块标准，企业落地需要在网关和编排层补齐——调用失败时 Agent 能否拿到机器可读的错误并自我纠正，是 demo 和生产的分界线；
  • 生态：微软 Copilot Studio、Azure AI Agent Service 已原生支持 MCP，主流 IDE 和客户端全面跟进，新接入工具优先考虑直接提供 MCP Server。

小结

MCP 的 2026 版规范讲了一个清晰的故事：协议设计的重心从"能连上"转向"能扛生产流量"。无状态化解决云端扩容，Header 路由解决企业治理，工具缓存解决推理成本，Extensions 打开 UI 与长任务的想象空间。对开发者来说，现在是把 MCP 从"尝鲜 Demo"纳入正式技术栈的合适时机。

下一篇我们换个方向，聊一个把算力还给用户设备的趋势：《零后端在浏览器跑大模型：WebGPU + WebLLM 端侧推理实战 2026》。