（系列：《AI 維運實戰：我用 Hermes 把 Agent 變成企業同事的 30 天》）
（主題：將 AI 模型整合進實際系統與產品的工程實踐）
選定 Hermes 之後，第一個問題不是模型，而是入口。
同一個 Agent，可以在終端機裡操作，也能從桌面介面使用，還能常駐成 Gateway 接收訊息。三種方式都能工作，但適合的場景完全不同。
────────────────────────────────
先把安裝鏈看懂
我採用官方安裝腳本，而不是手動建立 Python 環境：
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
這條指令看起來像「一鍵安裝」，背後其實完成了一條工程鏈：
我選擇保留 venv。原因很務實：Agent 會持續加入瀏覽器、語音、訊息平台等相依套件。如果全部灌進系統 Python，日後升級或除錯，很難判斷是哪個專案污染了環境。
這裡第一個容易踩的雷，是腳本跑完不代表 shell 找得到指令。launcher 在 ~/.local/bin；PATH 沒載入時，終端機只會回報 command not found。與其重裝，我先檢查 command -v hermes，再確認 PATH。
────────────────────────────────
CLI、Desktop、Gateway 的差別
| 入口 | 適合工作 | 優點 | 限制 |
|---|---|---|---|
| CLI | 安裝、除錯、一次性任務 | 最直接，log 與錯誤清楚 | 終端機關掉後，不適合當日常入口 |
| Desktop | 本機互動、檢視產物、人工協作 | 操作直覺，適合人在電腦前 | 仍以人主動打開與操作為主 |
| Gateway | Telegram、LINE 等訊息與排程 | 常駐、可遠端、能接進工作流程 | 必須處理服務生命週期、權限與認證 |
我沒有把它們理解成三套 Agent。它們是同一個 runtime 的不同入口。
CLI 像維修孔。Desktop 像駕駛艙。Gateway 則像公司的總機，外面的訊息先進來，再交給 Agent 處理。
────────────────────────────────
為什麼最後選 Gateway
我的目標不是坐在 Mac mini 前面陪 AI 聊天，而是讓它進入公司的日常通道。
財務日報要定時送達。客戶訊息要在群組裡處理。人在外面時，也要能從手機交辦。這些需求都指向 Gateway，而不是單次 CLI session。
如果只選 Desktop，我得到的是更好用的個人工具；選 Gateway，才有機會得到一名「在線的企業同事」。差別不在畫面，而在系統能不能持續接收事件。
但我沒有因此放棄 CLI。真正的做法是：
也就是說，Gateway 是正式工作面，CLI 是維運面。企業系統不能只有前台，沒有維修入口。
────────────────────────────────
我踩到的認知錯誤
一開始最容易誤判的是：「Bot 回得出第一句話，部署就完成了。」
其實第一句回覆只能證明當下模型、網路與訊息 adapter 剛好可用。它不能證明重新開機後會自動恢復，也不能證明群組權限正確，更不能證明認證過期時有人處理。
所以我的驗收拆成三層：
今天我重新讀回本機狀態：hermes 位於 /Users/user/.local/bin/hermes，安裝目錄是 /Users/user/.hermes/hermes-agent，實際執行版本為 Hermes Agent v0.21.0，Python 為 3.11.15。這些才是「裝好了」的本機證據。
至於訊息平台的端到端驗證，不能靠想像補上。那是下一個獨立工程問題。
────────────────────────────────
今天的結論
如果只是試玩，CLI 最快。如果要在電腦前完成知識工作，Desktop 最舒服。如果目標是讓 Agent 進入 Telegram、LINE 與排程，Gateway 才是正確起點。
我的選擇不是三選一，而是確認主從關係：Gateway 扛正式入口，CLI 保留可除錯性，Desktop 補人工操作。
下一篇 D3：接上訊息平台。Bot 能傳訊息還不夠，我會拆開 Telegram Gateway、allowed_chats 與端到端驗證，看看 Agent 怎麼真正變成「會回訊息的員工」。
iThome鐵人賽
看影片追技術