攝影機偵測到活動時，通知不一定只能送到 LINE、Email 或另一個專用 App。現在 OpenAI 的 MCP Events 已提供另一種路徑：讓 MCP server 對已訂閱的事件發送 webhook，由 ChatGPT 或 Dot 在指定的對話與任務裡接續處理。
我把 C230 攝影機事件接到 Dot，驗證過一筆真實事件連同兩張私有圖片附件抵達。這是一次端到端成功樣本，不代表每次通知都穩定觸發；後續也出現 webhook 收到 HTTP 200、Dot 卻沒有啟動任務的情況。這個差異，正好說明 Agent as Interface 不只要能收到訊息，還必須把「事件送達」一路驗到「Agent 執行」和「使用者看見」。
這裡的 webhook，不是 OpenAI API 的 Webhooks
OpenAI 文件把這項能力稱為 MCP Events。MCP server 公開可訂閱的事件，ChatGPT 呼叫 events/subscribe 時提供 webhook callback URL 與簽章密鑰；來源系統出現符合條件的事件後，MCP server 將事件送往 callback。官方文件明確列出 Dot 為可測試的客戶端之一。OpenAI MCP Events 文件
這與 OpenAI API 的 Webhooks 是不同方向：API Webhooks 是 OpenAI 把 API 作業狀態通知到開發者端點；這裡則是外部系統經由 MCP Events，把已訂閱的事件送進 ChatGPT／Dot 的對話任務。C230 使用的是後者。
資料流可以簡化為：
``text C230 攝影機／ONVIF → Raspberry Pi 事件接收與耐久佇列 → Cloudflare Worker / Durable Object 保存事件與媒體 → MCP Events 訂閱篩選與簽章 webhook 投遞 → ChatGPT／Dot 的訂閱任務 → 使用者看到通知、文字與可開啟的圖片附件 ``
關鍵轉變是：通知目的地不再只是「某個聊天室」，而可以是理解事件、讀取相關資料、依照任務指示採取下一步的 Agent 入口。這讓 Dot 有機會成為 Agent as Interface 的一個接收面；它不是 MCP server 本身，也不會自動替每種通知完成後續工作。
MCP Events 的實作面：事件定義、訂閱與簽章投遞
依 OpenAI 公開文件，MCP Events 使用 MCP 2026-07-28 protocol version，伺服器需在能力探索中宣告 events，並提供三個方法：events/list、events/subscribe、events/unsubscribe。events/list 描述可用事件、篩選參數與 payload schema；events/subscribe 建立或更新訂閱；取消時則以 events/unsubscribe 停止投遞。MCP Events 規格與生命週期
訂閱不是只有一個 callback URL。伺服器還要驗證登入使用者是否有權監看該事件、檢查過濾條件、驗證 callback、保存訂閱擁有者與有效期限，並讓重複的訂閱請求具冪等性。Webhook 使用 Standard Webhooks 風格簽章；webhook-id 應對應事件 ID，搭配時間戳、簽章與 subscription ID。事件 ID 在重試時保持不變，方便接收端辨識重複投遞。OpenAI 的訂閱與簽章要求
還有一個容易誤判的地方：HTTP 2xx 只表示 callback 收到 webhook；Dot 的任務是在之後非同步處理。 因此，監控至少要分開記錄 subscription 建立、事件投遞、callback 回應、Dot 任務執行與使用者可見通知。MCP Events 文件也提醒事件可能亂序、可能重複；暫時性失敗要有限次退避重試，會改動資料的工具要能冪等，不能把 webhook 說成 exactly-once。OpenAI 的投遞與重試說明
C230 → Dot：已驗證的路徑與尚未關閉的缺口
C230 Event Bridge 把攝影機的 ONVIF 活動整理成事件，由 Raspberry Pi 的 durable outbox 保留，再交給 Cloudflare Worker。Worker 將事件 metadata 存入 Durable Object，圖片存放於 private R2；MCP 同時提供事件查詢與圖片讀取能力，事件訂閱則走獨立的主動推播路徑。查詢（pull）和推播（push）是兩個產品面：能查到事件，不代表訂閱有效或通知已送到。C230 專案紀錄
2026 年 10 月 14 日的一筆 canary，從 RPi／ONVIF 記錄事件，到 Worker 對 OpenAI webhook 投遞 HTTP 200，相差約 45 秒；Dot 收到同一事件，並顯示兩張可開啟的 JPEG 私有附件。這證明當時有一條真實端到端路徑成功，不是只在本機測試 webhook，也不是用歷史查詢假裝即時推播。C230 驗收紀錄
同一天稍晚，新的主動推播驗收補上了重要證據：2026 年 10 月 18 日 21:21:39（台北時間）發生一筆 motion 事件；21:23:06 的 Dot 對話訊息標記為 MCP event 觸發並回報收到實際 webhook payload；21:23:34 又出現另一筆 MCP event 觸發訊息，附上 best 原始 JPEG 並回報圖片通知成功。這是「指定事件 payload 已抵達 Dot，圖片通知也完成」的單筆真實驗收，不能外推成其他漏接事件都已補送、影像已辨識出人或動物，或服務已證明持續可靠。C230 主動推播成功驗收
更早在 10 月 18 日 20:43 左右，另兩筆事件曾被 Worker 記為 HTTP 200／delivered，但當時查到 Dot 最近執行仍停在 10 月 14 日。後來訂閱於 21:14 更新，21:21 發生的事件隨後通過上述 Dot／圖片驗收。這證明更新後至少有一筆新事件成功觸發；時間先後本身不足以證明訂閱更新就是根因修復。HTTP 200 仍不能單獨當成使用者已收到通知。較早的訂閱診斷與本次成功驗收
這次實作也把幾個工程邊界固定下來：事件資料先耐久保存再確認接收；以穩定 UUID 去重；敏感圖片保持私有、只透過受控工具讀取；事件查詢與即時推播分開驗收；每次都要從真實 Dot 任務確認附件與通知是否可見。10 月 14 日的樣本約 45 秒到 webhook 接受；10 月 18 日的最新驗收則記錄到事件發生、Dot 收到 payload 與原始 JPEG 通知的時間點。兩筆是不同日期、不同事件與不同量測區間，不能混成同一個延遲指標；現有資料仍不足以推估 P95／P99 或持續可靠度。C230 延遲與驗收紀錄；C230 主動推播成功驗收
Dot 能不能成為集中通知窗口，甚至取代 LINE？
我希望逐步把需要 Agent 理解、整理或接續處理的通知集中到 Dot。長期來看，它有機會取代部分 LINE 通知窗口：使用者不必只收到一句「偵測到活動」，而可以直接在同一個 Agent 入口追問事件、讀取圖片、整理摘要，再依個人規則決定下一步。這是產品方向與實作假設，不是已完成的 LINE 全面替代，也不是 OpenAI 承諾的通知服務等級。
適合優先搬過去的，會是可以延遲處理、需要語意理解或需要後續查資料的通知。需要立即打斷、多人群組協作、外部客戶觸達，或有明確送達 SLA 的告警，則仍要依風險保留 LINE、簡訊、電話或原有監控通道。即使某次 webhook 回 200，也應再確認 Dot 是否執行；關鍵告警還要有事件紀錄、重試、人工升級與替代通道。
OpenAI 官方文件把 MCP Events 定位為一種可設定的事件訂閱能力，並建議完整測試訂閱、callback 驗證、實際投遞、任務回應、取消訂閱、重複事件與失效情境。社群已有開發者分享以 Python MCP SDK 與 ChatGPT 進行端到端測試的經驗；這證明有人在實作與討論，不能推論整個社群已普遍採用。OpenAI 開發者社群的端到端測試討論
Agent as Interface 不只是換一個收件匣
把訊息集中到 Dot，若只把舊通知原封不動搬進新視窗，價值有限。更重要的設計是讓通知帶著穩定事件身分、可查證來源與必要上下文進來；Dot 根據使用者事先交代的任務指示，知道該讀哪些資料、何時只提醒、何時整理，哪些動作必須先詢問。事件文字本身仍是外部資料，不應被當成可以覆寫 Agent 規則的指令。
對我而言，C230 的意義不只是在 Dot 顯示攝影機通知，而是把實體世界的事件接進一個可持續互動的 Agent 入口。下一步不是宣布已經能取代 LINE，而是先讓訂閱存續、Dot 任務觸發、附件可讀與使用者通知都能逐層觀測，再以足夠的真實事件樣本評估可靠度與延遲。Agent as Interface 要成立，通知抵達只是入口；任務結果能被理解、驗證與接續，才是體驗。
若要看這條路徑如何放進更完整的個人脈絡與任務循環，可接著閱讀Personal Context → Agent Experience與No App 不等於沒有 App。