5. 上下文工程与短期记忆

第 5 章 · 上下文工程与短期记忆

"Context window 不是无限的记忆——它是 LLM 唯一能看见的世界。"

学习目标

完成本章后，读者应能够：

1. 计算 token 预算并管理 LLM 输入长度
2. 用 LongLLMLingua 等方法压缩长上下文
3. 解释"Lost in the Middle"现象的工程影响
4. 区分上下文窗口、对话历史缓存、结构化反思条目三种短期记忆
5. 设计短期记忆的替换与淘汰策略

先修知识

• 第 1 章 · LLM 智能体时代
• 第 4 章 · 提示词工程

章节地图

• 5.1 上下文窗口：LLM 的"工作记忆"
• 5.2 Token 预算与计费
• 5.3 Lost in the Middle：长上下文的陷阱
• 5.4 上下文压缩：LongLLMLingua 等方法
• 5.5 短期记忆的三种实现
• 5.6 本章小结与第 6 章预告

5.1 上下文窗口：LLM 的"工作记忆"

在 LLM Agent 的语境下，上下文窗口（Context Window） 是 LLM 唯一能"看见"的内容——它包括系统提示、用户输入、工具描述、对话历史、工具返回结果。LLM 的所有决策都基于上下文窗口中的内容。

从认知科学的角度，上下文窗口 ≈ LLM 的"工作记忆"——容量有限（约 8K–200K tokens，取决于模型）、可被覆盖、随时间衰减（如果超过窗口，旧内容会被丢弃）。这一点与 Baddeley 的工作记忆模型高度相似。

图 5.1 · 上下文窗口的内容结构

┌──────────────────────────────────────────────────────┐
│  系统提示 (System Prompt)                ~500 tokens  │
├──────────────────────────────────────────────────────┤
│  工具描述 (Tool Definitions)             ~1,000 tokens │
├──────────────────────────────────────────────────────┤
│  短期记忆 (Short-Term Memory)             ~2,000 tokens │
│  - 对话历史 (前 N 轮)                                │
│  - 反思条目 (Reflexion)                              │
├──────────────────────────────────────────────────────┤
│  用户输入 (Current Query)                  ~200 tokens  │
├──────────────────────────────────────────────────────┤
│  工具返回结果 (Tool Observations)          ~5,000 tokens │
├──────────────────────────────────────────────────────┤
│  LLM 输出 (Completion)                   ~500 tokens  │
└──────────────────────────────────────────────────────┘
                  总计 ~9,200 tokens

关键点：上下文窗口的每一部分都消耗 token 预算。系统提示和工具描述是"固定开销"，短期记忆和工具返回是"动态开销"。设计 Agent 时必须明确每个部分的预算。

上下文窗口的大小限制了 LLM Agent 的能力。具体而言：

1. 对话长度受限：超过窗口的对话历史必须被截断或压缩。
2. 工具返回受限：返回大文件（如 PDF、CSV）的内容可能挤爆窗口。
3. 反思条目受限：第 1 章 1.3 节的"反思即记忆"机制受窗口容量限制。
4. 多任务切换受限：处理任务 A 后切换到任务 B，任务 A 的记忆可能被覆盖。

不同 LLM 的上下文窗口大小差异巨大：

复述框 · 5.1 节要点

• 上下文窗口 = LLM 的工作记忆：容量有限、可被覆盖、随时间衰减。
• 5 个组成部分：系统提示、工具描述、短期记忆、用户输入、工具返回。
• 关键约束：对话长度、工具返回、反思条目、多任务切换都受窗口限制。

5.2 Token 预算与计费

Token 是 LLM 处理文本的最小单位。英文 1 token ≈ 0.75 单词 ≈ 4 字符；中文 1 token ≈ 1–2 个汉字。Token 预算（Token Budget）是 LLM Agent 设计中最重要也最容易被忽略的资源。

不同模型的定价（每百万 token）：

表 5.1 · 不同任务的典型 token 消耗

Token 预算管理的核心原则是先算后用。设计 Agent 时，应先估算每个组件的 token 用量，再决定哪些信息进入窗口。例如：

