2026 OpenClaw 通道接入實務
Slack／Discord／Telegram 權限、OAuth 與「能連但不回」分症狀排查清單

先把「像連上卻沒反應」拆成六類通道症狀

通道問題常被誤報為「模型壞了」或「compose 網路又炸了」。在改映像或調 network_mode 之前，先用下列標籤描述現象，並與《Docker 網路分診》中的症狀表對照，避免兩條線同時改動無法復盤。

1. 入站事件缺失：應用程式後台顯示上線，但頻道裡新訊息不會觸發任何 Gateway 日誌行；多見於 Slack 事件訂閱未開、Discord Gateway intent 不足，或 Telegram 隱私模式擋住群組對話。
2. 只收私訊不收頻道：OAuth scope 或 Bot 加入策略只涵蓋 DM，頻道訊息被靜默丟棄；需在各平台檢查 channel 清單與 bot 成員身分。
3. 能解析指令但不回覆貼文：入站日誌有，回覆路徑被 groupPolicy、thread 策略或「僅同步已提及」類規則擋住；日誌裡常出現路由到空 agent 或權限拒絕。
4. 間歇性 OAuth／token 過期：主控台全綠，幾小時後突然全紅；多見於 refresh token 輪換未寫回金鑰庫，或容器重啟後未掛載同一 .env。
5. 多工作區／多 guild 串線：同一程序綁了多個 Slack workspace 或 Discord server，設定合併錯誤導致訊息路由到錯誤回呼 URL。
6. 模型層誤傷：通道層其實正常，但上游 429／5xx 讓使用者以為「機器人死了」；必須看 Gateway 與 provider 日誌占比，並回到《provider 降級篇》。

把這六類與「最近是否改過 allowedOrigins、是否滾動過映像」寫在同一變更單上，值班同仁才能在五分鐘內選對分診分支。

表 1：三層分診——Gateway、通道、模型誰先該負責

下列表格是「先看哪一層」的決策矩陣，不是互斥結論；每一格都應對應一條可執行的下一步指令或日誌關鍵字。實務上建議先在紙上畫三條豎線：左側寫「使用者端可見現象」，中間寫「Gateway 日誌裡最先出現的異常類型」，右側寫「是否出現上游模型 HTTP 狀態碼」。只要中間欄長期空白，就不要急著改 provider；若右側先出現大量 429，則通道 OAuth 再授權十次也救不了帳單。

與《Docker 網路分診》配合閱讀時，可把「容器內 channels 探針失敗」視作第 0 層：先確認同一 compose 網路裡 CLI 能打到 Gateway，再進入下表；否則你會在 Slack 後台看到永遠健康的 webhook 紀錄，卻在宿主機上面對無止境逾時。

三條應寫進監控面板的通道 KPI

下列指標把「感覺機器人卡了」拆成可告警的數值；口徑應與 Gateway 既有日誌欄位對齊。建議以小時桶聚合，而不是秒級抖動，否則夜班會被無意義告警淹沒。

1. 入站事件率（IER）：單位時間內通道層確認收到的事件數除以業務端傳送次數；長期低於 0.9 優先查 OAuth 與訂閱，而不是 GPU。
2. 路由命中率（RHR）：成功綁定到目標 agent 的入站占比；若下降而 IER 正常，表示策略或頻道對應已腐化。
3. 回覆完成率（RCR）：從入站到模型回傳 200 的端到端比例；若 IER、RHR 均高而 RCR 低，模型層優先。

社群文件在 2026 年仍強調 openclaw channels status --probe 一類探針；把探針結果與上述三率放在同一面板，可避免「重連一下就好」的不可重現操作。若你們已在《Gateway 健康檢查與滾動更新》裡設定了 HTTP 探針，請確認探針 URL 與通道回呼實際經過的反向代理路徑一致：探針只打 loopback 而公網回呼走另一憑證鏈時，會出現「監控全綠、使用者全紅」的經典錯位。

補充一條人工對照口徑：每週隨機抽十則使用者訊息，核對「平台端訊息 ID → Gateway request ID → 模型 trace ID」是否能在三處日誌裡閉環；若任一環缺失，表示結構化日誌欄位未對齊，優先修欄位再談擴容。

六步 Runbook：從探針到可回滾的授權變更

