---
title: "07 · 訊息閘道器"
description: "理解 Hermes Gateway、平臺入口、chat session、allowlist、DM pairing、slash commands、busy input 和 background session 的關係。"
verifiedAt: "2026-05-09"
---

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

官方資料：[Messaging Gateway](https://hermes-agent.nousresearch.com/docs/user-guide/messaging)、[Gateway Internals](https://hermes-agent.nousresearch.com/docs/developer-guide/gateway-internals)、[Sessions](https://hermes-agent.nousresearch.com/docs/user-guide/sessions)、[Security](https://hermes-agent.nousresearch.com/docs/user-guide/security)。

> [!NOTE]
> **先給結論**：Gateway 會把 Hermes 從"本機終端工具"變成"遠端常駐服務"。上線前**必須**先跑穩 CLI、收斂 toolsets、配置 **allowlist（允許名單）**或 **DM pairing（私聊配對）**，並區分 DM（私聊）、群聊和 background session（後臺會話）的許可權——三類場景的風險不一樣。

## Gateway 改變了什麼

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

```mermaid
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 策略：

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

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

## Allowlist 與 DM pairing

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

Allowlist 適合固定使用者：

```bash
TELEGRAM_ALLOWED_USERS=123456789,987654321
DISCORD_ALLOWED_USERS=123456789012345678
EMAIL_ALLOWED_USERS=trusted@example.com
```

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

```bash
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** | 等當前任務結束後排隊執行新訊息 | 團隊入口、多人發指令但不希望相互干擾 |
| **steer** | 把新訊息注入當前執行過程，等下一次 tool call 後生效（"讓正在跑的任務知道你想加這條資訊"） | 長任務過程中追加約束（比如"不要碰 prod 表"），但不打斷任務 |

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

## Background session

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

```text
/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](https://hermes-agent.nousresearch.com/docs/user-guide/messaging)（接入總覽 + 各平臺子頁）
- [Gateway Internals](https://hermes-agent.nousresearch.com/docs/developer-guide/gateway-internals)（路由、授權、session 排程細節）
- [Sessions](https://hermes-agent.nousresearch.com/docs/user-guide/sessions)（chat session 與 CLI session 共用機制）
- [Security](https://hermes-agent.nousresearch.com/docs/user-guide/security)（授權、審批、容器隔離）

## 下一步

<Cards>
  <Card title="自動化邊界" description="Gateway 穩定後，再看 cron、background 和 delegation 的安全邊界——它們疊在 Gateway 上會進一步放大許可權面。" href="/zh-Hant/docs/hermes/understanding/08-automation-boundaries" />
  <Card title="訊息閘道器手冊" description="需要具體平臺接入步驟（Telegram bot token / Discord webhook 等），查官方教程中文版。" href="/zh-Hant/docs/hermes/official/01-user-guide/messaging" />
</Cards>
