Open WebUI 釐清上下文壓縮限制，巨型單輪回覆仍可能使對話超出視窗

Open WebUI 在 10 月 20 日的一場技術討論中，釐清自動上下文壓縮的邊界：即使對話超過設定的 token 門檻，也不保證能產生摘要。社群回報者指出，工具密集的代理任務可能把大量輸出存進單一助理訊息，形成訊息數很少、實際內容卻已超出模型視窗的對話。專案成員將回報重新歸類為功能需求，說明目前行為符合文件描述。討論與專案回應

回報涉及兩道判斷：三則以下訊息會略過壓縮；保留近期內容的切點則依訊息數量選擇，而非各則訊息的 token 比重。因此，即使較長對話有執行摘要，保留下來的一則巨大工具回覆仍可能讓下一次請求超限。回報者表示在 0.12.0 的實際部署觀察到此情況，並提供不需呼叫模型的重現步驟；這些觀察仍應與所有版本的普遍影響區分。回報細節

版本差異是關鍵。專案成員表示，從 0.12.1 起，原生工具迴圈也會在工具輪次之間檢查並壓縮上下文，減少整段工具歷史累積成巨型回覆的情況。但已超限的舊訊息還有另一道限制：摘要請求本身也須容納待摘要全文，手動執行 /compact 同樣可能失敗。成員建議，受影響使用者可編輯第一則訊息後重送，建立不含巨大回覆的新分支，或另開對話。處理方式

官方文件明確說明，壓縮預設關閉，而且回合開始時必須找到合適的使用者訊息作為切點；找不到便送出完整歷史。因此，工程團隊應把門檻視為啟動摘要的條件，另行驗證最終請求大小，尤其要測試單輪大量工具輸出的負載。需要保證輸入上限時，文件建議以 filter Function 實作裁切政策。上下文管理文件

社群已提出按 token 比重調整切點的修補，但該 PR 已關閉、未合併，不能視為正式修復。後續值得追蹤的是專案是否接受此類切分策略，以及既有超大訊息能否取得更直接的復原路徑。修補提案