OpenClaw 在使用者眼中應是一個連貫的智能體，但閘道背後要協調 多套聊天 API，各自重試語意不同。2026 年，許多看起來像「模型發瘋」的事故其實是 Webhook 雙重投遞 或主通道中斷卻未演練備援路徑。本矩陣為 Slack、Telegram、Discord 排序故障轉移，定義冪等鍵，並給出八條可在 NodeMac 專用 Mac mini M4 上重現的步驟（SSH 自動化、一次性權限用 VNC，節點涵蓋 HK、JP、KR、SG、US）。
基線整合：Slack 與 Discord Webhook、多模型故障轉移與逾時、狀態目錄與無頭閘道清單。健康：就緒探針；診斷：doctor。定價：定價；說明：說明。
你真正在除錯的故障模式
當閘道 HTTP 回應慢時，聊天供應商會積極重試。若工具副作用（工單、發布、退款）非冪等，重試會變成重複事故。另方面，Socket Mode 或長輪詢在筆電睡眠、Wi‑Fi 切換或企業 TLS 中間盒時會中斷——在固定雲 Mac 與穩定出口上往往消失。
- 至少一次投遞 是預設假設——請依此設計。
- 人工升級 應在去重儲存不可用時繞過自動化。
- 跨發 同一智能體回覆到兩個主通道會混淆稽核軌跡。
通道層級矩陣
| 通道 | 2026 最佳角色 | 故障轉移注意 |
|---|---|---|
| Slack | 企業團隊主通道；豐富串文 | Socket Mode 權杖需依文件日曆輪換 |
| Telegram | 個人機器人快；良好備援廣播 | 群組隱私模式會改變提及語意——以真實群組測試 |
| Discord | 面向社群的智能體；Webhook 扇入 | 每公會速率限制不同；分片告警 |
冪等與重放矩陣
| 入站模式 | 去重鍵配方 | TTL 提示 |
|---|---|---|
| Slack Events API | 雜湊 event_id + team_id |
至少 24 小時 |
| Telegram updates | 每機器人 update_id |
若可能長時間離線維護則 48 小時 |
| Discord interactions | 互動負載 id + 公會 id |
除非代理更長重試，否則 12 小時 |
儲存提示：將去重狀態放在與 OpenClaw 狀態目錄相同的非同步卷上，以便 launchd 下 SQLite 或檔案鎖行為一致。
八步上線路徑
- 宣告層級：一頁架構說明含負責人。
- 實作去重儲存，帶命中率與逐出指標。
- 重播測試：每通道在預發儲存負載重播兩次。
- 增加斷路器：備援通道也出錯時——對人類 fail closed。
- 記錄關聯 ID：貫穿閘道、工具呼叫與出站聊天回覆。
- 自動化權杖輪換：Slack Socket Mode 每季演練。
- DNS 阻斷演練：針對主供應商 API。
- 記錄凍結開關：停止工具執行而不刪設定。
常見問題
Slack 與 Discord 是否都應為主？
否——自動工具執行只選一個主通道；另一個用於通知或降級模式。
好的去重鍵是什麼？
穩定提供商 ID 加工區或公會範圍，雜湊後以超出重試視窗的 TTL 儲存。
為何用專用 NodeMac Mac？
長連線上線時間、可預測路徑、與使用者及 API 鄰近的區域放置。