排程任務、內送 Webhook、CI 回呼與幕等
小型團隊已能運行 OpenClaw Gateway，但未必部署 Slack 式即時通訊，仍須以 排程巡檢、內送 Webhook、CI 結論 驅動自動化。本文界定三類觸發器、驗證與幕等對照表，以及可貼入值班 wiki 的 六步驟 Runbook。結尾整理常見正式環境數值錨點，並說明何時將工作負載放在代管 Mac 節點可降低維運阻力。
聊天頻道隱含「誰在何串流發言」的脈絡；純 HTTP 與排程若未事先寫入契約就會失去這層資訊。上線前請檢視下列失效模式：
重複投遞讓副作用執行兩次：CI 平台與 Webhook 轉送常因逾時重試。沒有幕等鍵與去重視窗時，同一工作成功可能被執行兩次。
驗證薄弱：秘密網址會從記錄檔與代理外洩。至少改為標頭密鑰、HMAC 或 mTLS。
排程撞上維護：常駐節點修補時排程仍觸發，處理常式可能處於半初始化狀態。
跨區順序迷思：先收到不代表先發生；請攜帶事件時間與單調序號。
可觀測性過薄：沒有請求識別、上游工作識別與幕等指紋，工單無法對應到伺服器記錄。
把觸發器當成產品需求：延遲敏感度、一致性需求與可接受漂移，決定排程、Webhook 或 CI 回呼。
| 觸發器 | 常見用途 | 優勢 | 主要風險 |
|---|---|---|---|
| 排程脈衝 | 健康掃描、日彙總、暫存資料清理 | 負載可預測、維運單純 | 與真實事件脫鉤；維護期應暫停 |
| 內送 Webhook | 工單掛鉤、核准、監控 HTTP 匯出器 | 貼近業務事件、近乎即時 | 重複、偽造寄件者、TLS 與代理複雜度 |
| CI 終端回呼 | 建置後簽章、釋出閘道 | 與成品綁定強 | 平台重試不透明；承載版本漂移 |
實務搭配
須單次生效的副作用請用 Webhook 或 CI 回呼加上具幕等的儲存；唯讀彙總 才留給排程。Gateway 面向公網時，請在邊界終止 TLS 並縮小監聽範圍；基線檢查請依 安裝與 Gateway 疑難排解檢查清單。
依序執行：先驗證再放大流量。密鑰命名請對齊金鑰庫政策。
凍結契約：JSON 必含 event_time、source、job_id、idempotency_key、payload_version；無版本之未知承載一律拒絕。
在邊界驗證：於反向代理驗證 Authorization 載具或 HMAC，並設 IP 允許清單；Gateway 只信任內部跳點。
加入幕等儲存：以 idempotency_key 為主鍵並設 TTL（CI 形事件常為 24–72 小時）；重複 POST 回傳相同業務語意。
維護期關閉排程閘道：用旗標檔或鍵值閘道；維護啟用時提早結束並寫心跳記錄。
串接可觀測三元組：每個入口產生 request_id、於回應標頭回傳，並在記錄檔寫入 job_id 與雜湊後的幕等鍵。
對重試做混沌測試：連送三筆相同 POST、斷上游三十秒後復原，確認無雙重副作用且告警分頁正確。
curl -sS -X POST "https://gateway.example.internal/hooks/ci" \
-H "Authorization: Bearer ${HOOK_SECRET}" \
-H "X-Idempotency-Key: ${CI_JOB_ID}-${CI_CONCLUSION}" \
-H "X-Request-Id: $(uuidgen)" \
-H "Content-Type: application/json" \
-d '{"payload_version":1,"job_id":"'"${CI_JOB_ID}"'","conclusion":"success"}'
僅內網與公開入口的威脅模型不同；用此表快速對齊審查者。
| 模式 | 適用 | 必設項目 |
|---|---|---|
| 共用密鑰與 TLS | 私有網路或零信任通道 | 輪替密鑰；回應內不回顯密鑰 |
| HMAC 簽章 | 公開 Webhook、多上游 | 時間戳視窗約 ±300 秒；常數時間比對 |
| mTLS | 企業 CI 至控制平面 | 短命葉憑證輪替與撤銷 |
幕等鍵形狀。 建議 {source}:{stable_id}。僅用毫秒會讓重試立刻破壞去重。
勿將原始密鑰寫入記錄檔。 只存雜湊或帶前綴的識別碼，別把記錄軟體供應商變成第二爆炸半徑。
下列區間彙整常見正式環境做法；請依 SLA 調整，勿視為廠商保證。
自行代管排程器與筆電可行，直到睡眠、不穩定的家用網路與系統升級讓排程與 Webhook 卡在半成功狀態。把 Gateway 與入口放在 VpsMesh 常駐 Mac Mini 雲端節點，通常能穩定對外 IP、維護視窗與硬體隔離，讓非即時通訊自動化從腳本嗜好走向對值班友善的閉環。