CliffCompaction 釋出代理壓縮套件，以原文片段縮減上下文

CliffCompaction 九月二十三日將 0.1.0 套件上架 PyPI，讓長時間執行的程式代理透過 API 代理服務壓縮對話。研究預印本於前一天提交，這次套件發布提供了可直接整合的實作。套件採 MIT 授權、需要 Python 3.11 以上。[套件紀錄](https://pypi.org/project/cliffcompaction/0.1.0/)、[論文紀錄](https://arxiv.org/abs/2609.26779)

方法在上下文超過門檻後，保留系統提示、任務與最近回合，較舊內容則依規則截短或刪除，不另外呼叫模型改寫。超過五百字元的工具結果會被丟棄，短結果原文保留；下一次壓縮也會捨棄上一份壓縮內容。因此，它保留的是有限範圍的原文線索，並未保存完整歷史。[公開實作](https://github.com/nguyenvuthientrang/cliffcompaction)

論文在 Terminal-Bench 2.0 使用 Terminus-2 與 Kimi K2.6，將壓縮門檻設為 16K token，解題率由完整上下文的 59.16% 變為 61.42%，主要成本表則由每題 0.40 美元降至 0.19 美元。不過該表以理想快取模型重算費用，不能直接當作服務商實際帳單；小幅分數差距也須連同多次執行的波動解讀。[論文結果與成本方法](https://arxiv.org/html/2609.26779v1)

公開代理還有重現落差：套件文件預設保留完整助理文字與思考，論文則將思考截至三百字元；預設觸發門檻也不是實驗的 16K。直接安裝後沿用預設值，不能視為重現上述成績。工程師應記錄版本與全部壓縮參數，再比較成功率和費用。[套件設定](https://pypi.org/project/cliffcompaction/0.1.0/)

整合時，代理會對訊息建立雜湊鏈，辨識原始歷史前綴，再替換成縮短內容。專案要求停用框架自身的壓縮，以免歷史改寫破壞匹配；解析或儲存失敗時，預設原文放行。因此門檻並非硬性上限，量測可另開嚴格模式，先以影子模式觀察哪些內容將被移除。[運作與失敗處理](https://github.com/nguyenvuthientrang/cliffcompaction)

作者另指出，壓縮後增加的步驟多為重讀檔案，部分任務會因此耗盡步數而未提交結果。[開發紀錄](https://nguyenvuthientrang.github.io/cliffcompaction/)

這種設計把長期記憶的負擔部分交還給檔案與工具。部署評估應追蹤重讀次數、步數耗盡與快取命中率；若被刪除的資料已無法重新取得，僅靠保留工具名稱也無法恢復內容。下一步需要的是實際專案中的版本固定重測，確認省下的上下文成本是否足以抵銷資訊重取。