最要紧的一条：请求-响应装不下现在的活
路线图开篇的判断是「现代 Agent 工作负载已经不适配标准的请求-响应模式」。跑几十分钟的长任务、边跑边出结果、中途插话改方向，这些在一问一答的框架里只能靠客户端不停轮询硬凑。现有的 Tasks 扩展（SEP-2663）、订阅与进度通知算是打了补丁，接下来要补的是服务端主动发起的事件——Webhook 和频道，让服务端有结果时直接推过去。Tasks 扩展也计划从实验状态并入规范正文。
传输统一，身份换轨
传输这条是 7 月 28 日那版规范的延续。协议层的会话在那一版被去掉之后，远程 MCP 服务器可以按普通 HTTP 服务的方式部署和横向扩容；这次的目标是把本地服务器也收进同一套传输（stdio 之上跑 Streamable HTTP），让远程和本地不再是两套心智模型。 身份这条改的是更根本的假设。今天的授权流程默认背后站着一个人，用浏览器点「同意」；而跑在云上的 Agent 是工作负载，它需要的是一个能被识别的身份，而不是一把长期有效的 API key。路线图点名的机制是 DPoP（RFC 9449，把令牌绑定到持有者的密钥上）、工作负载身份联邦，以及企业托管授权扩展里已经稳定下来的 ID-JAG 授权，并说明维护者正在 IETF 的 OAuth 与 WIMSE 工作组里推动相关标准。对企业侧，这决定了 Agent 调用内部系统时能不能审计到「是哪个负载在动手」。
工具太多，是要花钱的
第四条里有一句很实在的描述：连上一个有一百个工具的服务器，意味着「用户还没问第一个问题，模型就已经为整个工具面付过费了」。解法是渐进式发现——服务端随着对话收窄逐步露出目录，而不是开场全量灌进上下文；同时统一工具结果的契约，不再让每个实现自己发明返回形态。 对正在写 MCP 服务器的人，这版路线图的实际用法是当作提案筛选器：想推进的改动如果落在这五个方向里，走 SEP 更容易被接受；不在里面的想法不是不能提，只是得自己排队。没有时间表这一点也别忽略——路线图给的是优先级，不是发布日期。