• 系统提示：500 tokens（固定）
• 工具描述：5 个工具 × 200 tokens = 1,000 tokens（固定）
• 短期记忆：保留 2,000 tokens（动态）
• 用户输入 + 工具返回：5,000 tokens（动态，超出需压缩）

总预算 = 500 + 1,000 + 2,000 + 5,000 + 500（输出）= 9,000 tokens。

复述框 · 5.2 节要点

• Token 预算 = 固定开销 + 动态开销：先算后用。
• 5 个组件：系统提示、工具描述、短期记忆、用户输入、工具返回。
• 关键指标：单次成本 × 调用次数 = 总成本。

5.3 Lost in the Middle：长上下文的陷阱

Lost in the Middle 是 Liu 等人 2023 年的重要发现：LLM 对上下文窗口中间部分的信息利用能力显著弱于开头和结尾。这个发现对 LLM Agent 设计有深远影响。

图 5.2 · Lost in the Middle 现象示意

LLM 准确率
   ↑
   │ ██                              ██
   │ ██                              ██
   │ ██                              ██
   │ ██                              ██
   │ ██   ██                  ██   ██
   │ ██   ██                  ██   ██
   │ ██   ██   ░░░░░░░░░░░   ██   ██
   │ ██   ██   ░░░░░░░░░░░   ██   ██
   └─────────────────────────────────────→ 信息位置
     开头  早  ────中间────  晚  结尾
     (U形曲线：两端强，中间弱)

关键点：在长上下文中，重要信息应该放在开头或结尾，避开中间。这是工程上的"U 形布局"原则。

Lost in the Middle 的原因有多种解释：

1. 位置编码衰减：Transformer 的位置编码对"长距离依赖"的处理不如短距离稳定。
2. 注意力机制偏差：注意力权重倾向于极端位置（开头和结尾），中间位置被稀释。
3. 训练数据偏差：训练数据中"上下文头尾"通常包含更关键的信息（如 system prompt、用户问题）。

针对这个现象，LLM Agent 设计有三个实践建议：

建议一：重要信息放两端。 系统提示放最开头，工具返回的"关键结论"放最末尾，中间放辅助信息。

建议二：用结构化标记强调关键信息。 使用 Markdown 标题、引用、代码块等结构化标记，让 LLM 更容易"看到"重要信息。

建议三：分段检索而非堆叠全部。 当需要从长文档中查找信息时，不要把整个文档堆进上下文，而是先检索相关段落，再把检索结果放进上下文。这是第 6 章 RAG 技术的核心思想。

复述框 · 5.3 节要点

• Lost in the Middle：LLM 对中间信息的利用能力弱于两端。
• U 形布局原则：重要信息放开头或结尾。
• 3 个实践建议：两端布局、结构化标记、分段检索。

5.4 上下文压缩：LongLLMLingua 等方法

当上下文超出预算时，有四种压缩策略：

表 5.2 · 四种上下文压缩策略对比

LongLLMLingua 是微软 2023 年提出的"语义压缩"方法，2024 ACL Outstanding Paper。它的核心思想是：

1. 用一个小型 LLM 评分器对每个句子/段落打分（基于"对回答任务的相关性"）。
2. 保留得分最高的 tokens，丢弃低分 tokens。
3. 重新组织保留的 tokens，保留语序和上下文。

LongLLMLingua 在 LongBench 评测上达到了 9× 压缩比（从 9K tokens 压缩到 1K tokens）而准确率只下降 1.7%。这意味着可以用 1/9 的成本达到接近原始的准确率。

其他值得关注的压缩方法：

• LLMLingua-2（LongLLMLingua 升级版）：用更精确的分类器选择 tokens。
• RECOMP：抽取式压缩，保留与问题最相关的句子。
• Selective Context：保留与指令相关的上下文，丢弃无关内容。
• Prompt Compression with T5：用专门训练的小模型压缩 prompt。

压缩的工程实践有几个注意事项：

1. 先压缩再注入：不要把"压缩前"和"压缩后"都放进上下文，会浪费 token。
2. 保留元信息：压缩后保留"原始文档位置"等元信息，便于 LLM 引用。
3. 测试压缩比 vs 准确率：每个项目都应有自己的"压缩比-准确率曲线"，找到最佳平衡点。

复述框 · 5.4 节要点

