Hermes Agent 社群回報壓縮後歷史缺漏，桌面端編輯重複提示可能選錯位置

Hermes Agent 社群於 11 月 1 日提出一項長對話一致性問題：執行原地壓縮後，session.history 可能漏回先前已顯示、如今被封存的回覆與語音訊息。同一段對話透過其他讀取路徑仍能看到這些內容，讓不同客戶端取得的歷史不一致。回報針對當日主分支，附有重現測試及公開修補分支，尚不能視為已修復的正式功能。議題與重現說明

官方文件說明，Hermes 將完整訊息與工具呼叫等資料存入 SQLite；壓縮的用途是縮減模型當前使用的上下文，並不等於刪除紀錄。文件也指出，顯示用匯出應包含原地壓縮封存的回合，而完整備份還會保留被回退或編輯移除的資料。這些設計使「模型目前讀取哪些訊息」與「使用者應看見哪些歷史」成為不同的資料視圖。官方工作階段文件

依回報者分析，問題出在歷史 API 只讀取仍有效的對話脈絡，桌面顯示卻包含封存回合。當使用者中斷任務後，編輯較早、文字又與最新提示相同的訊息，定位程式比較的序號便可能錯位。作者提供的探測案例中，較早的 continue 被解析成最新一筆；另有訊息數量與實際回傳清單不符的情況。這些結果目前仍屬作者測試，未獲獨立重現確認。技術分析

提出的修補方向是合併顯示歷史與有效訊息，為封存列加上標記，並同步調整編輯定位與計數。對代理系統工程師而言，此案值得關注之處是壓縮後的資料契約：畫面、歷史 API 與編輯操作需要共享一致的訊息身分，才能避免同文提示產生歧義。後續應觀察修補是否合併，以及封存、回退和重複提示的回歸測試；現有證據不足以推論底層資料已被刪除。