5 個關鍵設計 + 4 個上手步驟：我怎麼看 Hermes Agent 不只是另一個 CLI Agent

如果你最近在看開源 AI agent 專案，NousResearch/hermes-agent 很容易讓人停下來多看兩眼。原因不是它又多了一個聊天介面，或又多接了幾個模型供應商，而是它試圖回答一個更大的問題：一個 agent 要怎麼從一次性的對話工具，進化成能長期累積能力、跨平台持續運作的工作代理？

截至 2026 年 5 月 1 日，Hermes Agent 在 GitHub 已經來到約 12.7 萬星，最新 release 是 v0.12.0 (2026.4.30)。這個熱度當然會吸引很多人先把它當成另一個「AI CLI 工具」來看，但我實際讀完 README 與官方文件後，感覺更準確的說法是：它想做的不是一個更花俏的 terminal 聊天工具，而是一個把記憶、技能、排程、通訊入口、遠端運作環境整合在一起的 agent runtime。

如果你只是想找一個能在本機幫你寫點 code 的助手，Hermes Agent 不一定是最簡單的起點；但如果你關心的是 agent 能不能真的陪著團隊工作、持續學習、跨平台接任務，那它值得仔細看。我認為這個專案最值得注意的地方，可以拆成 5 個關鍵設計。

1. 它不是把 agent 綁在筆電裡，而是把 agent 當成長期在線的服務

Hermes Agent 官方首頁對自己的定義很直接：它不是綁在 IDE 裡的 coding copilot，也不是單一 API 的聊天包裝，而是一個會隨時間變得更有能力的 autonomous agent。官方文件甚至明講，它可以活在你放置它的任何地方，例如 VPS、GPU cluster，或接近閒置成本的 serverless 基礎設施，然後你可以從 Telegram 等訊息入口去叫它做事。

這件事乍看像「支援很多平台」，但我認為真正重要的是運作位置的轉移。很多 AI agent 工具的實際限制，不在模型不夠強，而在它永遠只能跟著你的 laptop 活著。當 agent 只能在本機 terminal 被叫醒，它更像一個互動式工具；當 agent 可以常駐在遠端、被訊息喚醒、被排程觸發，它才開始接近真正的工作代理。

這也是我覺得 Hermes Agent 和很多「本地 AI 助手」最大的分水嶺。它不是預設你只會坐在 terminal 前叫它幫你做一次性任務，而是先假設：你可能需要一個能跨裝置、跨平台、長期存活的 agent。

2. 它把 learning loop 放在核心，而不是把 memory 當裝飾

Hermes Agent 最有辨識度的主張，是它內建 learning loop。官方文件的說法很明白：它會從經驗中建立 skills、在使用中改進 skills、提示自己保存知識，並逐步形成跨 session 的使用者模型。

這一點值得特別拆開看。因為現在很多 agent 產品都會說自己有 memory，但很多時候那比較像「把偏好存起來」或「把舊對話做檢索」。這些不是沒價值，但它們比較像記住資訊，不一定等於形成能力。

Hermes Agent 比較特別的地方，是它把 skill system 直接放到產品中心。也就是說，它不是只想記得你說過什麼，而是想把某些重複做過的工作方式沉澱成可以重用的程序。這對真正的 agent 很重要，因為最浪費成本的事情不是模型思考太久，而是每次都從零開始做一樣的事。

當然，這種 learning loop 在真實工作流裡能不能長期穩定地產出高品質 skills，還要看實際使用。但至少 Hermes Agent 很明確地把這個問題攤在檯面上，而不是把單純的記憶系統包裝成學習系統。

3. 它把 messaging gateway 當成一級入口，而不是附加外掛

Hermes Agent 官方文件把 Messaging Gateway 擺在非常前面，支援的方向包括 Telegram、Discord、Slack、WhatsApp 等。對我來說，這不是「又多了一堆 bot 整合」而已，而是 Hermes Agent 對 agent 入口的理解跟很多工具不一樣。

很多團隊不缺一個能在 terminal 裡跑的 agent，真正缺的是：怎麼讓 agent 進入團隊原本就在工作的通訊環境裡。 如果你的工作流在 Slack，或你平常用 Telegram 記靈感、派任務、收整理結果，那麼一個只能在本機 CLI 使用的 agent，摩擦成本還是很高。

Hermes Agent 想解的，是這種入口摩擦。你不一定要坐回同一台機器前，才能叫它繼續工作。這也讓它比較接近「營運型 agent」，而不只是展示型 agent。展示型 agent 很擅長 demo；營運型 agent 則必須真的活在既有工作入口裡，讓人願意長期用。

但這也帶出它的另一個現實挑戰：當 agent 活在多個平台裡，權限、訊息隔離、身分驗證、工具批准與容器隔離都會變得更重要。Hermes Agent 文件把 security、approval、container 等主題列進架構裡，我認為這代表它至少是清楚知道問題在哪裡的。

4. 它對模型供應商的態度很務實，不想被單一 provider 綁死

Hermes Agent 的 quickstart 與 installation 文件都把模型切換寫得很清楚。你可以透過 hermes model 設定或切換 provider，而且官方說明也明講：可以隨時切換，不需要被鎖在單一供應商上。

這件事看起來不酷，但其實非常重要。因為現在 agent 系統的成敗，往往不是「哪個模型最強」決定的，而是：

成本能不能接受
延遲是否穩定
某個模型是否更適合工具調用
某個供應商是否在你的區域可用
你是否需要在 hosted 與 self-hosted 之間切換

如果 agent runtime 本身太綁模型，團隊很快就會卡住。Hermes Agent 的做法，至少讓基礎設施層和模型選型層保持分離。這對實務導入很重要，因為幾乎沒有任何團隊願意把 agent 架構完全押在單一 provider 上。

