MCP

MCP 有了发布日历：SEP-3398、Server Cards 与十月安全浪潮对 B2B 智能体部署意味着什么

作者：IdeaBosque最后更新：2026年10月31日

核心要点

MCP 规范现在按固定日历发布 — SEP-3398 于 2026 年 10 月 14 日被接受，设定每六个月发布一次，时间为三月的最后一个周二与九月的最后一个周二，并将 2026 年 12 月的目标推迟到 2027 年 3 月下旬。
Server Cards 已成为正式标准 — SEP-2127 于 2026 年 10 月 6 日合并为 Final，为 MCP 服务器提供了标准化的元数据文档，可在建立连接之前发现传输方式、协议版本与连接指引。
官方仓库在 28 天内发布 31 条安全公告 — 据 eSEOspace 的 State of MCP October，其中包括 MCP Inspector 的两个严重级，已在 10 月 21 日的 1.0.3 安全版本中修复。
Smithery 代理与托管身份服务于 2026 年 10 月 31 日关停 — Smithery 自己的通知退役了 run.tools 与 server.smithery.ai 的服务器 URL——这是本月对"租用分发路由即运维风险"最清晰的证明。
按 2026-07-28 规范规划整个冬季 — 无状态核心不受影响；下一版本将于 2027 年 3 月下旬发布，迁移节奏可以写进日历，而不是被动追赶 changelog。

Smithery 的 MCP 代理与托管身份服务于 2026 年 10 月 31 日——今天——关停。仍通过 run.tools 或 server.smithery.ai 的 URL 解析服务器的智能体部署随之中断；Smithery 自己的通知列出了失去的一切：托管服务器 URL、API、Connect 与 Toolbox、账户、API key 以及 CLI。迁移方案落在供应商自己的端点——用 mcp.linear.app/mcp 替代 linear.run.tools——而从来没有自建迁移清单的团队，只能在今天现写一个。

同样在这 28 天里，MCP 的维护者接受了该协议的首个固定发布日历、将 Server Cards 发现标准合并为 Final，并且——按 eSEOspace 的统计——在官方 MCP 仓库记录了 31 条安全公告，其中两条在 MCP Inspector 被评为严重级。

这个组合是从三个方向看到的同一场转型——日程、发现与运维。MCP 已不再像快速迭代的胶水层，而开始像托管的基础设施。本文把十月的记录当作一个信号来解读，并给出它所要求的运维节奏：锁定规范版本，把发布节点写进日历，让 SDK 停留在安全发布轨道上，并且不再租用分发路由。

本文是 MCP 2026-07-28：无状态协议对 B2B 智能体部署意味着什么的续篇——那篇覆盖了无状态核心、显式句柄模式与 7 月 28 日规范的部署账算。这里聚焦的是十月围绕那份规范发生的变化：发布节奏、发现层、公告流与分发停服。无状态论点本身未被其中任何一项触及。

十月记录的一览

图注：28 天内的五个事件，把 MCP 从一份滚动的规范变成一个带日历、带发现标准、带安全发布轨道、并经历首次第三方分发中断的平台。

一个被接受、随后完成的发布日历

SEP-3398 是一份流程类 SEP，流程类 SEP 很少上头条——但这一份应该上。10 月 14 日被接受、10 月 27 日完成合并，它把 MCP 的发布节奏写进文本：规范每六个月发布一次，"通常是三月的最后一个周二与九月的最后一个周二"，每个版本有八个月的工作周期——两个月规划、一个排定的核心维护者（Core Maintainer）评审窗口、一个稳定阶段——相邻两个周期相互重叠两个月。过渡条款补齐其余：原定的 2026 年 12 月发布目标推迟到 2027 年 3 月下旬。

对维护者而言，这是评审容量的管理。对 B2B 部署而言，这是规划基础设施：

