今天刷到一个吵得挺凶的话题，正好和我们这种天天写接口的人有关。8 月 19 日 InfoQ 发了篇文章，标题问出了很多后端开发者心里的疑问：MCP 走向无状态，这不就又变回 API 了吗？知乎
背景先交代一下。7 月 28 日，MCP 发布了 2024 年问世以来最大的一次修订，版本号就叫 2026-07-28（目前是 v1.0 RC 阶段），核心动作一句话能说清：把协议从有状态改成无状态。以前 MCP 的玩法是「先握手再聊天」——客户端先发 initialize，服务器返回能力和会话 ID，之后每个请求都得带着这个 ID，服务端要记住每段对话进行到哪了。新规范直接砍掉了这套协议层握手，连 Mcp-Session-Id 这个头都成了历史，每个请求自带版本号、客户端信息和能力声明，任何一个服务实例都能独立接住并处理任何一次请求。知乎
还有一个配套变化值得注意：老协议里服务器可以顺着长连接主动向客户端发请求，比如让用户确认一个缺失的参数、或者请求模型做一次采样；新版统一改成了多往返请求（MRTR）——工具执行到一半需要输入时，服务器返回一个「input_required」结果附上问题，客户端拿到答案后重新发起一次调用就行。长连接这条路，算是彻底翻篇了。36氪
社区反应分成两派。一派认为这是「Agent 基础设施终于可以像 Web 一样部署」的时刻，Simon Willison 公开说无状态 MCP「重新点燃了他的兴趣」。知乎另一派则冷哼：这不就是承认之前设计错了？B 站上连 BetterStack 的视频都被搬过来了，标题相当直白——《MCP 从一开始就是错误的（他们刚刚修复了它）》。哔哩哔哩
但如果你和我一样是写 Web API 的，我的判断是：这个问题的答案恰好反过来。这不是 MCP 变回了 API，而是你的技能终于在 MCP 世界里值钱了。
先看这次改动帮我们省掉了什么。老 MCP 部署最头疼的就是服务端要保存会话：想扩容，网关得配粘性路由（session affinity），或者后端自己搞共享会话存储；实例一重启，还要考虑会话恢复。这些对写惯了 API 的人来说都是老本行，但在老 MCP 里全成了新问题。新协议把会话亲和直接删了——普通轮询负载均衡就能用，一个 /mcp 端点就能承载整个服务，Serverless 部署、水平扩容、跨区域切换都变成自然而然的事。知乎
新规范还允许把方法名和工具名镜像到 HTTP 头里，网关可以不解析业务正文，直接按请求类型做路由、限流和授权。这不就是我们每天在 API 网关前干的那些事吗？你现有的网关策略、WAF 规则、审计管道，基本可以原样复用。36氪
还有一个容易被忽略的细节：列表类响应新增了缓存提示和确定性顺序要求。为什么这个重要？工具目录如果每次返回的排序都不一样，哪怕内容没变，上游大模型的 prompt 缓存也会失效，等于每次调用都在白烧 token。稳定排序加缓存提示，本质是省钱优化——而「缓存一致性」这种词，API 开发者太熟了。授权部分也在向标准世界靠拢：引入 RFC 9207 发行者验证，动态客户端注册改成客户端元数据文档，做过 OAuth 集成的人上手不会陌生。知乎
不过先别急着高兴，有三件事协议没替你解决，恰恰是眼下最容易踩的坑。
第一，无状态不等于没状态。协议砍掉的是「协议层会话」，但你的工作流进度、长任务结果、用户权限、审批记录总得有地方放——只是从 MCP 服务器的内存搬进了应用层。放客户端内存、工作流数据库还是业务系统，这是你要做的设计决策，协议不管。
第二，无状态不等于可以随便重试。「查文档」这种读操作，靠请求 ID 和幂等键可以安全重试；但「发消息」「提交审批」「执行付款」这类写操作，必须配业务幂等、状态查询和人工确认点。协议解决的是请求怎么分发，副作用还得你自己兜底。
第三，也是最重要的：安全。今年 7 月的一篇公网扫描论文发现了 21,000 多个暴露在公网的 MCP 服务器，其中 91.8% 的生产服务器没有 OAuth 保护，还有 687 个实例允许无限制的 shell 调用。知乎另一个数字同样扎心：只有 18% 的工具声明了 outputSchema，意味着工具契约悄悄变更时，调用方只能当黑盒。新版本的授权改进取能改善身份验证，但证明不了「这个工具值得信任」——参数校验、输出过滤、最小权限，仍然是应用层的活。
反方的声音也值得认真听。今年 3 月 Scalekit 发布过一组基准测试：同一模型下，MCP 的 token 成本最高能到 CLI 的 32 倍。知乎具体到「这个仓库是什么语言」这种简单任务，CLI 只要 1,365 个 token，MCP 要 44,026 个，因为 MCP 会把全套工具定义塞进上下文。有人算过账：同样 1 万次操作，MCP 每月约 55 美元，CLI 做同等的 GitHub 任务只要 3 美元。Perplexity CTO、Y Combinator 团队也公开表态，优先用 CLI 加 API 的轻量方案。
所以到底怎么选？目前社区形成的判断准则其实挺清楚：单机、单用户、追求效率的小场景，尤其工具本身自带成熟 CLI 的，用 CLI 加 Skill 文件就够了；多租户 SaaS、需要按用户授权和审计、要上合规（HIPAA、SOC 2 这类）或者大规模治理的，MCP 仍然是绕不开的标准答案——CLI 的共享凭证、没有按用户审计这些问题，天生不适合多租户。Stacklok 对 100 位资深技术负责人的调查也印证了这个趋势：41% 的软件组织已经以某种形式把 MCP 用进了生产，67% 的 CTO 把 MCP 列为未来 12 个月的默认集成标准，而安全是第一大采用障碍。知乎
生态侧的信号也很密。这两天，企业微信 5.0.10 一次性开放了 CLI 和 MCP 能力，消息、邮件、文档都能让 AI 代操作。知乎飞书 MCP 接入实战、Azure API Management 挂 MCP Server、ASP.NET Core 一行代码转 MCP 这类文章这几天也在密集出现——这个领域已经从「讲概念」进入「拼落地」的阶段了。
最后给准备动手的同学一份迁移建议。官方 SDK 的迁移文档明确提醒：即使升级到 v2 包，也不会默认在线上传输新协议字节，客户端需要显式开启自动协商或锁定版本——这个设计避免了升级后突然和旧服务器失配。知乎所以安全路径是「双栈」而不是「切换日」：先升 SDK 和可观测性，再开协商，最后逐步放量。具体六件事：
列出现有 MCP 服务的所有会话状态，分清哪些是协议状态（可删），哪些是业务状态（必须保留）；
核实客户端和服务端 SDK 是否真的支持 2026-07-28，别只看包的大版本号；
用「新客户端 + 旧服务器」「旧客户端 + 新服务器」「双新」三组组合跑协商测试；
给每个有副作用的写工具定义幂等键、结果查询和人工确认点；
在网关、服务、工具三层传递同一个请求标识，不然一次 Agent 任务跨多次无状态调用，链路根本没法追踪；
先用一小部分无风险的读工具开新协议，稳定后再扩到写操作和长任务。
再往后看，有两个趋势值得盯。一是 8 月 6 日 OpenAI、Microsoft、GitHub、AWS、Vercel、Cursor 六家联合发布了 Agent Plugins 1.0.0，要定义 Agent 应用的打包与分发标准，而 MCP 的发明者 Anthropic 不在核心圈子里。知乎连接层的战争结束了，上层的标准战刚开始。二是注册表、网关、托管正在成为新的「收费站」：Arcade.dev 收购了 Smithery，Snowflake 收购 Natoma 做 AI 网关，Workato 推出企业 MCP 注册表，「连接免费、治理收费」正在变成这个生态的商业模式。
一句话总结：无状态化把 MCP 拉进了标准云基础设施的运行模型。对 Web API 开发者来说这是利好——你不用从头学一套有状态会话的新东西，既有技能可以直接接管；但幂等、授权、可观测性的责任，也更清楚地交还到了你手上。这不是 MCP 变回了 API，而是它终于开始像个正经基础设施。写接口的人，入场窗口就是现在。
