MCP 公布新路线图：Agent 工具链协议开始走向更轻、更标准的基础设施

Model Context Protocol（MCP）团队近日发布了更新后的协议路线图。相比今年 3 月上一版路线图聚焦的四个方向，这次更新不仅总结了过去五个月已经落地的变化，也进一步明确了未来几个月的重点：让 MCP 更适合 Agent 工作负载、更容易被开发者和企业集成，并逐步从工具连接协议走向更标准化的基础设施层。

对于正在构建 AI Agent、工具服务器或相关 SDK 的团队来说，这份路线图释放出的信号比较明确：MCP 正在减少不必要的状态和协议负担，强化安全授权能力，并试图解决工具数量增长后带来的发现、调用和结果处理问题。

上一阶段重点已部分落地：无状态服务器、Tasks 扩展与授权增强

MCP 团队表示，3 月发布的路线图提出了四个优先方向：传输演进与可扩展性、Agent 通信、治理成熟化以及企业就绪能力。过去五个月里，这些方向都取得了较明显进展，其中大部分变化已经体现在 2026-07-28 规范版本、SDK 和文档中。

在传输和扩展性方面，一个关键变化是移除了协议层面的会话和初始化握手。根据 SEP-2575 和 SEP-2567，MCP 服务器可以在不保存状态的情况下横向扩展。客户端也可以先调用 server/discover 获取服务器支持的版本和能力，再决定后续交互；列表结果还可缓存，相关设计见 SEP-2549。

这些调整意味着，远程 MCP 服务器可以更接近常规 HTTP 服务来部署，而不必为维持协议状态承担额外复杂性。对云托管、负载均衡和弹性扩容场景而言，这是一个更工程友好的方向。

在 Agent 通信方面，Tasks 根据早期采用者反馈被重构，并以官方扩展形式存在，编号为 SEP-2663。此前由服务器发起请求的模式，则由新的 Multi Round-Trip Requests 模式替代，对应 SEP-2322。这样，elicitation 等交互流程也可以运行在无状态服务器上。

Server Card 工作组仍在推进 .well-known 元数据规范，目标是让 MCP 服务器在未建立连接前就能被发现和理解。这一方向如果成熟，可能降低客户端接入服务器时的试错成本，也更利于服务目录、注册中心和自动化发现机制的形成。

治理方面，MCP 引入了 Contributor Ladder，由工作组负责各自领域的 SEP 分类处理，并为规范建立了功能生命周期和弃用策略。2026-07-28 版本中的弃用项就是首批遵循该流程的变更。

企业就绪能力则主要集中在安全授权。新版本引入了 issuer validation、issuer-bound client credentials，并将 Client ID Metadata Documents（CIMD）作为客户端注册的推荐路径。Enterprise-Managed Authorization 作为扩展能力提供，目前也已进入稳定状态。

新路线图聚焦五大方向：事件、传输统一、Agent 身份、工具调用与 SDK

新版路线图在既有基础上提出五个优先领域。其中一些内容此前只是远期规划，如今已被提升为独立重点，包括服务器发起事件、结果类型改进和 Agent 身份。每个方向都有核心维护者负责，并由一个或多个工作组推进。

第一，是面向现代 Agent 工作负载的通信机制。MCP 团队认为，当前 Agent 任务已经不再适合简单的请求与响应模式。循环可能运行更长时间，服务器可以推送流式结果，开发者也需要在任务执行过程中进行干预。MCP 已经引入 Tasks、subscriptions/listen 和进度通知等能力，接下来要确保这些机制能够协同工作。

这部分工作包括服务器发起事件，例如 webhooks 和 channels，让客户端不必持续轮询结果；也包括跨 Agents、Transports 和 Triggers & Events 工作组的组合审查；同时推动 Tasks 扩展成熟，使其未来可以进入规范主体。

第二，是继续强化传输统一性。2026-07-28 版本之后，远程 MCP 服务器已经可以像普通 HTTP 工作负载一样托管和运维。MCP 团队希望把这种模式扩展到更多部署形态，包括通过 stdio 使用 Streamable HTTP 的本地服务器。统一传输方式有望进一步降低服务器和客户端开发复杂度。

第三，是 Agent 身份与授权。当前 MCP 授权主要围绕用户在浏览器中确认访问展开，这对交互式客户端比较有效，但越来越多调用方是运行在云端工作负载中的 Agent。它们可能代表不在场用户行动，也可能把更窄权限委托给子 Agent。

MCP 希望为服务器提供标准化方式来识别和信任这些 Agent 身份，而不是依赖临时 API key 或长期 token。相关工作包括推进 Demonstrating Proof of Possession（DPoP）的落地，定义基于 Workload Identity Federation、Enterprise-Managed Authorization 背后的 ID-JAG grant 以及标准 token exchange 的 Agent 身份和委托路径。MCP 团队还将继续与 IETF OAuth 和 WIMSE 等标准组织沟通，推动底层标准适应 Agent 身份需求。

第四，是改进工具调用和结果处理。工具调用是大多数开发者最先接触 MCP 的部分，目前整体表现稳定，但结果处理仍有不足。一次 tools/call 响应可能以多种形式携带相同输出，服务器开发者难以知道客户端最终会把哪种形式提供给模型。MCP 计划通过更清晰的契约来统一这一问题。

另一个问题是工具规模扩大后的效率下降。如果客户端连接到一个拥有一百个工具的服务器，模型可能在用户尚未提问前就需要处理整个工具列表，而工具选择质量也可能随着列表变长而下降。MCP 正在启动渐进式发现机制，让服务器先提供较小入口，再根据对话范围逐步展示更多工具。

第五，是 SDK 体验。MCP 团队表示，SDK 是开发者接触协议的主要方式。后续将投入改善 SDK 的易用性和与规范的一致性。原文在此处未展开更多细节，但从路线图整体来看，SDK 的规范对齐、开发体验和工程稳定性仍将是生态建设的重要一环。

对开发者意味着什么：从“能连接工具”走向“可规模化集成”

从这份路线图看，MCP 正在从早期解决“模型如何连接外部工具”的阶段，进入更关注规模化运行和标准化集成的阶段。

• 对服务器开发者而言，无状态化和 HTTP 化降低了托管门槛，未来远程 MCP 服务可以更自然地接入现有 API 基础设施。
• 对 Agent 开发者而言，服务器事件、Tasks 和进度通知的进一步整合，可能改善长任务的执行体验，减少轮询和状态管理负担。
• 对企业用户而言，授权、身份和委托机制的标准化，是 MCP 从实验性集成走向生产环境的重要前提。
• 对工具和插件提供方而言，渐进式发现机制如果落地，将有助于缓解大规模工具列表带来的上下文压力和选择精度问题。

不过，这份路线图也说明，MCP 生态仍有不少部分处在演进过程中。Tasks 仍是扩展，服务器发现机制还在推进，Agent 身份和授权需要与外部标准继续协同，工具结果契约也尚未完全定型。对于准备接入 MCP 的开发者来说，关注规范版本、SDK 变化和相关 SEP 提案，仍是必要工作。

MCP 此次更新路线图，不只是对协议功能的补充，更是在为 Agent 工具链建立更稳定的工程基础。如果这些方向顺利推进，MCP 可能会从一种连接方式，逐渐成为 AI Agent 接入外部能力时的通用接口层。