我第一次注意到 Hermes Agent 的時候，早就已經晚到算不上早鳥了。
那天是禮拜四——2026 年 3 月 12 日。沒有主題演講，沒有倒數，X 上也沒發啟動串。Nous Research 只是推了一個 git tag，把 GitHub 倉庫翻成 public，然後在自家 Discord 裡丟下一句："這東西現在存在了。"到禮拜五早上，倉庫已經超過一千顆星，散在二十個時區的人正在爭到底該走哪條安裝路徑。
在那個 tag 打出來之前的兩個禮拜裡，六十三位素未謀面的貢獻者一起往專案裡推了 216 個 PR、關掉 119 個 issue，把測試套件從幾乎為零一路做到了 3,289 條測試。沒有一個是 Nous Research 的員工。他們隔著 GitHub 的留言區吵，吵到第十四天，把一個真的能跑的東西發了出來。
那麼盒子裡到底裝了什麼？
一個行程，七扇前門
v0.2.0 的主角是多平台訊息閘道。一個 Hermes 行程同時掛在 Telegram、Discord、Slack、WhatsApp、Signal、IMAP/SMTP 郵件和 Home Assistant 上面。同一套會話管理、同一份記憶、同一個工具註冊表。每個平台你可以分別設定哪些技能可用、附件怎麼處理，但另一頭的 agent 永遠是同一個 agent。
這件事比聽起來有趣，因為一般的替代方案——七個各自為政的 bot，每個都自己一套狀態——是個災難。記憶會分叉，工具狀態會跑掉對不齊。Hermes 讓閘道本身變成整合點，agent 始終只有一個。你把它裝在一台 5 美金的 VPS 上，手邊開著哪個 app，都能在那個 app 裡碰到同一個 agent。
原生 MCP，不是外掛貼上去的
緊挨著閘道的是一個完整的 Model Context Protocol 用戶端。stdio 和 HTTP 兩種傳輸都支援，涵蓋斷線重連、資源與 prompt 探索、伺服器端主動觸發的 sampling。給不太熟 agent 這塊的讀者解釋一下：MCP 是 Anthropic 發布的一套開放標準，目的是讓 LLM 用一致的方式跟外部工具說話。大多數框架是事後才拿 MCP 往舊的工具呼叫系統上貼一層轉接器。Hermes 從第一天起就把它直接接進核心——任何會講 MCP 的工具都能直接用，不用再包一層。
技能是一等公民
v0.2.0 一次就附上七十多個內建技能，分布在十五個類別底下，背後是專案裡叫作 Skills Hub 的那套機制：條件啟用（只有前置條件齊了，技能才會載入）、前置條件檢查、社群探索。這個 Hub 後來就變成了 agentskills.io。第一天就有的技能包括影像分析、沙盒裡跑 Python、檔案搜尋、抓網頁，再加上另外好幾十個。
這裡的技術選擇是：技能是宣告式的單元，帶 manifest、相依性、啟用條件——而不是在 import 的時候才註冊進去的 Python 函式。這就是為什麼一個 agent 可以同時背著七十個技能，而不會把 prompt 撐爆。
服務供應商路由器和那張安全網
v0.2.0 裡還有兩個架構層面的決定，把之後的一切都定了調。
第一個是集中式的服務供應商路由器。一個統一的 call_llm() / async_call_llm() API，取代了原本散落在視覺、摘要、壓縮、軌跡存檔各處的供應商邏輯。所有輔助呼叫者都走同一條程式碼路徑，憑證也由路由器自動解析。聽起來很無聊，直到你真的要換供應商——那一刻你只需要改一個檔案，而不是十一個。
第二個是安全雙保險：git worktree 隔離（hermes -w 會把每個會話丟進一個獨立的 worktree，所以 agent 不可能手滑碰到你真正的程式碼）和帶回復功能的檔案系統檢查點（破壞性操作前先打快照，用 /rollback 撤回）。這套機制讓 agent 敢放開手腳，因為你真的能把它拉回來。這就是「一個小心翼翼的 AI 助理」和「一個敢放手去做、而系統替它小心的 AI 助理」之間的差別。
還有編輯器那一頭
發布說明裡被埋掉、但其實很重要的最後一件事：ACP 伺服器支援。透過 Agent Communication Protocol，Hermes 原生接進 VS Code、Zed 和 JetBrains。它不再只是「一個躲在終端機裡的東西」，而是住進了你真正在用的那個編輯器裡面。
---
我老是回頭想起三月那個禮拜四。沒有公告、沒有投影片、沒有投資人電話——只有一個 git tag、一次公開翻轉，加上門打開那一刻剛好在裡面的那六十三個人。如果這個部落格後面那些文章要有一個主題，那主題就是：蓋 Hermes 的這群人跑得有多快這件事，比任何一個單獨功能本身跑得有多快都要重要得多。