Anthropic、Simon Willison 与无状态 MCP 的逆转

Anthropic 于 2024 年推出 MCP，但 Simon Willison 后来认为终端工具更灵活。如今，2026 年 7 月 28 日的规范修订扭转了这一判断的一部分：它移除了协议会话，将远程 MCP 调用变为自包含的请求。

这一变化重新激起了 Willison 的兴趣，并催生了 mcp-explorer 与 datasette-mcp 两个项目。更重要的是，它直击了一项架构弱点：这一弱点曾使远程 MCP 服务器比普通 HTTP 服务更难部署。

因此，Anthropic 与 Simon Willison 的故事并非又一次协议更新，而是一次检验：MCP 能否不再与命令行工具竞争，并确立一个更具合理性的定位。Skills 仍适合教会智能体如何使用现有软件；而无状态 MCP 则提供结构化远程工具、发现、授权与共享基础设施。

无状态 MCP 从每条请求路径中移除了会话

新规范将 MCP 从以连接为中心的协议转变为以请求为中心的协议。

模型上下文协议定义了一套标准接口，AI 智能体可借此发现并调用外部工具。Anthropic 于 2024 年 11 月推出它后，开发者很快为数据库、浏览器、通信平台和业务应用构建了服务器。

早期版本要求在常规工具调用前完成初始化流程。客户端与服务器会交换协议版本、能力和身份信息。这一协商建立了后续消息预期应保持的上下文。

HTTP 服务器还可签发 Mcp-Session-Id。客户端随后会在后续请求中返回该标识符。这种安排让一系列调用表现得像特定客户端与服务器实例之间持续进行的一段对话。

这一设计带来了基础设施层面的影响。负载均衡器需要将相关调用路由至正确实例，或将会话数据存入共享存储。运营人员还需要制定过期、重连、恢复和清理策略。

最终的 2026-07-28 修订移除了强制性的 initialize 握手，也移除了协议层的会话及其关联请求头。现在，每个请求都包含可供独立解读所需的信息。

官方 MCP 发布公告 将此次修订描述为协议发布以来最大的变化。无状态核心之外，还加入了扩展、修订后的 Tasks 支持、授权变更及正式的功能生命周期。

客户端现在可以直接发送工具调用。请求携带协议版本、方法、工具名称、客户端信息和相关能力。任何兼容的服务器实例都可处理它，而无需依赖此前的交互。

这一变化还新增了 server/discover，让客户端可在需要时请求服务器能力。发现机制不再要求每个调用方创建并维持协议会话。

这并不意味着每个应用都必须放弃状态。浏览器自动化服务、购物车、数据库事务或研究工作流，仍可在多次调用之间保留信息。

区别在于这些信息存放在哪里，以及如何被引用。服务器不再将其隐藏在会话背后，而是可以返回显式标识符。模型会在后续调用中提供该标识符。

浏览器服务器可在启动实例后返回 browser_id。之后的工具可在导航、截取页面或关闭浏览器时接受该值。数据库工具也可将相同模式用于事务标识符。

已获接受的 无会话提案 将这些值称为显式状态句柄。它们不是新的 MCP 数据类型，而是让应用状态可见的普通工具输入和输出。

这种可见性对智能体很重要。编排器可以与某个子智能体共享一个句柄，同时让另一个句柄保持隔离。它还可以记录该标识符以供后续工作使用，或将其交给另一个获得授权的进程。

列表操作还获得了另一项优势。当工具和资源不再能依据含糊的会话发生变化时，客户端就能更安全地缓存发现结果。这减少了短生命周期智能体之间的重复调用。

无状态 MCP 也能更自然地映射到常见的 HTTP 操作。远程服务器可采用标准轮询负载均衡、普通网关路由、按请求认证和成熟的可观测性系统。

正是这一组合重新赢得了 Willison 的关注。这次更新不仅缩短了握手流程，更移除了一项此前会渗透至每次部署和每个客户端实现的架构承诺。

为何 Anthropic 与 Simon Willison 的立场逆转值得关注

Willison 重燃兴趣之所以重要，是因为他早先的批评准确捕捉到了编码智能体用户逐渐远离 MCP 的真实趋势。

2025 年的大部分时间里，MCP 都备受关注。它的价值主张很容易理解：实现一个服务器接口，就能向多个兼容的 AI 客户端提供同一组工具。

但编码智能体也在同期不断进步。它们获得了可靠的终端访问能力、更好的 shell 使用能力，以及更强的文档查阅能力。许多智能体可以安装一个库，或使用 curl 调用常规 API。

这带来了直接挑战。文档完善的命令行程序本身就提供了可组合的工具接口。智能体可组合命令、重定向输出、编写小型脚本并检查错误，无需协议适配器。

