MCP Events（MCP 事件订阅规范）
| 分类 | 📖 技术协议 |
| 阅读时间 | ⏱️ 20 分钟 |
| 更新时间 | 📅 2026-10-23 |
| 条目编号 | ENC-PROTOCOL-21-mcp-events |
关键要点 ✦
- 补齐 MCP 的被动性：MCP 本是请求驱动，通知类消息不带载荷且依赖活跃连接，断线即丢；MCP Events 让服务端能主动推送「发生了什么」而不只是「资源变了」。
- SEP-3415 由 MCP 触发与事件工作组于 2026 年 10 月 5 日提出，截至 2026 年 10 月中旬仍为草案并持续修订（见 Hookdeck 对该提案的跟踪与 MCP 官方仓库）。
- 三个方法构成订阅生命周期：events/list 声明可订阅事件与过滤器，events/subscribe 创建或刷新订阅，events/unsubscribe 停止订阅；服务端在能力发现结果中以 events 字段宣告支持。
- 安全设计继承 Webhook 业界惯例：仅限 HTTPS、回调验证用一次性随机挑战、whsec_ 签名密钥须可解码为 24 至 64 字节、采用 Standard Webhooks HMAC 签名、单个事件上限 256 KiB、失败按指数退避重试且 410 或 413 终止。
- ChatGPT 已按草案落地支持，要求 MCP 2.0（协议版本 2026-07-28），可用于 Work 聊天与 dots；不支持轮询与流式，草案中的 gap 与 terminated 控制通知亦未纳入（据 OpenAI 官方文档）。
- 事件到达后的行为由客户端决定：加入对话、唤醒智能体或排队稍后处理——规范刻意不规定这一步，把策略留给宿主应用。
为什么 MCP 需要事件通道
没有事件机制时，想知道「构建失败了没有」只有两条路：客户端反复轮询 MCP 服务器，或者在协议之外写一个后台脚本盯着 CI 再手动唤起智能体。MCP 自带的通知机制填不上这个缺口——变更通知只说某个资源或列表变了，不带载荷，客户端还得再读一次才能知道发生了什么；而且通知依赖活跃连接，断线期间发出的通知会直接丢失，也没有机制告诉客户端错过了什么。MCP Events 的定位就是这下一跳：从 MCP 服务器到宿主应用内的 MCP 客户端。至于上游服务如何把事件送到 MCP 服务器（例如 GitHub 向服务器发 Webhook），不在规范范围内。
规范核心：三个方法与订阅模型
服务端在能力发现结果中声明 events 能力后，在同一鉴权端点上实现三个方法。events/list 返回事件目录，每个事件定义携带名称、描述、投递方式、订阅参数的 inputSchema 与载荷的 payloadSchema，过滤器（如频道或文档 ID）由服务端在投递前应用；目录过长时用游标分页。events/subscribe 创建或刷新订阅，请求携带事件名、过滤参数与回调信息；规范建议以鉴权主体、回调地址、事件名与参数确定性地推导订阅 ID，使重复请求更新既有订阅而非堆积。events/unsubscribe 停止订阅。订阅默认长期有效，可在过期前刷新，ttlMs 可为授权设上限。
安全与可靠性设计
MCP Events 把 Webhook 生态多年沉淀的安全惯例写进了规范。所有回调仅走 HTTPS，解析到的地址在连接时校验，私有与本地地址被阻止，重定向被拒绝，以缓解 SSRF。接受订阅前，服务端须先向回调地址发送带一次性随机挑战的验证请求并用订阅密钥签名，要求对方以恒定时间比较回显。每个事件以 Standard Webhooks 兼容的 HMAC 签名覆盖事件 ID、时间戳与请求体字节，密钥须为可解码成 24 至 64 字节的 whsec_ 前缀值。单事件不超过 256 KiB，大记录建议只推摘要并配读取工具；事件可能乱序到达，规范提醒写工具应实现幂等。投递失败按指数退避重试，410 与 413 终止重试。
客户端落地：ChatGPT 与插件自动化
OpenAI 在 2026 年 DevDay 上宣布 ChatGPT 插件支持 MCP Events 提案，让插件可以在连接的应用中发生事情时启动自动化，例如盯着项目看板，新任务进来就读取关联文档起草计划。据官方文档，该能力要求 MCP 2.0（协议版本 2026-07-28），当前支持 Web 端与桌面端的 Work 聊天以及 dots；ChatGPT 只支持 Webhook 投递与回调验证，轮询、流式以及草案中的 gap、terminated 控制通知均不支持。事件送达后做什么由客户端决定——加入会话、唤醒智能体或排队稍后处理，这也正是 MCP Events 与常驻型智能体设计的接合点：事件通道负责「叫醒」，常驻运行时负责「接住」。
与既有机制的关系及局限
MCP Events 与既有资源变更通知是分层关系：后者宣告资源变化且需长连接，前者承载带载荷的业务事件且经 Webhook 投递、可离线暂存。它与 WebMCP 也不冲突——WebMCP 解决浏览器页面向智能体暴露工具，MCP Events 解决服务器向智能体推送时机。局限同样明显：截至 2026 年 10 月中旬 SEP-3415 仍是草案且持续变动，早期实现多跟随工作组更早的设计稿，两套行为存在差异；ChatGPT 集成也只覆盖草案子集。对服务端开发者而言，当前意味着要同时盯规范演进与客户端实际支持的交集。
🎯 应用场景
✅ 最佳实践
- 事件名保持稳定并给出精确描述，把可发现范围限制在当前账号有权看到的事件。
- 过滤器在服务端投递前应用，不要把无关事件全量推给客户端。
- 写工具实现幂等，事件可能乱序或重复到达。
- 严格按规范做回调验证与签名校验，禁止重定向并阻断内网地址。
🔮 未来展望
SEP-3415 仍在快速演化，轮询与流式投递、gap 与 terminated 控制通知等待性条款尚未定型；草案与早期实现的行为差异需要生态收敛。若规范稳定，事件订阅将成为智能体从「被动应答」走向「常驻值守」的标准入口，与常驻型智能体、托管运行时形成配套。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。