协议的三段式进化
九月二十九日 DevDay 2026 上，OpenAI 把 MCP Events 接进 ChatGPT 插件，让插件能在连接的应用发生相关变更时启动自动化。这件事对模型上下文协议（MCP）的意义，被多家媒体概括为「补齐第三只脚」。回看协议轨迹：起点是标准的请求响应模型，用 JSON-RPC 让智能体向服务器查询信息；随后在 Streamable HTTP 里加入双向流式（SSE），改善实时数据流；而直到现在，协议一直缺一个原生的回调或 Webhook 机制——智能体要么反复轮询，要么维持长连接，两者都带来开销与延迟。MCP Events 用事件回推补上这一脚，让服务器在状态变化时主动通知智能体，从「智能体问世界」变成「世界告诉智能体」。对智能体而言，这等于多了一个 reflex：不必再机械轮询，而是对相关变更实时反应。
三个方法加一套签名
落到实现，MCP Events 要求 MCP 2.0（协议版本 2026-07-28）。服务器要在同一经过鉴权的端点上实现三个方法：events/list 描述可用事件与过滤项，events/subscribe 创建或刷新订阅，events/unsubscribe 终止订阅。事件定义要带名称、支持的投递模式、订阅参数与负载结构，且只返回连接账户被允许发现的事件。投递走 Standard Webhooks 的 HMAC 签名（webhook-id、webhook-timestamp、webhook-signature 三件套），单条负载上限二百五十六 KiB，并在激活前先发一个带签名的 HTTPS 校验挑战让 ChatGPT 回以 2xx 确认。安全约束很具体：回调地址禁用私有与本地地址，防止常见的内网探测与绕过。当前集成本质上只支持 Webhook 投递，不支持轮询与流式，也暂不含草案里的 gap 与 terminated 控制通知；若某类事件没有重放机制，中断期间漏掉的事件无法靠本协议找回，需要做重放的服务器得自己维护游标与历史。
谁在推、边界在哪
这项能力不是 OpenAI 单家闭门造的。MCP 的 Triggers and Events 工作组于 2026 年三月成立，由 AWS 的 Clare Liguori 与 Anthropic 的 Peter Alexander 牵头，MCP Events 正是这条标准化路线的阶段性产物。OpenAI 当前在 ChatGPT 里的集成可作为早期样板：用户让 ChatGPT 盯某个看板的新任务，任务一到，ChatGPT 就能读取关联文档、起草计划，即使用户暂时离开也能跑。但要把它当通用能力，边界得说清：草案仍在活跃演进，开发者要准备好协议细节可能变化；投递可能乱序到达，写入工具应当幂等，避免重试造成重复副作用；事件负载里用户写的评论应按数据而非指令对待，防止提示注入。对一个构建者，稳妥的起步是先用一个窄事件加一个过滤项，依次验证发现、订阅、回调校验、匹配投递与后续动作，再谈扩展。目前 MCP Events 在 ChatGPT 侧的具体覆盖计划与跨插件的通用程度官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
一句话收尾
MCP Events 把模型上下文协议从「问」补成「被通知」，让智能体由此获得对世界的实时 reflex。第三只脚站稳后，主动式工作流才真正有了协议级的地基——只是草案未定，构建者现在该做的是小步验证，而不是假定每个连接的应用都已能触发。