Skills 强化了这一路径。技能是一组指令、脚本和参考资料的集合，用于教会智能体如何完成任务。它可以解释现有 API，而不要求其所有者运营 MCP 服务器。

Willison 在其 2025 年回顾中概括了自己的怀疑。对于编码智能体，他更偏好命令行工具和库，而非 MCP。这些选择给予模型更大自由度，同时避免增加一层服务。

他的批评从来不是说结构化工具调用没有价值。更棘手的问题在于，MCP 提供的额外价值是否足以证明会话、传输管理、客户端兼容性工作和上下文开销的合理性。

无状态 MCP 缩小了这一差距。小型远程工具如今可以更像传统 Web 端点，同时为智能体客户端保留机器可读的契约。

Willison 的 无状态 MCP 分析 将这一变化与两个实验联系起来。第一个是 mcp-explorer，旨在让 MCP 服务器更易于检查和理解。第二个是 datasette-mcp，它将这种新方法应用于 Datasette。

Datasette 是 Willison 用于探索和发布结构化数据的开源系统。它已通过 Web 界面和 API 暴露数据库。MCP 则提供了另一种专为使用工具的语言模型设计的接口。

这种组合很有启发性。Datasette 部署天然是远程、结构化且供多用户共享的。与安装在智能体旁边的开发者工具相比，它并不那么契合本地命令行模式。

MCP 服务器可以使用客户端能够理解的模式来声明数据库工具。智能体可在提交查询前检查可用操作。服务器运营者则保留对认证、权限、限制和实现细节的控制。

这使 Anthropic 与 Simon Willison 的比较比“MCP 对阵 Skills”更为细致。技能可以教会智能体如何查询 API；MCP 则能为许多客户端提供发现和调用该 API 的共享契约。

两种方式也可以协同工作。技能可以说明何时使用 MCP 服务器、解释其领域概念，或提供跨越多个工具的工作流。MCP 则负责远程执行边界。

这种分工减轻了 MCP 成为每一种智能体行动通用答案的压力。本地命令可以保持在本地。库可以服务于灵活的编码任务。技能可以打包操作知识。

在服务器控制执行、且多个客户端需要同一可发现接口的场景中，MCP 获得了更清晰的角色。企业数据、托管搜索、共享服务和经认证的业务系统都符合这一模式。

因此，协议简化改变了竞争问题。开发者不再需要问：每个工具是否都值得套一层 MCP 包装？他们可以问：某项远程能力是否能从标准化发现和调用中受益？

这比 MCP 最早期最宽泛的诠释所作出的承诺更小，但也更可信。标准往往是在边界变得更清晰后才真正有用。

无状态请求让 MCP 更适配普通云基础设施

MCP 2.0 之所以重要，是因为它从常见部署路径中移除了专门的协调机制。

已获接受的 无状态提案 指出了旧初始化模型的三个问题：会话使扩展变复杂、削弱故障恢复，并增加双方的实现工作。

设想一个运行于三个服务器实例上的远程搜索工具。在面向会话的设计下，后续调用可能需要由处理初始化的同一个实例完成。基础的轮询负载均衡器无法保证这一结果。

运营人员可以通过粘性路由解决这个问题，也可以将会话数据存入共享服务。这两种方案都会引入运行状态、额外的故障模式和新的监控要求。

粘性会话可能导致工作分配不均。共享存储则会形成另一项依赖。服务器重启可能使本地状态失效，而客户端必须检测故障并重复初始化。

采用新的请求模型后，任何健康实例都可以处理兼容的工具调用。网关可依据方法和工具元数据路由，而非连接历史。

这一改变也让无服务器部署更具可行性。按需启动和停止实例的平台，在请求不依赖早先请求遗留内存时表现最佳。

服务器仍需要持久存储来保存真正持久的应用状态。无状态 MCP 并不会消除数据库、对象存储、浏览器工作进程或任务队列。它消除的是协议状态必须伴随它们存在的假设。

长时间运行的操作如今置于基于扩展的模型之中。服务器可以返回任务句柄，客户端随后通过显式操作检查、更新或取消该任务。

这种区别很重要。隐藏的会话状态会将工作流耦合至一段传输关系。任务句柄则会将工作流转化为可寻址资源，其他获得授权的组件也能够管理它。

多轮请求处理了另一种棘手情形。有些工具需要在完成前从用户或客户端获取更多信息。早期实现将这种交互与已建立的会话关联起来。

新设计只允许服务器在处理客户端请求期间发起请求。关联数据会在请求和响应周期中传递，从而避免建立永久性的协议会话。

这限制了某些行为。服务器无法在发起调用很久后意外联系客户端。这一限制降低了灵活性，但让用户提示拥有更清晰的来源和生命周期。

