无状态 MCP 如何让 AI 工具调用回归简洁（并重新点燃了 Simon Willison 的热情）

起因：MCP 从火爆到被冷落，再到重新点燃兴趣

MCP（模型上下文协议）自 2024 年底由 Anthropic 推出后，一度被视为 AI 代理工具调用的标准答案。但 2025 年它逐渐被一种更“野路子”的方式取代：直接给 AI 一个终端和 curl 命令，让它们自由发挥。这种“Skills”式的灵活性让很多人觉得 MCP 过于刻板，Simon Willison 自己也曾在 2025 年底总结中称 2025 是“MCP 唯一的年份”。

但随着 MCP 2.0（即 2026-07-28 规范）的发布，尤其是它彻底拥抱无状态设计后，风向变了。Simon 坦诚地表示，这种新架构重新点燃了他对 MCP 的兴趣——不仅因为它更安全可控，还因为实现成本急剧下降。

拆解：无状态 MCP 到底简化了什么？

旧版 MCP 要求客户端先发送一个 initialize 请求获得会话 ID，再用这个 ID 去调用工具。这看似简单，但引入了状态管理难题：服务器必须维护会话映射、处理过期和路由。对于需要在多台后端机器上横向扩展的应用来说，这是个沉重的负担。

新版无状态 MCP 则把所有信息压缩进一个 HTTP 请求。它通过自定义请求头（如 MCP-Protocol-Version、Mcp-Method）直接传递元数据，不再需要单独的握手步骤。用一个请求就能告诉服务器“我要调用搜索工具，参数是‘水獭’”（见原文示例）。

这种设计不仅让客户端代码量锐减（无需管理会话生命周期），也让服务器实现变得极其轻量——你可以用几十行代码写一个符合规范的 MCP 服务器，甚至可以轻松托管在 serverless 平台上。它也更符合 HTTP 惯用的无状态哲学，方便缓存、日志审计和调试。

趋势洞察：AI 代理的“去状态化”浪潮

无状态 MCP 的出现揭示了一个更大的趋势：AI 工具调用正在从“维护复杂会话”走向“单次无状态交互”。这并非偶然。随着智能体被用于更多生产环境，可审计性、可伸缩性和最小权限原则变得至关重要。一个无状态的工具调用就像 API 的一次普通请求，你可以清楚知道它做了什么，出了什么问题。相比之下，让代理在 Shell 里东奔西跑，虽然灵活，但像开盲盒，安全隐患和模型依赖都高得吓人。

Simon 自己也反思：给代理一个联网的 shell 环境确实危险（他引用了一个 OpenAI 网络攻击案例），而且对模型能力要求极高。而 MCP 工具则把边界收窄，每个工具承担明确职责，即使本地运行的小模型也能稳定驾驭。

实用价值：作为开发者，你可以怎么想、怎么用？

如果你正在构建 AI 工具链，无状态 MCP 带来三个直接好处：

1. 极低的接入成本：无论你是想暴露内部 API、数据库查询还是文件系统操作，实现一个 MCP 服务器都变成举手之劳。Simon 三天写了三个工具（包括用于探索 MCP 服务器的 CLI mcp-explorer 和结合 Datasette 的 datasette-mcp），就是最好的证明。
2. 天然适合微服务和边缘部署：无状态意味着你可以把 MCP 服务器部署成 Cloudflare Worker 或 AWS Lambda，轻松应对高并发。
3. 更放心的安全边界：每个工具调用都是独立、可记录的，你可以精确控制代理能做什么，不需要授予整个系统的 shell 权限。

反常识/意外：看似简单的改动，背后是安全与控制权的取舍

大多数人可能认为，简化协议只是为了开发体验。但其实，从“有状态”到“无状态”的转变，本质上是将安全责任从模型转移到架构。旧版会话模型下，一旦会话建立，代理就拥有了持续的操作能力；而新版每一次调用都必须自证清白，这大大压缩了意外或恶意行为的窗口。

另一个容易被忽略的角度：这种设计让 MCP 重新获得了与“Skills 类”方案的竞争资格。Skills 靠的是无限可能，而 MCP 靠的是明确边界和可靠性。在 AI 安全焦虑日益加剧的今天，后者可能才是更长命的方向。

总之，无状态 MCP 不是什么颠覆性创新，但它精准地踩中了开发者对简洁、安全、可扩展工程实践的真实渴望。这或许解释了为什么一个协议的版本更新，能让 Simon Willison 这样的资深玩家重新兴奋起来。

原文地址: Stateless MCP has recaptured my interest (and inspired mcp-explorer and datasette-mcp)