[Feature]Token-Threshold Context Compression

[Newtonian-No]

Description / 描述

希望解决的痛点 (Problem / Motivation)

目前 AstrBot 的原生上下文管理器ContextManager在处理长对话或需要多步推理/工具调用的 Agent 任务时，容易遇到 Token 浪费和“前言不搭后语”的问题。

通过排查源码发现，目前的 ContextManager.process() 触发自动压缩的条件是硬编码的（即当前会话 Token 达到大模型最大上下文窗口的 82%）。
然而，现在主流模型（如 DeepSeek、OpenAI 等）的上下文窗口动辄 128k。在实际高频对话或 Agent 连续调用工具（Tool Call）刷屏时，可能在积攒到 1~2 万 Token 时就已经由于中间信息过多导致模型注意力涣散或失忆，且每轮基础 Token 计费过高。而此时由于远未达到 128k 的 82%，原生的 Token 截断/压缩机制完全无法被提前唤醒。

我在官方文档中看到，可以通过手动调小模型的 Context Window 来“欺骗”系统提前触发，但这并非我期望的解决方案，且会全局影响模型的最大边界。

---

期望的标准功能 (Proposed Solution)

建议在 WebUI 的 “普通配置 - 上下文管理策略” 中，将原有的单一模式扩展为允许用户选择限制模式：

1. 按对话轮数 (Turn)：保持原有逻辑。
2. 按 Token 长度 (Token)：用户可以自定义一个触发阈值（例如 4000 或 114514 Token）。一旦当前会话的总 Token 数达到该设定值，立即提前触发 ContextManager 的截断或压缩逻辑（如 llm_compress 等）。

预期改动范围：

• 后端配置模型：扩展上下文配置结构，增加 context_limit_type 和 max_context_tokens 字段。
• 核心逻辑处理：改写 ContextManager.process()，将写死的 model_context_window * 0.82 改为根据用户配置动态切换。
• 前端 WebUI：在上下文策略配置处增加下拉选择框及联动输入框。

Use Case / 使用场景

场景一：复杂 Agent 执行长任务与多步推理遭遇的连续Tool Call

具体表现：当让 Agent 执行诸如“代码库排查”、“本地知识库深度检索”或“多步骤自动化工作流”等长任务时，Agent 通常会通过 Function Calling 频繁调用工具，并在几分钟内连续发送多条消息汇报进度或记录中间思维链。

当前痛点：在这种高频交互下，如果按“轮次”压缩，初始的核心任务指令会极其迅速地被冲掉导致 Agent “失忆”；如果按原生的 82% 窗口压缩，在 128k 窗口的模型下，中间过程会积攒数万 Token 的无用干扰信息，导致模型产生注意力涣散或严重幻觉，前言不搭后语。

改动后收益：用户可设置Token 限制。当 Agent 在后台调用工具产生大量中间文本时，一旦达到该阈值，系统会自动触发压缩，既保留了最新的工具状态，又通过压缩/摘要机制锁住了核心背景，保证长任务的稳定性。

场景二：使用商业 API的成本与速率控制

具体表现：开发者或个人用户在接入付费大模型 API 时，需要对单次对话的成本有严格的预期。

当前痛点：由于原生压缩必须等到大模型最大上下文窗口的 82%（约 10 万 Token）才触发，这意味着单次对话如果任其膨胀，在触发压缩前，每轮对话的基础消耗可能就已经高达数万 Token。对于个人开发者而言，这会导致 API 账单迅速飙升，甚至频繁触发服务商的 RPM/TPM（每分钟/每代币速率限制）阈值导致报错。

改动后收益：用户可以通过直接限制 Max Tokens，将每轮对话的成本卡在可控范围内，优化了高频开发测试阶段的钱包安全。

Willing to Submit PR? / 是否愿意提交PR？

• Yes, I am willing to submit a PR. / 是的，我愿意提交 PR。

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct. /