### 1、上下文压缩配置指南

| 上下文大小 | summaryWindowSize 建议 | summaryWindowToken 建议 | 适用场景与策略建议 |
| -------- | -------- | -------- | -------- |
| 20k     | 10 - 15     | 8,000 - 12,000     | 紧凑型： 必须频繁触发 Summarization。由于容量有限，需严格控制工作内存，防止超出导致的强制截断。 |
| 100k     | 30 - 40     | 24,000 - 32,000     | 均衡型： 能够容纳较长的代码段或多轮 ReAct 思考。32k 是目前大多数模型保持高召回率（Recall）的黄金线。 |
| 200k     | 50 - 60     | 48,000 - 64,000     | 扩展型： 适合复杂任务编排。利用长上下文减少摘要频率，保持原始 Tool Call 链路的完整性。 |
| 1m (100万)     | 100 - 150     | 128,000+     | 海量型： 此时 maxTokens 更多是为了控制成本和响应延迟。通常设为 128k 即可覆盖绝大多数超长对话。 |


### 2、重要提醒

* 摘要窗口越大，有助于 llm 理解上下文；但是，上下文的 token 也会越大（越费钱）
* 搞要窗口太小，llm 不好施展拳脚（还可能处处受制。比如：读取的文件，很快就被压缩了）