MCP这次更新路线图,没有堆新功能,反而先把话说明白:接下来要解决的,不是"能不能调用工具",而是"谁在调用工具,调用了多久,谁批准的"。这句话听起来像行政审批,但恰恰是MCP从一份协议规范走向生产基础设施必须迈过的坎。8月22日发布的新版路线图,把未来几个月的协议工作收拢到五个方向,其中异步任务、传输统一、代理身份三项,决定了这套协议能不能撑住真正的规模化部署。
速读:五个方向,谁会被牵动
- 代理式消息.把Tasks、subscriptions/listen、进度通知整合起来,加上服务端主动推送事件,减少客户端死等轮询,允许执行过程中插手干预。这块还在打磨,Tasks扩展(SEP-2663)要先成熟才能进正式规范。
- 传输层统一.计划让本地服务器也说Streamable HTTP,不再是stdio和HTTP两条线并存。官方说法是"现有远程HTTP模型已经证明可以扩展",本地统一目前还是方向,不是已经完工的规范。
- 代理身份与企业安全.授权体系要从"人在浏览器里点同意"转向"云端工作负载有自己的身份"。重点是DPoP落地和采用,以及基于Workload Identity Federation、ID-JAG授权、标准令牌交换的委托路径。
- 基础原语改进.tools/call的结果格式要收敛成统一契约,同时启动渐进式发现,让工具目录先露一个小入口,随对话收窄再展开——解决的是上百个工具挤爆模型上下文、拖累选择质量的问题。
- SDK体验.持续打磨各语言SDK的规范一致性和文档质量,原因很直接——越来越多开发者是指着SDK文档让agent自己写代码,文档不准,代码就跑不起来。
路线图内的SEP提案会被优先审查,路线图外的不算被拒,但维护者时间有限,注意力先给路线图上的方向——这本身也是一次公开的资源分配。
分水岭:异步、身份、规模化,哪个先卡壳
单看工具调用这一层,MCP已经跑得挺稳,这也是路线图里唯一被明确肯定的部分。真正悬而未决的,是异步执行、代理身份和工具规模化这三件事。
异步执行决定MCP能不能承载"长任务"。今天大多数客户端还在轮询等结果,一旦任务跑几分钟甚至几小时,轮询就成了笨办法。服务端主动推事件、支持执行中插手,才是Agent真正要的交互模式,而不是一问一答。
代理身份决定MCP能不能进企业。现在的授权逻辑天然假设有真人在场点同意,可现实是越来越多调用者是没人盯着的云端工作负载,或者代理把权限层层转发给子代理。没有标准化的身份和委托机制,大家会怎么做?贴一个长期有效的API Key了事——这恰恰是路线图想避免的默认答案。
授权还没定身份,代理已经在裸奔。
- 风险.路线图列的是优先级和方向,不是交付时间表。DPoP的采用、Tasks扩展转正、渐进式发现的具体接口,目前都还没有确定的落地时间。
工具规模化决定MCP好不好用。一个服务器挂上百个工具,模型在用户开口之前就要先"读"完整个目录,上下文成本先垫进去,选择质量还跟着下滑。渐进式发现如果做成了,才算把"工具越多越强"这个粗暴假设纠正过来。
这三件事没有一件是新问题,但这次路线图第一次把它们摆到和工具调用同等的优先级上,说明维护者也清楚:协议好不好用,已经不再是唯一的考题。传输层统一降低了部署门槛,这是实打实的好消息,尤其对已经把服务器接进现有API基础设施的团队来说。但身份、异步、规模化这三件事哪个先落地、哪个先卡壳,才是MCP从"聊天工具的插件层"走向"企业级代理平台"的真正分水岭。
眼下能看到的只是方向。正在评估MCP身份、安全或生产部署方案的技术负责人,现在还不该把这些当成现成能力去设计架构——路线图定的是优先级,不是交付清单。