> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/claude_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/claude_guide/di-si-bu-fen-shi-zhan-pian/10_optimization/10.3_context_mgmt.md).

# 10.3 上下文窗口管理

Claude Opus 5、Sonnet 5、Fable 5、Opus 4.8、Opus 4.7 和 Opus 4.6 已进入 1 百万 Token 上下文窗口 (Context Window) 的公开规格或 beta 规格；Sonnet 4.6 仅作为迁移期兼容性基线。可用性、账号权限和计费方式必须按官方模型页、迁移指南与价格页核验。按官方价格页，这些 1M 模型的整个上下文窗口按**标准单价**计费——90 万 token 的请求与 9 千 token 的请求单价相同，缓存与批处理折扣亦全程适用。Haiku 4.5、Sonnet 4.5 等其他 Claude 模型通常为 200K。这并不意味着应该无限制地往里塞东西。 **长上下文腐烂 (Context Rot)** 和 **注意力稀释 (Attention Dilution)** 是真实存在的问题。而且，越长的 Context 意味着越慢的响应速度和更高的延迟。

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

## 10.3.1 滑动窗口

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

```python
history = [...]

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

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

## 10.3.2 递归摘要

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

**Workflow**:

1. 对话达到 10 轮。
2. 后台触发 Summarizer: “请将这 10 轮对话总结为 200 字以内的摘要，保留关键事实（姓名、时间、偏好）。”
3. 将摘要存入 `previous_summary` 变量。
4. 清空历史，只保留 System Prompt + `previous_summary` + 最新对话。

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

## 10.3.3 关键信息提取

与其总结，不如提取。 当用户说了一大堆废话时，只提取对后续有帮助的 **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”的完美平衡。

**实现示例**:

```python
from chromadb import Client
import anthropic

chroma = Client()
collection = chroma.get_or_create_collection("chat_history")
client = anthropic.Anthropic()

def chat_with_memory(user_message, conversation_id):
    # 检索相关历史
    relevant_history = collection.query(
        query_texts=[user_message],
        n_results=3,
        where={"conversation_id": conversation_id}
    )

    # 构建上下文
    context = f"相关历史记录：\n{relevant_history['documents']}"

    # 调用 Claude
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        system=context,
        messages=[
            {"role": "user", "content": user_message}
        ]
    )

    # 存储新对话（chromadb 的 add() 要求显式提供 ids）
    import uuid
    reply = response.content[0].text
    collection.add(
        ids=[str(uuid.uuid4())],
        documents=[f"User: {user_message}\nAssistant: {reply}"],
        metadatas=[{"conversation_id": conversation_id}]
    )

    return reply
```

## 10.3.5 原生上下文压缩

随着智能体任务越来越长（跨越数十分钟到数小时），传统的滑动窗口和递归摘要策略显得力不从心。业界正在向 **原生压缩**（Native Compaction）方向演进——由模型本身而非外部脚本来执行上下文压缩。

### 原生压缩的工作原理

原生压缩的核心思想是：让经过专门训练的模型自动分析对话历史，生成一个高效的“压缩项（Compacted Summary）”，以紧凑的 Token 表示方式保留关键历史状态。

```
压缩前：180,000 tokens（完整对话历史）
   ↓ 模型执行原生压缩
压缩后：45,000 tokens（压缩项 + 最近对话 + 关键文件）
```

压缩完成后，新的上下文窗口包含压缩项以及之前窗口中最有价值的部分内容，使长时程工作流能够保持连贯而不丢失关键决策和状态。

### Claude Code 的 `/compact` 命令

Claude Code 提供了 `/compact` 命令来手动触发上下文压缩。当对话历史接近上下文限制时，也会自动触发压缩：

```bash
# 手动压缩
> /compact

# 带自定义重点的压缩（参数就是自由文本的摘要指令，没有专门的命令行旗标）
> /compact 重点保留架构决策与测试结果
```

Claude Code 的压缩策略遵循“缓存安全”原则（详见 [10.2.9 节](/claude_guide/di-si-bu-fen-shi-zhan-pian/10_optimization/10.2_caching.md)）：压缩请求复用完整的系统前缀以命中提示词缓存，只有新增的压缩指令本身按全价计费。

## 压缩前的记忆刷写

压缩是有损操作，必然丢失部分细节。为避免关键信息丢失，推荐在压缩触发前先执行 **记忆刷写（Memory Flush）**——将需要长期保留的决策、偏好和事实写入外部文件（如 `CLAUDE.md` 或项目笔记），然后再执行压缩。

```
上下文接近 75% 窗口限制
   ↓ 记忆刷写：关键决策写入 CLAUDE.md
   ↓ 执行压缩：对话历史 → 精简摘要
   ↓ 继续工作：摘要 + 最近对话 + 读取 CLAUDE.md 恢复状态
```

这种“先存后压”的模式确保了即使经过多次压缩，核心的项目知识和用户偏好也不会丢失。

## 服务端压缩 vs 客户端压缩

| 维度       | 服务端压缩         | 客户端压缩         |
| -------- | ------------- | ------------- |
| **触发方式** | 设置阈值，API 自动执行 | 客户端显式调用       |
| **优点**   | 零客户端逻辑，对开发者透明 | 完全可控，可自定义保留策略 |
| **缺点**   | 保留策略不够灵活      | 需要额外的编排代码     |
| **适用场景** | 标准对话机器人       | 复杂智能体工作流      |

对于大多数应用，建议从服务端自动压缩起步，随着需求复杂化再切换到客户端精细控制。

## 10.3.6 上下文管理的黄金法则

在实际应用中，请牢记以下原则：

1. **质量优于数量**：100 条精选的历史比 1000 条冗余信息更有价值。
2. **结构化存储**：使用 JSON 或 XML 格式存储状态，便于精确检索。
3. **定期清理**：为历史记录设置 TTL（生存时间），自动淘汰过期数据。
4. **A/B 测试**：不同的压缩策略效果因场景而异，务必用真实数据验证。

***

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

➡️ [模型选择与路由策略](/claude_guide/di-si-bu-fen-shi-zhan-pian/10_optimization/10.4_selection.md)