Hermes WebUI：Hermes Agent 的瀏覽器前端

面向伺服器端 agent 的瀏覽器介面

Hermes WebUI 是 Hermes Agent 的瀏覽器介面。README 將 Hermes Agent 描述為駐留在伺服器上的自主 agent，通常透過終端機或訊息應用程式存取。WebUI 是一個輕量、深色主題的網頁應用程式，目標是盡量與 CLI 體驗對等：README 宣稱終端機裡能做的每件事都能在介面裡完成。專案明確表示沒有建置步驟、沒有框架、沒有打包器，只有 Python 和原生 JavaScript。倉庫描述稱其為從網頁或手機使用 Hermes Agent 的最佳方式。

標準程式庫伺服器與原生 JS 前端

後端不是網頁框架，而是 Python 標準程式庫 HTTP 伺服器。後端程式碼位於 api/，server.py 是路由外殼和認證中介層，routes.py 用 if/elif 分派處理所有 GET 和 POST 路由，不使用裝飾器。其他模組處理認證、設定自動偵測、工作階段模型、SSE 串流引擎、上傳和工作區檔案操作。前端 static/ 由一組原生 JS 檔案組成：ui.js 處理 DOM 輔助與工具卡片，workspace.js 處理檔案操作與 git 偵測，messages.js 處理 SSE，panels.js 實作控制中心，commands.js 實作斜線指令補全。狀態預設存放在倉庫之外的 ~/.hermes/webui/。

三欄版面、composer 底部欄與控制中心

介面是三欄版面：左側邊欄放工作階段和導覽，中間是聊天，右側是工作區檔案瀏覽。模型、設定檔與 workspace 控制項位於 composer 底部欄，撰寫訊息時永遠可見。圓形上下文環顯示 token 用量。所有設定與工作階段工具都收在 Hermes 控制中心，從側邊欄底部啟動。外觀分為兩個軸：Theme（system、dark、light）和 Skin（ares、slate、poseidon、catppuccin、nous 等），以 data-skin 屬性加上 CSS 變數實作，暗色模式透過 .dark 類別解析。

啟動方式：bootstrap、start.sh 與 ctl.sh

README 記錄了三種啟動方式。python3 bootstrap.py 會偵測 Hermes Agent，缺失時嘗試用官方安裝腳本安裝，建立或找到具備 WebUI 相依套件的 Python 環境，啟動伺服器並等待 /health，然後開啟瀏覽器（除非傳入 --no-browser），並進入首次執行的引導精靈。./start.sh 是 shell 啟動器。對自架 VM 或 homelab，ctl.sh 封裝常駐程式生命週期指令（start、status、logs、restart、stop），不需要 fuser 或 pkill，PID 寫入 ~/.hermes/webui.pid，日誌寫入 ~/.hermes/webui.log。停止方式因啟動方式而異：bootstrap.py 在前景執行，按 Ctrl-C 即可；ctl.sh stop 只能管理它自己啟動的行程。bootstrap 目前不支援原生 Windows，需使用 Linux、macOS 或 WSL2。社群維護的原生 Windows 方案有獨立文件，社群量測的記憶體占用約為原生 330 MB，對比 WSL2 加 Docker 的 1080 MB。

聊天在 WebUI 程序內執行

預設情況下 WebUI 在程序內執行 Hermes Agent，直接讀取 HERMES_HOME 設定，不會為了聊天而連線外部 Hermes 或 OpenAI 相容 API 伺服器。README 明確指出 HERMES_API_URL 只被 Tasks/cron 健康探針讀取，不參與聊天路由。README 給出兩個使用外部端點的選項：在設定中加入自訂 OpenAI 相容 provider（填入 base_url），或設定 HERMES_WEBUI_CHAT_BACKEND=gateway 把聊天路由到 Hermes Gateway API 伺服器；完整的 agent 迴圈委派尚未發布，追蹤於 issue #1925。start.sh 會自動偵測大部分設定：agent 目錄、Python 可執行檔、狀態目錄、預設 workspace 與連接埠，必要時可用 HERMES_WEBUI_* 環境變數覆寫。

Docker、Nix 與遠端存取

預先建置的 Docker 映像檔（amd64 與 arm64）在每次發布時推送到 GHCR。單一容器 compose 檔案在程序內執行 agent，README 稱其為五分鐘的順利路徑；雙容器與三容器 compose 檔案把 agent 與 dashboard 分開。compose 檔案預設使用具名磁碟區，從結構上避開 UID/GID 不一致。已知限制（#681）是雙容器設定中從 WebUI 觸發的工具會在 WebUI 容器內執行，而不是 agent 容器。專案還有 Nix flake 套件與 NixOS 服務模組，支援宣告式安裝。遠端存取預設綁定 127.0.0.1；文件化的路徑是 SSH 隧道（ssh -N -L 8787:127.0.0.1:8787 user@host），或把伺服器與手機加入 Tailscale 網路並設定 HERMES_WEBUI_HOST=0.0.0.0 與 HERMES_WEBUI_PASSWORD。

版本配對與測試套件

README 對耦合問題直言不諱：WebUI 直接匯入 Hermes Agent 模組（api/config.py、api/providers.py、api/streaming.py），也直接讀取 agent 的狀態結構，因此版本錯位可能導致匯入或行為漂移。發布分支只針對對應的 agent 版本測試；政策是一起升級或一起固定版本，在 #1925 與 #2491 的穩定邊界工作完成前，固定為較舊或較新的組合屬於未測試且不受支援。Docker 使用者被要求固定兩個映像標籤，而不是一側用 latest。測試規模很大：約 11,500 個測試、約 1,150 個測試檔案，CI 在 Python 3.11、3.12、3.13 上各跑三個平行分片。測試在隔離的伺服器與獨立狀態目錄中執行，README 明確表示不會觸碰正式環境資料與真實 cron 任務。

針對 Hermes WebUI，請用 python3 bootstrap.py 啟動，再以 /health、工作區檔案瀏覽與 ~/.hermes/webui.log 檢查服務狀態；若使用 ctl.sh，另確認 PID 與停止路徑。 第1項檢查仍須記錄 hermes-webui 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第2項檢查仍須記錄 hermes-webui 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第3項檢查仍須記錄 hermes-webui 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第4項檢查仍須記錄 hermes-webui 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第5項檢查仍須記錄 hermes-webui 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第6項檢查仍須記錄 hermes-webui 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第7項檢查仍須記錄 hermes-webui 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第8項檢查仍須記錄 hermes-webui 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。

編輯結論

專案採用 MIT 授權。相容性方面，README 很明確：WebUI 與 hermes-agent 要一起升級或一起固定版本，因為在 #1925 與 #2491 的穩定 agent 邊界工作完成前，執行不匹配的版本組合是未測試且不受支援的。

官方來源

1. Official documentation
2. Official README
3. Project repository
4. Release notes