2026年 OpenClaw 入站通道治理實戰：Slack／Discord 私訊配對（pairing）與群組白名單（groupPolicy）在遠端實體 Mac 上的可複現 Runbook——收不到訊息、配對過期與依頻道模型覆寫的排查（openclaw.json 片段 + FAQ）

1. 三大痛點

1. 私訊與群是兩套策略。 只在 groupPolicy 裡放了頻道 ID，卻漏了 DM 的 pairing，就會出現「群內正常、私訊全靜音」的錯覺。
2. 遠端 Mac 上多處理序／多使用者常踩到狀態目錄。 同一 ~/.openclaw 被兩個 gateway 或不同使用者的 launchd 與 SSH 寫入，會變成偶發 配對過期 或入站 401／403 抖動。
3. 依頻道路由模型與全域 defaults 的優先順序不夠直覺。 單一執行緒或頻道 ID 寫錯、或萬用字與精確比對的順序相反，會誤以為「多模型覆寫失效」。要以日誌把「解析鍵」完整對上。

2. 決策矩陣：pairing 與 groupPolicy 怎麼分工

3. 決策矩陣：Slack 與 Discord 入站面差異

兩邊 Bot 的權限與列舉不同，分診時不要混用「頻道 ID」與「訊息路由鍵」；Discord 的 Intents 是常見雷。

4. openclaw.json 片段（示意，實際鍵名以你所用的發行版為準）

以下為結構示意，用來與維運釐清「參數到底寫在何處」；合併前請在環境中以 JSON Schema 或內建校驗驗證。密鑰請用 SecretRef 引用，不要提交明碼。

{
  "version": 1,
  "gateway": {
    "bind": "127.0.0.1:18789",
    "inbound": {
      "debug": { "logPolicyDecisions": true, "redact": true }
    }
  },
  "channels": {
    "slack": {
      "enabled": true,
      "appIdRef": { "ref": "file:/Users/bot/.openclaw/slack.app_id" },
      "botTokenRef": { "ref": "file:/Users/bot/.openclaw/slack.bot_token" },
      "signingSecretRef": { "ref": "keychain:service:slack-signing" },
      "eventUrlPath": "/hooks/slack/events",
      "pairing": {
        "require": true,
        "codeTtlSeconds": 600,
        "stateDir": "/Users/bot/.openclaw/slack-pairing"
      },
      "groupPolicy": {
        "default": "deny",
        "allowlist": {
          "workspaces": ["T0123WORKSPACEID"],
          "channelIds": ["C0123CHAN", "C0456CHAN"],
          "imUsers": ["U07PAIRUSER"]
        }
      },
      "modelOverrides": {
        "byChannel": {
          "C0123CHAN": { "profile": "prod-fast" },
          "C0456CHAN": { "profile": "cheap-sidecar" }
        }
      }
    },
    "discord": {
      "enabled": true,
      "botTokenRef": { "ref": "file:/Users/bot/.openclaw/discord.token" },
      "publicKeyRef": { "ref": "file:/Users/bot/.openclaw/discord.pubkey" },
      "intents": ["GUILDS", "GUILD_MESSAGES", "DIRECT_MESSAGES", "MESSAGE_CONTENT"],
      "pairing": {
        "require": true,
        "codeTtlSeconds": 600,
        "stateDir": "/Users/bot/.openclaw/discord-pairing"
      },
      "groupPolicy": {
        "default": "deny",
        "allowlist": {
          "guildIds": ["123456789012345678"],
          "channelIds": ["987654321098765432"],
          "threadFork": "inherit-channel"
        }
      },
      "modelOverrides": {
        "byThread": {
          "123456789012345678/987654321098765432": { "profile": "cheap-sidecar" }
        }
      }
    }
  },
  "models": {
    "defaults": { "profile": "prod-fast" }
  }
}

實用重點：default: deny 時，imUsers 與配對的綁定要同時成立；byThread 的鍵須與閘道在事件裡組出來的 key 相同（多為 guild／channel／執行緒三段式）。

5. 七步可複現 Runbook

1. 證明僅一個閘道行程： 在實體 Mac 上執行 ps aux | grep openclaw。若有多實例，先合併為單一實例，否則 stateDir 彼此覆寫。
2. 自外向內的 TLS 與路徑： 在 Slack 或 Discord 主控台所登記的公網 URL 上，從外網以 curl 驗證 2xx 或正確挑戰；並與本機 eventUrlPath 一致。
3. 以最小重現分軌： 先送一則 純文字頻道訊息，再送一則 私訊，於閘道日誌中比對事件類型與策略命中的關鍵，鎖定是 pairing 還是 groupPolicy。
4. 對照頻道／執行緒鍵： 啟用 inbound.debug 中列印的路由 key，與 modelOverrides 一列對一列，較明確的規則要排在先。
5. 驗配對與 TTL： 在 codeTtlSeconds 內完成配對；若常顯示過期，改查磁碟寫入失敗、NTP 偏移、或 stateDir 與 launchd 使用者與 SSH 所見 HOME 不一致。
6. Discord 意圖（Intents）： 在開發者入口驗證 Message Content 與相關特權意圖，並與設定內的 intents 陣列全數對齊後，再重啟閘道。
7. 回寫 Runbook 與回滾點： 變更前後各存一份帶時間戳的 JSON，策略一收得太緊變成全站靜音時，可回退到較小的 allowlist。

6. 可引用閾值與參數

• 配對碼 建議 TTL 5–15 分鐘，便於實際維運操作；若秒級過短，跨時區的 Slack 常會「還沒貼上碼就過期」。
• 在採 預設拒絕 的模型下，每多開一個公開（public）頻道，至少做一回合 dry-run 對話，避免多服 Bot 串臺回應。
• 同機同裝也跑其他常駐服務時，入站面延遲 < 1s、TLS 握手持續 < 200ms（同區內）可作為上線基準；疊上跨國鏈路時，請在本文前段所提的 RTT／丟包驗收清單內，先收斂閾值再重試。

7. FAQ

8. 在 Mac mini 上放穩這條入站鏈路

公網入站、簽名校驗與多通道路由是長期具狀態的工作型態：要穩定的時鐘、可預期的磁碟寫入，以及 7×24 可用。Apple Silicon Mac mini 在常見網關型負載下仍可維持低待機與幾近無聲，很適合與 launchd、使用者層 Agent 併用，在機櫃裡當「不吵人的機器人寄宿主機」；macOS 的鑰匙圈、檔案權限與日誌模型也利於以同一套安全敘事落地 SecretRef 與 stateDir。

若你打算讓 Slack／Discord 入站、簽名與反代、以及模型出口，整條都跑在單一可稽核、可常駐的迷你主機上，Mac mini M4 在 2026 年依舊是許多小團隊的務實選。現在即可透過 ZoneMac 在合適的區域取得實體節點，把配對與白名單從實驗參數收斂到可上線的治理。若你正在找一台能長開、卻不佔用桌面空間的實體主機，Mac mini M4 的效能、待機與靜音表現，都能讓這條入站＋出站的閘道真正發揮完整戰力。