学习指南 / 第九章
第九章

上下文管理

🎧 语音播放

理解 Hermes 如何管理长对话的上下文

🎯 本章目标

  • 理解上下文长度限制的问题
  • 掌握上下文压缩机制
  • 理解 token 估算方法

📚 前置知识

  • Token 和上下文窗口的概念

💡 学完收获

  • 理解上下文管理的必要性
  • 能够诊断上下文相关问题

9.1 上下文窗口的问题

每个 LLM 都有上下文窗口限制——这是硬件和算法的本质约束：

模型上下文窗口约等于
Claude 3.5 Sonnet200K tokens15万英文单词
GPT-4 Turbo128K tokens10万英文单词
Llama 3.1 8B8K tokens6千英文单词
💡 Token 是什么？

Token 是文本的最小单元。英文约 4 个字符 = 1 个 Token，中文约 1-2 个字 = 1 个 Token。当对话超过这个限制，LLM 就会出错或丢失早期信息。

9.2 Token 估算

Hermes 需要知道用了多少 tokens，才能判断是否需要压缩：

📊 estimate_tokens_rough()
model_metadata.py
def estimate_tokens_rough(text: str) -> int:
    """Rough token estimation"""
    # 英文约 4 字符/token
    # 中文约 1-2 字/token
    return len(text) // 4
⚠️ 估算 vs 精确计算

这是粗糙估算。真正的 token 数需要用 tiktoken 或 similar 库计算。但估算足够用于判断是否需要压缩。

9.3 压缩策略

当上下文快满时，Hermes 使用"保留最近 + 总结过去"的策略：

压缩前
150+ 条消息
[msg1] [msg2] [msg3] ... [msg100] [msg101] [msg102]
总共 ~150K tokens ⚠️ 超限！
压缩后
保留摘要 + 最近消息
[Summary: 用户在开发 Python 项目...] [msg95] [msg96] ... [msg102]
总共 ~80K tokens ✅ 安全

9.4 压缩执行流程

上下文压缩流程 Context Compression

flowchart TD A["📊 检查 tokens"] --> B{"超过 80%?"} B -->|否| C["✅ 继续"] B -->|是| D["📝 提取旧消息"] D --> E["🤖 LLM 总结"] E --> F["🗑️ 删除旧消息"] F --> G["➕ 插入摘要"] G --> C style B fill:#ede9fe,stroke:#7c3aed style E fill:#dbeafe,stroke:#2563eb style D fill:#fee2e2,stroke:#ef4444

9.5 Anthropic Prompt Caching

对于 Claude 模型，Hermes 支持 Anthropic 的 Prompt Caching 特性：

⚡ Prompt Caching

Anthropic 的 Claude 支持将系统提示和早期消息标记为"可缓存"，这样每次调用只需传新增的消息，而不是整个上下文。

这对长对话场景可以大幅降低成本和延迟。

9.6 最佳实践

✅ 应该做
  • 长任务定期让 Agent 总结进展
  • 使用合适的 max_iterations
  • 启用记忆摘要
⚠️ 避免
  • 单次对话过长（>100轮）
  • 上传超大文件到对话
  • 重复相同的任务

📚 本章总结

本章重点：

  • 上下文窗口是有限资源
  • 压缩策略：保留最近，总结过去
  • Token 估算是近似值
  • Claude 支持 Prompt Caching

一句话记忆点： 上下文管理就是"用多少省多少"——在有限窗口里装最多的有用信息

延伸思考

  1. 除了总结，还有哪些压缩策略？（如：分层记忆、重要性筛选）
  2. 如果总结丢失了重要细节怎么办？
  3. Claude 的 Prompt Caching 和传统压缩相比有什么优劣？