弃用窗口现在可以放进日历。 Roots、Sampling、Logging 与已弃用的 HTTP+SSE 传输自 7 月 28 日规范起就带着 12 个月的仅注解窗口。固定日历把"从 7 月 28 日起 12 个月"变成与 ERP 发布窗口同处一张路线图的节点。
未完成的工作顺延，日期不动。 与发布绑定的提案必须在 soft freeze 前达到 Final 并完成合并；未完成的提案顺延到之后的周期，发布日期不变。这正是团队对平台供应商的期待——可预测性优先于完整性。

最直接的实务结论来自 eSEOspace 对十月数据的解读：十月没有任何新规范版本发布——最新版本仍是 2026-07-28，日历把下一版本推到 2027 年 3 月下旬。今天部署所锁定锚定的无状态核心，整个冬季都仍然有效。

Server Cards：发现不再是一个配置文件

SEP-2127（MCP Server Cards）于 10 月 6 日合并为 Final——早于日历 SEP——补上了部署问题的另一半。无状态规范定义了智能体在连接之后如何与服务器通信。Server Cards 定义智能体如何在无需手工配置的情况下找到服务器：一份标准化的元数据文档，描述传输方式、协议版本与连接指引，由服务器暴露、由客户端在任何连接建立之前读取。

来自 SEP 本身的机制：每个服务器暴露自己的 card——card 可托管于任意未保留的 URI，推荐位置是 <streamable-http-url>/server-card——挂载于扩展标识 io.modelcontextprotocol/server-card 之下。域名级"AI Catalog"可以链接或嵌入相关 card，这正是注册表爬取与服务自动发现无需逐个端点手工处理的原因。

B2B 的对应物是 A2A 的 agent card——.well-known/agent-card.json——我们对 A2A 的覆盖已把它视为机器间发现的基础配置。Server Card 是协议服务器的同一思路，它删掉了多数智能体部署今天维护的制品：手写的服务器端点及其工具 schema 清单。当这份清单变成可发现的元数据，运维姿态在三个方面改变——新服务器自动宣告自己的表面；失效端点变得可审计（与在线服务器不再匹配的 card 本身就是发现项）；供应商升级不再需要客户端侧的重新配置。

SDK 与客户端支持是 SEP 声明的下一步，所以务实的做法是现在就按此设计：构建端点时预留 card 位置，并让服务器清单随时可以变成元数据而不是配置。

十月安全浪潮：公告成为运维节奏的一部分

十月记录中最锋利的行是安全行，读起来更像平台供应商的补丁日，而非业余项目的 changelog。MCP Inspector 的两个严重级于 10 月 21 日发布，均在 1.0.3 安全版本中修复：

GHSA-6x67-4w4w-9f3w — 远程 MCP App 可窃取代理的认证令牌并执行任意本地命令（RCE）。受影响版本：Inspector 0.20.0 至 1.0.2。
GHSA-4fc4-wcmh-4g86 — 恶意 MCP OAuth 回调可把传输切换到 stdio 并执行任意本地命令（RCE）。受影响版本：0.13.0 至 1.0.2。

Inspector 之外，TypeScript SDK 的十月公告是对 B2B 最有杀伤力的一条：GHSA-jm63-cq47-j5jp——"共享传输或服务器实例把一个 HTTP 客户端的消息发给了另一个"——评级为高，自 2.0.0 起受影响，在 2.3.0 修复。共享传输导致的跨客户端数据泄漏，恰是 B2B 部署无法容忍的缺陷类别，而它落在 SDK 的核心包里，不是实验性角落。

发布日期与严重程度同样清晰地讲述平台故事。Python SDK 2.3.0 于 10 月 2 日发布，在工具注册时收紧头部检查；TypeScript SDK 2.4.0 于 10 月 23 日发布，加入 Skills-over-MCP（SEP-2640）支持；Kotlin 0.16.0 于 10 月 27 日发布，封堵内存耗尽漏洞并弃用 SSE（发布说明；定性依据 eSEOspace 的发布说明评审）。四个主要的官方 SDK 在本月都至少发布了一次，而按 eSEOspace 的评审，贯穿其中的主题是加固：请求大小、会话数量与内存的硬性限制。他们对官方仓库公告数的统计——28 天 31 条——是他们自己的口径，但它描述的形态可以核验：安全发布轨道如今是连续的，不是间歇的。

