<!-- Source: https://hermesbible.com/flows/why-i-open-the-hermes-dashboard-every-day -->

滾動 Hermes 的 Twitter、Reddit，或這網站上的 flows。你會找到很多關於 SOUL.md、多 Agent 設定、Telegram 閘道、/goal、Polymarket 交易機器人和 9 小時隔夜工作流程的貼文。

你會少很多看到 hermes dashboard 作為日常操作介面的內容。官方文件涵蓋得很好。社群文章很少做到。

我認為這是一個缺口——這可能也是為什麼很多人在安裝後的蜜月期就停滯了。他們設定 Hermes Desktop 或執行一次 hermes chat，在 YAML 中配置一切，忘記他們的 Agent 實際做了什麼，然後 wondering 為什麼 Hermes 感覺像一個花哨的聊天應用程式而不是一個系統。

當我想和 Agent 聊天時，我使用 Hermes Desktop——那是我的主要聊天介面，不是原始終端機。當我想讓 Hermes 找到我時，我使用 Telegram。但我每天都開啟 dashboard，因為那是一個瀏覽器分頁中就能看到和操作整台機器的地方。而當我確實想要 CLI 時，我不需要另一個終端機：dashboard 的 Chat 分頁在瀏覽器中嵌入了完整的 TUI（hermes --tui）。

這不是功能導覽。這是一個誠實的說明，解釋為什麼那個無聊的瀏覽器分頁成為了我 Hermes 設定中最重要的視窗。

內容缺口（相對的，不是絕對的）

Hermes 有很多介面，社群注意力不均：

Dashboard 拍不出好照片。沒有戲劇性的前後對比。沒有一個 170 行的 markdown 檔案可以分享。也沒有「我的 Agent 在我睡覺時賺了 $12」的標題。

它是一個在 localhost:9119 的本地管理 UI。它看起來像設定頁面和表格。所以很多人跳過它——然後 wondering 為什麼他們的 MCP 伺服器在三天前就默默停止運作了。

公平地說：Hermes Desktop 共享相同的後端並涵蓋重疊的領域（技能、Cron、頻道、設定檔）。我用 Desktop 聊天，用瀏覽器 dashboard 做運維——它們是互補的，不是競爭的。官方文件有一個完整的 Web Dashboard 頁面。缺少的是實務者的角度——有人說「我就在這裡工作，以下是我的實際日常」。

Dashboard 實際長什麼樣

在目前的 Hermes（v0.17）中，開啟 http://127.0.0.1:9119/ 會落在 Sessions——預設不是聊天。左側邊欄是所有東西的地圖：Chat（真實的 TUI，透過 PTY——斜線命令、工具卡片、批准）、Sessions、Files、Models、Logs、Cron、Skills、Plugins、MCP、Channels、Webhooks、Profiles、Config、Keys、System。

我大部分從 Hermes Desktop 聊天，但當我已經在瀏覽器中配置東西時，dashboard Chat 分頁是同一個 Agent。

在那個邊欄的底部，一個 System 條顯示閘道狀態、活躍 session 和快速操作（重新啟動閘道、更新 Hermes）。那是我早上讀任何 session 之前的心跳檢查。

當我不再忽略它時改變了什麼

我舊的工作流程：編輯 config.yaml，從記憶中執行 hermes mcp add，在終端機中 grep 日誌，希望閘道還在運行。

我現在的工作流程：第一件事打開 dashboard，讀取邊欄 System 條，快速掃過 Sessions，我就立刻知道是否有問題，在浪費一個聊天回合之前。

這個單一習慣改變了一切。Dashboard 不是我的主要聊天視窗——Desktop 才是。它是我操作 Hermes 的地方。

我的日常 dashboard——我實際開啟什麼

以下是我普通一天的樣子。不是理想化的。不是設定指南。只是我點什麼。

早上：Sessions + 邊欄狀態（2 分鐘）

我保持 dashboard 後端運行——在我的機器上 Hermes Desktop 會自動做這件事，或者我在一個長時間運行的 tmux/systemd session 中執行 hermes dashboard。然後我只打開瀏覽器：

http://127.0.0.1:9119

首要檢查：

• 邊欄 → System： 閘道在運行嗎？有多少活躍 session？
• Sessions 頁面： 訊息總數、每個來源的明細（CLI、cron、Telegram…）、已連接的平台

如果一個 cron job 在凌晨 3 點運行並向 Telegram 傳送了垃圾訊息，我不會從訊息本身發現——我會在 Sessions 中發現。我在訊息內容中搜尋（dashboard UI 中的 FTS5），展開 cron session，閱讀工具呼叫，精確地看到哪裡出了錯。

CLI 也能做相關的工作。我仍然更喜歡 dashboard，因為我在一個視覺流程中獲得搜尋 + 完整歷史 + 工具呼叫檢查。

當我新增或修復整合時：MCP（5 分鐘）

每當我連接一個新工具——GitHub、資料庫、內部 API——我使用 MCP 分頁，而不是原始 YAML 編輯。

