Hermes 群聊的 Bot 變慢、不回話？新手先看懂這 4 種原因
你在 Hermes Desktop 開了一個 Bot 群聊，丟出一句話，結果有的 Bot 秒回、有的等了三分鐘才回，有的乾脆沒聲音。好消息是：多數時候它沒有壞，只是落在四種常見情況之一。新版 Hermes 已經會在群聊的 Activity 摘要裡顯示部分失敗原因，但「實際用了哪個模型、是不是換成備援、對話是不是快塞滿」仍然看不到。這篇先用白話帶你分辨，再給你一個雙擊就能開的健康檢查工具；最後才是給進階使用者的完整除錯紀錄。
不用寫程式。看懂名詞 → 判斷 4 種原因 → 用工具確認 → 第一次組隊就做對。
適合已經自己改過 config、遇到群聊卡死想深入排查的人。新手可以先跳過。
內容已對照 Hermes 官方文件與 v0.21.6 原始碼查核。要注意：v0.21.6 只更新了指令列（CLI）、Docker 與 Hermes Cloud，桌面版 Hermes Desktop 這次沒有更新，會等下一個整合版本一起推出。[4]所以你在 Desktop 群聊畫面上看到的功能，取決於你的 Desktop 版本；本文提到的 Activity 摘要、Compress history 按鈕若找不到，代表你的 Desktop 還是較舊的版本。
新手篇
先認識 6 個名詞
這篇會反覆用到下面這些詞。不用背，看不懂時回來查就好。
| 名詞 | 白話意思 | 比喻 |
|---|---|---|
| Bot（profile） | 群聊裡的一位 AI 成員，有自己的角色、記憶和使用的模型。 | 一位同事 |
| 群聊（room） | 你和多位 Bot 一起講話的聊天室。 | 會議室 |
| 對話紀錄（session） | 每位 Bot 在這個群聊裡各自累積的記憶。同一個群聊，每位 Bot 都有自己的一份。 | 每位同事自己的會議筆記 |
| context | 模型一次能讀進去的字數上限。對話紀錄越長，越接近上限。 | 同事一次能記住的筆記頁數 |
| 備援模型（fallback） | 主要模型失敗時，系統自動改用的第二選擇。 | 主講人請假時的代班 |
| 限流（429） | 模型服務太多人用或超過免費額度，暫時把你擋下。模型沒壞。 | 熱門餐廳要排隊 |
為什麼用免費模型，Bot 有時會很慢？
我們讓 Bot 用免費模型，不是因為免費模型最好，而是 Bot 要每天長時間工作：全部用付費模型，帳單會失控；自己的電腦又跑不動夠聰明的模型。免費模型是讓 Agent 能「長期上班」的現實選擇。
代價是：免費模型是很多人一起排隊用的。人一多就會變慢，甚至被暫時擋下（429）；免費模型也可能突然下架；不同模型一次能讀的長度（context）也差很多。
新版 Hermes 會顯示「某某正在思考…」，失敗時也會在 Activity 摘要寫出原因。但它仍不會告訴你：這位 Bot 這一輪實際用了哪個模型、是不是換成了備援、對話離上限還有多遠。下一節的 4 種原因，加上後面的健康檢查工具，就是幫你把這些「看不見」拆開。
一個簡單的分工原則
| 工作類型 | 建議用什麼模型 | 失敗時 |
|---|---|---|
| 整理、摘要、格式化、狀態回報 | 免費模型 | 可以等，或自動換另一個免費模型 |
| 一般內容與日常執行 | 免費模型為主，訂閱模型當備援 | 先確認備援模型讀得下目前的對話長度 |
| 重要決策、複雜除錯、最後審核 | 訂閱或付費模型 | 保留紀錄，確認用的是哪個模型 |
Bot 不回話，先對照這 4 種原因
從最常見、最無害的開始排除：
① 沒輪到它，或它被暫停了
症狀：其他 Bot 都回了，只有它安靜。
原因：你 @ 了特定成員時，只有被點名的人會發言；沒有 @ 任何人時，每位 Bot 都會輪到，但沒有新內容可補充的會選擇不說話。另外，如果曾在它的名字旁打過 stop、pause（例如「stop @writer」），它會被暫停，直到你再點名它。[1]
➜ 用 @名字 直接點名它一次。
② 被限流，在排隊
症狀：平常很快，今天特別慢，或過一陣子才突然回。
原因：免費模型太多人用，或超過免費額度（429）。v0.21.6 起，被限流的模型服務會說明原因和大約何時恢復。[4]
➜ 等幾分鐘。不用刪任何東西。
③ 換成備援模型了
症狀：有回答，但口氣、品質或速度跟平常不太一樣。
原因：主要模型這次失敗，系統自動改用你設定的備援模型完成。
➜ 偶爾發生正常；整天都這樣再考慮換主要模型。
還有一種比較少見的情況：模型其實已經回答了，只是群聊畫面沒有顯示。這時切換一下聊天室或重新整理 Hermes 視窗，通常就會出現。
群聊安靜下來後，展開 Activity 摘要。如果某位 Bot 失敗了，會直接寫出原因，例如「writer hit an error — …」（多半是金鑰或模型服務出錯），或「couldn't start — too many bots running」（同時跑的 Bot 太多，電腦這邊暫時排不進去）。一位持續回報工作進度的 Bot 最多可以想三小時；但如果它超過三分鐘完全沒動靜，那一輪就會被當作逾時。[1]
Activity 能告訴你「出錯了沒」，但不會告訴你「它用的是主要模型還是備援」或「對話快塞滿了沒」——這兩件事要靠下面的工具。
用健康檢查工具確認是哪一種
就算有 Activity 摘要，③（換成備援）和 ④（快塞滿）還是很難從畫面看出來。我們寫了一個小工具，讀取你電腦上的 Hermes 紀錄，在瀏覽器裡用顏色和白話告訴你每位 Bot 實際用了哪個模型、現在是哪一種狀態、下一步要做什麼。
你已經在用 Hermes Desktop 的群聊、電腦是 Windows 或 macOS，而且願意安裝一次 Python（免費，約 5 分鐘）。
你的群聊只有 1–2 位 Bot、很少卡住，或不想安裝任何東西。照上面 4 種原因判斷就夠了。
Hermes 群聊健康檢查 v1.1.1
只讀取紀錄，不會修改 Hermes 的設定、對話或群聊；儀表板只開在你自己的電腦上，不會上傳任何資料，也不會顯示 API key。
下載工具（ZIP）完整使用說明- 安裝 Python（只需一次）。到 python.org 下載 3.10 以上版本。Windows 安裝畫面第一頁記得勾選「Add python.exe to PATH」。
- 下載並解壓縮 ZIP。請先解壓縮成一般資料夾，不要直接在壓縮檔裡點開。
- 雙擊啟動檔。Windows 點
start-windows.cmd；macOS 點start-mac-linux.command（第一次若被系統擋下，按右鍵 →「打開」）。第一次會自動安裝需要的套件，約幾十秒。 - 看瀏覽器自動打開的儀表板。黑色視窗要保持開著，畫面每 5 秒更新；看完關掉視窗就停止了。
檔案完整性：SHA-256 checksum。若要把產生的 JSON 公開分享，請先自己看過一遍。
儀表板的顏色怎麼看
| 顏色 | 意思 | 你要做什麼 |
|---|---|---|
| 綠色 正常 | 用主要模型，有成功回覆 | 不用做事 |
| 黃色 用備援 | 原因 ③ | 偶爾出現不用管 |
| 紫色 待確認／限流 | 原因 ②，或證據還不夠 | 等一下，或點名它說一句話再看 |
| 紅色 需要處理 | 原因 ④，或金鑰、模型名稱有錯 | 照卡片上的「下一步」做 |
| 灰色 沒有動靜 | 原因 ① | 用 @ 點名它 |
每張卡片下方的「技術細節」是給進階使用者對照用的，新手可以不展開。
第一次組 Bot 群聊，就照這 5 步
- 先想角色，再選模型。每位 Bot 只負責一件事，例如「寫稿」、「查資料」、「審稿」。先別一次建十幾位。
- 每位 Bot 設一個主要模型和一個備援模型。主要用免費模型，備援選另一家的免費或訂閱模型，避免同時一起被限流。
- 先一對一測試。每位 Bot 先單獨聊一句，確認它能正常回答，再拉進群聊。
- 把重要結論放在群聊外面。專案決定、待辦、誰負責什麼，寫在一份文件或看板裡。群聊只放派工和結果摘要，對話紀錄才不會越塞越長。
- 日常用 @ 點名。例行工作用
@名字指定一位；只有需要大家一起討論時才叫全部的人。
官方文件也提醒：讓對話變長的通常不是圖片，而是貼進去的整份 log、長篇輸出和重複的說明。能貼摘要和檔案位置，就不要貼全文。[2]
對話太長、Bot 不再回應時怎麼辦
這是四種原因裡唯一一定要動手的。先記住一件事：群聊和對話紀錄是兩件事。群聊可以一直留著；需要處理的，只是那位 Bot 在這個群聊裡的對話紀錄。
官方文件描述的典型症狀是：這位 Bot 開始回空白，或出現「The model returned no response after processing tool results」。[1]
- 先把重點存下來。把這段時間的重要決定、進度、待辦寫進文件。這份文件就是 Bot 的「交接筆記」，之後不管怎麼處理都不會丟失進度。
- 用「Compress history」壓縮這位成員。新版 Hermes 可以直接在介面操作：點群聊右上角的齒輪打開「群組設定」，成員清單裡每位 Bot 旁都有「Compress history」按鈕。一次只壓一位，完成後會顯示摺疊了幾則訊息。[1]
- 壓縮只影響 Bot 當下要讀的量。群聊紀錄不會被動到，舊的對話歷史也還在資料庫裡可以搜尋；Hermes 會為壓縮後的對話自動接續一段新紀錄。[2]
- 不要刪掉整個群聊。刪群聊會讓你失去所有人的歷史；問題通常只出在一兩位 Bot 身上。壓縮後仍然不行，才需要進階篇的做法。
養成習慣：每完成一個段落，就請 Bot 把結論更新到交接筆記。對話紀錄就算哪天要重開，也不會丟失進度。
常見問題
Hermes 群聊裡有 Bot 不回話，是壞掉了嗎？
多半不是。最常見的是沒被 @ 到、被限流在排隊、自動改用備援模型，或對話太長。前三種通常等一下或點名一次就會恢復。
免費模型被限流（429）要怎麼辦？
429 代表模型還在，只是暫時太擠。通常幾分鐘內恢復；有設定備援模型的話會自動換手。不需要刪除對話或群聊。
Bot 的對話太長塞不下了，新手該怎麼處理？
先把重要結論存到文件，再到群聊的「群組設定」對這位成員按「Compress history」，一次壓一位。不要直接刪除群聊。
更新 Hermes 後，群聊出現「This room is managed by its gateway. Update Hermes Desktop to continue it.」？
這代表群聊已經交給新版的後端管理，但你的 Desktop 還是舊版，所以舊版 Desktop 不能直接在這個群聊送訊息。這是保護機制，群聊和紀錄都還在。請把 Hermes Desktop 更新到最新版再繼續；v0.21.6 這一版沒有更新 Desktop，可能要等下一個整合版本。[4]
不會寫程式也能用健康檢查工具嗎？
可以。只需要先安裝 Python，解壓縮後雙擊啟動檔，瀏覽器就會打開儀表板。工具只讀取紀錄，不會修改任何設定。
- AI session 怎麼整理？用一頁表把對話變成 SOP：交接筆記的現成模板。
- Hermes 桌面寵物完整教學：同樣是 Hermes Desktop 的實機紀錄，從安裝到 /hatch 生成。
- AI 變便宜，為什麼使用成本未必下降？：免費與訂閱模型怎麼分工的成本判斷。
進階篇
給已經會看設定檔與 log 的人：三層真相
以下內容需要你會打開 Hermes 的 config.yaml、看懂 log。新手可以先略過。
Hermes 官方把每個 Bot 定義為一個 profile，各自有設定、記憶、skill、credential 與歷史；群聊中的每位成員也維持自己的 persistent Group session。一則訊息最多觸發三輪 serial turns，不是每個 Bot 都一定要回覆。每位成員每輪會收到自上次發言以來的房間訊息，上限約 200 則或 32,000 字元，單則過長訊息會被截成 8,000 字元摘錄。[1]
「這位 Bot 用的是哪個模型」至少有三種看法，而且三者可能不同：
- Config：profile 的
config.yaml，代表預期路由。 - Session metadata：
state.db裡記錄的 model/provider，代表 session 身分，不代表這一輪實際用了什麼。v0.21.6 的群聊成員 session 標題是Group: <room_id>（房間 ID）；舊版 Desktop 用的是房間顯示名稱，兩種都可能同時存在於你的資料庫。 - Runtime evidence：log 裡主對話 API call 的 provider、base URL、exact model ID，代表這一輪真的打到哪裡。
看 UI 顯示名稱、Bot 自報，或只看 sessions.model，就宣布「模型已切換」。Fallback 仍可能回出成功訊息，舊 session metadata 也可能留著上一個 model。真正驗證要看設定修改之後的 provider-tagged main call。健康檢查工具做的就是這件事。
完整路由不是一個模型名稱
(provider, base_url, exact_model_id, context_window, credential_source, pricing, fallback_chain)看起來相同的模型，可能由不同 provider 提供，使用不同 key、OAuth 訂閱、價格與 context window。曾經有一個 alpha 名稱同時出現在不同 provider；把其中一邊的存在拿去證明另一邊，會得到完全錯的成本結論。Fallback 也要記 context window：目前對話長度若超過備援模型的上限，那條 fallback 對這一輪根本不可用。
401：這個 provider 的認證或帳戶有問題。404：這個 provider/base URL 找不到 exact ID，或模型已下架。429：route 存在，但速率或上游容量不足。不是「模型不存在」，也不等於 credential 無效。
新版在 Bot 之間互傳訊息失敗時，會附上機器可讀的原因代碼，例如 provider_rate_limit、provider_auth_or_access、context_overflow、model_unavailable，Desktop 的 needs-attention 標記也用同一套代碼；判讀時可直接對照，不必只靠 HTTP 數字。[1]
Hermes 把 secrets 放在 .env，OAuth credential 另有 auth 儲存。[3]工具只顯示 credential 來源與是否存在，不讀出值。
錯誤發生在哪一層
| 證據 | 分類 | 處理 |
|---|---|---|
| 沒有 session activity、prompt accepted、API call | zero dispatch | 查 mention、Desktop coordinator 與 responder selection |
| prompt accepted，接著 context length exceeded；沒有 provider call | API 前 blocker | checkpoint、compact；無進展才 rotate |
| provider 404 後 fallback | primary route retired/wrong | 驗 catalog 與 exact ID；分開記錄 fallback |
| API success，turn complete，UI 沒答案 | delivery/render gap | 查 Desktop append 與 room log |
| 只看到 turn settled | 未知 | settled 可能是零 responder，不能宣稱成功 |
| 新指令進入已封存 session ID | stale mapping（舊版 Desktop） | 查 room.sessions 與 session title discovery；新版先確認是否仍會發生 |
| Activity 顯示 couldn't start — too many bots running | 本機 backend 沒有空位 | 減少同時運作的 Bot，或稍後再點名 |
Context 維護門檻（我們的操作建議，不是 Hermes 產品保證）
- 模型視窗約 35–40%：更新 checkpoint。
- 約 45–50%：選 idle 時段 compact。
- compact 前後 token 幾乎沒降：準備 member session rotation。
- 整份檔案、完整 terminal output、長 diff：留在檔案系統，只貼摘要與路徑。
別用 sessions prune 解 context 壓力。Prune 是刪除已結束 session 的儲存維護；active context 卡住是另一個問題。官方建議資料庫變大時先用 non-destructive optimize。[2]
進階篇
我們怎麼從切模型一路走到 session 塞爆
新版 Hermes 已改善多處群聊行為：房間狀態改存在 gateway 的 shared-state.db 並由 gateway 驅動輪次，關掉 Desktop 也不會中斷；成員失敗會帶原因顯示在 Activity；群組設定可直接 Compress history。下面第五、六階段牽涉的 Desktop 本機儲存問題，我們沒有在新版重現，請把它當成理解原理的案例，不要照著操作。[1]
Bot Mode 群聊當時沒有每位成員的完整 route 顯示。我們一度相信 Bot 自報與 session model 欄位，後來才發現 fallback、session override 與舊 worker 會讓三者分家。
錯字只差一個連字號，或同一個 alpha 名稱出現在兩個 provider，就足以把免費、付費與訂閱 quota 混在一起。之後我們只記完整 tuple。
舊 session 還指向已退役 alpha。每輪先做三次 404 retry，再 fallback。只看最後有沒有文字，會錯過前面的 route 已經死掉。
舊 member session 累積大量訊息，fallback 模型視窗較小；compression 的 auxiliary provider 又無法使用。結果在主請求前就出現 Context length exceeded，且無法再壓縮。
我們把舊 session 改名、pin 並保留歷史，以為 Desktop 會建立新 session。實際上 room 的 localStorage mapping 先拿舊 session ID 去 resume，title lookup 排在後面。
localStorage readback 已空，但 renderer 關閉時，記憶體中的舊 room atom 把 mapping 寫回。修正後流程變成：write → readback → reload renderer → postReload readback → 才重啟。
原 room、roster、visible history 全部保留；五位成員各自建立新 session，初始 history 為 0。三位 primary 遇到 shared-pool 429 後由預定 fallback 完成，另外兩位直接以各自設定完成。「房間沒換、歷史沒刪、工作 context 換新」。
進階篇
三級修復 SOP
Level 1：唯讀診斷（任何人都可以做）
- 跑健康檢查工具，或自己讀 profile config、session DB 與 logs。
- 判定是 no dispatch、API 前 blocker、provider failure、fallback 還是 delivery gap。
- 沒有 runtime evidence 就寫「未驗證」，不要補故事。
Level 2：compress、checkpoint 與 member session rotation
- 先用群組設定的 Compress history（等同對該成員隱藏 session 執行
/compress）。 - 把專案記憶外部化。
- 備份所有 member DB。
- 舊 session 改名、pin、驗 message count，不刪除。
- 在同一 room 建立下一代 member sessions。
Level 3：Desktop plugin storage rescue（舊版紀錄，新版不適用）
這一級是針對 2026 年 8 月 Desktop 版本、房間對應關係存在 Desktop 本機儲存時的修復。新版房間狀態已移到 gateway，這段流程不應直接套用。只有在舊版、證據顯示群聊錯綁到已封存的舊 session、而且 Level 2 無效時才考慮。我們當時寫的救援腳本把 room ID 與本機路徑寫死，是一次事故、一個房間、有完整備份下的修復，不是日常工具，也不提供下載。一次回覆很慢、429、401/404、或後端完成但畫面沒顯示，都不需要走到這一級。
- 只清目標 room 的
sessions、sessionOwners、stranded、holds。 - 保留 room ID、name、roster、log、image 與 sync metadata。
- 必須有原始 storage backup、write readback、renderer reload、postReload readback。
- 重啟後送短 marker，再從 DB 與 provider logs 驗收。
不是「腳本 exit 0」，而是同一 room ID 還在、roster 與 visible history 還在、舊 sessions 可搜尋且 message count 沒變、新 session IDs 已建立，而且每位預期 responder 都有 provider-tagged main call 或明確 typed blocker。
Sources
- Hermes Agent Docs, Bot Mode：Bot/Profile 關係、per-Bot model pin、群聊 rounds、persistent member sessions 與 pass 行為。
- Hermes Agent Docs, Sessions：SQLite session history、context 組成、compression、search、optimize/prune 邊界。
- Hermes Agent Docs, Configuration：config、.env、auth、provider 與 secret 儲存邊界。
- Hermes Agent v0.21.6 Release Notes（2026-10-08）：更新範圍（CLI／Docker／Hermes Cloud，Desktop 未更新）、限流訊息改善；完整功能說明將隨 v0.22.0 發布。
本文的故障鏈、token 數量級與修復順序來自 HERAIZONE 在 Windows Hermes Desktop Bot Mode 的實機紀錄。不同 Hermes 版本的介面、log 字串與 Desktop 行為可能不同，動手修復前請以當前官方文件與實際紀錄為準。