轮询机制的隐形成本与事件驱动的起源

在使用 Grok Bot、Claude Code 等 AI 助理时，用户常遇到一种现象：助手似乎能主动处理事务。这种“看似智能的主动性”背后，其实依赖的是计算机领域一个非常古老的概念——事件驱动（Event-Driven）。这一机制直接决定了 AI 助手的 Token 消耗速度以及响应及时性。

最直观的做法是轮询（Polling）。例如，想让 Bot 帮忙监控邮箱或 X (Twitter) 账号是否有新动态，最简单的设置是每隔五分钟运行一次任务。在传统的计算机编程中，这种每分钟或每五分钟跑一次的排程几乎不需要考虑成本，因为CPU 资源通常是闲置的。然而，在 AI 助理的场景下，情况截然不同。每次 Bot “醒来”，它都需要读取指令、调用工具、抓取结果并分析，每一步操作都在消耗 Token。Token 是 AI 读写文字的计费单位，用得越多越贵。即使没有任何新内容产生，这一轮查询的费用照付不误。

“你叫 Grok Bot 每隔一段时间去 X 看某个账号有没有发新文，它每醒一次都要读指示、呼叫工具、把结果捞回来看。”

这种机制存在严重的效率问题。如果设定每五分钟检查一次，一天就是 288 次。假设用户每天只收到三封重要邮件，剩下的 285 次都是 Bot “醒来看一眼空信箱”的空转。博主实测发现，仅用 Codex 跑一轮最简单的检查（读取一个信箱档看是否有新信），虽然最终结果只有“没有新信”四个字，但输入端就消耗了约 58,000 个 Token。这是因为 Bot 每次醒来都要重新读取自己的指令和工具说明，“要做的事很小，开机成本很大”。按此推算，一天消耗约 1600 万 Token，其中绝大部分都浪费在“无新信”的空转上。

轮询的困境与事件驱动的解决方案

轮询机制陷入两难：排得密，Token 烧得快；排得松（如一小时一次），消息延迟严重。用户最久要等快一个小时才能知道新信到来。事件驱动则彻底反转了这一逻辑：Bot 平时处于休眠状态，只有当信箱那边有新信时，才主动“按门铃”叫醒它。在无事发生时，Bot 一个 Token 都不花。

这种机制并非新鲜事。你的手机每天都在使用这套逻辑：聊天 App 收到消息时，是对方服务器通过手机系统的推播通道（Push Notification）发送通知。手机平时安静等待，有消息才亮起屏幕。

“其实你的手機每天都在用這套。聊天 app 來訊息，是對方的伺服器透過手機系統的推播通道送過來。”

从技术历史来看，“中斷”设计早在 1950 年代初期就已出现。当你按下键盘时，键盘会主动向 CPU 发送信号，CPU 暂停手头工作去处理按键事件，完成后恢复原状。如果没有中斷机制，CPU 就必须不断循环询问键盘“有没有按键”，这与 AI Bot 的轮询如出一辙。70年后，AI 助理再次面临同样的问题。

在技术实现上，这个“门铃”通常被称为 Webhook。用户提供一个网址给外部服务（如邮箱、GitHub），当事件发生时，该服务向这个网址发送一笔通知数据。Bot 被叫醒后直接获取资料开工。事件驱动同时带来了两个核心优势：一是信一来就处理，响应速度远快于排程；二是没信就不醒，大幅节省 Token 成本。

Webhook、长轮询与 WebSocket 的技术演进

虽然事件驱动是理想状态，但排程仍有其适用场景。例如每周早上整理上周数据或每天早上查看行程，这类固定时间必须执行的任务交给排程最为合适。但对于“不知道什么时候会来”的事件，事件驱动是更优解。

在轮询和 Webhook 之间，还存在几种过渡或替代技术： 1. 长轮询（Long Polling）：客户端发起请求询问是否有新内容，服务器不立即回复，而是挂起该连接。一旦有新数据产生，才返回响应。客户端收到后随即发起下一次请求。 2. WebSocket：建立一条双向连接，双方随时可以互相发送数据。适合需要高频实时交互的场景。 3. SSE (Server-Sent Events)：单向通信，服务器有新数据时主动推送到客户端。常用于网页上的聊天或实时状态更新。

“WebSocket 是雙向的，兩邊隨時都能講話。SSE 是單向的，伺服器有新東西就往下推。”

