issue: context compaction keeps a percentage of the message count, so chats with large messages compact again on every single turn

快速结论：当开启 Open WebUI 上下文压缩（context compaction）且保留比例是按消息条数计算时，如果保留下来的尾部消息里包含体积很大的内容（长工具输出、粘贴文档、RAG 上下文），压缩后的请求仍会超过 token_threshold，于是下一轮会再次触发压缩。优先排查保留比例、token_threshold 以及压缩后尾部消息的实际 token 量。

适用环境：Open WebUI v0.11.3（Issue 作者也在 dev @ a096961a3 复现）；Pip Install (uv)；Linux；后端逻辑，浏览器不相关；使用 OpenAI 兼容 API，Ollama 不适用。

最快修复方案：暂无确认的一步修复方案。Issue 中管理员明确说明“保留消息数为消息条数百分比是设计如此”，因此官方不视为缺陷，报告中建议的按 token 感知的保留逻辑并未被采纳。

注意事项：Issue 已关闭，没有合并任何修复代码。管理员回应称“每一轮都会压缩”并不准确：每轮最多保留一半消息，且被摘要的消息不会回来，所以过大的尾部通常只多花一到两轮就会稳定；日志中第二次压缩覆盖的正是第一次保留的 35 条消息，中间没有新增，可能是对同一消息的重试或重新生成。该判断基于管理员的解释，未在 Issue 中提供进一步代码验证。

问题场景

用户在 Open WebUI 中开启上下文压缩，配置为默认的 token_threshold=80000、retention_percentage=40，对话中包含体积较大的消息（例如工具调用模型每轮携带约 17 KB 的 tool output，或多次粘贴长文档），在连续发送消息时反复看到 “Compacting context…” 提示，并且每次压缩都会额外调用任务模型做摘要。该问题在后端逻辑中触发，与浏览器无关，也可直接对 open_webui.utils.context_compaction 模块复现。

报错原文

Compacted chat context for chat=<redacted> dropped=52 kept=35
Compacted chat context for chat=<redacted> dropped=20 kept=15

Issue 标题中的核心描述：

issue: context compaction keeps a percentage of the message count, so chats with large messages compact again on every single turn

原因分析

最可能的原因是压缩的“是否触发”按 token 判断，而“保留多少”按消息条数判断：

_exceeds_token_threshold 基于 token，且优先使用真实的 usage.prompt_tokens。
_find_compaction_boundary 基于消息条数，完全忽略消息体积：keep_count = max(2, len(messages) * retention_percentage // 100)。

因此保留下来的 N% 消息尾部可能仍然远超 token_threshold，导致下一次请求再次压缩。Issue 中的复现脚本显示：41 条消息、每条 assistant 消息携带 40 KB 工具结果时，按 40% 保留后仍有 17 条消息、约 80386 tokens，超过 80000 阈值。消息体积均匀且较短的对话不会命中该问题。

需要注意的是，Open WebUI 管理员在 Issue 中回应：保留消息按消息条数百分比设计，文档也是这么描述的，并说明压缩并非硬性上限，当窗口再次超过阈值时会再次压缩，因此该行为属于文档化行为，而非已确认的缺陷。

环境排查

确认 Open WebUI 版本：Issue 中为 v0.11.3，并在 dev @ a096961a3 复现。
确认安装方式：Pip Install (uv)。
确认操作系统：Linux。
确认使用的是 OpenAI 兼容 API，Ollama 不适用（N/A）。
确认压缩配置：token_threshold、retention_percentage，Issue 默认值为 token_threshold=80000、retention_percentage=40。
确认对话中消息体积是否不均衡，例如是否存在大体积工具输出、长文档粘贴或多轮 RAG 上下文。
Python、CUDA、PyTorch、显卡等环境信息在 Issue 中未提供，无法据此排查。

解决步骤

先确认当前压缩配置，记录 token_threshold 与 retention_percentage 的实际取值。
复现时观察日志中每次压缩的 dropped 与 kept 数值，判断保留的尾部消息是否仍然很大。
如果对话中存在体积很大的工具输出或粘贴文档，可优先尝试降低 retention_percentage，以减少保留下来的消息条数。
可优先尝试提高 token_threshold，或在对话增长前提前开启压缩，避免出现压缩后仍超阈值的情况（管理员回应指出，开启压缩时若对话已经增长过大，或单条消息本身超过阈值，才会进入这种状态）。
如果日志中连续压缩的数字显示第二次压缩恰好覆盖第一次保留的消息、且中间没有新消息，需先确认是否是对同一消息的重试或重新生成，而不是新增的后续消息。
由于 Issue 已关闭且未合并修复，如果上述调整后仍反复压缩，建议按现有 Issue 链接关注后续进展，而不是依赖本 Issue 中的代码改动。

验证方法

在调整保留比例或阈值后，发送多轮短消息，观察日志中是否仍在每一轮出现 “Compacting context…”。同时确认压缩后的请求 token 量是否已低于 token_threshold。Issue 中管理员提到，即使尾部仍偏大，通常也只多花一到两轮就会稳定，因此可观察连续几轮压缩后是否停止继续压缩。