이미지: blog.modelcontextprotocol.io
摘要
- MCP核心维护者们公布了新路线图,距离2026年3月的上一版路线图仅过去5个月。
- 在2026-07-28的规范发布中,协议层面的会话与初始化握手被取消,服务器得以在无状态的情况下实现水平扩展。
- 新路线图将优先事项从原来的4项扩展到5项,智能体身份认证首次被列为核心课题。
- 발표일
- 2026-08-22 (현지시간), MCP 코어 메인테이너 발표
- 이전 로드맵
- 2026년 3월 공개, 4대 우선순위(전송 확장성·에이전트 통신·거버넌스·엔터프라이즈 준비)
- 주요 변경 반영 릴리스
- 2026-07-28 스펙 릴리스
- 세션·핸드셰이크 제거
- SEP-2575, SEP-2567
- 리스트 결과 캐싱
- SEP-2549
- Tasks 공식 확장 전환
- SEP-2663
- 신규 로드맵 우선순위 수
- 5개 영역(기존 4개에서 확대)
服务器不再需要一直占用连接了
MCP(Model Context Protocol)核心维护者们公布了更新后的路线图。MCP是连接AI与外部工具或数据的通用标准,常被称为"AI界的USB-C"。这次路线图中最引人注目的变化是:服务器不必再持续保持与客户端的连接状态。通过SEP-2575和SEP-2567,协议层面的会话与初始化握手被去除,这意味着服务器即便不持有状态,也能实现水平扩展。
从3月路线图到现在,进展到了哪一步
去年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标准的落地,并以关于工作负载身份联合的讨论为基础,定义智能体身份与权限委派路径。团队还表示将继续深化与IETF OAuth及WIMSE工作组的合作。
如何提交SEP提案
落在这五项优先事项范围内的SEP提案,审核速度会更快,被采纳的可能性也更高。范围之外的提案并不会被自动拒绝,但由于维护者的审核时间有限,优先事项领域内的提案会被优先安排。如果你正在筹备一份SEP提案,建议先确认它属于哪个优先事项领域,再提交给对应的工作组共同打磨。路线图页面已列出各领域负责的核心维护者姓名,想参与讨论的人可以通过Discord联系他们。
编辑视角
回想MCP在3月路线图里提出的"传输可扩展性"这个相当模糊的目标,这次直接取消会话与握手机制的做法可以说相当果断。此前,保持状态的服务器很难在负载均衡器后部署多台实例,而且一旦连接中断,正在进行的任务上下文也会随之丢失。如今在协议层面彻底移除这个问题,让MCP服务器能像普通HTTP工作负载一样被处理,这对运营MCP服务器的公司来说,是一次同时降低基础设施成本与复杂度的选择。
今年8月初,OpenAI联合AWS、Cursor、GitHub推出的Agent Plugins标准,也支持对MCP服务器配置进行打包。从这个角度看,MCP持续朝无状态、轻量化方向打磨规范,其实是在为那些标准打下更坚实的基础。我们已经多次见证过:一旦某个协议趋于稳定,建立在其之上的工具和标准数量就会随之增加。
对于国内正在自行运营MCP服务器或接入SDK的团队来说,眼下有两件事值得立刻着手。一是检查07-28版本中会去除会话和server/discover变更对现有服务器代码的影响；二是提前关注智能体身份认证方面的进展。目前直接粘贴API密钥的做法很可能很快会被基于DPoP或令牌交换的认证体系取代,而更换认证体系这件事,永远是拖得越晚、迁移成本越高。
预计未来几个月内,由服务器主动推送事件的Webhook、频道方式,以及针对工具繁多的服务器所设计的渐进式发现机制,都会先以规范草案的形式面世。这两项工作都是针对当下"请求-响应"模式难以应付的长时间智能体循环而设计的,如果你的团队已经在生产环境中使用MCP,不妨多留意这方面的SEP讨论进展。
评论