Hello，大家好，我是人蔘。你用 Grok Bot、dots 這類 AI 助理，有沒有遇過這種時刻？信一進來，它就主動跑來跟你說：「順便把事情處理掉。」看起來很聰明，像有人一直幫你盯著信箱。它背後靠的是一個很老的觀念，叫事件驅動。這集我想從頭講清楚，因為它直接決定你的 token 燒多快，也決定 bot 回你回得多及時。
先講最直覺的做法。你想讓 bot 幫你顧信箱，最簡單就是排程：每隔五分鐘叫它去看一下有沒有新信。這招叫輪詢（polling），就是一輪一輪去問。以前在電腦上跑排程，幾乎不用想成本；一支小程式每分鐘跑一次，花的是 CPU。電腦本來就開著，換成 AI 助理就不一樣了。
像你叫 Grok Bot 每隔一段時間去 X（Twitter）看某個帳號有沒有發新文，它每醒來一次，都要讀指示、呼叫工具、把結果撈回來看。每一步都在花 token，就是 AI 讀字、寫字的計費單位。用越多越貴，就算沒有新東西，這一輪照樣要付。
算一下就知道：每五分鐘一次，一天就是兩百八十八次。假設你一天只來三封重要的信，剩下兩百八十五次都是醒來看一眼空信箱。我自己實際量了一次：用 Codex 跑一輪最簡單的檢查，讀一個信箱檔看有沒有新信。它最後回我四個字：「沒有新信。」
可是這一輪，輸入就吃了大約五萬八千個 token。為什麼這麼多？我看主要是它每次醒來，都要先把自己的指示、工具說明整包重讀一遍才開始做事。要做的事很小，開機的成本很大。照這一輪推算，乘上兩百八十八次，一天大概一千六百多萬個 token。大部分花在「沒有新信」。
那排鬆一點，一小時看一次？省是省了，可是信進來之後，最久要等快一個小時它才知道。排密燒 token，排鬆消息慢；輪詢就卡在這兩邊。事件驅動把方向倒過來：bot 平常睡覺，信箱那邊一有新信，就主動按門鈴把它叫醒。沒事的時候，它一個 token 都不花。
其實你的手機每天都在用這套：聊天 app 來訊息，是對方的伺服器透過手機系統的推播通道送過來。手機平常就安靜等著，有訊息才亮。說它老是真的老：一九五〇年代初期電腦就有中斷這個設計，到現在你按一下鍵盤也是這樣。
鍵盤會主動送一個訊號給 CPU 先停下手上的事去處理，處理完再回來。沒有中斷的話，CPU 就得一直繞圈去問鍵盤：「有沒有按？」七十年後 AI 助理又遇到一模一樣的問題。這個門鈴，技術上通常就是 webhook：你給對方一個網址，對方有事的時候往這個網址打一筆通知過來。
裡面帶著發生了什麼。bot 被叫醒，直接拿到這筆資料開工。所以同一件事，事件驅動同時拿到兩個好處：信一來就處理，比排程快；沒信就不醒，比排程省。排程還是有它的位置：每週一早上整理上週數字、每天早上看行程，這種本來就是固定時間要做的事，交給排程剛好。
不知道什麼時候會來的事，交給事件。輪詢跟門鈴中間還有幾種做法：第一種叫長輪詢（long polling）。你去問有沒有新東西，對方不馬上回先把這個請求掛著，等有東西了才回你。你通常再馬上問下一次。
再進一步就是一直開著一條連線：WebSocket 是雙向的，兩邊隨時都能講話；SSE（Server-Sent Events）是單向的，伺服器有新東西就往下推。網頁上的聊天、即時更新很適合這兩種。這幾種都要接收的那一端一直開著連線，bot 的模型不會一直開著等。
所以實務上，是讓一般程式或平台先接住通知再用門鈴叫醒 bot。這件事各家其實做一陣子了：Claude Code 的雲端排程任務以前叫 routines，除了排時間也能用 API 呼叫或 GitHub 事件觸發（PR 一開它就醒過來）。最近 OpenAI 在推 MCP Events，它是 MCP 上的事件草案規格。
外部服務有新訊息、狀態改了就打一筆簽過名的通知給 ChatGPT dots，也支援這套。Grok Bot 的 routine 也有 webhook 觸發：每條 routine 一個專屬網址。我之前那集接 Notion 留言就是走這條。三家各走各的，方向卻一樣：讓 bot 有事才醒。我覺得這會是下一波個人助理的標配。
回到開頭那個問題：Grok Bot 為什麼好像會自己幫你收信？你用 connector（連接器）把 Gmail 接上去。connector 就是讓 bot 連進你信箱的通道，接好之後它能幫你搜信、讀信、寄信。可是光接上去，新信到了它不會自己醒；要它有事就醒，得再建一條 routine。
可以設成 GitHub、Sentry 有動靜，或是有人打它的 webhook 就把它叫起來做事。事情一發生 routine 被觸發，bot 醒過來讀內容、整理跟你回報。你只看到最後回報那一步，所以覺得它很主動；它的主動靠的是後台一串事件在接力。
信要能叫醒它，Grok Bot 多給一條路：每個用戶都能領一個 Grok Bot 自己的信箱，跟它說一聲就開好了。再建一條 routine：信寄到這個信箱就會叫醒它。這種主動感，你自己就能做出來。哪件事要讓 bot 馬上知道？就幫它裝一個門鈴。
為什麼 Grok Bot 的信箱要接 routine？像它幫你申請帳號，對方寄來一封驗證信。驗證信通常有期限，要是它過了十幾分鐘才去查，信可能已經失效這一步就卡住了。收信、叫醒、去點驗證是一段要接力的過程，這種事交給事件最穩當。
可是門鈴一裝下去問題就來了：每一家的門鈴規格都不一樣。dots 走 MCP Events，Grok Bot 走 routine webhook，Claude Code 又有自己的 API。我自己是輪流用的：額度用完就換下一隻。每換一隻，Notion、Gmail 這些通知就要重接一次。
這個月訂 dots，下個月想換 Grok Bot？門鈴全部得拆掉重裝。通知綁死在某一家 bot 身上，這就是 vendor lock-in（供應商鎖定）：你想換成本高到懶得換。這就是我做 PA Cafe 這間小屋的原因：小屋是讓好幾隻 bot 住在一起，共用通知的地方。
通知先進小屋，小屋再叫醒該接的那一隻：事件來源跟 bot 本身分開。小屋背後的原理很簡單，不需要動腦的事先讓電腦做掉：收通知、記下來、挑出該叫醒的那一隻。這些都是一般程式在跑，燒的是 CPU 不燒 token；真的要讀、要判斷、要寫的時候才叫醒 bot。
我看這些 AI 公司的內建機制也是同一個思路：重複、固定的工作交給單價比較低的算力去跑，貴的模型留給真正需要它的那一步。就算要輪詢也是讓一般程式去輪，輪到有事才叫醒模型。舉兩個公開的價格：Anthropic 跟 OpenAI 都有批次 API，不急著要答案的工作丟進去排價格打五折。
還有快取：同一段指示重複讀，Anthropic 的快取讀取最多只收原價一成。我剛剛量的那一輪五萬八千個 token 裡，大約一半就是快取讀的。Notion 的留言、Herdr（這個跑 coding agent 的終端機），它們的通知接到小屋一次就好。
今天住在小屋的是 dots，下個月換成 Grok Bot？只要把通知改派給新的那隻，外面的門鈴都不用動。小屋也替這些 personal bot 做了共用的整合：告示板貼一則規矩，店裡每一隻都收得到；書櫃放共用的知識頁跟技能包，派工的時候附進去。換哪一隻接手都讀得到。
未來不管哪一家出新的個人助理，只要它能被叫醒就能住進來：bot 可以換，小屋一直是你的。來看一個我自己在用的組合：我讓 Grok Bot 去指揮 Codex 或 Claude Code 寫程式。這些 coding agent 都開在 Herdr 裡，一次可以跑好幾隻各做各的。
先多講兩句 Herdr：你可以把它想成新一代的 tmux，專門為 coding agent 優化。它認得每個窗格裡的 agent：現在是在跑、卡住還是做完了？終端機視窗關掉、SSH 斷線，裡面的 agent 照樣在背景跑；重新接上畫面就回來工作一直沒停。
就算電腦關機重開之後，它會把原本的工作區、分頁還有每個窗格開在哪個資料夾原樣排回來。像 Codex、Claude Code 這種有接 Herdr 整合的 agent，它還會用各自的 resume（恢復）指令把原本那段對話接回來：正在跑的指令會停掉，對話跟位置都還在。
昨天聊到一半的工作今天開機可以接著聊。Herdr 很貼心，agent 做完或卡住它會叮一聲跳通知。問題是這個「叮叮叮」是叮你的，你人不在電腦前 bot 也聽不到。我最常遇到的卡法是審批：agent 要跑一個指令跳出來問你准不准，就停在那裡。
bot 不知道它卡住了，過了兩個小時你去問 bot：「怎麼還沒做完？」它才去看回你一句：「卡在審批。」要嘛就叫 bot 每十分鐘自己去看一次，又繞回輪詢。Herdr 有外掛可以接 webhook：agent 一做完、一卡住，外掛就打一筆通知出去。我把它接到小屋，小屋再叫醒負責追這件事的 bot。
卡在審批？bot 馬上跟你回報問你要不要放行；做完了它就接著下一步。在小屋裡這一段長這樣：外部來源接了 Herdr 最近事件寫著「Codex 卡住等你審批」。Grok Bot 接手之後馬上傳到你的手機：「Codex 要跑 npm run deploy，要放行嗎？」
程式寫完推上 GitHub開了一個 PR。GitHub 本身就有 webhook，PR 一開就發事件；這一棒交給另一隻負責 QA（品質保證）的 bot。它被叫醒去做審查，審完合併；合併也是一個事件接著部署。每次部署狀態有更新 GitHub 也會發通知，下一隻 bot 一收到就知道輪到它了。
上線之後還有一隻 bot 在顧：錯誤監控服務像 Sentry，告警規則一觸發就能打 webhook 出來。bot 被叫醒去看是不是這次上線帶進來的新錯誤，判斷要不要退版再跟你回報。這幾隻 bot 也可以來自不同家：指揮寫程式的是 Grok Bot，做審查的換成 dots 也行。
大家都住在小屋：事件進小屋再派給對的那一隻。從寫程式、審批、審查、合併、部署到上線監控，每一棒都是被上一棒的事件叫醒的。沒有哪一隻在排程空等，你也不用一直追問做完了沒。這整條接力就是靠事件驅動串起來的。
有些服務沒有門鈴？那就回到小屋那個原理：寫一支一般程式去輪，它每五分鐘抓一次跟上次比對。內容沒變就繼續睡，有變才叫醒 bot。輪詢還在但燒的是 CPU；這種小程式很便宜放在自己電腦的排程或 GitHub Actions 的定時工作都能跑。bot 只在真的有事的時候出場。
門鈴裝了也要顧：第一個問題，有人假冒按鈴怎麼辦？多數 webhook 會簽名或帶一把金鑰。GitHub 用一把你設定的密鑰算簽章放在通知裡；OpenAI 的 MCP Events 用 Standard Webhooks（標準網頁回呼）這套規格簽名。收到的一方先驗簽，對不上就丟掉。
我接小屋用的 Herdr 通知外掛送出去的通知也照 Standard Webhooks 簽名。第二個問題：通知沒送到？照 Standard Webhooks 的規格送不到就重送，每次重送都帶同一個編號。收的一方記住處理過的編號，同一件事就不會做兩次。
GitHub 比較特別：送失敗的通知不會自動重送，要你自己去補送。所以我看比較穩的做法是混著用：平常靠事件再留一條很稀的排程當備援，比如一天對帳一次把漏掉的撿回來。所以如果你的 bot 一直在燒 token，先翻一下你的排程：哪幾條其實是在等一件不知道什麼時候會發生的事？
那幾條就換成事件。翻排程的時候問自己三件事：這條排程在等什麼？等的那件事有沒有門鈴？沒有門鈴的話能不能先讓一般程式去輪，有變化才叫醒 bot？如果你也想讓 bot 有事才醒就去 PA Cafe 開一間自己的小屋，網址在畫面上也放在說明欄。
免費就能開始：先讓兩隻 bot 住進來，把 Herdr、Notion、GitHub 的通知接進小屋。之後 bot 想換哪一家門鈴都不用重裝。你現在讓 bot 每隔多久醒一次？有沒有哪一條排程你懷疑它一直在空轉？喜歡這集的話記得幫人蔘按讚、訂閱、分享，再留言跟我說你的排程。我們下集見。