1. 凍結變更範圍：紀錄目前映像標籤、環境變數雜湊與最近三次 compose 變更；通道問題常與滾動發佈同日出現。若同日還改過 allowedOrigins 或 TLS 憑證，請在變更單上明寫「回滾到上一憑證指紋」的步驟，避免 OAuth 回呼與 CORS 同時壞掉。
2. 跑 Gateway 基線：確認本機或容器內 gateway status 與《doctor 篇》中的健康檢查一致。若使用 systemd 或 launchd，請核對重啟策略：頻繁重啟會把通道 WebSocket 打到平台端頻率限制。
3. 依平台逐項授權：Slack 重走 OAuth，核對 scope；Discord 勾選必要 intent 並重新邀請 bot；Telegram 用 BotFather 關閉隱私模式或確保群組 @bot。授權完成後等待平台端快取失效視窗（常見 5–15 分鐘），不要連續點十次重新授權製造限流。
4. 驗證最小對話：各平台用單一頻道、單一 agent、無額外策略重現一次 ping-pong，再恢復 groupPolicy。建議把測試訊息加上固定前綴，便於在日誌裡 grep，而不是在千人頻道裡洗版。
5. 對照模型層：若 ping-pong 仍失敗，擷取 30 秒日誌統計 429 占比，再決定是否切換 provider。若 429 集中在某一 key，請檢查是否誤把消費級方案金鑰當成按量計費 key 混用。
6. 寫回維運筆記：把 token 輪換策略與金鑰存放路徑寫進與《Docker 網路篇》同一個儲存庫，避免「只有某人電腦能發佈」。對外部協作者只給最小 scope 的唯讀 token，主金鑰仍走內部 KMS 或 sealed secret。

Slack／Discord／Telegram 快速檢查表（平台差異一頁收）

下列檢查項應與各平台官方主控台對照執行；不要依賴截圖過期的「權限清單」。若團隊同時維護 staging 與 production 兩個 workspace，請把回呼 URL 主機名稱寫成表格裡的獨立欄，避免 staging 憑證被誤綁到 prod DNS。

• Slack：App 級 token 與 bot token 是否同時有效；事件訂閱 URL 是否指向目前可從公網存取的 Gateway；Socket Mode 與 HTTP 模式是否混用導致雙重訂閱。若使用 Enterprise Grid，請確認每個 workspace 的安裝紀錄是否都指向同一 OAuth client，否則會出現「有的區能收、有的區收不到」。
• Discord：Message Content Intent、Server Members 等是否與真實讀訊息需求一致；bot 是否在目標頻道可見；頻道級權限是否拒絕傳送。大型伺服器上常見「頻道覆寫權限」與「類別繼承」互相打架，建議用 Discord 內建的權限診斷檢視逐條對照，而不是只看 bot 角色名稱。
• Telegram：Webhook 與長輪詢是否二選一；憑證與回呼 URL 是否隨滾動發佈漂移；群組是否在隱私模式下要求明確 mention。若走自簽憑證，請確認 Telegram 要求的埠與 TLS 版本仍被目前 Gateway 監聽；憑證輪換日建議單獨開變更視窗，不要與功能發佈疊在同一天。

三平台都與出站 IP 穩定高度相關：若 Gateway 跑在會隨機切換出口的家用寬頻或頻繁重撥的 VPN 上，平台端可能把 webhook 當成異常流量；這與《多地區雲 Mac》裡強調的固定區域與可稽核出口一致——當你準備把機器人交給團隊長期依賴時，應優先把控制面搬到可證明可達性的環境，而不是在客戶端網路裡打游擊。

為什麼「只在個人筆記型電腦上掛通道」難撐團隊級 OpenClaw

個人裝置睡眠、VPN 與本機 Proxy 會改變出站 IP 與 TLS 指紋，導致 OAuth 回呼與平台端白名單隨機失敗；多人共用時也無法把 token 輪換與稽核欄位寫進統一金鑰庫。把 Gateway 與通道程序放在可值班、網路出口穩定、可按區域部署的執行平面，才能與團隊級 agent 策略一致。

對需要長期上線、固定回呼網域名與可預測出口的 OpenClaw 拓撲而言，MACCOME 在新加坡、日韓、香港與美東美西提供的 Mac Mini M4／M4 Pro 雲主機適合作為 Gateway 與 Apple 工具鏈共存的常駐節點；通道分診完成後，可在《SSH 與 VNC 指南》與幫助中心核對連線，再依公開價格與區域頁延長租期。

試點建議：先在獨佔測試機上用單一頻道跑滿 24 小時 IER 與 RCR，再接入 production workspace，避免「大群一開放就全紅」的不可逆事故。