团队希望 Agent 跟进文档批注：有人提出修改，它读取上下文、调整内容，再把结果交回。工具已经接通，程序也能改文件，任务却还卡在“什么时候开始”上。让人每次手动发消息不方便；每隔几分钟检查一次，又会反复得到没有变化的结果。
MCP Events 给这类工作增加了一个入口：用户订阅外部系统中的变化，符合条件的事件送到 ChatGPT，再按事先约定的任务继续处理。它能减少等待和无效检查，但一次可靠的处理，还需要权限、投递、写入和恢复共同配合。
轮询的成本，要看有没有真的调用模型
“有没有新工单”可以由普通程序查询，也可以把查询结果每次都交给模型。两种实现的成本不同：前者主要产生接口请求和后台任务开销，后者还可能产生模型调用费用。不能把所有轮询都写成每隔五分钟必然消耗 Token。
轮询也有适合的地方。上游没有事件接口、更新频率很低，或者需要定期核对完整状态时，简单查询仍然有用。对于已经能产生明确事件的业务，把每次变化直接送到处理入口，通常能减少无效请求，也避免等待下一轮检查。
因此，MCP Events 带来的变化是增加标准化的事件订阅方式。它没有证明所有 Agent 都应删除定时任务，更不意味着系统从此不需要补偿检查。
当前支持什么，需要先看宿主环境
OpenAI 的 MCP Events 文档明确列出的使用环境包括 ChatGPT 网页端 Work 会话、桌面端选择 Cloud 的 Work 会话，以及 dots。插件与事件任务还受工作区控制。这不能直接推广成普通聊天、本地运行环境或所有 MCP 客户端都已具备同样能力。
ChatGPT 这项集成要求 MCP 2.0，协议版本为 2026-07-28，采用事件草案中的 Webhook 投递与回调验证。当前集成不支持该草案的轮询、流式投递以及 gap、terminated 控制通知。这里说的是宿主支持的范围，不是对其他系统架构的禁令。
已有 MCP Server 也不会因为接了几个工具就自动支持事件。开发者需要实现订阅接口、保存订阅状态，并能向经过验证的回调地址发送 HTTPS 请求。
工具决定能做什么，订阅决定何时开始
服务端通过 server/discover 声明 events 能力，并在与工具相同的已认证 MCP 端点上实现三种方法：
events/list：列出事件及可用过滤参数。events/subscribe：创建或刷新订阅。events/unsubscribe：停止订阅。
以文档批注为例，用户先选定文档，并说明收到批注后要执行的动作。宿主发起订阅，服务端检查账号是否有权限、参数是否符合定义，再验证回调和保存订阅。文档随后出现符合条件的批注，服务端才将事件投递过去。
事件定义中的 inputSchema 描述订阅时的过滤参数，payloadSchema 描述送达数据的结构。两者不能混用：前者可以规定监控哪个文档，后者规定一次新批注需要携带哪些信息。
过滤应在服务端执行。只监控指定项目，就不要把其他项目的消息也送给模型再判断是否相关；账号失去资源权限后，也应停止对应投递。发现、订阅和后续交付都需要各自检查权限。
事件给线索，完整内容按需读取
一条事件应让 Agent 知道哪里发生了什么变化。长文档、完整工单和大段日志，可以通过读取工具取得，不必全部塞进通知。
下面是一份简化的业务事件示意。document_id、comment_id 和 summary 是这个示例自行定义的应用字段，需要由服务端的 payloadSchema 声明，并不是协议统一要求的字段：
{
"eventId": "evt_comment_456",
"name": "comment.created",
"timestamp":
"2026-10-06T09:30:00+08:00",
"data": {
"document_id": "doc_123",
"comment_id": "comment_456",
"summary": "请补充部署回退步骤"
},
"cursor": null
}
事件到达后，先读取相关段落及最新版本，再判断是否需要修改。批注出现时的内容与执行时的内容可能已经不同；把收到的一小段文字直接当成当前事实，容易覆盖后来的人工作业。
用户写在评论里的文字仍然是数据，不能自动升级为新的权限或系统指令。评论中即使要求发送密钥、删除资源，也不能越过订阅任务和工具自身的授权边界。
官方限制是每个请求投递一个事件，完整请求体不超过 256 KiB，即 262144 字节。这个限制不是可使用的 Token 配额，也不表示把载荷填满就更有效。大型记录采用摘要与读取工具配合，更容易控制一次任务要看的范围。
HTTP 成功，只是后续处理的起点
Webhook 返回 2xx，确认的是接收成功，ChatGPT 随后异步处理事件。它不能证明文档已经改好、测试已经通过，或者草稿 PR 已经创建。业务侧应分别记录收到事件、开始处理和动作完成的状态。
这一区分在重试时尤其重要。发送方遇到超时，不一定意味着接收方没有收到；同一个事件可能再次到达，事件之间也可能乱序。稳定的 eventId 可以识别同一条事件，但写入工具还需要自己的幂等控制。
例如，建议用事件标识和目标资源建立处理记录，创建草稿 PR 后保存结果。下一次处理同一事件时，先查已有结果，而不是再创建一个 PR。若工作流允许后续更新，还要区分“重复执行同一步”与“修改已有结果”。这是应用层设计，不能指望协议替所有写操作实现一次且仅一次的效果。
网络失败可按有限次数、指数退避安排重试。官方要求重试保留事件 ID、更新签名时间与签名，并明确不要重试返回 410 或 413 的投递。重试策略应按错误类型处理，不能一直重复同一个无法被接受的请求。
订阅、签名和反馈循环，要一起管理
订阅不是写入数据库后就永远有效。服务端需要跨重启保留状态，处理到期、刷新和取消。对于支持重放的事件，游标关系到中断后的恢复；不支持重放时，遗漏事件不能靠协议游标补回来。系统仍可根据业务需要做状态核对，但要先设计补偿范围，避免把所有历史变化重新触发一遍。
回调验证也不只是请求一次 URL。服务端先发送带签名的一次性、短有效期 challenge，确认成功响应及返回值后再交付业务数据。正式投递使用 Standard Webhooks；签名覆盖事件标识、签名时间和准确的请求体字节，因此应只序列化一次，签名和发送使用同一份字节。
HTTPS、签名验证和目标地址检查解决的是不同问题。发起连接时还要验证目标地址，阻断私有、本地及其他非公网地址，保留原始主机名用于 TLS 校验，并且不跟随重定向。只在订阅创建时检查一次 URL，不足以覆盖后续连接。
另一个容易遗漏的问题是自己触发自己。Agent 处理批注后回复一条消息，这条消息又可能变成新事件。应用可以按实际需求标记操作来源、过滤自动生成内容，并限制同一业务链的触发次数。这些策略需要开发者实现，不能把“事件驱动”当成天然没有循环。
第一条工作流，先让结果可以检查
适合先接入的场景，是范围明确、结果可复核的任务。例如，只监控一个文档，对新增批注生成修改建议；或者只处理一个反馈频道，为确认的问题创建草稿 PR。这里的范围由用户意图和授权决定，事件出现本身不意味着可以自动合并或直接上线。
验证时不要只触发一次正常事件。重复订阅应当归并；不符合过滤条件的消息不应送达；账号权限撤销后应停止交付。还要检查服务重启、订阅续期、重复投递、乱序、批量事件和取消监控。最后让任务真实执行一次写入，确认它产生的新事件不会引发循环。
多 Agent 工作流也可以采用类似的完成通知思路，但任务关系、恢复记录和错误处理仍需自行设计。MCP Events 提供的是事件入口，不是一个自动完成编排的多智能体调度器。
从一条批注到一份可检查的修改，接收到通知只是第一步。读到正确版本、在授权范围内写入、重复处理不产生额外副作用、中断后能恢复，这些环节打通以后，事件驱动才真正进入日常工作。