前面幾天，我們把 Hermes Agent 的模型、記憶、知識庫與自動化逐步接起來。到了真正每天使用的階段，另一個問題很快浮現：同一套能力要同時面對 Telegram、LINE、Gmail 和 Google Workspace，難道每個平台都要養一隻完全獨立的 bot？

我的答案是不應該。

如果每個平台各自複製一套 prompt、記憶與工具，短期看似很快，長期一定會出現三種漂移：同一件事在不同平台得到不同規則、權限邊界難以盤點，以及修正一個流程時必須同步修改多份程式。這不是多平台整合，而是多份難以維護的分支。

真正應該共用的是 core

我把系統拆成兩層：核心能力，以及平台 adapter。

核心能力包含任務理解、模型路由、記憶查詢、Company Brain 檢索、Skill 執行、驗證與回報格式。這些能力不應該因為訊息來自 Telegram 或 LINE 就重新定義。

Adapter 則負責平台差異：如何登入、如何取得事件、如何把訊息轉成統一輸入、如何處理附件與回覆、如何維持 session，以及如何把核心輸出轉回平台能接受的格式。

這個切法的重點，是把「平台差異」限制在邊界，不讓它滲進每個工作流程。

四個平台，四種完全不同的麻煩

Telegram 的優點是 Bot API 清楚，適合做 Gateway 與群組路由；但 allowed_chats、group_allowed_chats 和 profile_routes 都必須正確設定，否則訊息可能在授權層被靜默丟棄。

LINE 則要分清楚兩種情境。LINE@ OA Manager 是企業客服場景，涉及 chat.line.biz 的 session 與內部 API；個人 LINE 則是另一個 Chrome extension 與 CDP 操作面。兩者都叫 LINE，卻不能共用同一套認證或權限假設。

Gmail 與 Google Workspace 的問題不在「能不能呼叫 API」，而在帳號隔離。公司 Drive、Docs、Sheets 必須使用公司帳號；個人帳號即使看起來能登入，也不代表有權限讀取公司的資料。

因此，adapter 不只是 API wrapper。它同時是認證生命週期、資料邊界與錯誤語意的封裝層。

統一事件格式，但不要抹平重要差異

在 core 入口，我會把平台事件整理成類似下面的結構：

source: telegram
conversation_id: -5518656206
sender_id: 123456
message_type: text
text: 請整理今天的財務報告
reply_context: none
capabilities: [send_text]

LINE、Gmail 或其他平台都可以轉成同樣的基本欄位。這讓核心流程可以專注於「使用者要完成什麼」，而不是先處理每個平台的原始 JSON。

但統一格式不代表把差異藏掉。例如 Gmail 的 conversation_id、LINE 的聊天室 ID、Telegram 的群組 ID，其安全意義並不相同；附件、引用回覆、訊息長度與可用按鈕也各有平台限制。這些差異應該以明確 capability 或 metadata 保留，而不是假裝所有平台一模一樣。

我會特別保留三類資訊：來源身份、授權能力、回覆限制。如此一來，core 可以判斷「這個請求能不能做」，adapter 才負責判斷「要怎麼送出去」。

最容易踩到的坑：把 session 當成共用資源

多平台系統最危險的錯誤之一，是看到同一家公司、同一個使用者，就以為可以共用 Cookie、token 或瀏覽器 session。

這樣做會讓問題變得很難追：某次 API 失敗到底是 token 過期、帳號錯誤、權限不足，還是另一個平台的操作污染了狀態？更嚴重時，私人對話可能被錯誤送到公司帳號，形成資料隔離事故。

實務上，我把 session 綁定在 adapter 與帳號上，並為每個外部服務做認證 preflight。認證失效時，系統只能走已定義的恢復流程；若需要人工登入，就開啟登入頁並停止後續外部動作，不猜密碼、不複用舊 session。

這種設計多了一些管理成本，但換來的是可以回答三個關鍵問題：誰登入的、能讀什麼、失效後如何恢復。

從「能送出」到「真的送達」

平台整合不能只測試 API 回傳成功。一次完整驗證至少要分成四段：

1. Core 產生正確內容與目標。
2. Adapter 將內容轉成平台請求。
3. 平台回傳可追蹤的結果，例如 message_id 或 thread ID。
4. 再讀回目標平台，確認使用者實際看得到內容。

其中第四段最容易被省略。HTTP 200 只代表請求被接受，不代表訊息沒有被平台規則過濾，也不代表送到了正確聊天室。對報告、客戶通知與正式發布而言，讀回驗證才是完成標準。

我現在的原則是：adapter 可以回報「已提交」，但只有讀回目標後，系統才能回報「已完成」。這個差異看似文字遊戲，實際上是避免自動化系統自信地報錯。

結語：平台越多，核心越要小

多平台不是把每個 API 都接上就結束，而是要先定義邊界：core 管判斷與能力，adapter 管平台差異，policy 管授權與資料隔離。

這樣做的結果，不是讓所有平台都變得一樣，而是讓差異有固定的位置可管理。未來增加新平台時，只需實作事件轉換、session、能力宣告與讀回驗證，不必複製整家公司 Agent 的人格與規則。

今天的實際證據，是同一套 Hermes core 可以沿著不同 adapter 對接 Telegram、LINE、Gmail 與 Google Workspace；但每個平台的帳號、session、權限與回讀驗證仍然分開管理。這代表我們整合的是能力，不是混用身份。

下一篇會繼續談認證。因為當 adapter 數量增加後，最常讓自動化停擺的，往往不是模型，而是那些平常看不見、過期時才突然出現的登入狀態。