企业官网建设流程全解析

• 人工智能
• AI Agent
• 工具调用

2026 年 3 月，Model Context Protocol（MCP）核心维护团队发布了新版年度路线图，宣告协议开发模式从"按版本号排期"转向"按工作组驱动"，并明确了 2026 年的四大优先领域：传输演进与可扩展性、Agent 通信、治理成熟化与企业就绪。本文以该路线图公告为主体，结合仓库内的完整路线图文档、SEP 流程、工作组治理规则与 2026-07-28 版本变更记录，为你梳理优先领域背后的动机、SEP 评审的真实规则，以及贡献者如何借力路线图让自己的提案更快落地。

从"按版本发布"到"按工作组驱动"：路线图框架的转变

MCP 的上一份正式规范发布于 2025 年 11 月（对应仓库中的 2025-11-25 规范版本），此后项目并未冻结：协议早已超越"把本地工具接起来"的起点，正在大中小型企业中支撑生产环境与 Agent 工作流，并通过 Working Groups、Spec Enhancement Proposals（SEP） 与正式治理流程持续演进。

此前版本的路线图围绕发布里程碑组织——"下一个规范版本会带来什么、之后是什么"。在项目规模尚小、大部分工作由少数几个人推动时，这种框架是合理的。但如今 Working and Interest Groups 已成为协议开发的主要载体，路线图因此做了两项关键调整：

• 按"优先领域（Priority Areas）"组织，而非按日期组织：具体交付时间线由各工作组自行驱动，路线图只回答"哪些问题最重要、由哪个组在推进"。
• 更诚实地面对不确定性：发布导向的路线图隐含了一种开源标准工作很少具备的可预测性；领域导向的框架承认优先级可能漂移、交付方式可能变化。

这一点在 docs/development/roadmap.mdx 中有明确声明："本路线图反映的是当前思考而非坚定承诺。优先级可能变化，部分条目可能以不同方式交付或推迟，未列出的工作也可能进入发布。" 该文档当前版本标注的更新日期为2026-08-22，比这篇博客（2026-03-09）晚五个多月，正好可以用来对照路线图的演进轨迹——后文会专门做一次核对。

四大优先领域详解

核心维护团队对候选方向进行了排序，最终得出清晰的四大优先领域。这些领域内的 SEP 将获得加速评审，大部分维护者精力也集中于此。

1. 传输演进与可扩展性（Transport Evolution and Scalability）

Streamable HTTP 让 MCP 服务器可以作为远程服务而非本地进程运行，解锁了一大批生产部署。但规模化运行暴露出三类一致性问题：

• 有状态会话与负载均衡冲突：会话状态被绑定在单一实例上，横向扩展需要绕开负载均衡器做粘性路由；
• 水平扩展依赖变通方案：缺少原生的无状态扩展机制；
• 发现机制缺失：注册表或爬虫无法在不建立连接的前提下获知服务器能力。

对应的工作拆成两部分：

1. 演进传输与会话模型，让服务器无需持有状态即可水平扩展，并为会话管理提供清晰、显式的机制；
2. 标准化的元数据格式，通过.well-known路径对外服务，使服务器能力在无实时连接的情况下即可被发现。

路线图公告特别强调：本周期不会增加新的官方传输，而是演进现有传输。保持传输集合的"小而精"是一个刻意决策，其依据是 MCP 设计原则 中的 "Convergence over choice（收敛优于选择）"——"一个问题在 MCP 中应当只有一种解决方式"。

在后续的 docs/development/roadmap.mdx 中，这一领域被细化为"HTTP-Native Transport Unification and Hardening"（HTTP 原生传输统一与加固），由 Kurtis Van Gent 与 Nick Cooper 负责，列出了两项重点交付：

• HTTP over stdio：把 Streamable HTTP 作为唯一绑定，通过 stdin/stdout 承载本地服务器通信，目标是借助 HTTP/2 over stdio 获得多路复用传输能力，同时保留子进程的安全与生命周期保障；
• 缓存（Caching）：在 SEP-2549（列表结果的 TTL） 引入的ttlMs与cacheScope基础上，将缓存方案扩展到 ETag，从而支持对原始类型（尤其是工具调用）结果做版本化。

这一领域的成果已经在 2026-07-28 版本变更记录 中部分落地：协议级会话与Mcp-Session-Id头被移除（SEP-2567），initialize握手被废除、协议全面无状态化并新增server/discover（SEP-2575）。可以说，路线图在 3 月的方向性判断，在 7 月的规范中已经兑现了一大半。

2. Agent 通信（Agent Communication）

Tasks 原始类型（SEP-1686）作为实验性功能发布后，在预期场景中运行良好，但早期生产使用暴露出一份具体的生命周期缺口清单：

• 重试语义：任务瞬时失败时客户端应如何重试；
• 过期策略：任务完成后，结果应保留多长时间。

这类迭代只能发生在"真实部署并测试过"之后。路线图宣布的计划是：先发布实验版本 → 收集生产反馈 → 迭代，并将同样的方法应用到 MCP 的其他部分。

