MCP新路线图

# 新版MCP路线图 来源：https://blog.modelcontextprotocol.io/posts/mcp-roadmap/ 今天我们很高兴发布更新后的模型上下文协议（MCP）路线图（https://modelcontextprotocol.io/development/roadmap），涵盖下一次规范发布及后续规划。 该路线图确立了未来几个月协议工作的方向。它由核心维护者与社区维护者及工作组共同制定。 探索路线图→ (https://modelcontextprotocol.io/development/roadmap) ## 重点领域 路线图划分为五个重点领域。其中几项延续了上一版路线图（https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/）提出的前瞻事项，包括服务器发起事件、结果类型优化和代理身份认证——这些议题已发展成熟，现已升级为独立重点方向。每个领域由一组核心维护者和一个或多个工作组负责推进。 MCP路线图五大重点领域：代理通信原语、HTTP原生传输层统一与加固、代理身份与企业级安全、增强型原语、SDK开发者体验优化。 ### 代理通信原语 现代智能体工作负载已突破标准的请求-响应模式（https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns）。运行周期可能持续更久，服务器支持流式结果推送，且需要在任务执行过程中进行动态调控。MCP持续演进以满足这些需求，已引入任务系统（https://modelcontextprotocol.io/extensions/tasks/overview）、`订阅/监听`（https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions）和进度通知（https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/progress）机制。我们不仅要确保提供适配的原语组件，更要实现各组件间的协同运作。此项工作涵盖服务器发起事件（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）的成熟化以纳入规范体系。 ### HTTP原生传输层统一与加固 随着2026-07-28版本（https://modelcontextprotocol.io/specification/2026-07-28/changelog）的发布，远程MCP服务器已与其他HTTP服务无异，开发者可在任何现有API基础设施上轻松部署运营。该模型已验证具备良好扩展性，我们将进一步拓展其应用场景，支持包括基于stdio（https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/stdio）通信的本地服务器使用流式HTTP（https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http）等部署模式。统一传输协议将简化MCP服务器与客户端的开发流程。 ### 代理身份与企业级安全 当前MCP授权机制（https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization）基于用户在浏览器中的授权操作。这对交互式客户端运行良好，但越来越多的调用方已成为具有独立身份的云工作负载代理，可能代表缺席用户执行操作，或向下级代理委托受限权限。我们希望建立标准化方式，使MCP服务器能够基于现有标准（而非粘贴式API密钥和长期令牌）识别并信任这些代理身份。 此项工作包括：完善持有证明机制（DPoP）（https://www.rfc-editor.org/rfc/rfc9449）并推动其应用；通过工作负载身份联合（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1933）、企业托管授权（https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization）背后的身份授权联合框架（ID-JAG）以及标准令牌交换，定义代理身份与委托的规范路径。我们还将继续参与OAuth标准化组织（包括IETF OAuth与WIMSE工作组（https://datatracker.ietf.org/wg/wimse/about/）），协助构建代理身份所需的基础标准演进。 ### 增强型原语 工具调用是多数开发者接触MCP的首个环节，在协议生命周期中表现稳健。但结果处理机制仍存在优化空间：`工具调用`（https://modelcontextprotocol.io/specification/2026-07-28/server/tools#tool-result）响应可能以多种形式返回相同输出，当前服务器开发者无法预知特定客户端会向模型呈现何种形式。我们旨在通过标准化清晰契约来简化这一流程。 原语使用的另一挑战在于其规模持续增长：连接至拥有百个工具的服务器意味着用户尚未提问时模型已需处理全量接口，且工具列表膨胀会导致选择准确率下降。我们正启动渐进式发现机制开发，使服务器能提供入口点，并在对话收敛过程中逐步展示更多功能目录。 ### SDK开发者体验优化 SDK是开发者体验MCP的核心载体。我们正投入资源优化其人性化设计与规范符合性（https://modelcontextprotocol.io/community/sdk-tiers#conformance-testing），确保在所有支持平台与语言中提供直观易用的接口与完善文档。随着越来越多开发者通过智能体调用我们的库来构建MCP客户端/服务器，清晰的API设计与准确文档将直接决定代码运行的顺畅程度。 ## 提案优先级 属于这些重点领域内的规范增强提案（SEP）（https://modelcontextprotocol.io/community/sep-guidelines）将获得加速评审，接受概率最高。非相关提案不会自动驳回，但维护者评审资源有限，将优先处理路线图相关事项。 若您正考虑提交SEP，请确认其所属重点领域，通过对应工作组（https://modelcontextprotocol.io/community/working-interest-groups）发起讨论，并与工作组成员共同完善提案。路线图（https://modelcontextprotocol.io/development/roadmap）中每个领域都标注了负责的核心维护者，有意贡献者可通过Discord（https://modelcontextprotocol.io/community/communication#discord）联系他们。我们期待与社区协作评审并推进支持本路线图的提案。 ## 参与方式 上述每个重点领域背后都有已成立或正在组建的工作组，均欢迎更多贡献者加入。参与途径包括： - **加入工作组或兴趣组**：查阅工作组与兴趣组页面（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/contributing）涵盖规范、SDK及相关工具链 我们期待与社区共同推动MCP的成长与演进！