10.3 上下文窗口管理

虽然 Claude 拥有 200k 甚至更长的上下文窗口 (Context Window),但这并不意味着应该无限制地往里塞东西。 长下文腐烂 (Context Rot)注意力稀释 (Attention Dilution) 是真实存在的问题。而且,越长的 Context 意味着越慢的速度和越高的成本。

本节介绍几种高级的上下文压缩与管理策略。

10.3.1 滑动窗口 (Sliding Window)

这是最简单粗暴的策略,但在 Chatbot 中依然有效。

history = [...]
# 仅保留最近的 N 轮
if len(history) > 20:
    history = history[-20:]

问题: 容易丢失早期的关键指令(如 "我不吃辣")。 改进: Pinned System Message + Sliding History。永远保留第 1 条 System Prompt,只对后续的对话进行滑动。

10.3.2 递归摘要 (Recursive Summarization)

这是一种像"滚雪球"一样的记忆方式。每隔 N 轮,就让 Claude 把之前的对话浓缩成一段摘要。

Workflow:

  1. 对话达到 10 轮。

  2. 后台触发 Summarizer: "请将这 10 轮对话总结为 200 字以内的摘要,保留关键事实(姓名、时间、偏好)。"

  3. 将摘要存入 previous_summary 变量。

  4. 清空历史,只保留 System Prompt + previous_summary + 最新对话。

优点: 理论上支持无限长的对话。 缺点: 每一次 summary 都会丢失细节信息(Lossy Compression)。

10.3.3 关键信息提取 (Context Distillation)

与其总结,不如提取。 当用户说了一大堆废话时,只提取对后续有帮助的 State

  • User: "今天天气不错...对了,帮我把背景色改成蓝色...还要加个 Logo..."

  • Distillation Agent: update_state(background="blue", logo=True)

  • Context: 只保留 State Object,丢弃原始对话。

这在 Agentic Coding 中非常常用:只保留当前的文件内容代办清单 (TODO),而不需要保留 "尝试修 Bug A 失败了 3 次" 的完整日志。

10.3.4 RAG-based Long-term Memory

对于超长会话(如陪伴型 AI),最好的策略不是把所有历史都塞进 Context,而是存入向量数据库。

Retrieve Strategy: 当用户说 "像上次一样" 时:

  1. 用 "上次" 为 Query 去搜 Vector DB。

  2. 检索出 3 个月前的那段对话片段。

  3. 注入当前 Context。

这种方式实现了"无限记忆"与"有限 Context"的完美平衡。

实现示例:

10.3.5 上下文管理的黄金法则

在实际应用中,请牢记以下原则:

  1. 质量优于数量:100 条精选的历史比 1000 条冗余信息更有价值。

  2. 结构化存储:使用 JSON 或 XML 格式存储状态,便于精确检索。

  3. 定期清理:为历史记录设置 TTL(生存时间),自动淘汰过期数据。

  4. A/B 测试:不同的压缩策略效果因场景而异,务必用真实数据验证。


如果说上下文管理是"节流",那么模型路由就是"开源"。 不需要总是用最贵的模型。合理的模型搭配可以用白菜价享受到顶级的服务。

➡️ 模型选择与路由策略

最后更新于