5. 它真正想做的，不只是聊天工具，而是一個可持續運作的 agent 作業層

如果只看功能列表，Hermes Agent 可以被描述成：

有 CLI 與 TUI
有 messaging gateway
有 scheduler
有 memory system
有 skills system
有 MCP integration
有 voice mode
有多種工具與外部整合

但如果只把它看成功能堆疊，我認為會低估這個專案。更準確的說法可能是：Hermes Agent 試圖把這些能力組成一個讓 agent 長期工作的最小操作環境。它不一定是作業系統意義上的 OS，但非常接近「agent OS」的早期雛形。

這也是我覺得它值得關注的原因。很多 agent 專案現在還停在單回合能力展示或 benchmark 優化；Hermes Agent 則更像在處理那些真的又髒又難、但更接近真實世界的問題：

記憶怎麼持續
技能怎麼沉澱
任務怎麼排程
人怎麼跨平台介入
工作怎麼在遠端長期活著
工具怎麼被真的整合進日常使用

這條路當然比較難，但也更接近導入價值。

怎麼開始用 Hermes Agent？我建議先做這 4 步

如果你想先判斷 Hermes Agent 適不適合自己，我不建議一開始就去接 Telegram、Slack 或排程。比較好的方式，是先用最短路徑把它跑起來，再決定要不要走向長期常駐的 agent 架構。

第 1 步：先在本機裝起來

官方目前提供的一鍵安裝方式是：

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

安裝完成後，重新載入 shell：

source ~/.zshrc

然後直接啟動：

hermes

根據官方 installation 文件，這個 installer 會自動處理 Python、Node.js、ripgrep、ffmpeg、repo clone、虛擬環境，以及全域 hermes 指令設定。也就是說，多數 Linux、macOS、WSL2 使用者不需要手動補很多前置。要注意的是，原生 Windows 並不是官方支援路徑，文件明確建議使用 WSL2。

第 2 步：先完成模型設定，不要急著接平台

裝好之後，第一件該做的事是：

hermes model

如果你還想順手看整體設定，也可以再跑：

hermes tools
hermes setup

Hermes Agent 目前要求模型至少有 64K context window，這點在 quickstart 文件也寫得很直接。這代表它不是隨便接一個小 context 模型就能順跑的 agent。對我來說，這個要求反而是一個好訊號，因為它表示 Hermes Agent 是真的把多步驟工具調用與長上下文工作流當成核心能力，而不是只做單輪問答。

第 3 步：用 CLI 或 TUI 做第一個真實任務

官方 quickstart 建議你不要只測聊天，而是直接給一個容易驗證的小任務。這點我很同意。比起輸入「你好」，你更應該試：

幫我整理這個 repo 的目錄結構
幫我摘要這個專案的主入口與工具鏈
幫我設計一個乾淨的 PR workflow
幫我檢查目前資料夾像不像一個可部署專案

Hermes Agent 目前提供兩個終端介面：

hermes
hermes --tui

官方把 hermes --tui 列為推薦路徑。你可以把它理解成比較現代的互動介面，但和 classic CLI 共用同樣的 sessions、slash commands 與 config。這點很實用，因為你不需要在兩種介面之間維護兩套工作狀態。

第 4 步：確認 session 可延續，再決定要不要接 gateway

我很喜歡 Hermes Agent quickstart 把「確認 resume works」單獨拿出來。官方建議你在第一次對話後，先測：

hermes --continue
hermes -c

如果 session 可以穩定接續，才值得往下一步走，例如 gateway、voice mode、scheduler 或 MCP。這是一個很實際的設計順序，因為它先確認 Hermes 作為長期工作代理最核心的能力：它是不是能延續你的工作狀態。

對我來說，只有當前面這 4 步順了，Hermes Agent 的真正價值才開始浮現。否則你看到的還只是另一個能聊天的 CLI。

限制與現實邊界

Hermes Agent 很吸引人的地方，正是它想碰的問題比較大；但這也代表它不是「裝完就零設定」的消費級產品。你還是需要理解：

你要選哪個模型供應商
哪些工具該開、哪些不該開
是否真的需要讓 agent 長期在線
是否要把它接進 Slack、Telegram 這類正式工作入口
是否願意承擔長期運作 agent 的治理成本

另一個現實限制是，它的能力組合很多，學習曲線自然也比較長。如果你只是要一個簡單的 code assistant，Hermes Agent 的架構野心可能反而會變成使用負擔。

Hermes Agent 比較適合誰先試？

如果你屬於下面幾種情境，我認為 Hermes Agent 很值得花時間試：

想把 AI 助手從本機工具升級成遠端常駐 agent 的團隊
想測試 skill-based learning，而不是只做 prompt chaining 的使用者
希望 agent 能進入 Telegram、Slack、Discord 等既有工作入口的團隊
不想被單一模型供應商綁死，想保留切換彈性的工程團隊
對 memory、skills、scheduler、MCP、gateway 有中長期需求的人

反過來說，如果你只需要一個輕量、本機、低設定成本的聊天或 coding 工具，Hermes Agent 不一定會是最順手的起點。

結語

我看 Hermes Agent 的最大感想是：它不是在問「agent 能不能更像人」，而是在問「agent 要怎麼更像一個可持續運作的工作系統」。

這兩個問題差很多。前者比較容易做出驚豔 demo；後者比較難，但也更接近真正的導入價值。Hermes Agent 把 learning loop、skills、memory、gateway、session continuity、model portability 拉在一起，至少給出了一個很清楚的方向：如果你真的想把 agent 當成長期協作對象，就不能只優化聊天體驗，還得連運作環境一起設計。

而這，正是我認為它不只是另一個 CLI agent 的原因。

參考資料