聊天记录携带轮数优化以利用缓存

**例行检查**

[//]: # '方框内填 x 表示打钩'

- [x] 我已确认目前没有类似 features
- [x] 我已确认我已升级到最新版本
- [x] 我已完整查看过项目 README，已确定现有版本无法满足需求
- [x] 我理解并愿意跟进此 features，协助测试和提供反馈
- [x] 我理解并认可上述内容，并理解项目维护者精力有限，**不遵循规则的 features 可能会被无视或直接关闭**

**功能描述**
现在大部分模型都支持缓存了，而且命中缓存价格都比较低。现在携带固定轮数的历史记录发给AI的时候，会导致达到轮数以后每次滚动的最新6条对话记录无法命中缓存

**功能建议**
建议将轮数设置为一个动态范围，例如6-12，每当达到12的时候，就会清空缩减保留到6轮，然后再逐渐增加到12的过程中就可以利用缓存

⏺ 两种缓存策略成本对比分析

基本参数

- 提示词：8000 token（固定）
- 每轮对话：2000 token
- 默认价格：0.8 元/M token
- 缓存价格：0.16 元/M token（原价的 20%）

---
方案一：固定6轮滚动窗口

每次请求的输入：8000 + 6×2000 = 20,000 token

由于滚动（删旧加新），对话部分每次都变化，无法命中缓存：

| 部分 | Token数 | 价格 | 成本 |
|-----|--------|---------|------------|
| 提示词 | 8,000 | 0.16元/M | 0.00128元 |
| 对话 | 12,000 | 0.80元/M | 0.00960元 |
| 合计 | 20,000 | - | 0.01088元/次 |

---
方案二：6-12轮周期循环

一个完整周期（7次请求）：

| 请求 | 轮数 | 缓存部分 | 新增部分 | 成本计算 | 成本 |
|-----|-------|--------|--------------|-------------------|----------|
| 1 | 6→7 | 8,000 | 12,000+2,000 | 8k×0.16 + 14k×0.8 | 0.01248元 |
| 2 | 7→8 | 22,000 | 2,000 | 22k×0.16 + 2k×0.8 | 0.00512元 |
| 3 | 8→9 | 24,000 | 2,000 | 24k×0.16 + 2k×0.8 | 0.00544元 |
| 4 | 9→10 | 26,000 | 2,000 | 26k×0.16 + 2k×0.8 | 0.00576元 |
| 5 | 10→11 | 28,000 | 2,000 | 28k×0.16 + 2k×0.8 | 0.00608元 |
| 6 | 11→12 | 30,000 | 2,000 | 30k×0.16 + 2k×0.8 | 0.00640元 |

注：第1次清空后，对话内容改变，12k对话也无法命中缓存

周期总成本：0.04128元（6次请求）
平均每次：0.04128 / 6 = 0.00688元/次

---
对比结论

| 指标 | 方案一（固定6轮） | 方案二（6-12轮） |
|------|-----------|--------------|
| 每次成本 | 0.01088元 | 0.00688元（平均） |
| 相对成本 | 100% | 63.2% |
| 节省比例 | - | 约37% |

---
结论

方案二成本更低，约节省 37% 的费用。

核心原因：方案二在增长阶段（第2-6次请求）可以利用前缀缓存，只有新增的2000
token按原价计费，而方案一每次都有12000 token的对话按原价计费。

但需注意：
- 方案二在清空后的第一次请求成本较高
- 方案二的上下文平均长度更大（约18k vs 20k），可能影响响应速度
- 如果对话质量对历史长度敏感，方案二在不同阶段表现可能有差异