如果你现在正在迁移模型上下文协议（MCP）服务器，那么在你阅读本文的其他内容之前，有一件事会耗费你整个下午的时间：
@modelcontextprotocol/sdk 没有 2.x 版本。将来也不会有。
该包停留在 1.30.0 版本。如果你去寻找 @modelcontextprotocol/sdk@^2，你将一无所获，并得出结论认为 v2 版本尚未发布。但实际上它已经发布了——在 2026 年 7 月 27 日，只是使用了不同的名称：
@modelcontextprotocol/server 2.0.0
@modelcontextprotocol/client 2.0.0
@modelcontextprotocol/core 2.0.0
@modelcontextprotocol/node 2.0.0
@modelcontextprotocol/express 2.0.0 ┐
@modelcontextprotocol/fastify 2.0.0 ├ HTTP 适配器
@modelcontextprotocol/hono 2.0.0 ┘
@modelcontextprotocol/server-legacy 2.0.0 兼容垫片
@modelcontextprotocol/codemod 2.0.0
我知道这一点，是因为我自己的工具曾以十足的自信告诉人们相反的信息。
出了什么问题
日期为 2026 年 7 月 28 日 的 MCP 修订版是该协议有史以来最大的变更。
简而言之：
- 传输层是无状态的。
initialize/notifications/initialized握手过程已移除。现在每个请求都在_meta字段中携带其协议版本和客户端能力。 -
Mcp-Session-Id已从可流式传输的超文本传输协议（HTTP）中移除。协议层面不再存在会话。 -
server/discover是强制要求的。服务器必须通过此接口宣告其支持的协议版本和能力。 - 由服务器发起的请求（
roots/list、sampling/createMessage、elicitation/create）已被多轮往返请求取代：服务器返回一个InputRequiredResult（需要输入的结果），客户端则带着答案重试。 -
logging、sampling和roots已被弃用，但并未移除——保留了至少十二个月的过渡期。
第二点是最令人头疼的。如果你在由会话标识符键控的 Map（映射）中保存任何数据，它在你的笔记本电脑上单进程运行时完美无缺，但一旦有两个实例位于负载均衡器后面，它就会间歇性地失败。这种失败是静默发生的，这是最糟糕的失败方式。
因此，我构建了一个检查器：包含七条规则，采用确定性引擎，过程中不涉及任何模型。将其指向一个正在运行的端点或代码仓库，它会告诉你哪些地方出了问题，并为每个发现提供规范页面链接，以便你可以验证其正确性。它作为一个智能体技能发布，同时也执行迁移工作——我稍后会回到这个话题——因为事实证明，仅就扫描器本身而言，它只是较小的一半工作。
接着，我自己的规则也错了
其中一条规则 MCP007 会在 @modelcontextprotocol/sdk 解析到的版本低于 2.0.0 时触发，并提示：
升级到
@modelcontextprotocol/sdk ^2。运行官方的 v1→v2 代码修改工具以处理机械性的重命名，然后重新检查。
这两部分都是错误的，而且错误的方式各不相同。
@modelcontextprotocol/sdk@^2 无法解析。该包从未有过 2.x 版本。因此，该工具自信地推荐了一个不存在的版本——导致用户花费二十分钟疑惑自己到底做错了什么。
我检查了节点包管理器（npm），发现最新版本是 1.30.0，版本列表中没有任何 2.x 版本；我阅读了软件开发工具包（SDK）的公告，发现其中未提及任何主版本号，于是得出结论：这条规则完全是凭空捏造的。所以我删除了它，w
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
