👁 345 次阅读
2026年7月28日，Anthropic 推出的 Model Context Protocol（MCP）迎来了自 2024 年 11 月发布以来最大的一次版本变更：MCP 2.0 正式落地。这一次更新的核心只有一个词——无状态（Stateless）。曾经需要两次 HTTP 请求才能完成一次工具调用的协议，如今一次请求即可搞定。开发者社区对此反应热烈：知名 AI 开发者 Simon Willison 在 7 月 31 日发表长文《Stateless MCP has recaptured my interest》，文章在 Hacker News 上获得 386 分、225 条评论，成为当周讨论度最高的 AI 工具类话题之一。
本文基于 MCP 官方规范（2026-07-28 版）、官方 Changelog、Simon Willison 的实测体验以及 HN 社区的一手用户反馈，对 MCP 2.0 进行深度评测，回答三个问题：无状态化到底改了什么、对开发者意味着什么、以及它能否让 MCP 重新成为 AI 工具调用的主流标准。
一、背景：MCP 的两年浮沉
MCP（Model Context Protocol）由 Anthropic 于 2024 年 11 月推出，目的是为 LLM 驱动的 Agent 框架提供一种标准化的工具接入方式——把外部数据源和工具能力以统一的协议暴露给 AI 应用。据官方规范页面介绍，MCP 借鉴了语言服务器协议（LSP）的思路：LSP 标准化了编程语言在开发工具生态中的集成方式，MCP 则标准化了上下文与工具在 AI 应用生态中的集成方式。
协议推出后的 2025 年，MCP 曾经历一波巨大的关注热潮，几乎所有主流 AI 框架和平台都宣布支持。但随后情况发生了变化——Anthropic 推出的 Skills 机制逐渐抢走了风头。Simon Willison 在 2025 年度回顾中曾写道：一个拥有终端和 curl 的 Agent 框架，就能以更灵活的方式完成 MCP 能做到的大部分事情。MCP 一度显得有些”鸡肋”。
然而，把带互联网访问权限的 shell 环境交给 Agent，实际上是一把双刃剑：这需要足够强的模型才能安全地驾驭，而且失控风险极高。相比之下，MCP 的工具调用更易于审计和控制，简单到连运行在笔记本上的小模型都能较好地驱动。MCP 2.0 正是抓住”简化”这个关键点，重新点燃了开发者对协议的热情。
二、核心变化：从两次请求到一次请求
无状态化是 MCP 2.0 最直观、也最根本的变化。在旧版（Stateful MCP，官方 Changelog 中称其为 legacy MCP）中，一次工具调用需要两个 HTTP 请求：首先发送 initialize 请求建立会话并获得 Mcp-Session-Id，然后携带该会话 ID 才能调用 tools/call。这不仅增加了实现复杂度，还要求服务端维护会话状态，并在负载均衡场景下把同一会话路由到同一台后端机器。
新版（Stateless MCP）完全消除了会话概念：一次 HTTP 请求即可完成工具调用，协议版本、方法名、工具名全部通过请求头携带。官方 Changelog 明确写道：移除协议级会话与 Mcp-Session-Id 头、移除 initialize/initialized 握手，每个请求现在自带协议版本与客户端能力声明（io.modelcontextprotocol/protocolVersion 与 clientCapabilities）；版本不匹配时返回 UnsupportedProtocolVersionError。
以下是新旧协议的请求对比（示例来自 Simon Willison 文章引用的官方 5 月 21 日 RC 公告）：
| 维度 | 旧版 MCP（Stateful） | MCP 2.0（Stateless） |
|---|---|---|
| 建立连接 | 先 POST initialize 拿到 Mcp-Session-Id | 无需握手，直接调用 |
| 工具调用 | 第二次 POST 携带会话 ID | 单次 POST 一次完成 |
| 协议版本 | initialize 时协商 | 请求头 MCP-Protocol-Version 声明 |
| 服务端状态 | 必须维护会话状态 | 完全无状态，易于水平扩展 |
| 跨调用数据 | 依赖服务端会话 | 服务端铸造句柄作为普通工具参数传递 |
| 实现复杂度 | 客户端服务端都要维护状态机 | 大幅下降，一周可建三个实现 |
对开发者来说，这意味着实现一个 MCP 客户端或服务端不再需要处理会话状态机。Simon Willison 的亲身经历很有说服力：他在一周内用新规范构建了三个 MCP 实现——这在此前的协议版本下几乎不可想象。无状态化还让 MCP 更适合构建可扩展的 Web 应用：不再需要把同一会话路由到同一后端实例，负载均衡可以简单地在任意机器间分发请求。
三、其他关键变更：不止是”去掉会话”
MCP 2.0 的改动远不止无状态化。根据官方 Changelog，2026-07-28 版本还包含多项结构性调整：
1. Tasks 转正为官方扩展。原先试点性质的 tasks 功能从核心协议中移出，成为独立的官方扩展（io.modelcontextprotocol/tasks）。重新设计后的扩展用轮询（polling）替代原来的阻塞式方法，并允许服务端在无需逐请求选择加入的情况下主动返回任务句柄。HN 用户 brianjking 在热帖下评论：7-28 版本有一大堆优秀改进，tasks 被正式采用尤其值得期待——这标志着长时运行任务（long-running tasks）在 MCP 生态中有了标准答案。
2. MRTR 模式替代服务端主动请求。新引入的多轮往返请求（Multi Round-Trip Requests）模式，取代了此前 sampling/createMessage、elicitation/create 等服务端主动发起的请求。服务端现在返回 InputRequiredResult（resultType: “input_required”），携带完成请求所需的额外信息；客户端在重试原请求时附上这些信息即可。这让协议的数据流更清晰可控。
3. 订阅机制重构。原 HTTP GET 端点与 resources/subscribe 机制被订阅流（subscriptions/listen）取代：一条长连接的 POST 响应流，用于服务端向客户端推送变更通知（toolsListChanged、promptsListChanged、resourcesListChanged 等）。request-scoped 的通知（如进度）则继续跟随所属请求的响应流。
4. 一批弃用与清理。Roots、Sampling、Logging 三项特性进入弃用窗口（官方建议改用工具参数传路径、直接集成 LLM 提供商 API、用 OpenTelemetry 做日志）；HTTP+SSE 传输被正式标记为 Deprecated；OAuth 2.0 动态客户端注册协议同样被弃用，转向 Client ID Metadata Documents。官方还为此建立了完整的特性生命周期政策（Active/Deprecated/Removed），弃用窗口至少 12 个月，给生态留足迁移时间。
5. 面向性能的细节优化。工具列表按确定性顺序返回，便于客户端缓存并提升 LLM prompt 缓存命中率；资源模板列表新增 freshness hint 字段，允许客户端缓存响应、减少轮询频率。这些细节虽小，但对生产环境的调用成本和延迟有实打实的改善。
四、生态实测：Simon Willison 的一周三连
评测一款协议，最有说服力的证据是看实际生态里能不能快速跑起来。Simon Willison 的实践给出了正面答案——他基于 MCP 2.0 一次性构建了三个工具：
mcp-explorer：一个无状态的 Python CLI 工具，用于交互式探查 MCP 服务器，免安装直接用 uvx 运行。例如 uvx mcp-explorer list https://agentic-mermaid.dev/mcp 就能列出该 MCP 服务器的全部工具（包括参数 JSON Schema），inspect 查看单个工具详情，call 直接传参调用。此前社区已有官方 mcp-inspector 工具，但 Simon Willison 指出其 CLI 模式文档欠缺，这也是他自建工具的原因——mcp-explorer 的命令行体验明显更简洁。
datasette-mcp：一个 Datasette 插件，为任意 Datasette 实例添加 /-/mcp 端点，暴露 list_databases / get_database_schema / execute_sql 三个工具（execute_sql 当前只读）。Simon 表示这是他第四次尝试构建这个插件，前三次都因旧协议实现过于繁琐而未成行，新规范让他”终于做出一版值得发布的”。他把插件挂在自己的博客数据镜像上，通过 ChatGPT 和 Claude 都能直接对其执行 SQL 查询——他在共享会话中让 Claude “列出 simonwillison.net 的表”，Claude 连跑了 7 条 SQL 查询才找到答案，全程稳定。
llm-mcp-client：为 Simon 自研的 LLM 命令行工具提供官方 MCP 集成的 alpha 插件。安装后一条命令即可让 LLM 挂载任意 MCP 服务器：llm -T 'MCP("https://datasette.simonwillison.net/-/mcp")' 'count the notes'，模型会自主决定调用哪些工具并展示推理过程。Simon 计划在功能成熟后将其直接并入 LLM 核心。
一个细节值得留意：上述三个实现全部借助 AI 辅助完成（Simon 明确提到 mcp-explorer 由 Codex 帮助编写）。这本身就是 MCP 2.0″更易于实现”的注脚——协议足够简单时，连 AI 都能更快地写出符合规范的客户端和服务端。
五、安全性：MCP 比”给 Agent 一个 Shell”更可靠
MCP 2.0 引发的另一个讨论焦点是安全性。Simon Willison 的观点非常明确：给 Agent 一个带互联网访问的 shell 环境风险极高，MCP 工具更易于审计和控制，简单到小模型也能驱动，是”更安全的 Agent 构建方式”。
早在 MCP 发布数月后，Simon 就写过《Model Context Protocol has prompt injection security problems》，指出用户混合搭配工具的用法把数据外泄防护责任推给了终端用户。但与”给 Agent 任意 shell 和 curl 权限”相比，MCP 的可控性仍然显著更好：每个工具的能力边界清晰、输入输出是结构化 JSON、调用行为可以被审计记录。官方规范文档也专设了”安全与信任安全”章节，要求实现者确保用户对数据共享和操作有明确的知情与同意。
在敏感应用场景下——比如让 Agent 查询企业数据库、操作内部系统——MCP 这种”能力可枚举、调用可审计”的边界感，正是生产环境最需要的东西。HN 用户 CharlieDigital 的评价代表了相当一部分企业开发者的判断：MCP 将会成为企业 Agent 基础设施的基石。
六、社区真实声音：掌声、吐槽与保留意见
386 分、225 条评论的热度背后，社区的声音并不只有一片叫好。以下是 HN 讨论中具有代表性的真实反馈：
赞成的声音：开发者 tosh 分享了自己几个月前从零实现 MCP 服务端的经历——”完全无法在多个客户端间可靠工作”，因此对 MCP 的简化感到由衷高兴。brianjking 则点名表扬 7-28 版本中 tasks 的正式采用。多数认可无状态化的开发者都强调同一个点：实现门槛的大幅下降，让”小而美的 MCP 服务器”成为可能。
关键吐槽——2.0.0 质量存疑：HN 用户 hobofan 发出了一条重要警告：”想从本帖尝试的人请注意：请用最新的 pre-2.x 版本。上周发布的 2.0.0 即使在最常见的连接场景下也高度不可用（highly broken）。”这条评论提醒我们，协议规范发布与官方 SDK 成熟之间存在时间差——规范是好的，但参考实现的成熟度仍需时日，生产环境落地前务必验证工具链版本。
保留意见——”我根本不需要 MCP”：开发者 hchja 提出了相反观点：当年 MCP 重要是因为 Agent 还不能准确调用工具；如今模型能力大幅提升，完全可以用简单 CLI 工具配合 system prompt、skills 或 API 文档来替代 MCP（并吐槽 MCP 在 macOS 上使用体验不佳）。这种观点与”Skills 取代 MCP”的旧争论一脉相承，说明协议之争仍未尘埃落定——但值得注意的是，即便持此观点的开发者，也承认 MCP 的价值在于标准化与生态互操作。
七、局限性与适用边界
客观来看，MCP 2.0 仍存在明显局限：
1. 生态迁移成本。官方虽给出 12 个月弃用窗口，但大量存量 MCP 服务器是基于旧协议实现的。客户端需要同时兼容新旧两版协议，服务端迁移需要重写会话管理逻辑——过渡期的兼容性负担不能被低估。
2. SDK 成熟度滞后。hobofan 的反馈表明官方 2.0.0 SDK 在常见场景下仍不可靠，生产环境需要谨慎选择版本。
3. 无状态化的代价。去除会话后，需要跨调用共享状态（如用户登录态、分页游标）的场景，必须通过服务端铸造的句柄显式传递——这对协议设计者是好消息，对应用开发者则是新的心智负担。
4. 与终端方案的竞争仍在。Skills + shell 方案在灵活性上依然有优势，MCP 2.0 简化的是实现，不是”用不用 MCP”的决策本身。
八、总结与展望
综合评测，MCP 2.0（2026-07-28 规范）是一次方向正确、执行扎实的协议革新：无状态化直击旧协议实现复杂的病灶，MRTR、订阅流、Tasks 扩展等配套改动让协议体系更完整，特性生命周期政策则给生态吃了”不会突然破坏”的定心丸。Simon Willison 一周三个实现、ChatGPT/Claude 直接通过 MCP 查询 Datasette 的实测，证明新协议已经具备可用性；HN 社区 386 分的热度则验证了开发者对这次变化的认可。
对普通用户和开发者的建议：如果你是 AI 工具/Agent 的开发者，现在正是熟悉 MCP 2.0 规范的好时机——建议使用 pre-2.x 或修复后的 SDK 版本，先用 mcp-explorer 这类轻量 CLI 体验无状态调用的开发流程；如果你只是 AI 产品的使用者，其实已经在享受 MCP 的成果——ChatGPT、Claude 等产品中的”连接数据源/工具”功能，底层正是这套协议。协议层面的战争或许还要持续一段时间，但”标准化、可审计、低门槛”的工具接入方向，已经是整个行业的共识。
数据来源：Model Context Protocol 官方规范（specification 2026-07-28）与官方 Changelog（modelcontextprotocol.io）；Simon Willison《Stateless MCP has recaptured my interest》（simonwillison.net，2026-07-31）；Hacker News 热帖讨论（objectID 49131438，386 分/225 评论）。文中所有数据均可回溯至上述来源。