Hermes Agent v0.2.0 真正的頭條功能，不是某個模型整合，也不是技能系統。是那個多平台訊息閘道——一個 Hermes 行程同時聽著七個聊天平台的動靜：Telegram、Discord、Slack、WhatsApp、Signal、電子郵件（IMAP/SMTP）、Home Assistant。到 4 月 8 日那版發出來的時候，這個清單已經長到了十三個，中間陸續加上了 Matrix、飛書、企業微信、Mattermost、釘釘，還有走 Twilio 的簡訊。
這裡面很容易被忽略的一點是：寫一個 Telegram bot 並不難。難的是同時跑七個聊天整合，而且還要讓它們共用同一個 agent、同一份記憶、同一個工具註冊表——真正的架構工作都壓在這裡。這篇文章講 Hermes 到底是怎麼把這件事做出來的。
最樸素的做法，以及它為什麼行不通
如果讓你來做「一個既能在 Telegram 上回話、也能在 Discord 上回話的 AI bot」，第一反應大概是起兩個獨立的 bot。每個 bot 自己一個行程、一套資料庫、一份狀態，底下都呼叫同一家 LLM 的 API。概念上說，Telegram 那邊的使用者和 Discord 那邊的使用者面對的是同一個 agent；但實際上他們面對的是兩個互不認識的 agent。
現在大部分 bot 專案就是這麼做的，它糟糕的地方要過一陣子才顯出來：
- •記憶會分岔。 使用者在 Telegram 上說過自己對花生過敏，跑到 Discord 上問做菜問題時，這條資訊就不見了。同一件事，agent 得被教兩遍。
- •工具狀態會漂。 你在 Slack 裡建的一個 cron 任務，使用者在 Telegram 裡查 cron 的時候看不見。會話歷史是碎的。共享資源的授權 token（比如一個 Notion 整合），得在每個 bot 裡各裝一遍。
- •維運成本成倍漲。 N 個 bot 意味著 N 個行程、N 個服務、N 份日誌流、N 份設定檔，以及 N 個可能壞掉的點。複雜度跟平台數量成正比。
- •安全規則會碎掉。 在一個 bot 上把危險指令的審核策略收緊了之後，你還得記得去別的 bot 上同步一遍。安全策略的漂移是預設狀態。
Hermes 選了另一條路：只有一個 agent 行程、一個會話資料庫、一個記憶儲存、一個工具註冊表。各家平台只是轉接器——一層薄薄的「前門」，把訊息倒進和倒出那個共用的 agent。
這套閘道長什麼樣
Hermes 閘道在內部分三層。
最底層是 agent 本體——就是你在 CLI 模式下跑的那個 Hermes 核心。它對聊天平台的存在一無所知。它收到訊息，跑自己的 agent 迴圈（LLM 呼叫、工具呼叫、記憶查詢、checkpoint），然後吐出回應。它對外唯一的介面是一套以佇列為基礎的 API。
中間層是閘道核心——會話管理、使用者/平台路由、審核分發、cron 排程、串流輸出、媒體處理都在這一層。它負責把「來自平台 X、使用者 Y、頻道 Z 的一條訊息」翻譯成「在會話 S 裡、帶這組權限的一次 agent 執行」。同時它也統一處理那些跨平台的公共事務：限流、防刷、訊息去重、基於閒置的逾時、審核按鈕的路由、跨平台的狀態。
最上面是各家平台的轉接器。一個平台一個：Telegram 轉接器、Discord 轉接器、Slack 轉接器，依此類推。每個轉接器的職責很窄——連上自己那個平台（用輪詢、長輪詢、WebSocket、webhook，或者它家 SDK 偏好的任何方式），把平台原生的事件翻譯成閘道的內部訊息格式，再把閘道輸出的回應翻譯回那個平台吃得下的樣子（Markdown、MarkdownV2、mrkdwn、Discord rich embed、Matrix HTML、Slack blocks、電子郵件 MIME 全都在裡面）。
轉接器故意做得很小。加一個新平台（v0.4.0 那會兒一位社群貢獻者用不到 300 行 Python 就加上了 Mattermost）主要就是把那家 SDK 的事件對應到閘道內部的訊息形狀，再反著對應一次。
會話跨平台的時候是怎麼運作的
Hermes 裡的一個會話，是一串有自己記憶視窗、工具狀態和執行歷史的對話。只看一個平台，會話的對應關係很自然——一個 Telegram 聊天就是一個會話，一個 Discord 頻道就是一個，一個 Slack thread 就是一個。一跨到多平台上，事情就有趣起來了。
Hermes 預設的做法是把「平台 + 聊天」這個組合當成一個獨立會話。你在 Telegram 上跟 bot 的私聊、在 Slack thread 裡跟 bot 的對話、在 Discord 頻道裡跟 bot 的對話，是三段各跑各上下文的獨立會話，但是它們透過那層可插拔的記憶提供者共用同一份長期記憶（v0.7.0 之後預設是 Honcho）。所以那些你希望能跨會話帶過去的資訊——「這個使用者對花生過敏」、「這個使用者叫 Alice」、「這個使用者的專案叫 Atlas」——是掛在記憶層上的；而每段對話的短期上下文，仍然緊緊鎖在你當下用的那個平台裡。
就是這套設計，讓同一個助手在每個平台上用起來都像同一個助手，同時又不至於把每條訊息都變成一場糾纏不清的全域廣播。
為什麼「同一個 thread 裡分使用者的會話」那麼重要
v0.4.0 裡 Hermes 加了一個特性，叫同一 thread 內預設分使用者會話——在群組聊天裡，同一個 thread 底下，每個使用者各有各的會話。這件事聽起來像個小改動，但凡你在群組裡跑過多使用者 bot 的都知道，它是件大事。
在群組裡如果沒有按人分開的會話，每條訊息都屬於同一段共享對話。Alice 問了個問題，三十秒後 Bob 又問了一個不相干的問題，bot 的上下文就變成了兩人混在一起的一團漿糊。答案開始串味，Alice 的記憶裡被塞進了 Bob 的資料，群組裡人越多，閘道模式表現越差。
有了 thread 內分使用者會話之後，Alice 和 Bob 在同一個 thread 裡各有各的私有會話。他們在聊天介面上仍然看得到彼此的訊息，但 agent 對這兩個人維護的是兩套獨立的上下文和兩份獨立的記憶寫入。v0.8.0 開始，這成了所有閘道平台的預設行為。這種修補在你沒被另一種做法燒過之前是完全看不見的，一旦被燒過一次，你就再也不想回去了。
這套閘道到底是幹嘛用的
把這套架構多盯一會兒，你會慢慢覺得閘道不再像「一種在聊天平台上跑 bot 的方式」，而越來越像它本來的樣子：一層協調層，連接的一頭是人（不管這個人現在用的是哪個 app），另一頭是一個共享記憶和工具的、獨立的 AI 助手。
聊天平台不是產品。它們是入口。產品是躲在入口後面的那個助手，以及「你完全不用去想自己現在走的是哪個入口」這件事本身。
這才是 Hermes 第一天就發出來的那個功能。後面四個禮拜發生的一切，都是這層協調層一點點學會新本事的故事。