MCP 新版发布了，但你的旧代码还能跑（至少一年）

king of lion

171人浏览 · 2026-08-06 23:09:18

king of lion · 2026-08-06 23:09:18 发布

MCP 2026-07-28 正式发布了。这次不是小修小补——协议被"无状态化"重写了一遍：initialize 握手没了，Mcp-Session-Id 没了，Roots、Sampling、Logging 三个特性也被挂了弃用标签。

最近 MCP 新版发布后，有一个问题问得最多：“我的 MCP Server 会炸吗？”

不会。但有些东西会"悄悄坏掉"，你得知道。

Q：新版发布了，我的 Server 会炸吗？

不会。先说最直接的——弃用不等于删除。Roots、Sampling、Logging 在新规里有个最少 12 个月的过渡窗口，在此期间照常工作。你有一整年的时间慢慢迁。

另外，新版支持 dual-era——看到一个带着旧版 initialize 握手的请求，可以切回 legacy 逻辑；看到一个带着新版 _meta 字段的请求，就走 stateless 路径。还没升 SDK 的客户端不会掉线。

再就是 SDK 有兼容层。TypeScript SDK 2.0 已经发了，Python 2.0 在 RC，它们都在新版协议上实现了向后兼容。你的旧客户端连接新版服务器，SDK 自动走 legacy 路径，你一行代码不用动。

MCP 维护者自己的说法是：“Nothing breaks on July 28。”

在这里插入图片描述

Q：那我什么都不用改？

如果你的代码长这样——

@McpTool(name = "query_order", description = "查询订单")
public OrderDto queryOrder(@McpToolParam long orderId) {
    return orderService.findById(orderId);
}

这种情况不用改。@McpTool 注解、Resources 和 Prompts 的定义、你写的业务逻辑——全都原封不动。

但要搜一下代码里有没有这几个字符串：

Mcp-Session-Id
initialize
notifications/initialized

如果有，你需要处理。这些是新版删掉的东西。如果你只是用了 Spring AI 或 api2mcp4j 的 Starter，框架已经帮你封装好了，大概率搜不到。

Q：Elicitation 是什么？跟我有关系吗？

Elicitation 是 MCP 里"工具执行到一半，弹窗问用户确认"的机制——比如你写了个删除文件的工具，删之前想弹个确认框：“真的要删这 3 个文件吗？”

如果你做了这种交互，新版对它有变化。

旧版的 Elicitation 是服务器主动回调客户端——服务器发一个 elicitation/create 请求，客户端弹出确认框，用户点了"确认"，客户端再回复。

新版把这条路封了（stateless 协议不支持双向回调），换成了 MRTR——服务器返回 input_required，客户端重试原请求时带上用户的回答。对用户来说体验一样，对你的工具代码来说——调用方式变了，需要适配。

如果你只是单纯的查询类 API（查订单、查用户、查数据），压根没碰过 Elicitation，那这段跟你没关系。
在这里插入图片描述

Q：改了之后有什么好处？

对运维来说，最大的变化是：MCP 服务器终于可以当成普通 HTTP 微服务部署了。

旧版因为每次连接都有一个 Mcp-Session-Id，所有来自同一个客户端的请求必须打到同一台机器上——sticky session。这意味着你不能用普通的轮询负载均衡，要么配 session 亲和，要么搭共享 session 存储。

新版把协议级别的 session 砍了。每个请求自带版本和能力信息（塞在 _meta 里），可以打到任意一台实例后面。你用 Nginx、K8s Service、Cloudflare Workers，随便轮询，不用再搞什么 sticky routing。

GitHub 的 MCP Server 在接入新版后，changelog 里写了三件事：

删掉了整套 Redis session 存储——initialize 不再写数据库，每个请求也不再读数据库
不再对每个请求做 deep packet inspection（新版把 Mcp-Method 和 Mcp-Name 放到了 HTTP header，不用解析 body 就能做路由和日志）
elicitation 的每一步变成了独立 HTTP 请求，Go SDK 用一个 wrapper 同时兼容新旧客户端

另外，tools/list 现在可以缓存了。服务器返回 ttlMs 和 cacheScope，客户端不用每次连接都重新拉一遍工具列表。高频调用的场景下，光是省掉每次建连的 tools/list 请求，就能省不少 token 开销。

在这里插入图片描述

Q：一句话总结我要做什么，有没有现成的方案？

全局搜一下 Mcp-Session-Id、initialize、elicitation/create。三个都搜不到，你该干嘛干嘛。搜到了，打开 MCP 官方的 migration guide 对着改。

如果你用 api2mcp4j，它已经 100% 适配 2026-07-28 了——通过自定义 JSON-RPC Router 和 MRTR 状态机绕过了 Java MCP SDK 2.0 的限制，跟着升版本就行。

用 Spring AI 2.0 裸写的话，等官方 SDK 3.0 发布，现在 2.0 的 @McpTool API 在新版上仍然能跑，但底层走的是后向兼容路径。

其他语言看各自 SDK 的 release notes——TypeScript 和 Go 的 SDK 已经发了 2.0，Python 在 RC。

最后一句话

MCP 这次大刀阔斧砍掉的，都是它在过去一年半里发现"不该由协议层管理"的东西。session 不该管，state 不该管，日志不该管。砍完之后，MCP 变得更像一个协议该有的样子：薄薄一层，管好"AI 怎么发现和调用工具"，剩下的留给开发者自己决定。MCP 还会继续迭代，但方向已经清楚了——做薄协议层，把灵活性还给开发者。