这周有开发者把7月28号叫做"无状态MCP日"。Model Context Protocol发布了2026-07-28版规范,核心变化就一件事:工具调用从"建会话+调用"两次HTTP请求,压成一次。这是MCP自2024年11月发布以来改动最大的一次规范更新。
更值得注意的是时间点。开发者Simon Willison去年年底刚写文章说,MCP这一年被Anthropic自家的Skills和"开shell+curl"的通用agent抢了风头,判它有点过时。这周他反手一周内连做三个MCP项目。协议变简单只是表面原因,他自己给出的理由更直接:开放shell和网络权限给agent,风险已经暴露得够多,MCP工具反而更容易审计、更容易限权。这不代表MCP已经打败Skills或shell agent,材料能证明的,只是他自己重新看好并加大了投入。
一次请求代替两次,省的是什么
旧版MCP要跑通一次工具调用,得先发一次初始化请求,拿到一个Mcp-Session-Id,再带着这个ID发第二次请求才能真正执行工具。新版规范里,客户端在请求头带上MCP-Protocol-Version、Mcp-Method,一次POST直接调用。
具体差在哪,列出来更清楚:
| 环节 | 旧版 stateful MCP | 新版 2026-07-28 stateless MCP |
|---|---|---|
| HTTP请求数 | 2次(先initialize再tools/call) | 1次(直接POST tools/call) |
| 会话标识 | 需要Mcp-Session-Id头 | 不需要 |
| 协议头 | 无专用头 | 带MCP-Protocol-Version、Mcp-Method、Mcp-Name |
| 服务端状态维护 | 需要,还得保证同会话路由到同一台后端 | 不需要,请求可路由到任意后端 |
老子说"为学日益,为道日损"。技术圈平时都在做加法,这次MCP难得做了一次减法:去掉一次请求,去掉会话维护逻辑,协议反而更顺手。对正在自建或托管MCP服务端的团队,这直接省掉了分布式系统里最烦人的一类问题——粘性路由。对跑在笔记本上的小模型,工具调用变简单也意味着更容易驱动得动。
有一点规范博客没讲清楚:哪些场景还离不开会话状态,比如需要服务端主动推送、或者跑很久的任务,这类需求怎么处理,目前看不出来。想现在就迁移的团队,这是自己动手验证时该盯的第一件事。认证授权信息怎么在无状态请求里传递,原文同样没有展开。
三个项目,复杂度降没降
Willison没停在读规范,他连做了三个东西验证这套简化到底实不实在。
| 项目 | 功能 | 成熟度 |
|---|---|---|
| mcp-explorer | 命令行探针,uvx直接跑,列出/查看/调用任意MCP服务器的工具 | 可用 |
| datasette-mcp | 给Datasette加/-/mcp端点,三个工具:列库、看schema、跑只读SQL | 第四次尝试后终于做到可发布,SQL执行目前仍只读 |
| llm-mcp-client | 给他的LLM命令行工具接入MCP | alpha阶段,是否并入LLM core还在考虑 |
datasette-mcp这个插件他其实之前试过三次都没做出满意的版本,这次靠新规范才达到可发布的程度。这更像是复杂度确实降了的一个佐证,不是严格证明——毕竟第四次尝试本身也可能只是他这次找对了实现思路。
锐评:能力竞赛让位给边界设计
MCP工具的边界写在schema里,能审计、能限权,连本地跑的小模型也调得动。shell加curl自由度更高,但要完全审计一个能跑任意命令、又能联网的agent环境,成本高得多——Willison七月刚写过这类风险有多容易捅出问题。这是他去年觉得MCP"不如shell灵活"之后,今年又转回来的真正理由。
但无状态没有解决老问题。他2025年4月就写过MCP的提示注入隐患:用户自己混搭工具,数据外泄的风险责任其实甩给了用户自己。这次的改造只是把"agent能做什么"这件事变得更容易讲清楚,不代表提示注入或数据外泄被解决了。
对正在给agent设计工具接入的团队,这周的信号很具体:先查自己现有的MCP服务端是否要跟着升级,还是可以继续留在旧版——向后兼容范围规范博客没写清楚,值得自己测一遍再决定要不要迁移。还在用开放shell+curl做敏感数据agent的团队,更该重新评估权限设计,而不是先想着换个更强的模型。
模型看着更强,但真正难的从来不是能力,是把能力关进一个能审计的边界里。协议变简单不代表可以少想安全,边界画得越清楚,才越经得起审计。