MCP协议新路线图：五大改进方向直击生产级痛点

两周前，我打开一个 Spring Boot 服务背后运行的 MCP 服务器配置，打算在负载均衡器后面再加一个实例，这时我想起来——作为一个曾经踩过坑的开发者——那玩意儿是有会话状态的。协议会话、初始化握手、黏性路由。这是一个为代理设计的协议，最应该感觉像无状态的工作负载，结果水平扩展意味着会话复制或固定连接。

这个抱怨现在正式过时了，还有四个我之前吐槽过的东西也在被砍的名单上。MCP 维护者本周发布了新的路线图（241 个 Hacker News 点，而且还在涨），不同于大多数协议路线图，这一份读起来就像是「如果你真的在生产环境跑 MCP 服务器会碰到的那些烦人小问题」的清单。它涵盖了 2026-07-28 spec 发布的内容，以及接下来五个优先领域。

声明：这是对维护者路线图的分析，不是对已发布最终功能的评审。2026-07-28 的变更已经实装到当前 SDK 中。五个优先领域是方向性内容，SEP 处于不同阶段。我的生产服务器基本上还在用旧版形态，所以当我告诉你我会怎么做时，那是计划，不是实战经历。

以下是你用 Java 构建代理时需要关注的五个转变，以及每个转变带来的决策。

转变 1：会话没了，你的架构应该注意到

已经发布的最大变化。2026-07-28 的 spec 发布中，协议级会话和初始化握手被移除了（SEP-2575、SEP-2567）。远程 MCP 服务器现在用维护者的话说，「与其他任何 HTTP 工作负载没有区别」。客户端也可以调用 server/discover 来了解支持哪些版本和能力，然后再做其他操作，而且列表结果可以缓存了（SEP-2549）。

对于 Spring Boot 团队来说，这是 MCP 迄今为止对 Java 最友好的改动。一个 MCP 服务器现在就是一个普通无状态的 HTTP 服务，这意味着你已有的所有知识都适用：普通的 @RestController 语义、 ingress 不需要黏性会话、 serverless 可以零扩展、普通的 readiness probe 而不是协议感知的健康检查。

我会怎么做：如果你的 MCP 服务器用了黏性路由或者内存会话映射，拨出一个 sprint 的工作量来针对当前 SDK 剥离掉这些。我之前用的临时方案——把会话状态外置到 Redis 让任何实例都能服务任何客户端——虽然能接受，但每个工具调用都多了一跳和多了一个故障点。协议彻底移除了这种需求，这是你应该趁着迁移范围还小的时候去行动的难得好消息。

转变 2：服务端发起的请求出局了，多轮对话进来了

Java 团队应该重新学习的模式。旧 spec 中服务端发起的请求（服务端回调客户端）从来没有很好地适应无状态部署和企业防火墙。路线图确认 Task 被重新设计成了一个正式扩展（SEP-2663），一个新的多轮对话请求模式（SEP-2322）取代了服务端发起的请求，这样 elicitation 和类似流程可以在无状态服务器上工作。

实践中：客户端轮询，或者订阅，而不是服务端通过它打开的通道向下推请求。感觉老派——直到你想起这恰恰是 REST API 获胜的方式。路线图在这里的下一步是通过 webhooks 和 channel 实现服务端发起的 events，「这样客户端就不需要轮询等结果了」。

我会怎么做：停止设计假设持久双向管道的工具。如果你有长时间运行的工具（我的日志分析工具可以跑好几分钟），把它们建模成 Task：启动工作、返回一个 task handle、让客户端稍后回来查询。这个形态能熬过路线图上的每一次传输变更，因为它不假设任何连接相关的东西。

转变 3：代理身份要来了，Java 的准备出奇地好

这是我最关心的一个。今天，MCP 的授权是围绕一个人在浏览器里批准访问来构建的。路线图指出：越来越多的调用方是代理——它们有自己的身份、代表一个不在场的用户行事、或者把更窄的权限委托给子代理。计划是让服务器有一种标准化的方式来识别和信任这些身份，「建立在现有标准之上，而不是粘贴 API keys 和长生命期的 tokens」。

任何把代理绑定到第三方 API 的人都懂当前的现实：环境变量里的 SECRET_AGENT_API_KEY，没有过期、没有作用域、无法证明调用方是谁。当这个代理生出三个子代理，它们都共享那把上帝钥匙。

具体机制点名了：证明所有权演示（DPoP，RFC 9449）和工作负载身份联合，以及与 IETF OAuth 和 WIMSE 工作组的合作。企业托管授权（Enterprise-Managed Authorization），建立在这套机制之上的企业扩展，已经稳定了。

