07 · 訊息閘道器

你是 Hermes 訊息閘道器顧問。

【角色】
Hermes 訊息閘道器顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的具體步驟或示例，不停留在「建議」「考慮一下」這類空泛表述。

【輸入】
- 想接哪些聊天渠道：___
- 誰能發指令：___
- 涉及的敏感操作：___
- 是否多人：___
- 風險偏好：___

【工作流程】
1. 說明訊息閘道器怎麼工作
2. 給渠道接入步驟
3. 設計傳送方鑑權
4. 標出透過訊息觸發的高危操作
5. 給驗證

【輸出規範】
▌一、閘道器機制
▌二、渠道接入
▌三、鑑權
▌四、高危控制 + 驗證

【硬約束】
- 只允許授權使用者發指令
- 憑據 / token 安全存放
- 訊息內容視為不可信防注入
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述

Hermes Gateway（訊息閘道器）是把 Hermes 接到訊息平臺的後臺程序。它接收平臺訊息，維護 chat session（聊天會話），呼叫 agent，執行 cron scheduler（定時排程器），再把結果發回原平臺。從架構上看，它把"本機 CLI 工具"變成了"網際網路上常駐的遠端服務"——這個跨度比想象的大。

官方資料：Messaging Gateway、Gateway Internals、Sessions、Security。

Gateway 改變了什麼

CLI 需要你坐在終端前才能用。Gateway 讓你可以從手機、群聊、郵件、Home Assistant、Webhook 或 API frontend 呼叫 Hermes——人在地鐵、Hermes 還在你 VPS 上做事。

flowchart LR
    subgraph Platforms["訊息平臺<br/>Telegram / Discord / Slack / 郵件 / ..."]
        U["使用者訊息"]
    end
    subgraph GW["Hermes Gateway 後臺程序"]
        AC["allowlist / DM pairing<br/>訪問控制"]
        SS["chat session 路由"]
        AG["agent 呼叫<br/>(toolsets + backend)"]
        CR["cron scheduler<br/>定時任務"]
    end
    Platforms --> AC --> SS --> AG --> Platforms
    CR --> AG

注意箭頭方向：訊息進 Gateway 之前必須先過 access control（訪問控制）；Gateway 沒配好 allowlist 就上線 = 任意陌生人可命令你的本機或 VPS。

適合：

• 遠端跟進任務。
• 群組內低風險問答和總結。
• 定時報告投遞。
• 伺服器巡檢結果回傳。
• 透過 /background 發起非同步任務。

不適合預設開放：

• 高許可權 shell。
• 生產釋出。
• 刪除或遷移資料。
• 讀取敏感檔案。
• 無審查外發訊息。

方便性提升的同時，風險也放大。

接入前檢查

接訊息平臺前先確認：

1. 普通 CLI 對話穩定。
2. hermes --continue 能恢復 session。
3. Toolsets 已按任務收斂。
4. Terminal backend 邊界清楚。
5. Allowlist 或 DM pairing 已設定。
6. Bot token、郵箱密碼、webhook secret 按憑據處理。
7. /stop、/reset、/status 的操作路徑清楚。

這些沒完成之前，不要上線訊息入口。

平臺入口不是等價的

官方支援的平臺很多：Telegram、Discord、Slack、WhatsApp、Signal、SMS、Email、Home Assistant、Mattermost、Matrix、DingTalk、Feishu/Lark、WeCom、Weixin、QQ、Yuanbao、Microsoft Teams、Webhooks、API Server 等。

但平臺能力不同：

• 有的平臺支援執行緒，有的不支援。
• 有的平臺支援圖片/檔案，有的不支援。
• 有的平臺支援 typing/streaming，有的不支援。
• 群聊和 DM 的風險完全不同。
• 語音、檔案、圖片會引入額外處理和隱私邊界。

不要一次接很多平臺。先接一個可控入口，驗證許可權、session、停止和記錄，再擴充套件。

Chat session

每個 chat 都會維護自己的 session。這個設計讓多輪對話可持續，也帶來兩個問題：

• 舊上下文可能影響新任務。
• 群聊上下文比 DM 更不可控。

因此要明確 reset 策略：

{
  "reset_by_platform": {
    "telegram": { "mode": "idle", "idle_minutes": 240 },
    "discord": { "mode": "idle", "idle_minutes": 60 }
  }
}

個人 DM 可以更長；團隊頻道應該更短、更容易 reset；公開或半公開群不要給寬許可權。

Allowlist 與 DM pairing

Gateway 預設拒絕未 allowlist 或未配對的使用者，這是正確預設值。

Allowlist 適合固定使用者：

TELEGRAM_ALLOWED_USERS=123456789,987654321
DISCORD_ALLOWED_USERS=123456789012345678
EMAIL_ALLOWED_USERS=[email protected]

DM pairing 適合臨時批准使用者：

hermes pairing list
hermes pairing approve telegram XKGH5N7P
hermes pairing revoke telegram 123456789

GATEWAY_ALLOW_ALL_USERS=true 不適合有 terminal、file、browser、MCP 寫入能力的 bot。

聊天內命令

訊息平臺裡的 slash command 可以重置會話、切模型、停止任務、檢視狀態、執行後臺任務、呼叫 skill、重新載入 MCP、處理危險命令審批。

這意味著訊息平臺使用者不是隻能聊天，而是在遠端控制一個帶工具能力的 agent。

群聊入口必須更保守。能在 DM 裡安全的能力，不一定適合群裡。

Busy input · agent 忙碌時新訊息怎麼處理

Agent 忙碌（正在跑長任務、等工具響應）時收到新訊息，三種官方策略：

團隊入口要統一這個策略——否則有人以為自己在"補充資訊"，實際卻中斷了長任務（預設 interrupt）；另一個人以為自己在"停止任務"，實際只是排隊了下一條（queue）。同一個 chat 不同人對策略期待不同，會演變成長期溝通成本。

Background session

長任務更適合 background session。比如檢查伺服器、研究資料、跟進 PR、生成報告。

/background Run the test suite and summarize failures. Do not modify files.

它會讓主聊天保持響應，並在任務完成後把結果發回原 chat。

邊界必須寫清：

• 任務範圍。
• 允許工具。
• 是否允許寫檔案。
• 停止條件。
• 報告格式。
• 失敗時怎麼通知。

不要把高風險命令、釋出動作、刪除動作或資料庫遷移放進 background。

驗收清單

Gateway 上線前必須能證明下面 7 項。任何一項答不上來，先關掉 Gateway 修對再開：

• 目前 Gateway 接了哪些平臺？（hermes gateway status）
• 只有 allowlist 或 paired users 能發任務？（用未授權賬號發訊息驗證被拒）
• /status、/stop、/reset 命令能工作？（在不同 chat 裡都試一遍）
• 同一個 chat 的 session 能持續，也能按需要 reset？
• 一個 background session 能完成低風險任務並返回正確 chat？
• 群聊和 DM 的 toolsets 或審批策略不同？（防止群裡有外部賬號但設定和 DM 一樣寬）
• Gateway 停止後平臺入口不再執行任務？（kill 程序後使用者發訊息應得不到回覆，而不是"還在排隊"）

官方資料

• Messaging Gateway（接入總覽 + 各平臺子頁）
• Gateway Internals（路由、授權、session 排程細節）
• Sessions（chat session 與 CLI session 共用機制）
• Security（授權、審批、容器隔離）

下一步