对运维者的解读很简单。如果你的 MCP 资产有 SDK 更新策略，十月就是策略必须触发两次的月份。如果没有，上述公告就是会积累下来的东西。

Smithery：分发层的合同到期

第三个事件是运维团队今天就能感受到的。Smithery 的通知毫不含糊：2026 年 10 月 31 日，Smithery 关停其连接管理服务——这意味着每一个 run.tools 与 server.smithery.ai 服务器 URL、托管代理路径、API、账户、API key 与 CLI 都已失效。smithery.ai 目录仍作为公共目录在线，现由 Arcade.dev 支持。

对拥有供应商原生端点的服务器，迁移是直接的——Smithery 自己的示例就是从 linear.run.tools 指向 mcp.linear.app/mcp。对把代理当作分发策略来构建的部署，这是一场抢跑：没有供应商原生 URL，没有约定由什么在你的控制面里接替它，而在记录流量的代理消失之后，也没有审计说明现在是谁在连接。

这条教训的适用范围超出一家供应商：如果你的智能体队伍解析 MCP 服务器所经过的端点属于第三方，该端点的生命周期就是一项你既未选择也未跟踪的依赖。十月交付了这一证明——而且是在协议把发现元数据标准化、固定自身发布日历的同一个月份。持久的立场是供应商原生端点（按 Smithery 自己的迁移指引），或由你的团队运营的端点——我们的 MCP 服务器防护分析为边界所画出的 buy-vs-build 分界线，这份记录在分销层给出了证明。

B2B MCP 部署的运维清单

图注：六项控制，把十月的信号转化为部署策略——每一项都对应本月一个有日期的事件。

#	控制	它回应的十月事件	在部署中的样子
1	锁定规范版本	十月没有新规范版本；下一版本 2027 年 3 月下旬	显式锁定 2026-07-28；运行声明支持该版本的 SDK；在每个日历节点复审锁定
2	把发布节点写进日历	SEP-3398：三月与九月的最后一个周二	把 soft freeze（T−2.5 个月）与 hard freeze（T−1 个月）作为评审窗口排进团队路线图，而不是当作意外
3	停留在 SDK 安全轨道	十月 31 条公告；Inspector 1.0.3 中两个严重级	把 SDK 地板锁定在安全版本（TS ≥ 2.3.0，Inspector ≥ 1.0.3）；订阅官方仓库的公告流
4	优先供应商原生或自运营端点	Smithery 的 `run.tools` / `server.smithery.ai` 于 10 月 31 日停服	盘点服务器清单中的每一个非供应商端点；终止依赖代理的路由，或自行运营
5	为 Server Cards 元数据而设计	SEP-2127 于 10 月 6 日成为 Final，SDK/客户端支持在后	设计端点时预留 card 位置；让服务器清单随时可以变成可发现的元数据，而非配置
6	把注册表收录视为未审核	官方注册表 52,141 台服务器，66% 提供远程端点（按 eSEOspace 的统计）	收录不是安全信号；在第三方服务器接入之前，执行治理清单的模块审批门

这对 2026-07-28 部署模式意味着什么

我们此前分析所给出的无状态核心，是十月没有触及的部分——而这正是值得直白说出的重点。SEP-3398 重新安排未来的发布；它不动你整个冬季锁定的规范。Server Cards 增加发现能力，不改变传输。公告在同一个协议版本上加固 SDK。Smithery 的关停是第三方的商业决定，不是协议事件。

如果你的部署模式假设 MCP 迭代太快而无法锁定、太年轻而无法排期，十月就是这份假设的反证记录。从盯 changelog 转为盯日历的团队，会把 2027 年 3 月下旬的发布当作一次按期复审；其余团队将从一次故障中得知它。