• 4 种压缩策略：截断、摘要、抽取、语义压缩。
• LongLLMLingua：9× 压缩比，准确率仅降 1.7%。
• 3 个注意事项：先压缩再注入、保留元信息、测试压缩比 vs 准确率。

5.5 短期记忆的三种实现

短期记忆是 LLM Agent 的"动态上下文"——它在每次 LLM 调用时被注入，但在调用之间不持久。第 1 章 1.3 节提到过短期记忆的三种实现，这里深入展开。

列表 5.1 · 三种短期记忆实现的对比

1. 上下文窗口（Context Window）

• 存储方式：直接在 LLM 调用前把所有历史拼成 prompt。
• 容量：受模型窗口限制（4K–2M tokens）。
• 优点：实现最简单，零延迟。
• 缺点：超过窗口必须截断；每次调用都重新序列化。
• 适用场景：短任务（< 50 轮对话）。

2. 对话历史缓存（KV Cache）

• 存储方式：把历史 token 的 Key-Value 矩阵缓存到 GPU 内存。
• 容量：受 GPU 内存限制（约 10K–100K tokens 的 KV cache 占用 1–10 GB）。
• 优点：避免重复计算 prefix，推理速度提升 2-10 倍。
• 缺点：KV cache 不能跨模型迁移；上下文窗口超出时必须重新计算。
• 适用场景：长对话 + 高频调用。

3. 结构化反思条目（Structured Reflection）

• 存储方式：以 JSON 或 Markdown 形式存储反思条目，调用时按需检索。
• 容量：理论上无限（受存储介质限制）。
• 优点：可持久化、可跨会话、可语义检索。
• 缺点：检索增加延迟；格式不一致可能让 LLM 困惑。
• 适用场景：长期 Agent（跨会话、跨任务）。

图 5.3 · 短期记忆的混合策略

       LLM 调用
           │
           ▼
   ┌───────────────┐
   │ 检查 token    │  ← 预算：4K / 16K / 128K / 1M
   │ 预算         │
   └──────┬────────┘
          │
          ▼
   ┌──────────────┐
   │ 加载 KV cache│  ← 缓存历史对话的 prefix
   └──────┬───────┘
          │
          ▼
   ┌──────────────────┐
   │ 检索结构化反思   │  ← 从长期记忆中找相关反思
   └──────┬───────────┘
          │
          ▼
   ┌──────────────┐
   │ 合并到 context│
   └──────┬───────┘
          │
          ▼
   ┌──────────────┐
   │ 压缩超长部分 │  ← LongLLMLingua 等
   └──────┬───────┘
          │
          ▼
   LLM 推理

关键点：现代 LLM Agent 通常混合使用三种短期记忆——KV cache 处理重复 prefix、结构化反思处理长期知识、压缩处理超长上下文。单一方法不够。

短期记忆的替换与淘汰策略是工程上的关键决策：

1. FIFO（First-In-First-Out）：最旧的内容先被淘汰。简单但可能丢失关键早期信息。
2. LRU（Least Recently Used）：最久未被使用的内容先被淘汰。比 FIFO 更智能。
3. 重要性评分（Importance Scoring）：用 LLM 评估每条记忆的重要性，淘汰得分低的。智能但成本高。
4. 任务相关（Task Relevance）：根据当前任务检索最相关的记忆。无淘汰，但有"信息遗漏"风险。

复述框 · 5.5 节要点

• 3 种实现：上下文窗口、KV Cache、结构化反思。
• 混合策略：现代 Agent 用 KV cache + 结构化反思 + 压缩的组合。
• 4 种淘汰策略：FIFO、LRU、重要性评分、任务相关。

5.6 本章小结与第 6 章预告

本章展开 LLM Agent 的"短期记忆"。上下文窗口是 LLM 唯一能看见的内容，受容量限制。Token 预算是 LLM Agent 设计的关键资源，先算后用。Lost in the Middle 提示我们把重要信息放两端。LongLLMLingua 等压缩方法可以在不显著损失准确率的前提下大幅降低 token 消耗。短期记忆的 3 种实现 + 4 种淘汰策略是工程上的核心决策。

常见误区