為什麼？因為有 Test 按鈕（閃電圖示）。它連接、列出工具、斷開。我在開始聊天 session 之前就知道整合有效，不用 wondering 為什麼 Agent 看不到我的工具。

我已經數不清多少次了，我在 config.yaml 中有一個伺服器是 enabled: false，或者在環境變數中有打字錯誤，或者需要閘道重啟。MCP 分頁用視覺化方式顯示所有這些。啟用、測試、從 Channels 或 System 重啟閘道，搞定。

根據官方文件，MCP 啟用/停用在下一次閘道重啟時生效——不是在 session 中間立即生效。

當 Agent 感覺「不對勁」時：Skills（3 分鐘）

在我怪罪模型之前，我先打開 Skills：

• 我預期的技能真的啟用了嗎？
• 正確的工具集是活躍的嗎？
• 有什麼東西被封存了嗎？（背景 curator 會把長期未使用的Agent 建立的技能移到 ~/.hermes/skills/.archive/——檢查 System → Skill curator 或 hermes curator list-archived，而不只是啟用開關。）

一個使用頻繁的 Hermes 實例會累積數十個技能。它們在日常聊天中是不可見的——你不會看到 Agent 載入了哪個劇本。Skills 分頁是程序記憶變得有形的地方。關掉一個，開始新的 session，注意差異。

當我想讓 Hermes 不需要我也能工作時：Cron

我在 Cron 分頁中建立和除錯 cron job，不只是 CLI。

因為我需要看到：

• 這個 job 是暫停的還是出錯的？
• 它上次什麼時候運行？
• 投遞目標是什麼？

當我在測試時，我按 Trigger now 而不是等待排程。

當我對成本好奇時：Analytics

這個分頁完全沒有炒作。我愛它——當它啟用的時候。

每日 token 使用量。每個模型的使用量。估計成本。快取命中率。在一個重度使用週後，我打開 Analytics 看看是否應該換模型、減少 cron 頻率，或修復一個失控的 job。

注意： 在 v0.17 中，本地 token 分析預設可能隱藏。如果你看到「TOKEN ANALYTICS HIDDEN」訊息，在 Config（或 config.yaml）中設定 dashboard.show_token_analytics: true。數字是估計值——查看你的提供者 dashboard 以取得權威的帳單。

當有東西壞掉時：Logs + System

Logs——按 gateway/agent/errors 過濾、即時追蹤、找到那一行。

System——主機統計、閘道 啟動/停止/重啟、記憶提供者、憑證池、doctor、備份/還原、skill curator。

當我想和 Agent 互動時，我用 Hermes Desktop。當有東西出錯時，或當我需要改變 Agent 運行方式時，我用 dashboard。

為什麼我認為很多人跳過它

根據我的經驗，三個原因：

1. 它看起來像管理 UI，不是魔法。

SOUL.md 貼文會散播，因為它們是可複製貼上的身份檔案。Dashboard 貼文會是表格的截圖。比較不那麼好分享。但更有用。

2. 人們把聊天當成整個產品。

Hermes Desktop、dashboard Chat 分頁和終端機中的 hermes chat 都和同一個 Agent 聊天。很容易在安裝了其中一個之後就覺得你「看過 Hermes 了」——從來不打開 Sessions、MCP 或 Cron。聊天介面是真實的；它們只是不是運維層。

3. 只有 YAML + Desktop 在不行之前是夠好的。

當你只有一個設定檔、少數幾個技能、沒有 cron 時，一個乾淨的 Desktop 安裝工作得很好。但當你有多個設定檔、數十個技能、多個 MCP 伺服器、一個 Telegram 閘道、以及向多個平台投遞的 cron job 時，就變得更難了。那是基礎架構——而基礎架構受益於一個控制面板。

讓它點亮的那一個概念

Hermes Desktop（或 dashboard Chat 分頁）是用來聊天的。

Dashboard 是用來管理聊天的系統的。

Hermes 會持久化記憶、技能、session、cron 和訊息，無論聊天視窗是否開啟。Dashboard 是我看到那個狀態的地方。Desktop 和 dashboard 共享相同的設定——我各用它們最擅長的地方。

一旦我內化了這一點，我就不再把 hermes dashboard 當作可選的。

Desktop vs. dashboard vs. CLI——我實際如何分配

Desktop 是我的 Agent UI。Dashboard 是我的控制室。

重點

社群發表了很多關於人格檔案、訊息機器人和隔夜迴路的文章——都很有價值。

但日常運維——保持一個 24/7 Agent 健康的不起眼工作——獲得的關注比 SOUL.md 帖文少得多。對我來說，dashboard 就是那項工作發生的地方。

如果你已經過了「我安裝了 Hermes，它能聊天」的階段，想讓它真正運作，打開 dashboard。從 Sessions 和邊欄 System 條開始。當有東西壞掉時搜尋 Sessions。在信任 MCP 伺服器之前先測試它。

它不豪華。它是我發現的 Hermes 中最強大的部分。