图片：blog.modelcontextprotocol.io
摘要
- MCP核心维护团队在2026年3月路线图发布5个月后,公开了新的路线图。
- 在2026-07-28的规范发布中,协议层面的会话和初始化握手被取消,服务器得以在无状态的情况下实现水平扩展。
- 新路线图将原有的4项优先事项扩展为5项,智能体身份认证首次被列为核心议题。
服务器不用再一直保持连接状态了
MCP(Model Context Protocol)核心维护团队公开了更新后的路线图。作为将AI连接到外部工具或数据的通用规范,MCP常被称为"AI界的USB-C"。这次路线图中最引人注目的变化是,服务器不必再持续保持与客户端的连接状态。通过SEP-2575和SEP-2567,协议层面的会话和初始化握手被取消,这使得服务器可以在无状态的情况下实现水平扩展。
从3月路线图到现在,5个月里走到了哪一步
去年3月公开的路线图提出了传输方式演进与可扩展性、智能体通信、治理成熟度、企业级准备这四项优先事项。维护团队表示,过去5个月里这四个领域都取得了显著进展,大部分变化已经体现在2026-07-28的规范发布中,开发者很可能已经在SDK和文档里见过这些改动了。
除了取消会话外,客户端现在可以在连接服务器之前先调用server/discover来了解对方支持的版本和功能,列表查询结果也支持缓存了(SEP-2549)。在智能体通信方面,团队根据早期采用者的反馈,把Tasks功能正式转为扩展规范(SEP-2663);此外还引入了Multi Round-Trip Requests模式(SEP-2322),用来取代此前由服务器主动发起请求的方式,这种新模式即便在无状态服务器上也能正常运作。
治理和安全方面也做了调整
治理方面,团队正式采纳了Contributor Ladder(贡献者等级体系),并将各工作组自主审核所辖领域SEP(规范改进提案)的权限下放。规范本身也新增了正式的功能生命周期和废弃政策,2026-07-28版本中的功能废弃就是首个遵循该政策的案例。
企业级准备工作在这一阶段主要集中在安全性上。团队引入了发行方验证、与发行方绑定的客户端凭证,并将Client ID Metadata Documents(CIMD)确立为客户端注册的首选方式。此前以扩展形式提供的Enterprise-Managed Authorization,这次也升级为稳定版本。
新路线图重新划定为5项优先事项
| 优先事项 | 核心内容 |
|---|---|
| 智能体通信 | 引入服务器主动通知事件(webhook、频道),将Tasks扩展升级为正式规范 |
| 传输方式统一 | 把远程MCP服务器当作普通HTTP工作负载处理的方式,扩展到本地服务器(基于stdio的Streamable HTTP) |
| 智能体身份 | 用DPoP、Workload Identity Federation及标准令牌交换取代浏览器授权来验证智能体身份 |
| 工具调用与结果处理 | 将工具调用响应格式统一为单一契约,引入面向大量工具列表的渐进式发现机制 |
| SDK | 提升多平台、多语言SDK的易用性、规范符合度及文档质量 |
其中智能体身份这一项格外引人注目。目前MCP的身份验证依赖于人工在浏览器中直接批准访问权限,但随着越来越多智能体在云端以独立身份运行、在用户不在场时代为处理任务,以及需要向子智能体委派有限权限的场景增多,这种方式已经不够用了。为此,团队计划完成Demonstrating Proof of Possession标准的引入工作,并基于围绕Workload Identity Federation的讨论,定义智能体身份与权限委派路径。团队还表示将继续扩大与IETF OAuth及WIMSE工作组的合作。
想提交SEP提案该怎么做
只要落在这五项优先事项范围内的SEP,审核速度会更快,被采纳的可能性也更高。虽然范围之外的提案不会被自动拒绝,但由于维护团队的审核时间有限,优先事项领域的提案会被优先安排。如果你正在准备一份SEP,可以先确认它属于哪个优先事项领域,再提交到相应的工作组一起打磨完善。路线图页面上列出了各领域负责的核心维护者姓名,想参与讨论的人可以通过Discord联系。
编辑视角
回想3月路线图里"传输可扩展性"这个相当模糊的目标,这次干脆把会话和握手环节整个拿掉,称得上是相当果断的决定。此前保持状态的服务器很难在负载均衡器后面部署多台实例,一旦连接中断,进行中的任务上下文也会跟着丢失。如今在协议层面彻底去掉这个问题,让MCP服务器可以像普通HTTP工作负载一样处理,对于运营MCP服务器的公司来说,这相当于同时降低了基础设施成本和复杂度。
8月初OpenAI联合AWS、Cursor、GitHub推出的Agent Plugins标准,也支持打包MCP服务器配置。MCP持续朝无状态、轻量化方向打磨规范,可以看作是在为那些标准打下更稳固的地基——一个协议一旦稳定下来,建立在它之上的工具和标准数量往往会随之增长,这样的情形我们已经见过不止一次。
对于国内自己运营MCP服务器或接入SDK的团队来说,眼下有两件事值得优先处理。一是检查07-28版本中会话取消和server/discover的变动对现有服务器代码的影响;二是提前关注智能体身份认证方面的进展。目前直接粘贴API密钥的做法很可能很快会被基于DPoP或令牌交换的认证体系取代,而认证体系的迁移工作向来是拖得越晚、成本越高。
预计未来几个月内,服务器主动推送事件的webhook、频道机制,以及面向工具较多的服务器、只按需展示部分内容的渐进式发现机制,会先以规范草案的形式面世。这两项工作针对的都是当前"请求-响应"模式难以支撑的长时间智能体循环场景,对于已经把MCP用于生产环境的团队来说,这方面的SEP讨论值得持续跟进。
评论