MCP 无状态改造：变化在哪里，Theo 为何转向乐观

我一直是 MCP 比较直言不讳的批评者之一。让 agent 连接工具是个有用的想法，但运行 MCP 服务器的体验往往比它应该有的更笨重。最新版本第一次让我觉得，这个协议正朝我期待的方向发展。

在我的设置中，agent 工作流可能启动许多进程，新 agent 出现时又要重复设置。我也见过 macOS 的 syspolicyd 占用大量 CPU，怀疑频繁创建进程是原因之一。这只是我对自己环境的观察，并非基准测试，也不能证明新规范本身就解决了这个问题。

Anthropic 正在推出对 MCP 2026-07-28 版本的支持。核心变化是无状态协议核心，同时还有授权改进和官方扩展。比起版本号，我更关心调用工具的机制是否真的变简单了。

此前，客户端需要先初始化协议，再发出普通请求。新核心让请求能够自描述：相关元数据随请求发送，initialize/initialized 握手和 Mcp-Session-Id 则被移除。如果客户端希望提前了解服务器能力，仍可选择使用发现功能。

这意味着服务器不再需要协议会话才能理解请求。对于偶尔调用工具的 agent，需要协调的协议步骤减少了。但这并不意味着所有旧实现都保持着 TCP 长连接，也不意味着新版本会消除所有本地进程。

协议层无状态，也不代表有用的应用不能有状态。工具可以为资源提供显式句柄，并在后续请求中接收它。关键区别是应用明确表达这种关系，而不是依赖隐含的协议会话。

这种设计应该更适合无服务器和边缘部署。请求可以发往可用实例，不必为了协议会话固定到某台后端，也不必在所有实例之间共享协议会话状态。服务仍然需要运维，应用自己的状态也可能需要独立的存储和路由。

此版本还改进了扩展和授权。Apps 和 tasks 支持更丰富的交互，授权方面的变化则加强了安全性。无状态核心不会自动让工具变安全：工具能访问什么、谁可以调用、输出如何处理，仍然很重要。

部署示意图直观展示了区别：旧的会话式方案把客户端路由回同一个实例，或使用共享会话存储；新方案则把独立请求分发到不同实例。这讲的是协议会话管理，而不是说 TCP 连接本身永远不能复用。

Simon Willison 写文章分享了他对新规范的尝试，并比较了旧版设置交换和新版请求格式。这个对比说明了我为什么喜欢这次改动：工具调用可以更接近普通请求，不必事先单独完成协议设置。

有些交互仍然需要多次往返。例如，工作流可能先向用户获取更多输入，然后继续执行。无状态协议请求简化了这些交互的承载方式，但不会把所有多步骤任务都变成一次调用。

Willison 构建了命令行工具 mcp-explorer，用来检查服务器。他的示例查询一个 Agentic Mermaid 服务器，列出执行代码以及将图表渲染为 SVG、ASCII 或 PNG 的操作。用一个小型命令行工具检查服务器，是了解其能力的实用方法。

他还构建了 datasette-mcp 插件，提供列出数据库、检查结构和执行只读 SQL 的工具。他说，之前的尝试令人沮丧，而无状态规范帮助他做出了一个愿意发布的版本。

这些案例展示了 agent 和聊天工具发现实用能力的潜力，开发者不必为每个场景设计专门的集成。它们是可行方法的示例，并不能证明所有现有服务器都能不加修改地迁移。

但版本是关键。客户端和服务器必须对使用的协议达成一致，过渡需要时间。一些实现可能支持或桥接多个版本，因此不兼容并非必然；但也不能假定旧客户端一定能理解更新后的服务器。

这有点像宣传支持某种连接器，却没有说明实际支持的版本或能力。“支持 MCP”是一个有用的起点，但开发者仍需检查具体客户端和服务器实现了什么，并测试自己打算部署的组合。

即便目标架构更好，迁移负担也是真实存在的。现有实现需要更新，用户可能需要在一段时间内面对混合版本。我之所以乐观，是因为这次改造解决了一个结构性问题，而不是因为规范一变，整个生态就会立刻跟进。

更大的前景是为 agent 使用工具提供统一接口。当协议更容易使用和部署时，这种统一接口就更有吸引力。某个集成是否可靠、高效，仍取决于具体客户端、服务器、工具和周边基础设施。

我的立场已经改变：当实现支持这种新设计时，我更愿意使用 MCP。我仍想看到生态真正采用它并妥善处理兼容性，但这个方向令人鼓舞。

真正的考验将是人们构建出的工具，以及运行它们的实际体验。现在，我很高兴看到协议朝着我期待的更简单的模型迈出了重要一步。