2025 年 12 月 31 日，Simon Willison 在他的年度 LLM 回顾中，给 MCP 章节加了一个意味深长的标题：The (only?) year of MCP。一个问号，一个括号，一句话判了一个协议的死缓。他给出的理由很直白，一个能用终端和 curl 调用一切工具的 Agent，让 MCP 这种中间层显得多余。
但七个月后，2026 年 7 月 31 日，他写了一篇标题完全相反的博客：Stateless MCP has recaptured my interest。他不仅收回了判词，还在一周内为这个他曾判死缓的协议写了三个开源项目。
这中间发生了什么？
现象：MCP 2.0 的无状态时刻
2026 年 7 月 28 日，MCP 官方正式发布 2026-07-28 规范版本，行业通称的 MCP 2.0。这是自 2024 年 11 月 Anthropic 推出 MCP 以来，该协议最重大的一次修订。
核心变化只有三个字：无状态。
在旧版 MCP 中，一个客户端调用一个工具需要两次 HTTP 请求。先发送 initialize 握手建立会话，拿到 Mcp-Session-Id，再发送真正的工具调用请求。这意味着服务器必须维护会话状态，负载均衡器必须做粘性路由，分布式部署需要共享会话存储。这些对于大规模生产环境来说，都是沉重的运维负担。
新版 MCP 把这一切抹平了。每次请求独立自描述，携带协议版本、客户端身份和能力信息，任何一台服务器实例都可以独立处理。路由信息从 JSON 响应体前置到了 HTTP 头部。Mcp-Method 和 Mcp-Name 两个头字段，让网关、限流器和 WAF 可以在不解析 JSON 响应体的情况下完成路由和鉴权。微软 Azure 团队在官方分析中直言，这正是他们一直在 work around 的老问题。
官方博客给出了一个令人惊讶的数字：MCP 的 Tier 1 SDK（TypeScript、Python、Go、C#）月下载量已接近 5 亿次，其中 TypeScript 和 Python SDK 各自突破了 10 亿次总下载量。这个协议在被判死缓的同时，其实一直在以惊人的速度渗透到 AI 基础设施的每一个角落。
除了无状态化，MCP 2.0 还引入了多项关键改进。Multi Round-Trip Requests 替代了原先需要保持双向流打开的采样和请求模式，当工具需要用户确认或补充参数时，服务器返回 input_required，客户端在重试请求时附加答案。列表结果现在可缓存，tools/list、resources/list 等响应携带 ttlMs 和 cacheScope，客户端可以缓存工具目录，无需每次重新连接都重新获取。授权体系全面加固，强制要求 RFC 9207 发行者验证，从动态客户端注册向客户端元数据文档迁移。Roots、Sampling、Logging 三个功能正式进入弃用状态，12 个月最低弃用窗口确保开发者有时间迁移。Tasks 等功能被移出核心协议，成为官方扩展。
分析：MCP 为什么死而复生
MCP 为什么曾被判死缓
要理解 MCP 2.0 的意义，得先回到 2025 年，看看 MCP 为什么会在短短一年内从 AI Agent 的 USB-C 变成被质疑的协议。
MCP 于 2024 年 11 月由 Anthropic 推出，定位是 AI 模型的 USB-C 接口，一个标准化的工具发现和调用协议。2025 年初，它经历了爆炸式增长。5 月，OpenAI、Anthropic 和 Mistral 在 8 天内相继宣布在 API 层面支持 MCP。热度一度达到顶峰。
但两个天花板让 MCP 迅速降温。
第一个天花板来自 Skills 的降维打击。2025 年 10 月，Anthropic 推出了 Claude Skills，一个比 MCP 更轻量、更灵活的替代方案。一个具备终端和 curl 访问权限的 Agent 几乎可以完成 MCP 能做的所有事，而且更灵活。Simon Willison 在年度回顾中写道：“自从我深入使用 Claude Code 后，几乎再也没用过 MCP，我发现 gh 和 Playwright 等 CLI 工具是比 GitHub MCP 和 Playwright MCP 更好的选择。”他的核心判断是，MCP 作为中间层可能是多余的，直接给 Agent 一个 Shell 环境就足够了。
第二个天花板来自安全问题的集中爆发。2025 年 4 月，Simon Willison 在《Model Context Protocol has prompt injection security problems》一文中指出了 MCP 的结构性安全风险。工具描述对 AI 模型可见但对用户界面不可见，意味着隐藏的对抗性指令可以轻易嵌入工具描述中。2025 年 6 月 16 日，他提出了致命三重奏（Lethal Trifecta）概念：当 AI Agent 同时具备访问私有数据、接触不可信内容和外部通信三种能力时，它在设计上就是可被利用的。MCP 的混合匹配工具模式恰好把安全责任推给了终端用户。
为什么这次不一样
MCP 2.0 的无状态化解决了两个层面的问题，分别对应着运维和架构的死穴。
运维层面，无状态意味着可扩展。旧版 MCP 的会话状态要求服务器端维护 session 信息，这对于分布式部署是灾难性的。你需要共享会话存储、做粘性路由、在负载均衡器上做额外配置。MCP 2.0 让每个请求独立自描述，任何实例都可以处理任何请求。这意味着 MCP 终于可以像普通 REST API 一样部署在标准的 HTTP 基础设施上。
架构层面，无状态化带来的是更安全的工具边界。这是一个反直觉的结论。无状态化本身并不直接提升安全性，但它让 MCP 工具变得更容易审计和控制。Simon Willison 在 7 月 31 日的文章中做了一个关键转折。他承认，给 Agent 一个 Shell 环境和网络访问权限，实际上是充满风险的，并且需要足够强大的模型才能有效驱动这样的环境。而 MCP 工具的边界更清晰、可审计性更强，即使是能在笔记本电脑上运行的小模型也能很好地驱动它们。
这个转折非常微妙。Willison 的核心关切从为何需要中间层变成了为何不需要中间层。2025 年他关心的是效率和技术自由度，2026 年他关心的是安全和控制力。这种转变，折射出整个 AI Agent 行业在过去一年中的集体学习曲线，从能做就行到安全可控地做。
三个项目释放的三个信号
Simon Willison 在一周内为 MCP 2.0 写了三个项目。
第一个是 mcp-explorer，一个无状态 Python CLI 工具，用于交互式探测 MCP 服务器。用户可以用 uvx 直接运行，无需安装。它可以列出服务器的工具清单、查看工具 JSON Schema、调用工具并查看结果。Willison 说：“我发现构建 CLI 工具是熟悉一个规范的最有效方式，即使大多数代码是 AI 写的。”
第二个是 datasette-mcp，一个 Datasette 插件，为任何 Datasette 实例添加 /-/mcp 端点，提供三个工具：list_databases、get_database_schema、execute_sql。Willison 透露，这已经是第四次尝试构建这个插件。前三次都因为旧版 MCP 的复杂性而放弃。无状态化让第四次终于成功。
第三个是 llm-mcp-client，一个 LLM 命令行工具的 MCP 插件，让用户可以通过 LLM 的 chat 接口连接到任何 MCP 服务器。Willison 表示，一旦这个插件成熟，他考虑将其直接集成到 LLM 核心中，并在 Datasette Agent 和 llm-coding-agent 中进一步实验 MCP 集成。
这三个项目释放了三个信号。
信号一：门槛降到了一个人一周能写三个的程度。 如果 MCP 2.0 的 stateless 设计让 Simon Willison 在第四次尝试中终于做出了 datasette-mcp，那说明旧版 MCP 的复杂性确实劝退了大量潜在开发者。无状态化直接降低了服务端和客户端的实现难度。
信号二：从纯工具到数据基础设施。 datasette-mcp 代表了一个很有意思的方向，将数据库查询能力以 MCP 工具的形式暴露给 AI Agent。这不是简单的给 Agent 加个工具，而是让 Agent 可以直接通过 SQL 查询结构化数据。Willison 演示了一个场景：让 Agent 在他的博客数据库上运行了 7 次 SQL 查询来回答一个问题。
信号三：LLM 工具正在全面拥抱 MCP。 Willison 的 LLM 命令行工具是 AI 开发者社区中广泛使用的工具之一。他计划将 MCP 集成到 LLM 核心中，这意味着 MCP 正在从一个协议变成所有 AI 工具的标准接口。
结论：安全与效率的再平衡
MCP 2.0 的发布，本质上是一次安全与效率的再平衡。
2025 年，行业被 AI Agent 能做一切的叙事所吸引，Shell 和 curl 的灵活性让 MCP 显得多余。2026 年，当 Agent 安全事故频发，从 OpenAI 对 Hugging Face 的意外网络攻击，到致命三重奏成为行业共识，行业开始重新审视可控性的价值。
Simon Willison 的态度转变，正是这种行业集体反思的缩影。他在文章中写的一句话值得深思：
我计划在构建基于 LLM 的敏感应用时，更多地依赖 MCP。
这不是一个技术决策，而是一个信任决策。
MCP 2.0 的最大受益者不是 Anthropic，而是整个 AI Agent 生态。无状态化让 MCP 从 Anthropic 的协议变成了互联网的协议。它不再需要特殊的 SDK、特殊的部署方式、特殊的运维知识。任何懂 HTTP 的开发者都可以理解和使用。
微软已经明确表态，Azure 正在全面适配 MCP 2.0 的无状态架构。Gartner 预测，到 2026 年底，75% 的 API 网关厂商将加入 MCP 特性。MCP SDK 的月下载量已经接近 5 亿次，且仍在增长。2025 年 12 月，Anthropic 将 MCP 捐赠给了 Linux 基金会旗下的 Agentic AI Foundation，确保其作为开放标准的长期治理。
对仍在坚持给 Agent 开一个 Shell 就走的 Agent 框架来说，MCP 2.0 的安全叙事构成了竞争压力。当行业开始用你是否支持 MCP 来衡量一个 Agent 平台的成熟度时，不支持 MCP 就相当于 2010 年的网站不支持 HTTPS。
MCP 2.0 没有发明什么新东西，它只是把一个好协议从太复杂到没人愿意用变成简单到一个人一周能写三个项目。但有时候，这就是从死到生的全部距离。
MCP 2.0 没有改变 MCP 的野心，它只改变了 MCP 的造价。从需要一整个团队来维护，到一个人，一个周末，就够了。
快报