（系列：《AI 維運實戰：我用 Hermes 把 Agent 變成企業同事的 30 天》）
（主題：將 AI 模型整合進實際系統與產品的工程實踐）

前一天我把 Hermes Gateway 設成正式入口。但 Gateway 能啟動，不代表 Telegram 已經接通。

真正的驗收不是畫面出現「running」，而是我從手機送出一則訊息，Agent 能收到、判斷、執行，再把結果送回同一個聊天室。

────────────────────────────────

先拆開一則訊息走過的路

Telegram Bot 並不是直接呼叫模型。完整路徑至少有五段：

1. 使用者在聊天室送出訊息。
2. Telegram Bot API 產生 update。
3. Hermes Gateway 收到 update，檢查聊天室與使用者權限。
4. Agent 載入設定、上下文與工具，交給模型處理。
5. Gateway 再透過 Bot API 把答案送回原聊天室。

任何一段失敗，使用者看到的結果都一樣：Bot 沒回話。

所以我不把「沒回」直接歸咎於模型。先分層，才能避免一直換模型、重啟服務，卻沒有碰到真正的問題。

────────────────────────────────

建立 Bot 只是拿到入口，不是完成部署

Telegram 端先用 BotFather 建立 Bot，取得 token，再把 token 放進 Hermes 設定。Token 等同 Bot 的密碼，不能寫進文章、Git repository 或 log。

接著我先驗證 Bot API，而不是立刻測 Agent：

• getMe：確認 token 對應到預期的 Bot 身分。
• getChat：確認 Bot 看得到指定聊天室，Chat ID 沒抄錯。
• sendMessage：確認 Bot 有能力把測試訊息送到目標聊天室。

這三項只能證明 Telegram 的「送出路徑」可用。它仍不能證明 Gateway 收得到訊息，也不能證明授權規則會放行。

這是我早期踩到的第一個認知坑：Bot API 回傳成功，很容易讓人誤以為 Agent 已經上線。其實那只是 adapter 的一半。

────────────────────────────────

allowed_chats 是安全邊界，不是方便用的清單

Bot token 一旦接進 Gateway，下一個問題是：誰可以叫這個 Agent 做事？

Hermes 的 allowed_chats 用來限制可互動的聊天室。我的做法是白名單制，只加入明確授權的 Chat ID，不把 Bot 開成任何人找到都能使用的公共入口。

這裡還有一個常見陷阱：Telegram 的私聊、一般群組、超級群組，Chat ID 形式不完全相同。群組轉成超級群組後，ID 也可能改變。不要靠肉眼猜，應從實際 update 或 getChat 結果取得，再原樣寫入設定。

白名單的價值不只防陌生人聊天。Agent 後面會取得檔案、瀏覽器、終端機與公司資料的工具權限。錯放一個聊天室，風險不是多花幾次模型費，而是讓不該下指令的人碰到真實系統。

────────────────────────────────

我的端到端驗證方式

完成設定後，我不只看 Gateway process 存不存在。我用真實 Telegram 聊天室做一輪測試，並逐層留下證據：

1. 從授權聊天室送出一則可辨識的測試訊息。
2. 確認 Gateway log 收到對應 update，而不是舊紀錄。
3. 確認訊息通過 allowed_chats，建立了本次 Agent 執行。
4. 確認 Agent 回覆出現在同一個聊天室。
5. 讀回回覆的 message_id 與 chat_id，確認不是送到錯誤目的地。

這個驗證比「我在終端機看到 exit code 0」嚴格得多。exit code 0 只代表某個程序正常結束；使用者真正關心的是手機上有沒有收到正確結果。

測試時我也刻意保留一個不在白名單內的入口。授權聊天室應該成功，未授權入口應該被拒絕。只有成功案例，不能證明安全邊界有效；負向測試同樣重要。

────────────────────────────────

為什麼「會回訊息」是一切自動化的前提

當 Telegram 的收發閉環成立後，Agent 才從本機工具變成日常工作節點。

人在外面，可以從手機交辦。排程完成後，可以把報告送回固定聊天室。執行失敗，也能把阻塞原因送到同一個入口。後續的財務日報、社群雷達、工程追蹤，都建立在這條穩定訊息通道上。

但我也得到一個更重要的結論：訊息平台不是單純的 UI，而是系統邊界。它同時處理身分、權限、路由與交付證據。Bot 能說話只是表面；能確認誰在說、訊息該去哪裡、結果是否真的送達，才像一名可上班的員工。

────────────────────────────────

今天的結論

把 Agent 接上 Telegram，不是填入 token 就結束。我最後採用的驗收順序是：先驗 Bot 身分，再驗聊天室，再驗白名單，最後跑完整的收訊、推理與回覆閉環。

這個順序讓故障可以被切成 Telegram API、Gateway、授權、模型與回傳五層。少猜一次，就少一次無效重啟。

下一篇 D4：模型選擇不是挑最強，而是挑最適合工作的組合。我會談從單一模型走向分工後，為什麼機械工作、固定格式與跨來源推理，不該付同一種成本。