[Bug] xAI grok-4.3 在 MCP 工具呼叫中丟失選填多行字串參數，AgentMail 寄出空白信
回報者發現在 provider xai-oauth 配 grok-4.3（codex_responses 模式）時，AgentMail 的 send_message 每次都寄出主旨與內文都空白的信，但工具回報成功，agent 無法自我修正。此 issue 由 AI agent 調查並代表帳號擁有者提交，附可重現的證據。
Agent 核心（80 筆）
agent 主流程、工具呼叫與模型行為相關的官方 issue。 資料來自官方 GitHub repo，狀態由官方 label 推導，每筆附原始連結與最後檢查日期。
[功能請求] 執行任務前自動載入相關 skills
回報者指出 agent 裝了很多 skill 卻常常忘記載入：遇到任務不先查 skill，而是憑空猜參數或反問使用者。根因是 skill 是被動的，缺少「分析請求並提示相關 skill」或自動注入 skill context 的機制。
[Bug] context 壓縮打斷 tool 訊息鏈，嚴格 provider 回 400（tool 訊息缺少對應 tool_calls）
長 session 觸發 context 壓縮時，可能把帶 tool_calls 的 assistant 訊息壓掉、留下孤兒 tool 訊息，違反 OpenAI Chat Completions 契約。DeepSeek 等嚴格 provider 會回 HTTP 400，寬鬆的 provider 可能默默吞掉。此 issue 已關閉。
[提案] 把 Hermes 當作 Gotong 治理工作流中的個人 agent 層
Gotong 專案作者提出整合構想：Hermes 繼續當個人 agent / 記憶 / 推理層，Gotong 提供外圍的治理協作基底（任務派發、人工審批、append-only 紀錄、MCP/A2A 邊界）。屬於外部專案的整合提案。
壓縮功能當機：_summarize_tool_result 出現 AttributeError 'dict' object has no attribute 'count'
當 write_file 工具結果的 content 參數被解析成 dict 而非字串時，context compression 會在 _summarize_tool_result 拋出 AttributeError 而當機，導致壓縮功能完全失效，session 持續增長直到超過 context window。
Subagent 委派（delegation）忽略設定，永遠使用 credential pool 裡的 glm-4-flash 模型
即使將 delegation 設定為指定的 provider / 模型（如 NVIDIA NIM 的 deepseek-v4-flash），subagent 仍完全忽略該設定，永遠使用 credential pool 中的 glm-4-flash（Zhipu）。issue 附上 5 次測試皆重現此問題，包含 delegation 設定為空時也未如預期繼承 parent 模型。
[Bug] minimax-oauth provider 明明是 OAuth，卻仍要求設定 API key 環境變數
當 auxiliary.title_generation 設定為 minimax-oauth provider 時，Hermes 仍會嘗試讀取 MINIMAX-OAUTH_API_KEY 環境變數，即使該 provider 應該透過 hermes auth add 的 OAuth token 認證，導致標題產生功能報錯。
暫時解法
錯誤訊息本身建議可暫時用 hermes model 切換到其他 provider 以避開此錯誤。
Anthropic OAuth 用量顯示錯誤：低用量時段被誤算成 100% 已用
/usage 儀表板在 Anthropic OAuth 帳號用量極低（0~1%）時，會誤顯示為 100% 已用、0% 剩餘。原因是程式碼把 API 回傳、本身已是百分比的數值誤判為 0-1 的小數並乘以 100，造成換算錯誤，回報者也指出 Codex 那條路徑並沒有這個問題。
[Feature] 建議讓 pre_llm_call 掛勾能拿到「上一輪做了什麼」的紀錄
目前 pre_llm_call 這個 plugin hook 只能在每輪對話開始前看到「將要做什麼」，卻看不到上一輪實際發生的結果（例如是否切到備援 provider、工具是否一直失敗），因為這些狀態會在下一輪開始時被清空。提案新增一個 turn-outcome 紀錄，並透過新的 last_turn 參數傳給下一輪的 pre_llm_call。
[Bug] 依文件設定 save_trajectories: true 後，Trajectory 檔案仍未產生
官方文件說明可透過 config.yml 設定 agent.save_trajectories: true 來啟用軌跡紀錄檔，但實際測試發現程式碼從未檢查這個設定，導致對話結束後不會產生任何 *.jsonl 軌跡檔案，在 CLI、TUI、Gateway 皆是如此。
[Feature] 建議在工具呼叫格式錯誤時，強制指定 tool_choice 重試
透過 OpenAI 相容介面連接的本機／量化模型偶爾會產生格式錯誤的工具呼叫（如缺少必要欄位），目前無法修復的呼叫會被靜默替換成空參數執行，或是把錯誤訊息丟回模型重試卻常常重複失敗，浪費對話輪次與 context。提案是偵測到格式錯誤時，在重試時把 tool_choice 釘選在該工具上；作者提到此功能已在另一個 PR（#44587）實作並運作中。
[Feature] 建議加入「先驗證才能宣稱完成」的行為規範與未驗證完成宣稱偵測器
目前 agent 常在沒有實際驗證的情況下就宣稱任務完成或可運作，缺乏引導 agent 先驗證再宣稱完成的機制，也沒有偵測器能標記出沒有紀錄支持的完成宣稱。提案新增系統提示引導與一個預設只記錄不阻擋的影子偵測器；作者提到此功能已在另一個 PR（#54576）實作並運作中。
[Feature] 建議讓 MoA 參考顧問模型可各自設定獨立的 reasoning_effort
在 MoA（Mixture of Agents）架構中，參考模型只是提供建議，aggregator 只讀取它們的最終回答，但在推理模型上大部分運算時間都花在 aggregator 看不到的內部思考過程；目前沒有辦法只調整參考顧問的推理強度而不影響 aggregator。提案新增一個可選的 per-slot reasoning_effort 設定；作者提到此功能已在另一個 PR（#57043）實作並運作中。
[Feature] 建議讓 agent 能「附加」到一個開啟中的桌面視窗，直接觀看與操控
目前若要讓 assistant 操作某個桌面應用程式，使用者必須用文字描述視窗與其中的控制項，對記不住選單路徑的使用者（含輔助科技需求者）幾乎不可行。提案新增「附加 app / 視窗」功能，讓使用者選取一個開啟中的視窗後，agent 可透過 UI 自動化側車程式觀看並操控它；作者提到此功能已在另一個 PR（#53852）實作並運作中。
[Feature] 建議讓 local backend 的 prompt 前綴保持「熱機」，避免每次都重新做 cold-session prefill
本機 llama.cpp / vLLM 類伺服器只有在新請求與先前快取狀態的 prompt 前綴完全一致時才能重複使用 KV 快取，否則每個新 session 都要重新處理共用前綴（通常 1~2 萬 token），造成延遲。提案是新增一個選用的 gateway watcher，定期重放最小化請求讓共用前綴保持在快取中；作者提到此功能已在另一個 PR（#57019）實作並運作中。
[Bug] Bedrock 的 /model 選擇器會顯示無法使用的裸模型 ID，選到後還會被永久儲存
Bedrock provider 的 /model 選擇器會同時列出裸 foundation-model ID 與對應的 inference-profile ID，但在 on-demand 帳號下裸 ID 無法呼叫；一旦選到裸 ID 會被寫入 config.yaml 的 model.default，導致之後每次呼叫都收到 HTTP 400 錯誤。回報者指出安裝精靈其實已經有處理這個問題（會過濾掉裸 ID），但 /model 選擇器路徑沒有套用同樣的去重邏輯。
長時間對話經過多次 context compaction 後，訊息序列變成無效格式，導致 session 永久失效（DeepSeek）
trajectory_compressor 在執行 context compaction 後，會產生不合法的訊息序列（孤兒 tool 訊息），造成 DeepSeek API 以 HTTP 400 拒絕請求，錯誤訊息為「tool 角色訊息必須回應前一則帶 tool_calls 的訊息」；長時間運行、累積大量工具呼叫訊息的 session 在多次壓縮後會完全無法繼續對話。此 issue 已關閉。
redact: 敏感資訊遮罩規則有漏洞，SendGrid API key 只遮住 key-id 段，key-secret 段仍明碼外洩
agent/redact.py 的 SendGrid 遮罩正規表示式在遇到第二個句點就停止匹配，導致三段式 SendGrid API key（SG.<key-id>.<key-secret>）中真正包含密鑰熵值的 key-secret 段完全沒有被遮罩，會在 log、對話紀錄等地方以明碼留存。回報者提出加入可選的第三段比對群組來修正此問題。
[Bug] is_container() 在跑 Docker 容器的主機上誤判為容器內部，導致 home_mode: auto 的子行程 HOME 不穩定，使瀏覽器自動啟動出現「找不到 Chrome」
回報者指出 hermes_constants.is_container() 在 cgroup v2 主機上會掃描 /proc/self/mountinfo 尋找 containerd 等關鍵字判斷是否身處容器內，但只要主機上正在執行任何使用 containerd 快照的 Docker 容器，該容器的 overlay 掛載資訊就會誤觸發這個判斷，讓一般 host 被誤判為容器，且此結果會被快取整個程式生命週期，進而造成瀏覽器功能找不到 Chrome。
[Bug] Thinking 區塊導致 CLI 模式文字回應變空白，並引發無限心跳迴圈
回報者指出使用 DeepSeek 等預設啟用 thinking 區塊的模型時，agent 的文字回應無法傳送給使用者，只會顯示終端機工具的輸出結果；在 cron/心跳排程情境下，因使用者看不到回應而無法給出新指示，導致 agent 反覆觸發、耗費大量 API 費用並形成無限迴圈。
暫時解法
停用 thinking 區塊可讓文字正常送達，但目前沒有針對此設定提供獨立的開關選項。
[Bug] 訊息路由錯誤：使用者輸入被送到錯的 session
回報者指出在 Hermes TUI 中，於某個 session（Session A）輸入的訊息卻被錯誤地送到另一個 session（Session B），Session B 的 AI 因此回應了原本要給 Session A 的任務，而 Session A 沒有收到任何回應。
[Bug] Ollama/GLM provider 對簡短完整回應誤判 finish_reason='length'，觸發多餘的續寫重試
回報者指出當 agent 產生很短但完整的最終回應時，對話迴圈的 finish_reason == length 截斷處理邏輯仍會誤判並注入「回應被截斷，請繼續」的系統訊息，導致 agent 在 Telegram 上重複傳送同一則簡短回應 2 到 3 次。
[Bug] 非同步 LLM 呼叫透過忙碌輪詢阻塞桌面版 WebSocket 主迴圈
回報者最初懷疑 interruptible_api_call 中 300ms 的忙碌輪詢拖慢主執行緒，但經過超過 4 小時的深入調查，確認真正原因是 Anthropic SDK 串流消費端在解析大量 SSE chunk 時造成的 worker 執行緒 GIL 競爭，導致主執行緒長時間無法取得 GIL。此 issue 已關閉。
[Bug] Envelope 快取版面在工具迴圈中的快取斷點失效，造成 OpenRouter 與 Claude 輸入成本增加約兩倍
回報者指出在 OpenRouter/envelope 快取版面下，system_and_3 策略把快取斷點放在 tool 訊息與內容為空的 assistant 訊息上，但這兩種訊息實際上無法有效承載快取標記，導致 agent 迴圈中除了 system prompt 之外的快取斷點全部靜默失效，整段對話每次都以全額輸入價格重新計費。此 issue 已關閉。
Session JSON transcript 匯出功能未過濾 PII（email / SSN 等）
此 issue 回報 agent/redact.py 目前只遮蔽密鑰、token 等機密資訊，但沒有涵蓋一般 PII（如 email 或身分證字號）。作者指出 state.db 本身不做遮蔽是設計上合理的，但選擇性開啟的 JSON transcript 匯出功能（sessions.write_json_snapshots，預設為 False）在寫入 session_{id}.json 時同樣缺少這類 PII 的遮蔽，屬於實際的落差。
MCP stdio 子程序在長時間運作的 worker 中重新連線時會洩漏，孤兒程序持續累積直到 DB 爭用
長時間執行的 Hermes worker 會累積孤兒 MCP stdio 子程序，案例中單一 worker process 累積了 53 個 mimir 子程序，共佔用 1.4GB RSS 與大量檔案描述符，全部搶同一個 SQLite DB，超過約 50 個子程序後會造成 DB handle 爭用，導致 memory 工具呼叫間歇性失敗，但 hermes mcp test mimir 仍顯示健康。
[功能需求] 透過 pre_llm_call 的 model override 實現依任務類型的逐輪模型路由
此 issue 提出功能需求：希望 plugin 能依照每一輪傳入的訊息內容，選擇該輪要使用的模型（例如寫程式用程式導向模型、簡單問題用快速便宜模型、分析用強推理模型）。作者指出目前 pre_llm_call 只能把內容注入使用者訊息、無法改變模型，pre_gateway_dispatch 也只能 skip / rewrite / allow，沒有 hook 能讓 plugin 直接呼叫 switch_model()。
[Bug] context 壓縮在第 2、3 次觸發時報 Jinja 模板錯誤並毀損 session
用 LMStudio 自架模型時，內部 context 壓縮流程在第二或第三次觸發時，會因 No user query found in messages 的 Jinja 模板錯誤而崩潰，session 毀損、對話連續性遺失，只能開新 session。此 issue 已關閉。
追蹤 Issue：Windows 桌面版 GUI 產生子行程時，主控台視窗（cmd/conhost/git/gh/powershell）會閃現
此為彙總約 25 篇回報的追蹤 issue，說明 Windows 桌面版 GUI 在無視窗的 pythonw.exe 後端呼叫 cmd.exe、git.exe、gh.exe、powershell.exe 等主控台子行程時，因未加上無視窗旗標，導致黑色主控台視窗閃現，有時甚至持續閃現；內文整理了曾嘗試並回退的修復方式，以及依實際原始碼與 git 歷史驗證過、目前仍有問題的產生點。
z.ai 在「尖峰時段」對 hermes agent 做速率限制（429 錯誤）
使用 Max coding plan 搭配 glm-5.2 時，z.ai 在尖峰時段會限制 hermes agent，回傳 429 錯誤（1302/1305），但同帳號下的 opencode 和 claude 不受影響。回報者懷疑是 z.ai 依請求簽章辨識出 hermes 而限速。此 issue 已關閉。
Anthropic Max OAuth 登入失敗：token 交換回傳 404（Anthropic 封鎖了 claude-cli/ User-Agent）
內建的 Anthropic OAuth 登入流程在 token 交換階段失敗並回傳 404，根因是 Anthropic 現在會封鎖所有帶有 claude-cli/ 開頭 User-Agent 的 token 交換請求，不論版本號為何；回報者測試多種 User-Agent 字串驗證了這個結論。此 issue 已關閉。
功能提案：可設定的記憶後端，將 memory.md 改名為 rules.md 並支援只用 honcho/fact_store
提案指出 Hermes 目前把 MEMORY.md 與 USER.md 兩個固定檔案的全部內容在每一回合都注入 system prompt，造成規則（永遠該注入）與事實性資料（應可查詢）混雜，且大量條目會造成每回合的 token 浪費；提案建議把 memory.md 更名為 rules.md，並支援可設定的記憶後端。
[Bug] openai-codex 帳號池誤判健康帳號為額度用盡，執行 hermes auth reset 可恢復
Hermes 錯誤地將所有 openai-codex 帳號池憑證標記為已達速率限制，包含實際上仍有可用額度的第三個帳號；回報者懷疑是帳號池內部的重置時間戳記狀態管理有誤。
暫時解法
執行 hermes auth reset openai-codex 後 Hermes 立即恢復運作，並成功選到第三個可用的憑證。
功能請求：整合 headroom-ai 做工具輸出壓縮
這個 issue 提議整合開源工具 headroom-ai，在個別工具輸出（如 log、grep 結果、JSON、程式碼）進入 context 前先壓縮，以解決現有 context_compressor.py 在對話層級摘要壓縮時遇到的多項已知問題，例如誤判觸發時機、壓縮後反而變大、摘要失敗導致資料遺失等。
修正（vision）：_resolve_single_provider 的 kwargs 回歸問題導致 Gemini 額度錯誤時 fallback_chain 靜默失敗
此 issue 回報當 Gemini 回傳 HTTP 429（額度用盡）時，vision fallback chain 嘗試透過 _resolve_single_provider 建立 xiaomi-tp、ollama 等備援 provider 的 client，但該函式沒有正確把 explicit_base_url / explicit_api_key 等參數轉傳給 resolve_provider_client，導致整個 fallback chain 對所有 provider 都靜默回傳 None，使用者只會看到原始的 Gemini 錯誤，看不到任何備援。
功能請求：解決 Hermes 多租戶（multi-tenant）問題
這個 issue 指出 Hermes 目前的 memory 操作會繞過 hook 系統，導致無法在不修改核心程式碼的情況下做到租戶隔離。作者團隊釋出了開源專案 Hermes Swarm Map，擴充現有 Hermes 模式以支援多租戶環境下的權限控管，並提案將相關修改回饋（upstream）到 Hermes 核心。
暫時解法
作者表示已在正式環境自行維運修正版本數月，並釋出開源專案 Hermes Swarm Map 作為現階段的替代方案。
OpenAI Codex provider 當機，錯誤「'NoneType' object is not iterable」（HTTP None）
回報者指出切換到 gpt-5.5（透過 OpenAI Codex provider，以 OAuth 訂閱登入）後，傳送第一則訊息就會立即觸發「Non-retryable error (HTTP None): 'NoneType' object is not iterable」的當機。雖然會自動 fallback，但 Codex provider 本身無法使用，回報者認為問題可能出在回應解析路徑。
[Bug] openai-codex 服務商每次請求都因 TypeError（'NoneType' object is not iterable）而崩潰（chatgpt.com 回傳的 output 為 null）
使用者回報在 gateway 重啟後，openai-codex 服務商每一次請求都會因 TypeError 崩潰，重新登入也無法解決，因為憑證池雖然重新填入卻立刻再次被抑制。根因是 chatgpt.com 的 Codex 端點在 response.completed 事件中回傳 output: null，OpenAI SDK 2.24.0 的 parse_response() 對 null 值做迴圈導致例外，此例外未被現有的錯誤處理攔截，被記錄為 HTTP None 並導致憑證池被抑制、耗盡。此 issue 已關閉，狀態為已修復。
[討論] 為什麼移除了 smart_model_routing？希望能夠恢復
此 issue 是一則討論串，詢問 2026 年 3 月新增、隔月即被移除的 smart_model_routing 功能（會將短小簡單的訊息自動路由到便宜模型）為何被整個移除，而不是保留為 opt-in 選項；作者認為許多使用者仍認為此功能對成本控制有幫助，希望能說明移除原因或考慮以 opt-in 形式恢復。
暫時解法
作者提到目前可用的暫時替代方式是手動切換模型，例如執行 hermes chat -m opencode-zen/deepseek-v4-flash-free。
[Bug] Hermes v0.14.0 中 openai-codex/gpt-5.5 仍不穩定：subagent 幾乎都會連線逾時，官方 Codex CLI 卻正常
回報者指出在 Hermes v0.14.0 中使用 openai-codex/gpt-5.5 仍非常不穩定，主要 agent 約有五成機率遇到連線失敗，多個 subagent 同時執行時幾乎必定失敗，但同一台機器、同一網路、同一 ChatGPT/Codex 帳號下的官方 Codex CLI 卻能正常使用，導致 Hermes 的委派功能幾乎無法用這個 provider。此 issue 已關閉。
Codex Responses 串流當機，錯誤 TypeError: 'NoneType' object is not iterable（openai-codex / chatgpt.com backend）
回報者透過外部檔案與截圖回報 Codex Responses 串流功能發生 TypeError: 'NoneType' object is not iterable 的當機，issue 本文未附詳細文字說明，細節放在附件檔案中。此 issue 被標記為重複（duplicate）。
Bug：openai-codex provider 崩潰，SDK 的 parse_response 無法處理 Codex 後端回傳的 null output
此 issue 指出 Hermes v0.14.0 在使用 openai-codex provider 搭配 gpt-5.5 時，每次呼叫 hermes chat 都會噴出 'NoneType' object is not iterable。根因是 ChatGPT Codex 後端在 response.completed 的 SSE 串流事件中回傳 output: null，而 OpenAI Python SDK 的 parse_response()（openai/lib/_parsing/_responses.py:61）沒有做 null 檢查就直接對 response.output 跑迴圈，在 Hermes 自己的回填邏輯執行前就讓 stream parser 先崩潰。作者指出這會影響 2.38.0（含）以前的所有 OpenAI SDK 版本，並已在 openai-python 上游回報。此 issue 已關閉。
暫時解法
body 提供了直接修補已安裝 SDK 的 sed 指令，把 parse_response() 裡 for output in response.output: 改成加上 or [] 的 null 防護；但作者提醒此修補會被 hermes update 或 pip install openai 覆蓋掉。
Bug：Hermes 使用 OpenAI Codex（ChatGPT）時噴出 'NoneType' object is not iterable 錯誤
此 issue 回報在使用 Provider 為 openai-codex、Model 為 gpt-5.5 時，透過 Telegram 或 CLI 傳送任何訊息都會噴出 'NoneType' object is not iterable 錯誤，並被當成不可重試的用戶端錯誤中斷。回報者認為 Hermes 呼叫 ChatGPT Codex 後端 API 端點時應妥善處理所有分支，不應因 Python 端的 None 值而直接出錯。此 issue 已關閉。
修正 Codex stream 回傳 None 時的還原機制
此 issue 描述 OpenAI Codex Responses 後端在串流結束時可能回傳 response.output 為 None，導致 OpenAI SDK 的 stream parser 直接崩潰、被 Hermes 誤判為不可重試的用戶端錯誤。作者提出修補方式，包含從已串流的 output items / text delta / reasoning delta 回填缺漏的 output、在 SDK stream parser 崩潰時改用 responses.create(stream=True) 作為 fallback，並針對 output_text 的存取加上防護與新增回歸測試。此 issue 已關閉。
套用 #31967/#32016 修復後，openai-codex / gpt-5.5 仍反覆卡在沒有 first byte
回報者指出即使已套用先前針對 Codex timeout 的修復（#31967、#32016），openai-codex / gpt-5.5 仍經常在串流開始前卡住，出現「No first byte from provider in 45s」的重試與斷線訊息，且此問題與舊有的 context 為 0 或 300 秒 stale timeout 不同。
功能請求：支援 Proton Pass AI Access Tokens 作為機密來源後端
Hermes 目前支援 Bitwarden Secrets Manager 作為外部機密來源，官方文件也表示歡迎提出其他後端需求。Proton Pass 最近推出 AI Access Tokens，提供唯讀 vault 存取、可設定過期時間、稽核紀錄與端對端加密，此 issue 提議將其新增為 Hermes 的機密來源後端。
[Bug] 同時設定 provider、base_url 與 api_key 時，auxiliary task 的 provider 身分會遺失
回報者指出當 auxiliary 任務（如 auxiliary.vision）同時設定 provider、base_url 和 api_key 時，provider 名稱會被系統忽略並強制改為 custom，導致原本針對特定 provider 的處理邏輯（如 ZAI vision 的 max_tokens 略過、Anthropic transport 偵測等）被跳過，引發後續錯誤。
Bug：「Response truncated due to output length limit」在 #7237 修復後仍然發生（重新開啟已關閉的 issue）
此 issue 指出「Response truncated due to output length limit」錯誤在先前 #7242 與 #9525 的修復（回應 #7237）之後仍然持續出現。#7237 曾被維護者以「這不是 bug，是 context window 限制」為由關閉，但作者指出關閉後累積的 10 多則留言與大量測試，在不同模型（包含 414k、131k token，甚至 Gemini 1.5 的 2M token）上都能重現此問題，顯示輸入 context 可能足夠，但輸出 token 上限或長工具輸出/摘要的接續邏輯可能有問題。作者附上針對大型 context 模型的新鮮 session 重現資料。此 issue 已關閉。
[Bug] MiMo 推理模型的 reasoning_content 未被保留，導致多輪對話失敗
回報者指出 MiMo 推理（thinking）模型在多輪對話中，前一輪 assistant 訊息的 reasoning_content 欄位沒有被保留並回傳給 API，而 MiMo 的 API 要求在 thinking 模式下必須回傳此欄位，因此後續請求會收到 400 錯誤。
所有模型被拒絕，錯誤「context window below minimum 64,000 tokens」，Telegram 完全癱瘓
回報者指出 Telegram bot 因 MiniMax-M2.7 與 kimi-k2.6（皆為 32,768 context）被 Hermes Agent 判定 context window 低於 64K 門檻而全面拒絕，導致 Telegram bot 與 cron job 同時失效。這些模型先前皆可正常運作，使用者並未變更任何設定。
輔助 fallback chain 應該重用 fallback_providers 設定，而不是維護另一份寫死的清單
此 issue 指出 Hermes 目前維護兩套互不相通的 fallback 機制：使用者在 config.yaml 設定的 fallback_providers，以及給 compression、vision、title、web_extract、curator 等輔助任務使用、寫死在程式中的另一份 fallback 清單（含付費模型）。主要 agent 走使用者設定的 fallback_providers，但所有輔助任務卻走另一份寫死清單，兩者彼此不知道對方的存在。
RFC 提案：可插拔的 SessionDB 供應者，支援 PostgreSQL、MySQL 等
此 RFC 提案指出 Hermes 目前多個行程（CLI、Gateway、cron、TUI、API server）共用同一個 SQLite state.db 檔案，在一邊執行一邊更新（git pull / hermes update）時容易發生資料庫鎖定，甚至 WAL checkpoint 中斷造成損毀，因此提議讓 SessionDB 支援可插拔的資料庫後端（如 PostgreSQL、MySQL），取代目前 SQLite 在多行程情境下的限制。
openai-codex / gpt-5.5 作為主要模型時，每次呼叫都會靜默卡住直到 stale timeout
回報者指出當主要模型設為 openai-codex / gpt-5.5 時，每次對話都會在約 300 秒的 non-streaming stale timeout 期間完全沒有任何回饋（無 token、無錯誤、無提示），之後才會觸發 fallback。同樣設定改用 gpt-5.4-codex 則能立即正常運作，顯示問題出在 Hermes 對 gpt-5.5 在 Codex 端點的請求建構方式。
功能提案：Model Presets，可針對單一回合臨時升級到更強的模型
提案指出目前 Hermes 整個 session 只能用同一個模型，若平時用便宜或快速模型，遇到需要更強推理能力的回合時，只能手動切換模型（之後還要再切回來）或硬著頭皮用弱模型應付；提案建議新增 model_presets 設定，讓使用者能為單一回合臨時呼叫指定的 provider 加 model 組合，用完自動切回預設模型。
功能請求：壓縮閾值（compression threshold）依模型 / provider 個別設定
目前 compression.threshold 是全域單一數值，對 1M context 模型（如 DeepSeek V4 Flash）門檻形同虛設，對小 context 模型又太保守。issue 提議在 config.yaml 新增依 provider 或依模型覆寫 threshold 的設定選項。
[Feature] 支援遠端 Hermes agent 搭配本機工具執行（遠端大腦、本機執行）
回報者希望能使用遠端的 Hermes Agent，同時把工具執行留在本機端。目前如果本機把 model.base_url 指向遠端 Hermes 的 OpenAI 相容 API server，工具呼叫（例如 pwd）也會在遠端主機上執行，而不是在本機使用者實際的工作目錄執行，這和一般 LLM provider 把 tool_calls 回傳給用戶端執行的行為不同，讓人意外。作者希望的模式是遠端提供 skill、記憶、session 連續性、推理設定，本機負責執行 terminal、檔案、程式碼執行、瀏覽器 / 本機開發伺服器互動、本機 MCP server 等工作區相關工具。
[Bug] google-gemini-cli 服務商觸發 429 錯誤，但 gquota 額度顯示正常
使用者更新到最新版 Hermes，且 /gquotas 顯示 Gemini AI Pro 額度充足，但使用 google-gemini-cli 服務商搭配 gemini 3.1 pro 模型測試訊息時仍收到 429 錯誤，額度顯示接近 98%。此 issue 為開放狀態，處理狀態為 workaround。
[Bug] DeepSeek API 出現 400 錯誤：思考模式下的 reasoning_content 必須被送回 API
使用者回報搭配支援思考模式的 DeepSeek 模型（如 deepseek-v4-flash）時，Hermes 出現 HTTP 400 錯誤，訊息指出思考模式下的 reasoning_content 必須在後續請求中送回 API，但 Hermes 目前並未正確處理並回傳先前的 reasoning_content。此 issue 已關閉，狀態為已修復。
Hermes agent 無法根據先前的對話內容準確回答問題
使用者回報使用 hermes chat 搭配 ollama 自訂端點與 gemma4:e4b 本地模型時，agent 無法記住並根據先前對話（例如使用者告知的名字）回答後續問題，對話紀錄顯示前後回答不一致且答非所問。此 issue 已關閉，狀態為已修復。
在官方 Codex CLI 仍可正常運作的同一台機器/網路上，Hermes 的 openai-codex 服務商卻失敗
使用者回報在同一台 macOS 機器與同一個網路環境下，官方 codex CLI 用 ChatGPT 登入仍可正常完成回應，但 Hermes 設定為 openai-codex 服務商時卻反覆出現 APIConnectionError / APITimeoutError，最終顯示連線錯誤，顯示 Hermes 的 openai-codex 相容層與官方 Codex CLI 的傳輸方式並不等價。此 issue 為開放狀態，處理狀態為 workaround。
功能請求：原生支援 Google Cloud Vertex AI provider
Hermes 目前沒有可用的 Google Cloud Vertex AI 整合路徑，設定 google-vertex provider 時因缺少 OAuth 驗證機制而在每次 cron 執行時靜默失敗。回報者提到自己寫了一個 standalone proxy 處理服務帳號驗證與 token 更新，並透過現有 custom_providers 機制與 Hermes 整合，希望能將此方案貢獻回專案。
暫時解法
回報者提供了一個 standalone proxy（127.0.0.1:8787），處理 GCP 服務帳號驗證與 token 更新，透過 custom_providers 機制串接使用。
功能請求：簡化新增 OpenCode Go 等自訂模型到 Hermes Agent 的方式
目前要把 OpenCode Go 這類新模型串進 Hermes Agent，沒有明確或簡單的擴充機制，開發者必須深入內部程式碼才能實驗替代的 LLM provider 或自架推論服務。此 issue 提議建立設定式（YAML/JSON）的模型註冊機制與標準化 adapter 介面。
功能提案：為具視覺能力的主模型提供原生 Vision 支援，附參考實作與相關 bug 發現
提案指出 Hermes 目前所有影像分析都會繞道經過輔助視覺模型（如 qwen3-vl），即使主模型本身具備原生視覺能力（如 gpt-4o、glm-5v-turbo、claude-sonnet-4）也是如此，造成額外延遲、成本與資訊流失；回報者提供了一套修改 4 個檔案的原生 vision bypass 參考實作，並在過程中發現了多個會影響任何多模態內容的 pipeline 問題。
[功能討論] 自我改進 agent 的「憑據追溯」：如何證明是哪個版本的 skill 產生了哪個輸出
使用者以討論形式提出治理層面的問題：Hermes 具備從經驗中自動產生與改進 skill 的自我修改能力，但這也代表一個 skill 的「哪個版本」在何時執行、產生了什麼輸出，缺乏可追溯的憑據。作者提出三個具體的溯源問題，例如某個 skill 在早上被建立、下午被改進後，之後執行時究竟是哪個版本產生的結果。此 issue 為開放狀態，處理狀態為調查中。
建議在 auxiliary_client.py 新增 MiniMax 作為 vision backend 支援
設定 AUXILIARY_VISION_PROVIDER=minimax 時，vision_analyze 工具會靜默失敗，因為 _resolve_strict_vision_backend() 沒有處理 MiniMax 的分支，回報者指出 MiniMax 有提供如 MiniMax-VL 之類的多模態端點可以串接。此 issue 已關閉。
[Bug] 當終端 response.output 為 null 時，Responses 串流會崩潰
當某個 OpenAI 相容 provider 傳回有效的串流事件、但最終 response.completed 的 response.output 是 null 而非空陣列時，Hermes 既有針對空陣列的復原邏輯無法涵蓋這種情況，stream.get_final_response() 會在 Hermes 能補回串流輸出內容之前就先拋出例外。此 issue 與 #5879、#5689、#5730 屬於同一類 provider 相容性問題。此 issue 已關閉。
功能提案：單一 daemon 支援多 agent，各自獨立 workspace 與記憶，依 topic 隔離
提案指出 Hermes 目前每個 agent 都需要獨立的 profile 與 gateway 行程，若要同時跑多個不同用途的 agent 就要開多個 process，各自佔用資源；提案參考 OpenClaw 的單一 daemon 架構，讓多個 agent 共用同一個 daemon 行程，各自擁有獨立 workspace 與記憶，並依 session key（含群組內 topic）路由訊息。
feat(delegation)：delegate_task 支援自訂 agent profile，打造客製化編排 harness
此 issue 提議讓 delegate_task 能從 config.yaml 中定義的具名 agent profile 產生子 agent，讓使用者不用改 Hermes 核心就能打造類似 oh-my-opencode-slim Pantheon agents 的客製化編排 harness。作者指出目前 delegate_task 產生的子 agent 只是父 agent 的複製品，可自訂的部分很有限：系統提示是寫死的模板、model 全域共用、工具權限只到 toolset 群組層級、且沒有系統化的路由規則來區分 explorer / fixer / reviewer 等角色。
功能提案：跨 session 搜尋與自動壓縮的持久化 Session Memory
此提案指出 Hermes 目前的 session memory 是暫時性的，session 結束或 gateway 重啟後對話脈絡就會遺失，導致使用者必須不斷重新說明環境、偏好與專案狀態；提案建議建立一個以 markdown 檔案為單位、可搜尋且能自動壓縮的持久化「Vault」式 session memory 系統。
[Feature] 原生支援多 Agent：單一 Gateway 服務多個具名 Agent
此 issue 提議讓 Hermes 支援原生多 agent 架構，讓單一 gateway process 能同時服務多個具名 agent，各自擁有獨立的 session、人格、記憶與工具設定，類似 OpenClaw 的多 agent 架構。作者指出目前 Hermes 是單一 agent 系統：session key 寫死帶 agent:main: 前綴（gateway/session.py:477-484）、SOUL.md 只從單一全域路徑（~/.hermes/SOUL.md）載入、記憶也是全域共用（~/.hermes/memories/），導致使用者同時討論多個不相關主題時 context 會混在一起、增加 token 消耗、降低推理品質，也無法讓使用者擁有各自專精不同領域的獨立 agent。
[Feature] 延遲載入工具 Schema：用兩階段注入減少 Token 開銷
此 issue 指出目前每次 API 呼叫都會把所有啟用 toolset 的完整工具 schema 一次注入，在啟用 50 多個工具（terminal、file、web、browser、delegate、vision、memory 等）時，每次呼叫大約會多耗 3,500 到 5,000 個 token，即使該次對話根本用不到這些工具。作者引用另一則 issue 的實測數據，指出在本機模型上帶工具格式的 prompt 處理速度比純文字慢 10 倍（8 個工具下 1,230 tok/s 對比 134 tok/s）。提案是採用兩階段延遲載入：第一階段每次呼叫只送工具名稱與一行說明，第二階段等模型指定要用某個工具後，才在後續呼叫中送出完整 schema。
feat(dreaming)：在 CLI 與 gateway 全面導入穩定的 Dreaming 反思模式
此 issue 描述把 Dreaming 打造成 Hermes 的正式一級功能，讓對話總結、分析與洞察產生這個反思模式能在 CLI 與 gateway（包含 Telegram 傳送）兩種執行路徑上穩定運作。內容包含讓 Dreaming 在正確的 runtime 設定下執行、不依賴工具呼叫、即使底層 agent 發生錯誤也能回傳可用的回應；具體改動包含新增專屬 Dreaming 流程、讓 Dreaming 同步執行、停用 Dreaming 的工具集使其保持反思與確定性、把 runtime/provider 設定傳入 Dreaming、移除傳入 AIAgent.run_conversation 的無效 session_id，並新增錯誤呈現機制與回歸測試。
功能請求：危險本機操作的核准規則可自訂（approval-locked command patterns）
Hermes 已有危險指令核准機制，但目前需要核准的指令樣式寫死在 tools/approval.py 原始碼中，使用者無法在不修改原始碼的情況下把特定於自己環境的指令（例如重啟 gateway 服務）標記為需要核准，也無法針對非系統層級危險、但在特定部署中具破壞性的操作設定規則。
暫時解法
目前只能在本機修改原始碼並維護 dirty diff、自建外部 runtime overlay/wrapper，或單純依賴 agent 的 memory / 指示來遵守規則。
feat：通用化 ACP client，支援多種 coding agent 的多 agent CLI 編排
此 issue 提議把 Hermes 現有的 ACP（Agent Client Protocol）client（目前是針對 Copilot 特化的 copilot_acp_client.py）通用化，讓 Hermes 可以編排所有相容 ACP 的 coding agent，包括 Claude Code、Codex CLI、Gemini CLI 等共 14 種，做法是改用各家 CLI 廠商與 Zed Industries 官方維護的 ACP adapter，而不是像先前 #3660 提案那樣直接把 CLI 執行檔當子程序呼叫（該做法有合規疑慮）。提案包含新增 agent/acp_client.py 通用 ACPClient 類別、agent/acp_agent_registry.py 的 agent 註冊表，以及 hermes_cli/providers.py 中新增的 provider overlay。
[文件] Context 檔案（AGENTS.md/SOUL.md）的說明文件與實際程式碼行為不一致
這個 issue 指出文件描述的三項行為與程式碼實作不符：AGENTS.md 文件說會遞迴合併子目錄設定，但程式碼只讀當前目錄；SOUL.md 文件說會先檢查 cwd 再 fallback 到 ~/.hermes/，但程式碼完全不讀 cwd；文件描述的 terminal.cwd 設定在 gateway/訊息模式下實際會被覆寫成 home 目錄。這導致 Telegram、Feishu、Discord 等訊息平台使用者無法真正使用 context 檔案。
功能提案：憑證代理 daemon，zero-knowledge 的 HTTP/HTTPS 憑證中介機制
此提案指出現有的 env scoping（#3628）與 PID namespace isolation（#4432）雖降低憑證外洩風險，但子行程仍可能存取到真實憑證值本身；提案建議在 HTTP 傳輸層攔截，讓真實憑證值永遠不出現在 agent 可存取的任何位置，才能從架構上根本防止 agent 讀取憑證。
[功能] 優化 Ollama 整合：改用原生 /api/chat 端點取代 OpenAI 相容端點
使用者提出以 Ollama 原生 /api/chat 端點取代目前使用的 OpenAI 相容端點 /v1/chat/completions，宣稱可帶來真正的逐字串流、更長的逾時時間、完整的 Ollama 參數支援，以及約 15-20% 的延遲降低，並附上一份 581 行的 agent/ollama_adapter.py 實作範例。此 issue 為開放狀態，處理狀態為調查中。
Token 開銷分析：每次 API 呼叫有 73% 是固定開銷（約 13.9K tokens），附數據與改善建議
使用者透過自建的監控儀表板分析 Hermes v0.6.0（Telegram + WhatsApp + Cron 三個 gateway）的 6 份 request dump，發現每次 API 呼叫中有 73% 是不隨請求內容變動的固定開銷，主要來自工具定義（31 個工具佔 46.1%）與系統提示詞（SOUL.md + skills catalog 佔 27.2%），總計約 13,935 tokens。此 issue 為開放狀態，處理狀態為 workaround。
[Feature] 支援 A2A（Agent-to-Agent）協定：遠端 Agent 探索、通訊與互通
此 issue 提議讓 Hermes 支援 Google 提出的 A2A（Agent-to-Agent）開放協定，作為與 MCP 互補的機制：MCP 回答「我能用哪些工具」，A2A 回答「誰能幫我」，讓不同框架打造的 agent 能互相探索能力並透過標準 HTTP 協作任務。作者認為 Hermes 已有成熟的 MCP client（tools/mcp_tool.py），適合進一步支援 A2A，讓 Hermes 能呼叫其他框架的遠端 agent，也能被其他系統當作可被 A2A 探索的 agent 呼叫。
功能請求：使用者可自訂的多模型路由（能力分類 + 評估回饋）
此 issue 提議讓使用者能把多個 LLM 分配到不同能力分類（如速度、智慧程度、不受限、低成本、高度推理），讓工具依宣告的需求動態選擇模型，而非固定使用單一開發者指定的模型，並可選擇性地用評估指標隨時間優化模型選擇。此 issue 已關閉。