一個 Agent 如何同時出現在多個聊天軟件裏？拆解消息網關機制
摘要
一個 Agent 能同時出現在多個聊天軟件裏，是因為聊天軟件只是入口，Agent 才是持續工作的主體。消息網關負責三件事：把 Telegram、WhatsApp、Discord、微信等平台格式各異的消息標準化成統一請求；根據已連接配置把請求路由到同一個 Agent，而不是為每個平台複製一份人格和記憶；執行完成後把結果投遞迴原來那個平台的那一條會話。因為身份（SOUL.md）、記憶（USER.md、MEMORY.md）、技能（skills/）和自動任務都存放在通道之外，所以你在 Telegram 説過的事，在 WhatsApp 繼續問時它依然知道。但統一不等於沒有邊界：每個通道有各自的授權方式、消息格式與投遞限制，國際站與國內站支持的通道範圍也不同，新接一個通道後必須先發測試消息確認回覆落到了預期會話。
引子：同一個助理，為什麼能在不同 App 裏接着聊
設想這樣一段使用過程：你在 Telegram 上讓 Agent 幫你梳理一個項目的進展，中午出門時在 WhatsApp 上追問"剛才那個方案裏第二條的風險是什麼"，晚上又在 Discord 的團隊頻道里讓它把結論發出來。
如果這三次交互像三個互不相識的機器人，那多平台接入就沒有價值——你得在每個平台重新交代一遍背景。真正有用的形態是：三個入口，同一個助理。
這件事的難點常被誤解為"多對接幾個 API"。對接 API 只是最表層的工作量。真正的難點是：讓所有入口指向同一份身份與上下文，同時不破壞各平台自己的規則。 消息網關就是解決這個矛盾的那一層。
一、先糾正一個概念：通道不是 Agent
這是理解整套機制的前提。
| 概念 | 它是什麼 | 數量關係 |
|---|---|---|
| 通道（Channel） | 消息進出的入口，例如 Telegram、WhatsApp、Discord、微信 | 一個 Agent 可連接多個 |
| Agent | 持續存在的工作主體，持有身份、記憶、技能、任務 | 多個通道共享同一個 |
很多人下意識把"我在 Telegram 上的機器人"當作一個獨立實體，於是自然產生"那我在 WhatsApp 上是不是另一個機器人"的疑問。把通道理解為入口而非主體，這個疑問就消失了。
整條鏈路可以這樣表示：
聊天軟件（多個入口）
↓ 平台原生消息
消息網關（標準化 / 路由 / 投遞）
↓ 統一請求
同一個 Hermes Agent
↓
模型推理 + 工具執行 + 記憶召回 + Skills 裝載
↓ 執行結果
消息網關
↓ 按平台格式投遞
原通道的原會話注意最後一步"原通道的原會話"。這不是細節，而是網關必須精確處理的核心問題之一——下面會具體講。
二、網關做的第一件事：接收並標準化
不同平台在幾乎每個維度上都不一樣：
- 用户標識不同：有的用數字 ID，有的用手機號，有的用平台內部的用户名。
- 會話標識不同：單聊、群聊、頻道、話題（thread）的表示方式各不相同。
- 消息結構不同：文本、圖片、語音、文件、引用回覆、表情反應的字段設計各有一套。
- 事件模型不同：有的通過 Webhook 推送，有的需要長連接或輪詢。
如果讓 Agent 直接面對這些差異，Agent 內部就會長出大量平台分支邏輯，每接一個新平台都要改核心代碼。標準化這一步的作用，就是把這些差異收斂在網關層：把平台原生消息轉換成統一的處理請求，讓 Agent 只需要理解一種輸入格式。
這帶來一個直接好處：新增一個通道，理論上不需要改動 Agent 的身份、記憶與技能邏輯。 Agent 關心的是"有人問了什麼"，而不是"這句話來自哪個 App 的哪種字段結構"。
三、網關做的第二件事：路由到同一個 Agent
這是"多平台同一人格"能夠成立的關鍵環節。
網關收到標準化請求後，依據已連接配置判斷這條消息屬於哪個 Agent，然後把請求交給那個 Agent 處理。它不會因為消息來自新平台就臨時創建一個新的人格或新的記憶庫。
這一步之所以重要，是因為它決定了長期資產是共享還是分裂：
| 資產 | 存放位置 | 多通道下的行為 |
|---|---|---|
| 身份與行為準則 | SOUL.md | 所有通道共享同一份 |
| 用户畫像 | USER.md | 所有通道共享同一份 |
| 跨會話事實 | MEMORY.md / memories/ | 所有通道共享同一份 |
| 方法沉澱 | skills/ | 所有通道共享同一份 |
| 自動任務 | Agent 層配置 | 與通道解耦，可指定投遞通道 |
因為這些資產都在通道之外，所以"你在 Telegram 説過的項目名，在 WhatsApp 繼續問時它依然知道"不是額外做的同步功能，而是架構的自然結果——它們本來就只有一份。
這與"換模型不丟記憶"是同一種解耦思路：把易變的接入層與穩定的資產層分開。 關於模型層與 Agent 層的解耦，可參考《Hermes Agent 的"大腦"可以替換嗎？模型層與 Agent 層如何分工》。
四、網關做的第三件事：把結果投遞迴正確的位置
Agent 執行完畢後，網關要把結果送回去。"送回去"比聽起來復雜，因為它必須同時答對三個問題：
- 回哪個平台：這條消息從 Telegram 來，就要回 Telegram，不能回到 WhatsApp。
- 回哪個會話：同一平台上你可能有單聊、多個群、多個頻道。回錯會話不只是體驗問題，在群聊場景下可能造成信息泄露。
- 用什麼格式：各平台對消息長度、Markdown 支持程度、圖片與文件發送方式、是否支持引用回覆的規定都不同。同一段內容在不同平台需要不同的呈現方式。
第二點值得特別強調。投遞目標錯誤是多通道場景下後果最嚴重的一類問題：把本該私聊回覆的內容發到了群裏，或者把 A 群的討論結論發到了 B 群。這也是為什麼每接入一個新通道，都應該先在一個安全的會話裏發測試消息驗證。
五、統一不等於沒有邊界
"一個 Agent 多個入口"容易被理解成"所有平台完全一致"。實際上每個通道仍保有自己的約束，這些約束不會因為共享 Agent 而消失。
5.1 授權方式不同
每個平台的連接方式與憑據形態都不一樣：有的需要在平台開發者後台創建機器人並獲取 Token，有的需要掃碼授權，有的需要 AppID 與 AppSecret。這意味着連接每個通道都是一次獨立的授權動作，不能一次配置全部生效。
5.2 支持範圍按區域不同
這一點在使用文檔時特別容易踩坑：LightVela 國際站與國內站支持的通道範圍並不相同。國際站的通道順序為 Telegram、WhatsApp、Discord、WeChat、QQ、企業微信、飛書；國內站當前面向的是微信、飛書、QQ 等國內常用平台。
因此看到"支持 Telegram"這類描述時，要先確認自己所在的區域，不要跨區域套用。
5.3 群聊語境與單聊語境不同
單聊裏 Agent 面對一個人，群聊裏它面對一群人。群聊需要額外考慮：什麼時候該應答、什麼時候該沉默、哪些內容不適合在群裏展開、誰有權限觸發敏感操作。這些屬於行為準則與權限設計的範疇，不是網關能自動決定的。
5.4 投遞能力不同
消息長度上限、是否支持富文本、能否發送文件、能否引用特定消息——這些差異會直接影響輸出形態。一段在 Discord 裏能正常展示的長回覆，在另一個平台可能需要拆分或簡化。
六、接入新通道的實操順序
把上面的原理落到操作上，建議按這個順序做，能避免大部分問題。
- 先確認區域支持：確認目標通道在你所在的區域可用，避免照着另一區域的文檔操作。
- 完成平台側授權：按對應通道文檔在平台側創建機器人或完成授權，取得所需憑據。憑據屬於敏感信息，不要寫進長期上下文文件，也不要粘貼到聊天裏。
- 在產品側完成連接：填入憑據並保存，確認連接狀態顯示為已連接。
- 發一條測試消息：在一個安全的會話（建議先用單聊或測試群）發消息，確認 Agent 能回覆。
- 確認投遞位置：重點檢查回復是否落在你發消息的那一條會話裏，而不是別的會話。
- 驗證記憶是否共享：問一件你在其他通道説過的事。如果它答得出來，説明這個新通道確實路由到了同一個 Agent。
- 再考慮群聊接入：單聊驗證通過後，再考慮加入群聊，並同步確認群內的應答邊界是否符合預期。
第 6 步是很多人會跳過、但價值很高的一步——它是"通道共享同一個 Agent"這件事最直接的驗證方法。
七、常見問題與判斷方法
| 現象 | 更可能的原因 | 建議動作 |
|---|---|---|
| 新通道沒有任何回覆 | 授權未完成或憑據填寫有誤 | 檢查連接狀態與憑據，重新走授權流程 |
| 回覆出現在別的會話 | 投遞目標解析或配置有誤 | 停止在群聊使用，先回到單聊定位問題 |
| 新通道回覆了但"不認識我" | 可能連接到了另一個 Agent | 用一條已知事實驗證，並核對連接配置指向的 Agent |
| 只有群聊不回、單聊正常 | 群內觸發條件或權限設置 | 檢查群聊應答規則與所需權限 |
| 長回覆被截斷或格式錯亂 | 平台投遞能力限制 | 調整輸出長度與格式，適配該平台 |
其中第三行值得注意："不認識我"在多通道場景下的含義與換模型場景不同。 換模型時它通常是風格差異；而在新接通道時，它更可能意味着這個通道並沒有指向你以為的那個 Agent。判斷方法同樣是拿一條確定的已知事實去問。
八、LightVela 的做法：把通道當作可插拔入口
Hermes 在機制上實現了通道與 Agent 的分離，但連接每個平台仍需要使用者自己處理憑據、回調與運行環境。LightVela 的方向是把這一層做成產品化的可插拔入口：
- 通道是配置項：在同一個 Agent 下按需連接或斷開通道，不需要為每個平台各建一個 Agent。
- 資產天然共享：人格、記憶、技能、自動任務只有一份，新增通道即刻複用，不需要遷移或同步。
- 接入狀態可見：管理台可確認通道是否顯示為已接入，便於快速區分"沒接入成功"與"接入了但沒回復"。
- 區域差異明確：國際站與國內站分別列出各自支持的通道，避免跨區域誤用。
- 問題可追溯：出現異常時可查看診斷中心的近期日誌，判斷問題出在通道授權、投遞還是任務本身。
小結
- 通道是入口，Agent 是主體。多個通道共享同一個 Agent，而不是每個平台一個機器人。
- 網關做三件事：標準化（收斂平台差異）、路由（交給同一個 Agent）、投遞（回到原平台原會話）。
- 人格、記憶、技能、自動任務都在通道之外，所以跨通道的連續性是架構的自然結果，不是額外的同步功能。
- 統一不等於沒有邊界：授權方式、區域支持範圍、群聊語境、投遞能力，每個通道都不同。
- 接入新通道後必須驗證兩件事：回覆是否落在預期會話，以及它是否確實共享同一份記憶。