企业官网建设流程全解析

重点领域

路线图分为五个重点领域，其中部分领域承接了 上一版路线图 规划的工作，如今已发展成熟成为独立重点。每个领域都有一组核心维护者负责，并有一个或多个工作组参与。

自主消息原语

现代自主工作负载已不适用于标准的 [请求 - 响应模式]。其循环运行时间可能更长，服务器能推送流式结果，且运行中对工作进行引导的需求明确。MCP 不断发展以满足这些需求，引入了 [任务]、[`subscriptions/listen`] 和 [进度通知]。我们既要确保提供合适的原语，也要保证它们协同工作。这项工作包括服务器发起的事件（Webhook 和通道，避免客户端轮询结果）、跨 [代理]、传输和 [触发器与事件] 工作组的组合审查，以及完善任务扩展（[SEP - 2663]）使其纳入规范。

原生 HTTP 传输统一与强化

随着 [2026 - 07 - 28 版本] 发布，远程 MCP 服务器与其他 HTTP 工作负载无差异，开发者和组织可在现有 API 和服务基础设施上轻松托管和运行 MCP 服务器。实践证明该方法扩展性良好，我们希望将其应用到更多部署模式中，包括通过 [标准输入输出] 使用 [可流式 HTTP] 的本地服务器。统一传输方式可进一步简化 MCP 服务器和客户端的开发。

代理身份与企业级安全

目前，[MCP 授权] 基于用户在浏览器中批准访问实现。这种方式对交互式客户端效果良好，但越来越多调用者是作为云工作负载运行的代理，它们有自己的身份，代表不在场用户行事，或将更窄权限委托给子代理。我们希望 MCP 服务器有标准化方式识别和信任这些代理身份，基于现有标准，而非粘贴 API 密钥和长期令牌。这项工作包括完成 [证明所有权]（DPoP）并推动其应用，通过 [工作负载身份联合]、[企业管理授权] 背后的 ID - JAG 授权以及标准令牌交换，定义代理身份和委托的明确路径。我们还将继续加强与 OAuth 标准组织的合作，包括 IETF OAuth 和 [WIMSE] 工作组，以助底层标准随代理身份所需构建块不断发展。

改进原语

工具调用是多数开发者最先接触的 MCP 部分，在协议生命周期中表现良好，但结果处理存在不足。一个 [`tools/call`] 响应可携带多种形式的相同输出，服务器开发者目前无法确定特定客户端会将哪种形式呈现给模型。我们目标是通过标准化清晰契约简化这一过程。原语面临的另一挑战是规模不断增长。连接到拥有一百个工具的服务器，意味着模型在用户提出第一个问题前就要处理整个工具集，且随着工具列表增加，工具选择往往更困难。我们正在开展渐进式发现工作，使服务器能提供小的入口点，并在对话逐渐聚焦时展示更多工具目录。

提升 SDK 开发者体验

我们的 SDK 是开发者体验 MCP 的途径。我们正投入精力提升其易用性，确保其 [符合规范]，并使其在我们支持的每个平台和语言上都直观且文档完善。现在，许多开发者通过将代理指向我们的库来构建 MCP 客户端和服务器，清晰的 API 和准确的文档对代码顺利运行至关重要。

提案优先级排序

属于这些重点领域的 [规范增强提案]（SEP）将获快速评审，并有更大机会被接受。不属于这些领域的提案不会自动被拒绝，但维护者评审时间有限，会优先处理重点领域的提案。

如果你正在考虑提交一个 SEP，请确定它所属的重点领域，向相关的 [工作组] 提出，并与成员共同完善你的提案。[路线图] 上的每个领域都列出了负责的核心维护者，任何有兴趣贡献的人都可在 [Discord] 上联系他们。我们期待与社区共同评审和完善支持此路线图的提案。

参与方式

上述每个重点领域背后都有一个工作组，或正在围绕其组建工作组，且都欢迎更多贡献者加入。你可以通过以下几种方式参与：

• 加入工作组或兴趣小组：查看 [工作组和兴趣小组] 页面和 [社区渠道]。
• 提出或评论 SEP：阅读 [SEP 指南]，然后提交提案或发表意见。
• 启动实验性扩展：[SEP - 2133] 允许任何工作组或兴趣小组在正式提交 SEP 之前，在 `experimental-ext-` 仓库中进行实验。
• 直接贡献：[贡献指南] 涵盖了规范、SDK 和工具的相关内容。

我们期待与大家共同推动 MCP 的发展和演进！

• [MCP]
• [路线图]
• [社区]
• [治理]
• [工作组]

[文档] · [文章] · [存档] · [搜索] · [标签] · [GitHub] · [领英] · [RSS]