然而，对于 AI Bot 而言，直接维持 WebSocket 或 SSE 连接并不现实。因为Bot 的模型本身不会一直开着等消息。在实务操作中，通常是由一般的程序或平台先接收通知（这些服务可以保持长连接），然后再通过 Webhook 的方式“叫醒” Bot。这种架构分离了通知接收端和AI 处理端。

目前各大 AI 平台都在推行类似机制，但标准各异： * Claude Code：其云端排程任务（以前叫 Routines）除了支持时间触发，还能通过 API 调用或 GitHub 事件（如 PR 开启）来触发。 * OpenAI：正在推广 MCP Events，这是 MCP 上的事件草案规格。外部服务有新消息或状态改变时，会发送一笔签过名的通知给 ChatGPT。 * Grok Bot：其 Routine 功能也支持 Webhook 触发。每条 Routine 拥有一个专属网址，博主此前连接 Notion 留言的功能正是通过此路径实现。

“三家各走各的，方向卻一樣：讓 bot 有事才醒。我覺得這會是下一波個人助理的標配。”

Grok Bot 的主动性原理与供应商锁定风险

回到最初的问题：为什么 Grok Bot 看起来会主动收信？这是因为用户通过 Connector（连接器）将 Gmail 接入，Connector 提供了搜、读、寄信的通道。但仅连接并不足以触发主动响应。要让 Bot 在有新信时自动醒来，必须额外建立一条 Routine。

这条 Routine 可以设置为：当 GitHub Sentry 有动静，或有人向 Bot 的 Webhook 地址发送请求时，将其唤醒。事件触发后，Bot 醒来读取内容、整理并汇报。用户看到的只是最后一步的“主动回报”，其背后是一串事件在接力。

Grok Bot 甚至为每个用户提供了一个专属邮箱地址。当邮件发送到该地址时，即可触发 Routine 唤醒 Bot。这种“主动感”完全可以通过事件驱动自行构建：任何需要 Bot 立即知晓的事情，都可以为其安装一个“门铃”。

“信要能叫醒它。Grok Bot 多給一條路，每個用戶都能領一個 Grok Bot 自己的信箱。”

以申请账号为例：对方发送验证邮件，通常有时效性。如果 Bot 通过轮询在十几分钟后才查到，验证码可能已失效。收信、叫醒、点击验证是一个需要紧密接力的过程，事件驱动能确保这一链条的稳定性。

然而，随着“门铃”（Webhook/Event）的安装，供应商锁定（Vendor Lock-in）问题浮现。目前各家平台的门铃规格不统一： * ChatGPT 走 MCP Events * Grok Bot 走 Routine Webhook * Claude Code 有自己的 API

博主指出，如果用户每月更换不同的 AI Bot（如本月用 ChatGPT，下月换 Grok Bot），所有的通知连接都需要拆掉重装。这种高迁移成本导致用户被绑定在单一供应商身上。为了解决这一问题，博主开发了 PA Cafe（一间“小屋”），旨在让多个 Bot 共享通知源，实现事件来源与具体 Bot 的解耦。

PA Cafe：去中心化的通知中枢与 Herdr 集成案例

PA Cafe 的核心原理是“不需要动脑的事，先让电脑做掉”。接收通知、记录日志、判断该叫醒哪只 Bot 等逻辑，由普通程序执行。这些操作消耗的是廉价的 CPU 算力，而非昂贵的 AI Token。只有当真正需要阅读、判断或生成内容时，才唤醒 Bot。

这一思路与 AI 公司的内部优化策略一致：重复、固定的工作交给低单价算力，昂贵的模型留给关键步骤。例如 Anthropic 和 OpenAI 提供的批次 API（Batch API），将不紧急的任务放入队列处理，价格打五折。此外还有缓存机制（Caching）：Anthropic 的缓存读取最多只收取原价的一成。博主实测中，58,000 个 Token 里约有一半用于缓存读取。

在 PA Cafe “小屋”中，通知先进入中枢，再由中枢叫醒对应的 Bot。如果用户从 ChatGPT 切换到 Grok Bot，只需在内部更改通知派送目标，外部的 Webhook（门铃）无需任何改动。小屋还为 Personal Bot 提供了共用的整合能力： * 告示板：存放通用规则，所有 Bot 均可读取。 * 书柜：存储共用知识库和技能包，确保换 Bot 后上下文不丢失。