• ❌ 把上下文窗口当无限资源：窗口满了必须截断或压缩。
• ❌ 忽视"Lost in the Middle"：长上下文中关键信息放中间会被弱化。
• ❌ 过度依赖 KV cache：KV cache 不能跨模型迁移，且占用大量 GPU 内存。
• ❌ 单一淘汰策略：FIFO 丢失关键早期信息，重要性评分成本高，应混合使用。
• ❌ 压缩后丢失元信息：丢失"原始文档位置"会让 LLM 无法引用。

第 6 章将进入长期记忆与检索增强。短期记忆受窗口限制，跨会话时无法持久——这些问题需要"长期记忆"来解决。MemGPT 的分页机制、A-MEM 的动态记忆网络、RAG 的检索增强生成，都是第 6 章要展开的核心内容。

本章小结

• 上下文窗口 = LLM 的工作记忆：5 个组成部分、固定/动态开销。
• Token 预算：先算后用，单次成本 × 调用次数 = 总成本。
• Lost in the Middle：重要信息放两端，避免中间布局。
• 4 种压缩策略：截断、摘要、抽取、语义压缩（LongLLMLingua 9× 压缩比）。
• 3 种短期记忆 + 4 种淘汰策略：混合使用是工程上的最佳实践。

推荐阅读

• 📖 Lost in the Middle [Liu et al., 2024]：长上下文中的"中间丢失"现象。$TRAE_REF
• 📖 LongLLMLingua [Jiang et al., 2024]：语义压缩的代表性方法，2024 ACL Outstanding Paper。$TRAE_REF
• 📖 MemGPT [Packer et al., 2023]：把 LLM 当 OS，在 main/外部上下文间换页。$TRAE_REF
• 📖 Self-Evolving Agents 综述 [Fang et al., 2025]：记忆与上下文在自进化 Agent 统一框架中的位置。$TRAE_REF
• 📖 A-MEM [Xu et al., 2025]：Zettelkasten 风格动态记忆网络。$TRAE_REF

练习题

1. 设计题：为"多轮客服 Agent"设计 token 预算：固定开销（系统提示 + 工具描述）多少？动态开销（对话历史 + 工具返回）多少？给出具体数字。
2. 分析题：选一个真实 LLM 应用，分析它的"信息位置"——系统提示在哪？用户输入在哪？工具返回在哪？这个布局是否合理？为什么？
3. 动手题：用 Python 实现一个简化版 LongLLMLingua（不超过 100 行）：用关键词频率给每个句子打分，保留得分最高的前 K 个句子，丢弃其余。
4. 设计题：对比 FIFO、LRU、重要性评分、任务相关四种淘汰策略在"长对话 Agent"场景中的优劣。给出你的推荐组合。
5. 批判题：Lost in the Middle 现象在不同 LLM 上的严重程度是否相同？GPT-4 与 Llama 3.1 70B 哪个更严重？为什么？
6. 工程实践题：为你的 LLM Agent 设计一个"上下文监控仪表盘"：实时显示总 token 数、各组件占比、压缩前后对比、压缩比 vs 准确率。

参考文献（本章内）

1. Liu, N. F., et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. TACL. $TRAE_REF
2. Jiang, H., et al. (2024). LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression. ACL. $TRAE_REF
3. Packer, C., et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560. $TRAE_REF
4. Xu, W., et al. (2025). A-MEM: Agentic Memory for LLM Agents. NeurIPS. $TRAE_REF
5. Wang, Y., et al. (2025). O-Mem: Omni Memory System for Personalized, Long Horizon, Self-Evolving Agents. arXiv:2511.13593. $TRAE_REF
6. Chhikara, P., et al. (2025). Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv:2504.19413. $TRAE_REF
7. Fang, J., et al. (2025). A Comprehensive Survey of Self-Evolving AI Agents. arXiv:2508.07407. $TRAE_REF
8. Baddeley, A. (2000). The Episodic Buffer: A New Component of Working Memory? Trends in Cognitive Sciences, 4(11), 417-423.

本章进度：5.1–5.6 节全部完成（约 5,500 字，含 3 张图 + 2 张表 + 1 张列表 + 8 篇引用 + 6 题 + 5 误区 + 5 推荐），达到 22 页计划。status: final。