ChatGPT MCP事件触发：从Gmail/Slack/GitHub启动任务

OpenAI 正在把 ChatGPT 从“你问它答”的对话框，推向一个能被外部事件驱动的自动化工作台。最新的 MCP Events 功能允许开发者把 Gmail、Slack、GitHub 里的动作——一封新邮件、一条频道消息、一次代码提交——直接变成 ChatGPT Work 任务的触发源。这意味着工作流的起点不再是打开聊天窗口，而是事件本身。

MCP Events 到底解决什么问题

传统上，把 ChatGPT 接入业务流程需要轮询：定时检查邮箱有没有新邮件、仓库有没有新 PR，然后决定要不要调用模型。轮询既浪费资源又有延迟。MCP Events 改用 Webhook 签名回调的思路——事件发生时，外部服务主动把数据推给 ChatGPT，由平台负责验证签名并启动预设任务。

据官方说明，触发源既包括 Gmail、Slack、GitHub 这类内置连接器，也支持开发者自己搭建的 MCP server 发出事件。这种“内置 + 自定义”的组合，把可触发的场景边界交给了开发者。

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 于 2024 年底提出并开源的协议标准，用于统一大语言模型与外部工具、数据源之间的连接方式，可类比为"AI 应用的 USB-C 接口"。在 MCP 之前，每接一个外部系统（数据库、日历、代码仓库）都需要单独编写适配代码，接口形态各异；MCP 通过定义标准化的工具调用、资源读取和提示模板接口，让同一套客户端可以复用任意符合协议的服务器。围绕 MCP 已形成较完整的生态，既有官方维护的参考实现，也有社区提供的数百个开源 MCP server，覆盖搜索、文件系统、云服务等场景。OpenAI 在该协议基础上加入事件推送能力，意味着 MCP 从"被动响应模型调用"扩展为"主动驱动任务启动"，这是协议能力边界的一次实质性延伸。

三种典型触发场景的配置路径

Gmail：邮件即任务

把 Gmail 接入后，可以设定在收到特定发件人或包含特定关键词的邮件时启动任务。适合的场景包括客服工单自动分类、合同邮件自动提取要点、销售线索自动入库。配置的核心是收窄触发条件，避免每封邮件都触发任务导致噪声。

Slack：频道消息驱动协作

Slack 侧的触发通常绑定到特定频道或特定消息模式。比如运维频道出现告警格式的消息时，自动让 ChatGPT 汇总上下文并生成处置建议。这一步的关键是把消息格式约定清楚，否则触发条件会过于宽泛。

GitHub：代码事件触发审查

GitHub 事件适合接入 PR 创建、Issue 打开、评论提及等节点。典型用法是新 PR 触发一次结构化代码审查任务，把 diff 交给模型生成评审意见。相比手动复制粘贴，事件驱动的方式能保证每次提交都被覆盖。

自定义 MCP server

对于内部系统，开发者可以在自己的 MCP server 中实现事件推送，配合签名 Webhook 完成鉴权。官方给出的实现要点是：请求体需要签名，ChatGPT 侧校验通过后才启动任务，防止伪造事件触发消耗额度。

30 次/小时的触发上限意味着什么

官方明确了一个硬性约束：每小时最多触发 30 次任务运行。这个数字不大，决定了 MCP Events 的定位不是高吞吐的批量处理管道，而是低频、高价值的自动化节点。

对高频场景需要做聚合设计：比如不是每条 Slack 消息都触发，而是把一段时间内的消息合并成一个摘要任务；或者用前置过滤把大部分事件挡在触发之前。把 30 次额度花在真正需要模型判断的事件上，是这套机制落地时的核心工程决策。

签名 Webhook 的安全设计

事件驱动架构的常见风险是伪造请求。MCP Events 要求对回调进行签名校验，开发者需要在服务端用密钥对请求体计算签名，并与请求头中的签名比对。实现上有几点值得注意：签名计算必须基于原始请求体而非解析后再序列化的内容，否则字节级差异会导致校验失败；密钥应通过环境变量注入而非硬编码；校验失败时必须直接拒绝，不能降级处理。

这套设计与主流 Webhook 实践一致，也说明 MCP Events 面向的是有一定工程能力的团队，而非纯终端用户。

Webhook 是服务之间"反向通知"的机制：不是调用方反复询问"有新数据吗"，而是事件发生时由数据源主动向预先登记的 URL 发起 HTTP POST。由于该 URL 通常对公网开放，任何人都可能向它发送伪造请求，因此主流服务都会在请求头附带一个基于共享密钥（Secret）和请求体计算的 HMAC 签名，例如 GitHub 使用 X-Hub-Signature-256 头并采用 HMAC-SHA256 算法。接收方用同一密钥重新计算并比对，即可确认请求确实来自可信源、且内容未被篡改。HMAC 是一种基于哈希的消息认证码，其安全性依赖于密钥保密而非算法保密。实践中还需注意防范重放攻击，常见做法是校验请求时间戳并设定容忍窗口，或在签名内容中加入一次性随机数。

落地建议

先从一个明确的单点场景开始，比如新 PR 审查或工单邮件分类，跑通签名校验和任务模板，再逐步扩展触发源。同时要为 30 次/小时的额度建立监控，避免某个异常事件源把额度耗尽导致关键任务无法触发。MCP Events 的价值不在于替代工作流引擎，而在于把模型的判断能力嵌进已有的业务事件流中。