“小屋背後的原理很簡單。不需要動腦的事，先讓電腦做掉... 燒的是 CPU，不燒 token。”

博主展示了一个具体的自动化工作流组合：使用 Herdr 作为新一代的终端管理器（类似 tmux，专为 Coding Agent 优化），在其中运行 Codex、Claude Code 等编程助手。

Herdr 的特性包括： 1. 状态感知：识别每个窗格中的 Agent 是运行中、卡住还是已完成。 2. 断线重连：即使终端关闭或 SSH 断开，Agent 仍在后台运行。重新连接后画面恢复，工作继续。 3. 上下文保留：支持 Codex、Claude Code 等 Agent 的 Resume 指令，恢复之前的对话和代码位置。

然而，Herdr 自带的通知仅针对用户本人。如果 Bot 卡在“审批”环节（等待人工确认），Bot 本身无法感知，导致长时间空转。博主通过 Herdr 的 Webhook 插件解决此问题：当 Agent 完成或卡住时，发送通知至 PA Cafe 小屋，再由小屋叫醒负责追踪的 Bot（如 Grok Bot），实时向用户手机汇报状态。

事件驱动工作流实战与安全性考量

一个完整的事件驱动接力流程如下： 1. 编码阶段：Grok Bot 指挥 Codex/Claude Code（运行在 Herdr 中）写代码。 2. 审批阶段：Agent 执行指令（如 npm run deploy）时若需人工批准，Herdr Webhook 插件触发通知。PA Cafe 叫醒 Grok Bot，Grok Bot 向用户手机发送：“Codex 要跑 npm run deploy，要放行吗？” 3. 审查阶段：代码推送到 GitHub 并创建 PR。GitHub Webhook 发送事件，PA Cafe 叫醒负责 QA 的 Bot（如 ChatGPT）进行代码审查。 4. 部署阶段：QA Bot 合并 PR。GitHub Webhook 再次触发，通知负责部署的 Bot。 5. 监控阶段：上线后，错误监控系统（如 Sentry）若触发告警规则，发送 Webhook 通知。Bot 被叫醒检查是否为本次上线引入的新错误，并决定是否回滚。

“這幾隻 bot 也可以來自不同家。指揮寫程式的是 Grok Bot，做審查的換成 ChatGPT 也行。”

在这个流程中，每一棒都由上一棒的事件叫醒，没有任何 Bot 在排程空等。用户无需反复询问进度。

对于没有原生 Webhook 的服务，PA Cafe 的原理依然适用：编写一个普通程序进行轮询（如每五分钟抓取一次），与上次结果比对。若无变化，继续休眠；若有变化，再叫醒 Bot。轮询依然存在，但消耗的是便宜的 CPU 而非昂贵的 Token。

在实施 Webhook 时需注意两个安全问题： 1. 伪造请求：多数 Webhook（如 GitHub、OpenAI MCP Events）采用签名机制。GitHub 使用用户设定的密钥计算签章；OpenAI 的 MCP Events 遵循 Standard Webhooks 规范。接收方需先验证签名，无效则丢弃。 2. 消息丢失：Standard Webhooks 规范支持重试机制，每次重送携带同一编号。接收方需记录已处理的 ID 以避免重复执行。

博主建议采取混合策略：平时依赖事件驱动，同时保留一条极低频率的排程（如每天一次对账）作为备援，以捡漏可能遗漏的通知。

结论

本视频详细阐述了从传统轮询（Polling）向事件驱动（Event-Driven/Webhook）架构转型的必要性。核心论点在于：轮询机制导致 AI 助理在等待未知事件时产生巨大的 Token 浪费（如每5分钟一次即每天288次空转），而事件驱动通过“有事才醒”的机制，实现了零空闲成本与即时响应的双重优势。

视频指出当前各 AI 平台（ChatGPT、Grok Bot、Claude Code）虽均支持事件触发，但标准不一导致严重的供应商锁定（Vendor Lock-in）问题。为此，博主提出了 PA Cafe 作为去中心化的通知中枢解决方案，通过分离“通知接收”与“AI 处理”，利用廉价 CPU 算力预处理逻辑，仅将高价值判断交给 AI Model。结合 Herdr 等终端管理工具与 Webhook 插件，博主展示了一个涵盖编码、审批、审查、部署及监控的全自动化事件接力工作流。最终建议用户审视现有排程，将等待未知事件的轮询任务替换为事件驱动架构，并辅以低频备援排程以确保稳定性。