上下文管理

会话上下文的压缩、重置、归档与恢复——让 AI 保持高效响应。

为什么需要上下文管理

LLM 有上下文窗口限制。随着对话进行，历史消息越来越多，会导致：

OpenVort 提供四种上下文管理操作来解决这些问题。

压缩是最常用的操作。它用 LLM 将旧消息总结为一段摘要，保留最近的 10 条消息，大幅减少上下文长度。

在聊天中发送 /compact 命令：

/compact

> 已压缩: 38 条 → 11 条（摘要 + 最近 10 条）

系统会在每轮 LLM 调用前估算上下文 Token 数。当超过约 70000 Token 时，自动触发压缩。

压缩前: [msg1, msg2, ..., msg38]
压缩后: [摘要消息, msg29, msg30, ..., msg38]
         ↑ LLM生成的摘要     ↑ 保留最近10条

摘要会保留关键信息：用户需求、重要决策、工具调用结果等。如果 LLM 摘要生成失败，系统会回退到简单文本摘要（截取每条消息的前 200 字）。

重置比压缩更"干净"——直接清空活跃上下文，从零开始。但旧消息不会删除，而是移入归档。

重置前:
  活跃消息: [msg1, msg2, ..., msg25]
  归档消息: []

重置后:
  活跃消息: []（空白开始）
  归档消息: [msg1, msg2, ..., msg25]（可查看、可恢复）

重置后的历史消息不会丢失。在 Web 面板中可以分页浏览归档消息，查看之前的对话内容。

多次重置会累积归档——每次重置的消息追加到归档末尾。

如果需要继续之前被重置的话题，可以将归档消息合并回活跃上下文。

恢复后归档会被清空，所有消息回到活跃状态。

恢复会导致上下文变长。如果归档消息很多，恢复后可能需要执行一次压缩。

除了压缩和重置，系统还有一个自动裁剪机制：当活跃消息超过 50 条时，自动丢弃最旧的消息。

裁剪时会注意保持工具调用的完整性——不会只保留 tool_use 而丢失对应的 tool_result，避免 LLM 混淆。