MCP的下一步是什么？团队分享了未来6-12个月的公共路线图：

• 支持流式传输、服务端推送和动态调控的长时运行工作负载
• 使用HTTP作为本地服务器通过标准输入输出的通信协议（意味着更高度的统一）
• 针对大型目录的渐进式发现机制（类似于我们现有的技能发现功能）
• 为智能体提供标准化身份验证和委托权限
• 生成SDK并依据规范进行校验

期待看到协议持续演进！路线图详情：https://modelcontextprotocol.io/development/roadmap

路线图 - 模型上下文协议

来源：https://modelcontextprotocol.io/development/roadmap 本页面概述了核心维护者在未来六至十二个月对协议发展的愿景，重点标出下次规范更新及后续版本的目标规划。我们将阐述主要战略目标，以及工作组（https://modelcontextprotocol.io/community/working-interest-groups）与兴趣小组的预期成果。

SEP优先级管理

**属于以下优先领域的规范增强提案（SEPs）将获得优先审阅，并有较高通过概率。**不属于这些领域的提案不会自动被拒，但需经历更长排队时间及更严格的论证要求。维护者审阅时间有限，我们将优先处理此类提案。若您考虑撰写SEP，请首先确定其所属优先领域并向相关工作组提出，再由该组提供提案支持。获得工作组背书且与本路线图路径清晰的SEP将获得最快推进。完整流程请参阅SEP指南（https://modelcontextprotocol.io/community/sep-guidelines）。每个优先领域均标注了负责的核心维护者，任何有意贡献者均可通过Discord（https://modelcontextprotocol.io/community/communication#discord）联系。各领域下列出的条目为本路线图周期的优先交付成果。其余范围由各工作组自主界定并推进。

优先领域

1. 智能体消息基础架构

核心维护者：Caitie McCaffrey（https://github.com/CaitieM20）、Clare Liguori（https://github.com/clareliguori）、Peter Alexander（https://github.com/pja-ant） 智能体工作负载需要超越简单请求-响应的消息模式（https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns）：包括运行数分钟的持续任务、服务端主动推送、结果流式传输以及任务进行时的动态调控机制。MCP已为此发展出一系列概念，如任务（Tasks）（https://modelcontextprotocol.io/extensions/tasks/overview）、订阅/监听（subscriptions/listen）（https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions）和进度通知（progress notifications）（https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/progress），但这些概念分散在多个工作组中。存在“服务未就绪”三种不同响应方式的风险，它们缺乏统一的生命周期、取消模型或错误处理机制。我们期望实现组件化协作。本路线图周期内：

• 服务端主动事件：触发与事件工作组（https://modelcontextprotocol.io/community/working-groups/triggers-events）。用于推送交付的频道与订阅机制（包括webhook）。随着我们通过任务处理及其他事件开展异步工作负载，需要扩展机制让服务端通知客户端任务完成，而非完全依赖代价高昂的客户端轮询。
• 组件化审查：智能体（https://modelcontextprotocol.io/community/working-groups/agents）、传输与触发/事件工作组（https://modelcontextprotocol.io/community/working-groups/triggers-events）。正在开发中的原语（如任务与触发器）需要相互协调组合，并适应具体应用场景。

除此之外，我们将持续推进任务扩展（SEP-2663（https://modelcontextprotocol.io/seps/2663-tasks-extension））的开发，最终目标是将其纳入核心协议。

2. HTTP原生传输统一与强化

核心维护者：Kurtis Van Gent（https://github.com/kurtisvg）、Nick Cooper（https://github.com/nickcoai） 2026-07-28版本（https://modelcontextprotocol.io/specification/2026-07-28/changelog）使远程MCP服务器成为标准HTTP工作负载，我们越来越依赖HTTP头部信息和状态码承载传输层数据。每个HTTP原生特性都需要为标准输入输出设计专门适配方案，否则无法在本地工作。SDK需要维护两套传输管道，协议元数据现在同时存在于HTTP头部和需要交叉验证的消息字段中。我们希望统一为单一传输模型，并在其上采用标准HTTP实践。本路线图周期内：

• HTTP over 标准输入输出：传输工作组。将可流式HTTP作为统一绑定协议，通过标准输入输出/标准输出供本地服务器使用。我们相信可通过标准输入输出实现HTTP/2多路复用传输，同时保持子进程的安全性与生命周期保证。
• 缓存机制：传输工作组。最新协议版本在缓存方面取得进展，为列表结果和资源读取添加了ttlMs和cacheScope（SEP-2549（https://modelcontextprotocol.io/seps/2549-TTL-for-list-results））。作为此项工作的延伸，我们计划扩展缓存方案以支持ETag机制，从而实现对原语（特别是工具调用）结果进行版本控制。

除此之外，我们将致力于制定跨所有接口的标准化错误处理方案，完善SEP-2575（https://modelcontextprotocol.io/seps/2575-stateless-mcp）之后的工具列表能力范围控制，以及为服务器提供安全的配置选项。

3. 智能体身份认证与企业级安全

