MCP 2.0:从有状态到无状态,AI Agent工具协议的一次重写

摘要：2026年7月28日，Anthropic发布了MCP协议的重大更新——2026-07-28版本（MCP 2.0）。这次更新删除了会话握手和Session ID机制，把协议从有状态改成了无状态。Simon Willison在7月31日发文说这是"MCP规范发布以来最大的变化"，并一周内造了三个工具。核心变化不只是"两次请求变一次"，而是整个协议架构的重写。

MCP到底是什么，为什么它重要

MCP（Model Context Protocol）是Anthropic在2024年11月推出的开放协议，灵感来自微软的Language Server Protocol（LSP）。LSP统一了编辑器和编程语言的对接方式，MCP想做类似的事：统一AI应用和外部工具/数据源的对接方式。

协议定义了三个角色：

Host：发起连接的LLM应用（比如Claude Desktop、Cursor）
Client：Host内部的连接器
Server：提供工具和数据的服务端

它们之间用JSON-RPC 2.0通信。Server可以暴露三类能力：

Resources：数据和上下文（给用户或模型用）
Prompts：模板化的消息和工作流
Tools：LLM可以调用的函数

本质上，MCP解决的是"AI Agent怎么发现和调用外部工具"这个问题。没有MCP之前，每个Agent框架都有自己的工具接入方式，工具开发者要为每个框架写适配。MCP想成为那个统一标准。

但MCP 2025年火了一阵之后，被Skills抢了风头。一个有终端和curl能力的Agent能做MCP能做的大部分事情，还更灵活。Simon Willison自己也在2025年年度总结里写过对MCP失去兴趣的原因。

现在他改变看法了。

"Stateless MCP has recaptured my interest. The new stateless MCP specification also greatly decreases the complexity of implementing both clients and servers for the protocol."— Simon Willison, 2026.07.31
无状态MCP重新点燃了我的兴趣。新的无状态规范大幅降低了客户端和服务端的实现复杂度。

MCP 2.0到底改了什么：九项重大变化

MCP 2.0规范首页，定义了无状态协议的核心架构

这次更新不是小修小补。从changelog来看，2026-07-28版本相对于上一个版本（2025-11-25）有9项重大变化。我按重要程度排列：

1. 删除会话机制，协议变为无状态

这是最核心的变化。旧版MCP的Streamable HTTP传输需要一个初始化握手：

// 旧版：需要两次请求
POST /mcp
{"method": "initialize", "params": {"protocolVersion": "2025-11-25", ...}}

// 拿到 Mcp-Session-Id: 1868a90c-3a3f-4f5b

POST /mcp
Mcp-Session-Id: 1868a90c-3a3f-4f5b
{"method": "tools/call", "params": {"name": "search", "arguments": {"q": "otters"}}}

新版只需要一次请求：

// 新版：单次请求，元数据放在 _meta 里
POST /mcp
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
{
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {"q": "otters"},
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {"name": "my-app", "version": "1.0"}
    }
  }
}

Mcp-Session-Id被删除了。 每个请求独立携带协议版本和客户端能力，服务端不再维护会话状态。这意味着：

不需要sticky session，天然支持负载均衡
水平扩展变得简单，每个请求可以路由到任意后端
服务端实现复杂度大幅降低

2. 删除 initialize 握手，改为 server/discover

旧版的initialize/notifications/initialized握手被完全删除。取而代之的是一个新的RPC方法：server/discover。

服务器必须实现这个方法，用来广播自己支持的协议版本、能力和身份信息。客户端可以在发送任何其他请求之前调用它，用来做版本选择。但它不是必须的。客户端也可以直接发请求，如果版本不匹配，服务器会返回UnsupportedProtocolVersionError并告诉客户端它支持哪些版本。

本质上，版本协商从"连接时握手"变成了"每次请求时声明"或"按需查询"。

3. 多轮请求模式（MRTR）替代服务端发起请求

旧版中，服务端可以向客户端发起独立的JSON-RPC请求（比如sampling/createMessage、elicitation/create、roots/list）。这在无状态协议中不可能实现。

新版引入了Multi Round-Trip Requests（MRTR）模式：服务端返回一个InputRequiredResult（resultType: "input_required"），里面包含需要客户端提供的信息。客户端收到后，重新发起原始请求，附带inputResponses和requestState。

// 服务端需要用户输入
Client -> Server: tools/call (id: 1)
Server -> Client: InputRequiredResult (inputRequests: elicitation/create)
// 客户端收集输入后重试
Client -> Server: tools/call (id: 2, + inputResponses + requestState)
Server -> Client: 最终结果

所有结果现在都必须携带resultType字段："complete"表示正常结果，"input_required"表示需要更多输入。

4. subscriptions/listen 替代 GET 端点

旧版有一个HTTP GET端点用于建立SSE流，加上resources/subscribe/resources/unsubscribe来订阅资源变更。

新版删除了GET端点和资源订阅机制，统一用一个subscriptions/listen POST请求替代。客户端发送这个请求时声明自己想监听哪些通知类型（toolsListChanged、promptsListChanged、resourcesListChanged等），服务端确认后，通过这个长连接的SSE流推送变更通知。

5. OAuth 2.1 授权体系

MCP 2.0定义了一套基于OAuth 2.1的授权机制。受保护的MCP服务器充当OAuth 2.1资源服务器，MCP客户端充当OAuth 2.1客户端。

关键设计：

