2026 OpenClaw「通道線上但不回覆」排查手冊：pairing、requireMention、Discord intents / Slack 許可權與閘道器日誌分層對照（Mac VPS 7×24）
Dashboard 與 channels status 都綠，使用者卻收不到一句回覆——這類「假線上」在 Mac VPS 7×24 場景裡極常見，根因卻往往不在模型。本文把排障拆成三層：IM 與 Bot 策略（pairing、requireMention、intents、Slack 安裝範圍）、閘道器投遞與鑑權（probe、doctor、18789、Token）、模型與配額（429、長上下文）。你將拿到一張現象對照表、六步可復現 Runbook、三條可寫進評審的硬指標，以及 FAQ；並與站內 mention/pairing 清單、heartbeat 靜默、429 分流 形成互補閱讀。
1. 三類痛點：為什麼「線上」不等於「能回覆」
許多團隊把「通道已連線」理解成整條鏈路暢通，但在 OpenClaw 架構裡，IM 平臺是否把訊息交給 Bot、閘道器是否把會話交給模型、模型是否成功返回是三個可獨立失敗的階段；Dashboard 上的綠燈通常只證明其中一段。
- 策略層靜默丟棄：
requireMention、群白名單、或「僅處理執行緒內回覆」類規則會讓訊息在到達模型前被吃掉；私聊無 @ 約束時常表現為「私聊正常、群聊裝死」。若同一 Bot 在多群表現不一致，還要懷疑分房間覆蓋配置是否遺留舊值。 - pairing 與信任邊界：新成員或新會話可能停在 pending；在未
pairing approve或等效放行前，閘道器不會向下遊投遞。連線測試仍可透過，因為握手與心跳走的是另一路徑。升級後預設值漂移時，這類問題會突然「集體復發」。 - 平臺許可權與 intents 缺口：Discord 未開啟
Message Content Intent、Bot 未加入頻道、Slack 重授權遺漏事件訂閱範圍時，常出現「入站偶現、出站失敗」或平臺側靜默丟包。與閘道器崩潰不同，CPU 與記憶體曲線往往仍很平穩，容易誤判為模型抽風。
若你已在 Mac 雲上跑 launchd，還要額外警惕環境變數切片：手工 SSH 登入後執行的 openclaw 與守護程序讀取的 HOME、PATH 不一致時，會出現「命令列全綠、守護程序舊配置」的假一致。
2. 現象—根因—驗證：對照表
先把現象釘在層位上，再選工具；避免一上來換模型或清快取。
| 現象 | 優先層位 | 首選驗證 | 可先排除 |
|---|---|---|---|
| 僅群聊無回 | 策略層（mention/房間規則） | 群內帶 @ 短句 A/B | 整站 API Key 吊銷 |
| 新成員無回、老人正常 | pairing 佇列 | pairing list / approve 演練 | 磁碟滿 |
| Discord 僅伺服器頻道無聲 | intents / 角色 / 可見性 | 開發者門戶對照表 | 閘道器埠隨機佔用 |
| Slack 偶發「已讀不回」 | 事件訂閱 URL / Workspace 安裝範圍 | 重授權 + 事件投遞日誌 | 模型 temperature |
| 全通道無回且日誌含 429 | 模型與配額 | Provider 控制台與降級策略 | pairing 全量清空 |
3. 六步 Runbook：從 probe 到模型分流
建議在變更視窗單變數執行，每步記錄時間戳與命令輸出片段，便於次日對照。
- 通道探針：執行
openclaw channels status --probe，確認 RPC 與通道握手；若此處失敗，先停在下文「閘道器層」。 - pairing 審計：
pairing list檢視 pending；對新協作流明確「誰有權 approve」，避免把審批鏈綁在單人日曆上。 - 策略核對：匯出當前 messaging 相關配置，顯式標註
requireMention、群白名單與執行緒策略；與產品文件對齊「群內必須 @」的運營承諾。 - 平臺許可權矩陣：Discord 勾選必要 intents，Slack 校驗
chat:write、事件訂閱與重定向 URL 是否指向當前閘道器公網入口。 - 閘道器自檢：
openclaw doctor與openclaw gateway status（必要時--deep）對照官方 command ladder；Mac VPS 上同時核對 launchd plist 的EnvironmentVariables是否與互動 shell 一致。 - 模型分流：若前五步無異常，再檢視 Provider 429、長上下文與工具呼叫門禁日誌，與 429 分流文 對齊降級策略，避免把配額問題誤裝成「通道壞了」。
openclaw channels status --probe
openclaw pairing list
openclaw doctor
openclaw gateway status
4. 三條可引用指標
- probe 失敗率：在固定視窗內
channels status --probe失敗次數上升，而 CPU 平穩，優先懷疑 Token / URL / 平臺側限流，而非模型。 - pending pairing 深度：pending 佇列長期大於零說明審批或通知鏈路與人因耦合過大，需要制度化而不僅是臨時清佇列。
- 群/私聊成功率差：若群訊息到達率顯著低於私聊，九成可收斂到 mention 與可見性，而非「再買一臺 Mac」。
5. FAQ
問：要不要先重啟閘道器？ 若 probe 與 doctor 均無紅項，盲目重啟往往只重置短時快取，掩蓋未儲存的配置漂移；先完成表格分層更省時間。
問：多通道並行時如何縮小爆炸半徑？ 先在非生產 Slack/Discord 工作區復現，再切流量；保留一份「僅啟用單通道」的最小配置用於對照。
問：和 Matrix 外掛混佈會干擾判斷嗎？ 會。建議排障期暫時只保留一條 IM 通道作為金線，確認無回消失後再逐步開啟其它通道。
6. 結論
「線上但不回」多數是策略與許可權在閘道器之前攔截，而不是模型突然變笨；把三層拆清，才能把 Mac VPS 上的 7×24 值班從「玄學重啟」變成可審計流程。
僅依賴桌面會話或臨時容器很難穩定復現 launchd 與 IM 回撥的組合邊界；在自家筆記本上「好像能跑」也不等於生產閘道器配置已對齊。要在可預測的 Apple Silicon 環境裡把閘道器、通道與模型日誌釘在同一套路徑上，租賃 VPSMAC 的 Mac 雲節點，用 SSH 與 plist 固化執行身份，通常比在通用筆記本或混用環境裡反覆試錯更接近問題本質。