工具发现也更容易进行路由和缓存。该规范将方法和工具元数据添加到 HTTP 标头中。网关无需解析每个请求体即可检查这些元数据。

服务器可以为列表响应附加存活时间值。客户端随后可以在允许期限内复用工具信息，而不必为每个短生命周期的子代理重复请求同一份列表。

无会话提案警告称，早期行为可能导致与子代理数量乘以服务器数量成正比的重复发现流量。无状态列表让编排器有了更好的依据来避免这类成本。

随着代理系统变得更加分布式，这一点愈发重要。一次用户请求可能触发一个规划器、多个专门工作器以及一个验证器。为每个分支重复初始化和发现会增加延迟与流量。

修订后的协议还为工具定义采用了完整的 JSON Schema 2020-12。JSON Schema 是一套用于描述结构化数据的标准词汇，包括必填字段、类型和验证规则。

更丰富的 schema 可以描述更精确的输入与输出。这让客户端获得更好的信息，用于验证调用和构建界面，也减少了对表述宽泛的工具描述的依赖。

扩展提供了另一种架构分离形式。MCP Apps 可以提供服务器渲染的界面，而 Tasks 则处理耗时较长的操作。这些功能能够独立演进，无需将每项能力都塞入协议核心。

正式的生命周期规定，从功能弃用到最早移除之间至少间隔 12 个月。这并不能消除迁移工作，但在这次彻底调整之后，它为实现者提供了更清晰的规划窗口。

官方 TypeScript 指南表明，迁移仍需要有意识地推进。SDK migration guide 指出，新线缆格式需要显式采用，而不会悄然改变每一个现有应用。

这种谨慎是恰当的。新规范不会仅凭发布就自动创造互操作性。客户端、服务器、网关和 SDK 必须实现相同的细节，并针对真实工作负载进行测试。

即便如此，这一机制仍解决了一个具体弱点。它用云团队已在普通 HTTP 服务中使用的模式，取代了 MCP 特有的会话机制。

显式状态带来新的安全性与可靠性问题

无状态 MCP 消除了基础设施摩擦，但将更多责任转移给了工具设计、授权和代理记忆。

显式句柄让状态变得可见且可移植。这些优势也扩大了敏感标识符可能出现的范围。句柄可能进入聊天记录、提示词、日志、追踪信息、剪贴板内容或子代理消息中。

服务器不能将知晓某个标识符视为充分授权。它应在每次调用时同时验证句柄和经过身份验证的身份。

这类似于许多文档和项目服务采用的设计。资源 ID 用于识别对象，而当前授权上下文则决定调用者能否读取或修改该对象。

未认证服务面临更棘手的问题。在这种场景下，一个不可预测的句柄可能像持有者令牌一样运作。任何获得它的人，都可以在句柄过期前访问其底层状态。

无会话规范建议在这类情况下使用高熵标识符和有限生命周期。由于 MCP 未定义线缆级句柄类型，这项建议仍属于实现指导。

这造成了执行缺口。客户端无法自动识别哪些返回字符串代表活跃状态。除非工具名称和描述传达其角色，否则 browser_id 看起来与其他值没有区别。

因此，编排器并不总能知道哪些标识符必须在上下文压缩后保留。它也可能难以判断哪些值需要清理，或绝不应传递给另一个子代理。

模型通常会携带文件路径、提交哈希、URL 和交易标识符。它们仍可能错误复制句柄、遗漏句柄，或在长对话被总结时丢失句柄。

会话状态也有类似弱点。客户端使用不一致的生命周期，许多客户端在断开连接后也不会恢复会话。移除会话让这些问题变得明确，但并不会让状态管理自动化。

清理带来了另一个尚未解决的细节。会话结束曾经理论上能作为释放资源的信号。实际上，客户端往往结束会话过于频繁、过于罕见，或因无关的页面重新加载而结束。

显式工作流需要自己的过期和销毁策略。浏览器服务可能提供 close_browser，同时强制执行空闲超时。任务服务则可能在规定期限内保留已完成的结果。

在采用过程中，向后兼容增加了运营复杂性。依赖会话 ID 的现有服务器无法在不改变其状态模型的情况下，直接接受新的协议修订版本。

客户端和 SDK 可以在必要时协商使用较旧的修订版本。这允许逐步迁移，但也形成了两条开发者必须测试的行为路径。

在无状态 HTTP 下，某些能力变得不那么直接。非请求触发的通知和长期、服务器驱动的交互，无法像独立请求那样自然契合。扩展和监听机制必须承载这类工作。

也不能保证仅仅因为会话消失，每个 MCP 集成都将变得高效。设计不佳的 schema 可能消耗上下文。大型工具目录可能令模型困惑。不清晰的描述仍可能触发错误调用。

