07 · 訊息閘道器 · AI 程式設計教程中文版

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

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

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

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。
生產釋出。
刪除或遷移資料。
讀取敏感檔案。
無審查外發訊息。

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

接入前檢查

接訊息平臺前先確認：

普通 CLI 對話穩定。
hermes --continue 能恢復 session。
Toolsets 已按任務收斂。
Terminal backend 邊界清楚。
Allowlist 或 DM pairing 已配置。
Bot token、郵箱密碼、webhook secret 按憑據處理。
/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	等當前任務結束後排隊執行新訊息	團隊入口、多人發指令但不希望相互干擾
steer	把新訊息注入當前執行過程，等下一次 tool call 後生效（"讓正在跑的任務知道你想加這條資訊"）	長任務過程中追加約束（比如"不要碰 prod 表"），但不打斷任務

團隊入口要統一這個策略——否則有人以為自己在"補充資訊"，實際卻中斷了長任務（預設 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（授權、審批、容器隔離）

07 · 訊息閘道器