web_search / web_extract 失敗時完全沒有提示,使用者可能不知道搜尋功能已失效
當未設定任何 web backend API key 時,web_search 和 web_extract 會靜默失敗或回傳空結果,不會提示使用者搜尋功能不可用,可能導致使用者數週都不知道核心搜尋功能已失效。issue 建議在失敗時回傳明確錯誤訊息與解決步驟。
config.yaml 與環境設定相關的官方 issue。 資料來自官方 GitHub repo,狀態由官方 label 推導,每筆附原始連結與最後檢查日期。
當未設定任何 web backend API key 時,web_search 和 web_extract 會靜默失敗或回傳空結果,不會提示使用者搜尋功能不可用,可能導致使用者數週都不知道核心搜尋功能已失效。issue 建議在失敗時回傳明確錯誤訊息與解決步驟。
使用者透過飛書(feishu)與 hermes agent 對話,發送 /model xxx --provider xxxx 切換模型時,agent 會自動把這個模型與 provider 設成 config.yaml 的預設值(並回覆「Saved to config.yaml (--global)」),但使用者並未輸入 --global 參數,預期應該只改變當前執行期的模型設定。
當 config.yaml 的 agent.disabled_toolsets 包含複合 toolset(如 coding)時,Hermes 會扣除該複合 toolset 底下所有工具,即使使用者已明確啟用 terminal 和 file 這兩個子 toolset,最終結果是模型收到零個工具,過程中沒有任何警告,UI 上(/toolsets、hermes tools)仍顯示 terminal 和 file 是啟用的。
當 profile 的 config.yaml 出現 terminal:(有 key 但沒有值)這種空欄位時,YAML 會解析成 None,導致 load_cli_config() 用 defaults.get("terminal", {}) 拿到的是 None 而非預期的空字典,後續判斷式因此拋出 TypeError,使 agent 在第一輪對話前就直接當機。
使用者同時執行多個 Hermes profile,但發現非 default profile 在多個子系統中被當成次等公民對待,例如 cron job 會寫到錯誤 profile 的目錄、dashboard 功能只看得到 default profile、Desktop App 完全忽略非 default 的 session。issue 把這些個別問題彙整成一個總覽,指出根因是程式碼假設 ~/.hermes/(default 根目錄)才是唯一正式路徑。
在 Windows 上,一個無害的自訂 config key 會讓 _normalize_custom_provider_entry() 在每次 load_picker_context() 呼叫時都印出警告,配合 Windows 上 concurrent-log-handler 的跨程序鎖,大量警告觸發 RuntimeError: Cannot acquire lock after 20 attempts 並重試,佔滿 CPU 並讓 asyncio 事件迴圈卡住約 14 秒,導致所有 desktop / TUI WebSocket 斷線,而 /health 端點仍顯示健康。
回報者指出更新 Windows 系統自身的 Node.js 版本後,Hermes 會使用系統的 Node.js 而非內建版本,因版本不同導致終端機視窗持續閃爍。預期行為是 Hermes 應一律使用其內建的 Node.js。
回報者指出在 config.yaml 設定 platforms.weixin.enabled: false 後,只要 .env 中仍存在 WEIXIN_ACCOUNT_ID、WEIXIN_TOKEN 等環境變數,gateway 啟動時仍會照常連上微信/iLink 平台,未遵守 enabled: false 的設定。此 issue 已關閉。
把 gateway.multiplex_profiles 從 true 改回 false 後,先前在多工模式下建立的 profile session 仍殘留在共用的 state.db 中,gateway 會持續讀到這些過期 session 並把訊息路由到錯誤的 profile,即使該 profile 的 gateway 已停用。
此 issue 標題回報使用者在嘗試新增某個 address model API 時遇到錯誤且功能無法運作,內文僅附上一個外部文件連結與一張截圖,未提供進一步文字說明。
回報者指出在 Windows 上使用 Hermes 桌面版狀態列的聊天模型選擇器切換模型時,會直接修改全域的 ~/.hermes/config.yaml,而非按文件所述僅套用於當前 session;預期應該只有透過 Settings → Model 才會變更全域預設值。
在 macOS 桌面版切到自建 profile(例如只設定 WeChat 的 rucy)時,UI 仍會顯示屬於 default profile 的 sessions、通訊頻道與 cron jobs,屬於 UI 層的跨 profile 資料外洩。
這個 issue 指出即使先前 PR #47276 的修復曾經成功,在拉取最新程式碼更新後 Desktop build 又再次失敗,因為更新過程會清除 Electron binary 快取,出現「electronDist does not exist」錯誤,顯示 #47266 的修復並未徹底解決問題。此 issue 已關閉。
回報者指出在桌面版(與 TUI gateway)點擊任何舊對話續接時都會失敗並顯示「resume failed: No LLM provider configured」,即使目前設定的預設 provider 完全有效、開新對話也正常;同樣的 session 用 CLI 的 hermes chat --resume 卻能正常續接,僅桌面版/TUI 的 resume 路徑會失敗,回報者已定位到 server.py 中 _stored_session_runtime_overrides() 的 provider 讀取邏輯疑似有問題。
回報者指出在 config.yaml 中設定 terminal.cwd 對 local 終端機後端完全無效,根因是 cli.py 中有一段無條件覆寫邏輯,當後端為 local 時會直接用 os.getcwd() 蓋掉設定值,導致該設定只在 docker、ssh 等非 local 後端才生效。
Hermes Desktop 目前對許多已知 provider 有內建 API key 欄位,但對自訂的 OpenAI 相容端點(如 AI Router、LiteLLM、自架 gateway 等)只有部分 UI 支援,使用者只能借用其他 provider 的欄位或手動編輯設定檔,容易造成混淆並限制模型清單。此 issue 提議在 Providers 設定中直接加入「Custom provider」選項,只需填 Base URL 與 API key。
目前只能借用 LM Studio 等其他 provider 的欄位,或手動編輯設定檔/環境變數。
回報者指出在 Hermes Desktop 中,即使在 Settings 中正確設定了新的 Working Directory 並寫入 config.yaml 的 terminal.cwd,若 renderer 端的 localStorage 已記住舊的 workspace 路徑,新 session 仍會在舊目錄啟動,造成 UI 顯示已設定新路徑但實際行為不一致。
回報者想把 Hermes Desktop 安裝成連線到遠端既有 Hermes 服務的輕量用戶端,但現況是只要偵測不到本機安裝,桌面 App 就一定會在首次啟動時自動跑 electron/main.cjs 裡的 bootstrap,執行 install.ps1 安裝 Python、Node 等依賴,沒有官方提供的純用戶端安裝版本。
body 提到可在首次啟動前先設定環境變數 HERMES_DESKTOP_REMOTE_URL 與 HERMES_DESKTOP_REMOTE_TOKEN,讓桌面 App 改連線遠端後端、跳過本機後端啟動;但 Electron 外殼本身仍會被安裝,且一旦取消設定這兩個環境變數,下次啟動仍會嘗試 bootstrap 本機環境。
回報者指出當 auxiliary 任務(如 auxiliary.vision)同時設定 provider、base_url 和 api_key 時,provider 名稱會被系統忽略並強制改為 custom,導致原本針對特定 provider 的處理邏輯(如 ZAI vision 的 max_tokens 略過、Anthropic transport 偵測等)被跳過,引發後續錯誤。
此 issue 指出 Hermes 目前維護兩套互不相通的 fallback 機制:使用者在 config.yaml 設定的 fallback_providers,以及給 compression、vision、title、web_extract、curator 等輔助任務使用、寫死在程式中的另一份 fallback 清單(含付費模型)。主要 agent 走使用者設定的 fallback_providers,但所有輔助任務卻走另一份寫死清單,兩者彼此不知道對方的存在。
此 issue 是 #3630(外部 Vault 支援)的子項目,指出目前支援的外部 Vault 清單(HashiCorp Vault、AWS Secrets Manager、1Password CLI、Bitwarden CLI)缺少對 self-host 使用者很重要的 Infisical。回報者說明若採用 Infisical 建議的多專案架構,Hermes 目前沒有原生方式讀取這些機密。
目前只能用寫死單一專案 ID 的外部 shell wrapper,或把所有機密合併成一個扁平專案,兩者都違背 Infisical 多專案架構的用意。
此 issue 提議把 Mistral 加入 Hermes-Agent 原生支援的 LLM provider 清單,理由是 Mistral 使用者基數比某些既有支援的 provider 更大,且其語音模型已經整合進 Hermes,作者認為新增文字 LLM 應該不會太困難。目前只能透過 custom provider 選項使用 Mistral,較不方便。
目前 Hermes 的設定、profile、skills、session 與 memory 都只存在本機 ~/.hermes/ 目錄,多台裝置間沒有內建同步機制,使用者需手動匯出匯入。此 issue 提議加入內建雲端同步功能,涵蓋 config、profiles、skills、memory、sessions 與憑證。
目前只能手動匯出匯入 profile、複製 skills 資料夾,在各裝置間手動同步設定。
提案指出目前 Hermes 整個 session 只能用同一個模型,若平時用便宜或快速模型,遇到需要更強推理能力的回合時,只能手動切換模型(之後還要再切回來)或硬著頭皮用弱模型應付;提案建議新增 model_presets 設定,讓使用者能為單一回合臨時呼叫指定的 provider 加 model 組合,用完自動切回預設模型。
目前 compression.threshold 是全域單一數值,對 1M context 模型(如 DeepSeek V4 Flash)門檻形同虛設,對小 context 模型又太保守。issue 提議在 config.yaml 新增依 provider 或依模型覆寫 threshold 的設定選項。
設定 Hermes 使用 deepseek provider 搭配自訂 OpenAI-compatible 端點(如 Volcengine ARK)時有兩個 bug:非標準模型名稱會被強制正規化成 deepseek-chat 導致遠端回傳 404;credential pool 的 base_url 每次啟動都會被硬編碼預設值覆寫,忽略 config.yaml 或 auth.json 中的自訂設定。
目前只有設定 DEEPSEEK_BASE_URL 環境變數能讓自訂端點生效,但官方文件並未將其列為正式設定方式。
目前要把 OpenCode Go 這類新模型串進 Hermes Agent,沒有明確或簡單的擴充機制,開發者必須深入內部程式碼才能實驗替代的 LLM provider 或自架推論服務。此 issue 提議建立設定式(YAML/JSON)的模型註冊機制與標準化 adapter 介面。
此 issue 提議為 Hermes 儲存在 ~/.hermes/ 的所有 agent 資料(記憶、skill、對話紀錄、輸出)內建自動備份機制與版本控制,避免使用者因硬碟故障等問題遺失 agent 累積學到的狀態,目前使用者只能自行架 cron job 或第三方工具。提案包含新增 hermes backup CLI 指令,可立即快照或設定每日排程等用法。
hermes dashboard 預設綁定在 127.0.0.1:9119,且程式碼中 CORS 的 allow_origin_regex 寫死只允許 localhost/127.0.0.1,即使加上 --host 0.0.0.0 讓前端能載入,後端 API 呼叫仍會被 CORS 擋下,導致無法透過 Tailscale 等 VPN 遠端存取 dashboard。此 issue 提議開放設定 dashboard 的 host/port 與 CORS 來源。
此 issue 提議讓使用者能定義多個具名「角色」(例如營養師、開發者、財務顧問),各自擁有專屬 session 與系統提示,並用一個輕量分類器(如 Gemini Flash)自動把訊息路由到對應角色,藉此解決目前 Hermes 所有話題共用單一 session、單一人格,導致不同主題互相污染 context、無法給予特定領域專長、且需要使用者手動用 /title、/resume 管理 session 的問題。作者註記此提案在 2026 年 5 月已針對 v0.14.0 架構大幅重寫為 v2 版本,取代舊版有缺陷的做法,改用更乾淨的 contextual classifier 與誤路由回復機制,原始 v1 提案保留在摺疊區塊作為歷史紀錄。
這個 issue 指出目前用同一個 gateway 跑多個 Telegram 群組或 Discord 伺服器時,所有 session 都共用同一組人格、system prompt、CLAUDE.md 與工作目錄,無法針對不同群組或討論串客製化。提案在 config.yaml 新增 topic_configs 區塊,依平台與聊天室 ID 對應各自的設定覆寫。
提案指出目前 gateway 對所有頻道只能使用同一組全域模型與 system prompt,但 Discord 或 Telegram 群組中不同頻道常有不同用途(如低成本摘要頻道、程式開發頻道、閒聊頻道),因此建議新增 channel_overrides 設定,讓每個頻道可個別指定模型、provider 與 system prompt,並定義優先順序(/model 指令高於 channel_overrides,channel_overrides 高於全域設定)。