在后续路线图中，这一领域被扩充为"Agentic Messaging Primitives"（Agent 化消息原语），核心维护者包括 Caitie McCaffrey、Clare Liguori 与 Peter Alexander。其担忧非常具体：MCP 已经围绕 Tasks、subscriptions/listen、进度通知长出了一组概念，但分散在多个工作组中——风险在于"服务器还没干完"会出现三种互不共享生命周期、取消模型与错误面的答案。因此本周期重点包括：

• 服务器发起的事件（Server-initiated events）：由 Triggers & Events 工作组 负责，定义推送投递的通道与订阅机制（含 webhook），避免客户端用高成本的轮询等待任务完成；
• 组合性审查（Composition review）：由 Agents、Transports、Triggers & Events 三个工作组联合，确保 Tasks、Triggers 等新原语之间能干净组合、贴合真实用例。

Tasks 本身作为扩展（io.modelcontextprotocol/tasks）继续演进，详见 Tasks 扩展文档：服务器对长耗时请求返回CreateTaskResult（resultType: "task"），携带taskId、初始状态、TTL 与建议轮询间隔；客户端通过tasks/get轮询、通过tasks/update回传input_required状态所需的输入、通过tasks/cancel协作式取消。状态机包含working、input_required、completed、failed、cancelled五个状态，其中后三个为终态。该扩展最终有望通过 SEP-2663 进入核心协议。

3. 治理成熟化（Governance Maturation）

当前瓶颈很直接：每一个 SEP 无论领域如何，都需要完整的核心维护者评审。这会拖慢那些"本已具备领域评审能力"的工作组。

目标是在不牺牲质量的前提下移除瓶颈，具体手段有二：

1. 文档化的贡献者阶梯（contributor ladder）：提供从社区参与者到维护者的清晰晋升路径。这一设计已由 SEP-2148 落地，完整规则见 contributor-ladder.mdx：从 Contributor → Member → Maintainer → Core Maintainer → Lead Maintainer，外加并行的 Community Moderator 轨道，晋升依据是"实际贡献、良好判断与持续投入"，而非单纯任职时长。
2. 委托模型（delegation model）：让受信任的工作组在自己的领域内接受 SEP，无需等待完整的核心评审。核心维护者保留战略监督权，工作组获得行动空间。

这一"最低层级做决策、必要时升级"的委托原则，在 Working and Interest Groups 治理文档 中有完整的落地规则：

• 工作组内部决策遵循Lazy Consensus（默认）→ Formal Vote（受阻时）→ Escalation（投票无法解决时）的三级递进；
• 简单事项的惰性共识期至少 5 天、重大事项至少 10 天，沉默即同意；
• 正式投票需要 50% 活跃 WG Member 的法定人数，常规事项简单多数、范围变更需 2/3 多数；
• 涉及范围、权限、跨组冲突等争议直接升级至核心维护者，指定一名与当事方无组织关联的 CM 处理，5 个工作日内有初步响应。

对贡献者而言，这意味着：成为某个工作组的持续贡献者，是让提案获得更快评审的现实路径——WG Leads 可以在范围内对 SEP 做分流（triage），包括以记录在案的理由关闭不符合路线图的 SEP（作者可向核心维护者申诉）。

4. 企业就绪（Enterprise Readiness）

企业在生产环境部署 MCP 时遇到的可预测问题清单：审计追踪（audit trails）、SSO 集成的认证、网关行为、配置可移植性。

这一领域是四大优先项中定义最不明确的——而且这是刻意为之：团队希望正在经历这些挑战的人来帮助定义具体工作。需要注意的是，专门的企业工作组（Enterprise WG）当时尚不存在；如果你在企业基础设施领域工作并想牵头或加入一个，可以参照 Working Groups 页面 的启动流程。

路线图同时给出了一个明确的边界判断：企业就绪的大部分工作预计以扩展（extensions）形式落地，而非修改核心规范——"企业的需求是真实的，但不应该让基础协议为所有人变重"。

这一判断在后续路线图中被深化为"Agent Identity and Enterprise-Ready Security"（Agent 身份与企业级安全），由 Paul Carleton 与 Den Delimarsky 负责，核心洞察是：MCP 的授权默认假设"同意时浏览器前坐着一个真人"，但调用方越来越多是 Agent——自带身份的云工作负载、为不在场的用户代行、或需要比父级更窄权限的子 Agent。对应重点包括：

• DPoP（Demonstrating Proof of Possession）：固化规范并推动广泛采用；
• Agent 身份与委托：围绕 Workload Identity Federation、Enterprise-Managed Authorization 使用的 Identity Assertion JWT Authorization Grant（ID-JAG）与 RFC 8693 Token Exchange，并与 IETF OAuth、WIMSE 工作组协调。

SEP 优先级排序：对贡献者意味着什么

路线图中最实用的新增内容，是明确说明 SEP 评审容量如何分配。规则可以浓缩为一句话：

与上述优先领域对齐的 SEP 会走得最快。不在优先领域内的 SEP 不会被自动拒绝，但会面临更长的评审时间线和更高的论证门槛。维护者带宽有限，团队选择把话说在前面。

如果你正在考虑撰写 SEP，SEP Guidelines 是起点；熟悉流程后，官方给出两条可操作建议：