Skills 和命令行工具在这里仍保有优势。编码代理通常可以检查程序的帮助输出，并写出一段短脚本，而无需加载庞大的远程工具目录。

本地工具还可以让敏感数据留在用户机器上。远程 MCP 部署会引入认证、网络暴露、日志记录和服务可用性等问题，而本地执行能够避免这些问题。

MCP 也无法解决提示注入问题。无论传输是否有状态，具备工具能力的代理都可能将私密信息、不可信输入和外部通信结合起来。

服务器运营者必须限制权限和输出。代理构建者必须控制哪些工具会同时出现。用户需要为具有实质影响的操作设定清晰的审批边界。

这些限制挑战了对 Anthropic Simon reversal 最强的一种解读。Willison 再度产生兴趣，验证的是架构变更，而不是每一种 MCP 实现或每一个拟议服务器。

mcp-explorer 和 datasette-mcp 是有价值的早期实验，因为它们暴露了实际问题。客户端能否稳定地发现工具？schema 是否易于理解？认证和状态句柄能否经受真实工作流的考验？

无状态 MCP 最有力的论据将来自互操作性证据。独立客户端应能无需定制补丁就连接独立服务器，而运营者应能使用常规基础设施部署它们。

在这些证据不断积累之前，MCP 2.0 仍是一项更好的基础，而非一场已经完成的胜利。协议消除了一个主要摩擦来源。最终系统是否安全且易于理解，仍取决于实现者。

MCP 2.0 之后开发者应关注什么

下一项考验是 SDK、真实服务器和客户端的采用情况，而不是仓库数量的又一次激增。

第一个信号是对 2026-07-28 修订版本的实现覆盖率。官方 SDK 需要一致支持发现、每请求元数据、显式能力、Tasks 和授权行为。

仅有版本标签并不够。开发者应关注一致性结果和跨语言测试。Python 服务器、TypeScript 客户端和托管网关应对相同请求和错误达成一致。

强大的跨 SDK 兼容性将强化这样一种观点：MCP 现在提供了稳定的远程工具边界。持续的不匹配则会削弱这一观点，因为它会让开发者重新回到面向特定客户端的适配器。

第二个信号是生产服务器如何迁移有状态工作流。浏览器自动化、交易、购物车和长期运行的研究任务，为显式句柄提供了严苛测试。

成功的迁移应展示可靠的清理、逐请求授权、句柄交接和上下文压缩。它们还应说明，当代理丢失或重复使用标识符时会发生什么。

如果这些模式变得可复用，显式状态将显得比模糊的会话更具抽象优势。如果每个服务器都发明不兼容的生命周期规则，协议只是转移了复杂性，而非降低它。

第三个信号是 MCP 与 Skills 的关系。代理平台应展示何时选择本地命令、由 skill 引导的 API 调用，或远程 MCP 服务器。

清晰的选择规则将强化这一更狭义的论点。MCP 将服务于共享的远程能力，而 Skills 则封装指令和本地工作流。

持续重叠可能造成重复维护。工具所有者可能需要为同一项能力维护 API、CLI、skill 包、MCP 服务器和面向特定客户端的集成。

开发者不应将这种重复视为不可避免。一个 skill 可以引用 MCP 服务器，MCP 服务器也可以封装现有 API。真正有用的问题是，哪种接口拥有持久的契约。

对于数据工具，Willison 的实验提供了一个值得关注的具体方向。Datasette 已经通过 Web API 提供结构化信息。datasette-mcp 可以检验，面向代理的契约是否能改善发现和安全查询。

构建知识工作流的团队面临类似选择。本地文档和笔记通常适合放入私有、可搜索的工程知识库。共享业务系统则可能更适合经过认证的远程工具。

关键在于，不要仅仅因为通用协议让连接变得容易，就授予单个代理一组不受限制的工具。标准化降低了集成工作，但无法替代权限设计。

Anthropic Simon Willison reversal 的价值在于，它发生在一段真正怀疑之后。MCP 并非通过品牌宣传重新获得关注。其维护者移除了批评者能够在已部署系统中指出的一项结构性负担。

协议就应当这样演进。它应吸收失败假设带来的证据，收窄自身职责，并让常见操作更容易被理解和推理。

在接下来的三个月里，检查你实际使用的客户端和服务器。确认它们是否支持最终修订版本、如何表示应用状态，以及它们的授权是否遵循每个句柄。

然后将结果与最简单的替代方案进行比较。如果本地命令仍然更清晰，就继续使用它。如果许多代理需要同一项受治理的远程能力，就测试无状态 MCP，并记录互操作性仍然失败的地方。