这里有一个让 Java 开发者会心一笑的部分：Spring 生态已经会讲 DPoP 了。Spring Authorization Server 1.5（2025 年 5 月 GA）发放 DPoP 绑定的 tokens，Spring Security 6.5 在资源服务器上验证 DPoP proofs。DPoP 把访问令牌绑定到客户端持有的密钥上，所以偷来的 token 没有私钥就毫无用处。对于代理身份故事来说，这就是「有人泄露了 token」和「token 只能在拥有密钥的工作负载上使用」的区别。

我会怎么做：如果你现在在构建一个 MCP 服务器，而且它将来会面对其他团队的代理，不要自己造一个 API key 层。搭起 Spring Authorization Server，要求 DPoP 绑定的 tokens，把 MCP 未来的代理身份工作当作你已经运行的模式的采用。你将通过配置迁移，而不是重写。

转变 4：渐进式工具发现修复了你已经踩过的坑

最安静的一项，却对模型质量影响最大。路线图对规模直言不讳：「连接到一个有一百个工具的服务器意味着在用户还没问一个问题之前，模型就要为整个表面付钱，而且工具选择往往随着列表增长而变差。」修复方案是渐进发现：一个小的入口点，随着对话收窄逐步揭示更多目录。

这和我自己在代理布线中看到的一致。超过几十个工具之后，模型开始选看起来像模像样的错误工具，而且每次调用时你的 prompt 预算都会因为工具 schema 而流血。我上个月写把 Spring Boot 服务暴露为 MCP 服务器时，建议是诚实标注工具、保持表面小。协议现在把这个建议正式化了。

还有一个 contracts 清理：tools/call 响应当前可能以多种形式携带相同输出，而服务器开发者没有办法知道客户端会把哪种形式放到模型面前。路线图的目标是标准化为一种清晰的 contract。

我会怎么做：现在就把你的工具目录设计成树形，即使机制还没落地。按领域对工具分组，暴露一个总结性的「列出能力」工具作为入口，让详细工具引用它们的组。当渐进式发现在 SDK 中到来时，你的形态可以直接映射上去，而不需要重新设计。

转变 5：一个传输协议统治一切

不起眼的清理工作，缩小你的代码库。2026-07-28 后，远程 MCP 服务器变成了普通的 HTTP 工作负载。路线图想把这一点也延伸到本地服务器：本地服务器通过 stdio 上的 Streamable HTTP 说话，「统一到一个传输协议」以简化服务器和客户端开发。

如果你维护过双传输路径——一个给本地 stdio 服务器，一个给远程 HTTP——你就知道代价：两套配置表面、两个故障点、两套 bug。统一传输意味着统一。

我会怎么做：不紧急，但停止在 stdio 特有处理上投入。你拥有的任何根据传输类型分支的抽象都是技术债务，而且已知兑付日期。

我交给自己团队的检查清单

从 MCP 服务器部署中剥离会话黏性；以无状态的 2026-07-28 形态为目标（spec changelog）

把长时间运行的工具建模成 Task，永远不要建模成假设存活连接的 tools

用 Spring Authorization Server + DPoP（1.5+ / Spring Security 6.5+）替换自造的 API keys，让代理身份作为配置到来，而不是重写

现在就把你的工具目录做成树形，在渐进式发现落地之前

采用 server/discover 和缓存列表结果来削减每个会话的冗余轮询

关注 Server Card 工作组：.well-known 元数据让客户端在连接之前就能了解你的服务器，所以从第一天起就保持那个文件准确

我会做得不同的地方

我花了太长时间把 MCP 当成一个聊天应用协议来应付，我的第一个服务器设计暴露了这一点：有状态、会话固定、单传输、自己发明的基于密钥的认证。每一个选择现在都被方向变迁废弃了。我会送给过去自己的经验：当一个被所有主要实验室支持的协议发布了路线图，把它当作下一次重构的预览来读，趁对齐还便宜的时候早点对齐。

这个路线图也对贡献异常开放。优先领域的 SEP 会得到快速评审，工作组自行 triage 各自的领域，而且各处都缺更多贡献者。Java 在 MCP 客户端和服务器实现中的代表性相对于其企业足迹是不足的，这意味着一个 Java 视角在 Agents 或 Transports 工作组里有超大的杠杆。

MCP 正在围绕 web 上无聊但经过验证的模式进行整合：无状态 HTTP、联邦支持的 identity、能力的渐进披露。如果你跑 Spring Boot 服务，这个整合直接发挥你技术栈的优势。把这个路线图当作待办清单的团队将通过配置迁移。忽视它的团队将在以后、在压力下通过重写迁移。

你在生产环境跑过 MCP 服务器吗，还是你的代理栈还在直接调用 SDK？什么先坏的？我看每一条评论，战壕故事是我们其他人学习的方式。

每周写 Java、Spring Boot 和 AI。订阅——免费的。