1. 检查你的提案是否映射到某个优先领域。如果不在，请为评审延迟做好准备；
2. 把它带到相关工作组。带着工作组背书、并与路线图有清晰关联的 SEP，才是会推进的那批。

这与 SEP 流程本身的设计相互印证。SEP 的完整生命周期是：提交 PR → 等待赞助人（Awaiting Sponsor，最长 6 个月）→ Draft（获得赞助人、非正式评审）→ In-Review（正式评审，核心维护者每两周开会）→ Accepted / Rejected → Final（完成参考实现与一致性测试）。关键角色是Sponsor（赞助人）——一位在相关领域内的 Core Maintainer 或 Maintainer，负责评审、推动状态更新并发起正式评审。SEP 草案必须先有原型实现才可能被接受（官方 SDK 分支、独立概念验证、集成测试或参考服务器均可），伪代码与纯设计文档不满足要求。对于涉及可观察协议行为的 Standards Track SEP，进入Final前还必须在一致性测试仓库合并带 SEP 编号的场景与sep-NNNN.yaml追踪文件（SEP-2484）。

流程上有两点值得注意：

• dormant（休眠）不等于rejected：只是 6 个月内没找到赞助人，想法本身可能仍然成立，条件变化后可复活；
• 被拒绝也不是终点：可以消化反馈重新提交、在 Discord 询问原因、提交竞争性 SEP，或等待合适的时机——"今天被拒绝的，未来可能受欢迎"。

On the Horizon：视野之内而非弃置不顾

并非所有被重视的工作都进入了前四，团队也不希望它们从视野中消失。路线图新增的On the Horizon（视野之内）部分收录了确有社区兴趣的工作：

• 触发与事件驱动更新（triggers and event-driven updates）
• 流式与引用式结果类型（streamed and reference-based result types）
• 更深的安全与授权工作（deeper security and authorization work）
• 扩展生态的成熟（maturing the extensions ecosystem）

这些方向的定位是"不是优先级意义上的'我们不想要'"：团队乐意支持社区组建工作组、并在时间允许时评审相关 SEP，只是核心维护者本周期不会主动搭建它们。部分方向已有活跃提案在审，例如SEP-1932（DPoP）与SEP-1933（Workload Identity Federation）（对应 docs/community/interest-groups/auth.mdx 相关主题）；而 triggers 与事件驱动更新这类方向，则"受益于一个新的工作组"——事实上，Triggers & Events 工作组章程（2026-03-24 建立，由 Clare Liguori 与 Peter Alexander 领导）正是为了承接这部分工作而设立，其孵化仓库为modelcontextprotocol/experimental-ext-triggers-events。

如何参与：从加入一个工作组会议开始

路线图上的每一项交付都经由工作组完成，而每个工作组都对贡献者开放。官方给出的参与方式有三条：

• 加入工作组（Join a Working Group）：工作组是真正做协议设计的小团队，定期开会、欢迎新参与者。当前活跃的工作组及联系方式的完整列表见 Working Groups & Interest Groups 页面，仓库内每个工作组都维护了自己的章程，例如 SDK 工作组、Transports 工作组、Agents 工作组；
• 提出 SEP（Propose a SEP）：SEP 是协议变更被提出与评审的正式机制，完整流程见 SEP guidelines，仓库内 seps/ 目录 保存了全部提案的历史记录；
• 启动扩展（Start an extension）：扩展允许在核心规范之外实验新能力。扩展框架本身由 SEP-2133 定义，允许任何工作组或兴趣组在正式 SEP 之前于experimental-ext-仓库中先行实验，相关说明见 Extensions 总览。

如果你不确定从何开始，最简单的第一步是：参加一个工作组的会议并自我介绍。加入工作组与兴趣组不需要先加入另一个组（"是否需要先加入 IG 才能发起 WG？——不需要"），提交 SEP 也不需要先加入工作组（"任何人都可以提交 SEP，但工作组协作能显著增强提案并帮助它找到赞助人"）。从 Observer 到 Participant 再到 WG Member（持续参与 3 个月以上、有实质贡献、经成员或 Lead 提名且 7 天内无异议），是一条清晰可见的参与路径。

附：路线图演进核对——从博客到最新文档

将这篇 2026-03-09 的博客与仓库中最新版 docs/development/roadmap.mdx（更新于 2026-08-22）对照，可以清楚看到优先领域如何随周期推进而细化：

同时，2026-07-28 版本的变更记录 已经证实了路线图多个方向的实际落地：协议无状态化（移除initialize握手、新增server/discover）、Tasks 移入官方扩展并重构为轮询模型（SEP-2663）、subscriptions/listen取代资源订阅、列表结果统一携带ttlMs/cacheScope（SEP-2549）、MRTR 多轮往返模式（SEP-2322）、以及错误码分配策略的规范化。对协议使用者而言，这些变化意味着：新实现应默认无状态、通过_meta携带版本与能力、并用server/discover做能力探测；对贡献者而言，路线图 + 工作组 + SEP 的完整链路，就是让想法变成协议规范的最短路径。

• 人工智能
• AI Agent
• 工具调用