核心维护者：Paul Carleton（https://github.com/pcarleton）、Den Delimarsky（https://github.com/localden） MCP授权机制假设用户在授权时刻拥有浏览器交互环境。但调用方越来越多地变为智能体：具有独立身份的云端工作负载，代表不在场的用户行动，或生成应获得比父级更受限权限的子智能体。现有MCP服务器依赖粘贴式API密钥和长期刷新令牌。我们需要标准化方式让MCP服务器处理智能体身份认证，并将持续通过采用现有标准来增强安全性。本路线图周期内：

• DPoP证明：智能体身份工作组（本路线图周期内组建）。完成持有证明（DPoP）规范制定，重点推动广泛采用。
• 智能体身份与委托：智能体身份工作组。我们希望为MCP服务器提供标准化方式，使其能通过智能体自身身份或用户委托身份接收访问请求。工作重点将围绕工作负载联合身份（SEP-1933（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1933））、企业托管授权（https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization）使用的身份断言JWT授权许可（ID-JAG），以及RFC 8693（https://www.rfc-editor.org/rfc/rfc8693）令牌交换机制，并与IETF OAuth及WIMSE（https://datatracker.ietf.org/wg/wimse/about/）工作组协同。

除此之外，随着工作组的形成，更多议题将被讨论，包括区分交互式客户端与无头智能体的人类存在性证明等智能体身份相关问题。

4. 原语功能增强

核心维护者：Kurtis Van Gent（https://github.com/kurtisvg）、Peter Alexander（https://github.com/pja-ant）、Den Delimarsky（https://github.com/localden） MCP的工具调用接口表现良好。但tools/call允许同时返回content和structuredContent，这给服务器和客户端开发者带来困惑，导致实现分歧。我们计划在本路线图周期改进tools/call接口形态，实现更一致的语义。同时社区反复反馈服务器需要更多选项来引导客户端浏览大量工具、资源及其他原语，因此我们正启动渐进式发现专项研究，定义实验性服务端发现机制。本路线图周期内：

• 工具结果形态：核心原语工作组（本路线图周期内组建）。重新设计tools/call接口，解决返回类型的保真度差异，简化结构化与非结构化输出的处理流程。
• 渐进式发现：核心原语工作组。客户端按需学习服务器工具和资源，而非预先加载完整目录，并与HTTP原生传输统一与强化（https://modelcontextprotocol.io/development/roadmap#2-http-native-transport-unification-and-hardening）中的缓存方案明确交互规范。
• 原语注释：核心原语工作组。规范中的内容注释（https://modelcontextprotocol.io/specification/2026-07-28/server/resources#annotations）声明了内容的目标受众与优先级。将其应用于工具结果和资源可能解决SEP-2200（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2200）描述的可见性混淆问题，但多数实现者尚未采用这些注释，也可能不了解其用途。若确实无实用价值，我们应考虑将其废弃。

此外，文件上传工作组（https://modelcontextprotocol.io/community/working-groups/file-uploads）将继续推进作用域文件操作与类文件系统资源语义（范围读取、层级化列表）。

5. SDK开发者体验优化

核心维护者：Den Delimarsky（https://github.com/localden）、David Soria Parra（https://github.com/dsp-ant） 我们的SDK、参考服务器和快速入门指南目前均依赖人工维护。虽然这种方式可行，但我们认为规范结合人工审核的合规测试套件可以成为事实来源，使更多制品能从中自动派生，从而让SDK和示例在每次发布时重新生成验证，而非发布后修补。本路线图周期内：

• 扩展契约规范：SDK工作组（https://modelcontextprotocol.io/community/working-groups/sdk）与核心维护者共同推进。明确扩展绑定角色（宿主、客户端、服务器、智能体）及声明能力时的执行逻辑；SDK必须原生支持的内容；扩展打包方式；能力增强作为扩展的版本化变更；以及授权作为独立领域处理。
• 制品生成实验：SDK工作组（https://modelcontextprotocol.io/community/working-groups/sdk）。从规范生成候选的一级SDK（https://modelcontextprotocol.io/community/sdk-tiers）及其配套快速入门示例，使用合规测试套件（https://modelcontextprotocol.io/community/sdk-tiers#conformance-testing）验证两者，并发布包含下轮改进建议的研究报告（明确哪些层应使用确定性代码生成，哪些需模型辅助）。

除此之外，我们将重新评估参考服务器和快速入门仓库的所有权与维护时效要求，并将生成过程中暴露的规范清晰度问题视为文档缺陷处理。

参与方式

上述每个优先领域都有工作组支撑或正在组建，所有工作组均欢迎更多贡献者参与。可通过以下方式加入：

• 加入工作组或兴趣小组：参阅工作组与兴趣小组（https://modelcontextprotocol.io/community/working-interest-groups）页面及社区频道（https://modelcontextprotocol.io/community/communication）。
• 提案或评论SEP：阅读SEP指南（https://modelcontextprotocol.io/community/sep-guidelines），然后提交提案或发表见解。
• 启动实验性扩展：SEP-2133（https://modelcontextprotocol.io/seps/2133-extensions）允许任何工作组/兴趣小组在experimental-ext-仓库中开展实验，无需正式SEP提案。
• 直接贡献：贡献指南（https://modelcontextprotocol.io/community/contributiong）涵盖规范、SDK及相关工具链。