服务器通过WWW-Authenticate头告诉客户端需要哪些scope
客户端通过OAuth 2.0 Protected Resource Metadata（RFC 9728）发现授权服务器
支持Client ID Metadata Documents和动态客户端注册
服务端可以在每次请求中根据token的scope返回不同的工具集

这对企业场景很重要——你可以控制哪些Agent能调用哪些工具。

6. 工具增强：outputSchema、icons、x-mcp-header

工具定义现在支持更多字段：

outputSchema：可选的JSON Schema，定义工具输出的结构。这让客户端可以验证返回值。
title：工具的可读显示名称（不同于name用于程序调用）
icons：工具的图标数组，用于UI展示
x-mcp-header：扩展属性，允许将工具参数映射为HTTP头
工具列表现在必须按确定性顺序返回，方便客户端缓存和提高LLM prompt cache命中率

7. 删除的特性

ping：删除
logging/setLevel：改为通过_meta中的io.modelcontextprotocol/logLevel按请求设置
notifications/roots/list_changed：删除
Roots功能：标记为deprecated，建议改用工具参数、资源URI或服务器配置传递目录信息
SSE流可恢复性：删除Last-Event-ID和SSE事件ID。连接断了就重新发请求。

8. 缓存机制

tools/list、resources/list等列表端点的返回值现在必须携带ttlMs（缓存有效期，毫秒）和cacheScope（"public"或"private"）。这让客户端可以缓存响应，减少轮询。

9. 扩展机制

协议核心精简后，一些功能被移到了官方扩展：

Tasks（io.modelcontextprotocol/tasks）：长时间运行的异步操作
Skills over MCP：通过MCP发现和消费的结构化Agent工作流指令
MCP Apps（io.modelcontextprotocol/ui）：在对话中内联渲染的交互式UI元素

扩展在初始化时协商，双方都声明支持才启用。

无状态 vs 有状态：不只是少一次请求

表面上看，无状态MCP只是把两次HTTP请求合并成了一次。但实际影响比这大得多。

运维层面： 有状态协议需要在服务端维护会话，这意味着要么用sticky session（同一会话路由到同一后端），要么用Redis之类的共享存储。对于想把MCP工具部署为Web服务的开发者来说，这是额外的运维负担。无状态MCP就像普通的REST API，每次请求独立处理。

安全层面： Simon Willison说了一句关键的话："给Agent一个能上网的shell环境太危险了。MCP工具更容易审计和控制。" 无状态协议的审计更简单。每个请求自包含，不需要关联会话上下文就能理解这个请求在做什么。

小模型层面： 无状态MCP对小模型更友好。不需要理解复杂的会话管理，不需要记住Session ID，每次调用就是一次独立的HTTP请求。这对边缘设备上的Agent部署有实际意义。

向后兼容： 规范定义了完整的兼容性矩阵。支持新版的客户端（Modern）和只支持旧版的服务器（Legacy）之间不能直接通信，但"Dual-era"实现可以同时支持两种模式。stdio传输通过server/discover探测，HTTP传输通过检查400响应体来判断服务器版本。

Simon Willison一周造了三个工具

无状态规范让Simon Willison一周内造了三个工具：

mcp-explorer：一个无状态CLI工具，用来交互式探测MCP服务器。用uvx mcp-explorer list https://example.com/mcp就能列出服务器的所有工具，uvx mcp-explorer call可以直接调用工具。不需要安装，用uvx直接运行。

datasette-mcp：给Datasette（Simon的数据库探索工具）加了MCP接口，暴露list_databases()、get_database_schema()和execute_sql()三个工具。Simon说这是他第四次尝试做这个插件，之前的有状态版本总觉得不对，无状态版终于让他满意了。

llm-mcp-client：给他的LLM CLI工具加了MCP客户端支持。一条命令就能让LLM调用MCP工具：llm -T 'MCP("https://example.com/mcp")' 'your question'。

这三个工具的共同特点是：实现简单，不需要复杂的会话管理。

几个值得留意的点

MCP的定位在调整。 从"万能工具协议"变成"安全可控的工具暴露方式"。这跟Skills形成了互补：Skills适合复杂任务，MCP适合需要审计和控制的场景。MCP 2.0把Tasks、Skills over MCP、MCP Apps都移到了扩展层，核心协议变得更精简。
无状态是正确的方向。 大多数工具调用不需要状态，强制维护状态增加了实现和运维成本。新版的MRTR模式解决了确实需要交互的场景（比如让用户输入），但用的是"请求-重试"的方式，而不是维护会话。
OAuth 2.1让企业场景成为可能。 之前MCP的授权是空白，企业没法控制谁能调用什么工具。现在有了完整的OAuth 2.1支持，结合scope控制和Protected Resource Metadata，企业可以精细管理Agent的工具权限。
生态在回暖。 Simon Willison是AI工具圈最有影响力的博主之一，他重新看好MCP可能会带动更多开发者重新关注这个协议。他一周造三个工具的速度说明无状态MCP的实现门槛确实低了很多。
向后兼容做得不错。 规范明确定义了Modern/Legacy/Dual-era三种模式的兼容性矩阵，不会出现"升级就断"的问题。服务器可以同时支持新旧版本，客户端会自动探测。

参考来源

Stateless MCP has recaptured my interest — Simon Willison, 2026.07.31
MCP Specification 2026-07-28 — 官方规范
MCP Changelog 2026-07-28 — 变更日志
mcp-explorer — Simon Willison
datasette-mcp — Simon Willison

更多AI前沿动态，欢迎关注「智械AI」