Hermes Agent 社群回報長對話轉送失敗，1 MiB 傳輸上限阻擋新提示

Hermes Agent 社群於 10 月 26 日回報，多個後端共用同一設定檔時，長對話可能無法接收新提示。回報情境包含閘道擁有者與 Desktop-SSH 隔離後端；後者收到請求後，須將提示轉送給持有該工作階段的後端。問題發生在轉送前的還原程序，使用者可能只看到忙碌或拒絕訊息。問題回報與討論

依社群分析，轉送連線先呼叫 session.resume，回應攜帶完整對話歷史，卻沿用 WebSocket 函式庫的預設接收上限。當資料超過 1 MiB，連線便以代碼 1009 關閉，尚未執行後續的 prompt.submit。這表示失敗點在代理的通訊層，不能據此判定模型上下文已滿。技術分析

上游 websockets 官方文件確認，connect() 的 max_size 預設為 1,048,576 位元組，控制的是傳入訊息大小；設為 None 可取消限制。這項文件支持回報描述的限制機制，但無法單獨證明 Hermes 的所有部署都受影響。websockets API 文件

社群提出將容量提高至 8 MiB，與一般客戶端路徑對齊；27 日另有參與者回報，9 MiB 回應仍會失敗，並指出轉送端其實只需要工作階段識別碼。討論因此進一步主張，讓還原端遵守 omit_messages，避免傳回不需要的歷史資料。修補與邊界測試討論

對維運長時間代理的工程師而言，此案提醒工作階段持久化與跨後端路由也有容量邊界。後續應追蹤修補是否進入正式版本、超限錯誤能否清楚呈現，以及省略歷史的行為是否落實。截至查核，問題仍開放，本文未獨立執行重現，也未確認正式修復版本。