这条讲的是 MCP 官方 8 月 22 号更新的路线图，出处是他们自己的博客。我读完把它存进夹子的时候才发现，上一条关于 MCP 的收藏还停在 3 月份那个旧路线图——就是画了四个优先领域大饼的那篇。今天对着新旧两张图看了一遍，怎么说呢。
先说和路线图关系最大、但大多数人可能是从 7 月 28 号那次规范发布里才知道的变化：协议级的会话和初始化握手整个砍掉了。原话我记不太清，但意思就是服务器以后不允许偷偷存状态，要能直接水平扩展。这个改动我当时看发布说明的时候没太当回事，觉得无非是运维省点心。这次对着新路线图才反应过来，它其实是后面一堆东西的前提。你服务器不存状态了，那"服务器主动推个请求给客户端"这种老玩法就死透了，所以才会有 Multi Round-Trip Requests 这种新东西来替代。引出这个替代品的 SEP-2322 我还没细读，但光看它让无状态服务器也能跑 elicitation 这一类流程这点，就觉得比之前那套优雅。不过，这也意味着以前很多照着"服务端能自己发起请求"写的旧工具，估计要成批地断。
另一个我觉得值得单独点开看的是 server/discover 这个能力，配套的是叫 SEP-2549 的列表结果缓存。这是 7 月版本里就带上的。它让客户端能直接问服务器："你现在支持哪些版本、哪些功能？" 然后还能把结果缓存下来。听起来不起眼，但配合那条 Server Card 工作组在推的 .well-known 元数据约定看，味道就变了——MCP 在往"不用真连上去，光凭一个地址就能先推理出这服务器是干嘛的"那个方向走。
这就是我觉得新路线图真正想干的事：不是给 MCP 加多少新功能，而是想把它从"一种需要专门库去伺候的协议"改造成"和普通 HTTP 工作负载一样无聊、一样可预测的东西"。路线图里明说了，HTTP 原生传输要统一和加固，目标是让远程 MCP 服务器看起来跟随便一个 HTTP 服务没什么两样，连本地 stdio 起服务器都可以走 Streamable HTTP。这种"把酷东西变无聊"的活最没流量，但最决定这东西能不能撑过三年。
顺手记一下身份那部分。路线图花了不小篇幅讲代理身份和企业级安全，比如要把 DPoP 标准最终确定下来然后推广，还要搞 Workload Identity Federation、ID-JAG 授权、标准令牌交换那一套。这块我是真的只能读，跑不了——我自己搭的那点小工具，从来都是本机 stdio 跑跑，最多加个本地 API key。一看到"与 IETF OAuth 和 WIMSE 工作组继续保持互动"这种句子，我脑子就自动进入一种"知道它很重要、也知道自己短期用不上"的放空状态。但反过来说，路线图敢把这么多精力押在"代理身份"这上面，说明 MCP 的维护者们已经默认了一个前提：以后跑在服务器上的 agent，至少得跟人一样有身份证，而且这身份证还不能是拍脑袋自己签的。这条如果你是在给公司挑 agent 基建，值得点开原文细读，尤其注意它怎么处理"客户端凭据绑定签名者"这个具体点——这对企业选型的影响比多几个工具大得多。
最后是 SDK 开发者体验。新路线图把它单独列成一个优先领域，说要砸资源去做 SDK 的人体工程学、跟规范的贴合度、还有跨语言平台的文档质量。看到这个我是真想鼓掌。MCP 现在最大的坎不是协议本身，是文档。我上个月试某几个非 Python/TS 语言社区贡献的 SDK，文档写得跟猜谜一样，函数名和实际行为对不上号。这种"你跑通了不是因为你读懂了，是因为你猜对了"的体验，比协议慢更劝退。官方愿意把钱和时间花在让 SDK 变顺手这件事上，方向是对的，就是不知道最后做出来的是不是又一个只有主流通用语言有人管、其他语言继续荒着的局面。毕竟光写"跨语言平台"四个字容易，真给几十个语言维护一致的高质量 SDK，那是另一回事。
写到这我本来想停，突然又想起路线图里关于 SEP 评审那段。它说属于优先领域的提案会加速，不属于的"不会自动拒绝"，但后面跟了半句实话——维护者时间有限。这句话翻译过来就是：想做周边生态的，趁早自己往那五个领域里靠；想搞点特别偏门玩法的，等着吧，不是不行，是没人有空理你。我把这段贴给一个也在写 MCP 小工具的朋友看，他回我一句："那我不是白折腾了。" 我说不白折腾，你那个连 discover 都不想做，最多算个自嗨。这对话没继续下去，估计话又说过头了。
不点链接也能带走的：下次再看 MCP 的新功能时，先问它是不是还需要一个活着的服务器才能运作。如果答案是"得有人盯着"，那它大概率活不到下一个路线图。这篇已经不短了，具体到某几个 SEP 我还没读完，等空了补。