核心观点：Agent 记忆管理的核心是突破三个瓶颈——模型上下文长度、HBM 显存大小、大海捞针问题。KV Cache 是推理优化，Context 才是工程化可控的记忆。
一、为什么 Agent 记忆管理如此重要？
硬件层面
在模型推理时，需要占用两类存储：
- KV Cache（键值缓存）：按 token 数量占用显存，随着对话增长急剧膨胀
- 上下文（Context）：输入文本本身，相对较小
关键区别：KV Cache 是模型推理时的计算优化，Context 是开发者可控的「工程化记忆」。
三个核心瓶颈
| 瓶颈 | 说明 | 影响 |
|---|---|---|
| 模型上下文长度 | 模型能处理的 token 上限 | 25K~200K 不等 |
| HBM 显存大小 | GPU 显存限制 | 显存不足导致 OOM |
| 大海捞针问题 | 长上下文中找关键信息的难度 | 信息在中间时最难找到 |
二、8 种记忆管理方法详解
方法 1：全量记忆（Full Context）
原理：不做任何处理，保留所有对话历史、工具调用、返回结果。
优点
- 实现最简单
- 信息完整无丢失
缺点
- 被动截断
- 可能报错或效果极差
适用场景：对话轮数少、上下文短的简单应用。
方法 2：滑动窗口（Sliding Window）
原理：模仿人类对话，只保留最近 N 轮对话，丢弃更早的内容。
优点
- 主动控制上下文长度
- 实现简单
缺点
- 断崖式遗忘
- 无法召回已丢弃信息
方法 3：相关性过滤（Relevance Filtering）
原理：选择性记忆，保留重要信息，丢弃无关细节。
工程化方案：
- 关键词打分：提到「帮我完成某个功能」打高分，闲聊打低分
- 语义相似度：计算每轮对话与整体对话的相关性
- 整句/整轮评分：给完整对话一个权重分数
方法 4：压缩（Compression）
原理：将长对话压缩成简洁摘要，保留关键信息。
工作流程：
- 当对话超过阈值长度
- 将最早的 N 轮对话提取出来
- 用大模型总结成摘要
- 用摘要替换原始对话
注意：细节会丢失，如修改按钮颜色的具体代码会被压缩成「修改了某个按钮」。
方法 5：向量数据库 / RAG
原理：将所有对话向量化存储，需要时进行语义检索。
工作流程：
- 收集完整对话（包括工具调用、返回结果）
- 送入向量化模型，存入向量数据库
- 用户提问时，用问题检索最相关的记忆片段
- 将检索结果注入当前上下文
方法 6：知识图谱 / GraphRAG
原理：用大模型提取对话中的「主体」和「关系」，构建知识图谱。
vs 普通 RAG：GraphRAG 能提取「学生和老师发生了什么事」，保留关系；普通 RAG 只能提取「学生怎么了」「老师怎么了」。
方法 7：分层记忆（长短期记忆）⭐ 推荐
原理：模仿人类记忆，区分短期和长期记忆。
| 记忆类型 | 存储位置 | 特点 |
|---|---|---|
| 短期记忆 | 内存/上下文 | 不压缩，每次对话都发送 |
| 长期记忆 | 硬盘/数据库 | 需要时检索 |
OpenClaw 使用的就是这种方式。
方法 8：类 OS 内存管理 / SWAP
原理：模仿操作系统虚拟内存，内存不足时将冷数据换出到硬盘。
- 热数据（近期使用）保留在内存
- 冷数据（长期未用）换出到硬盘/数据库
- 需要时从硬盘读回内存
建议：可与方法 7 结合使用，长期记忆存硬盘，短期记忆存内存。
三、方法对比总结
| 方法 | 复杂度 | 信息保留 | 实现难度 |
|---|---|---|---|
| 全量记忆 | ⭐ | ⭐⭐⭐ | ⭐ |
| 滑动窗口 | ⭐ | ⭐ | ⭐ |
| 相关性过滤 | ⭐⭐ | ⭐⭐ | ⭐⭐ |
| 压缩 | ⭐⭐ | ⭐⭐ | ⭐⭐ |
| 向量数据库 | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
| 知识图谱 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 分层记忆 ⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 类OS内存管理 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
四、核心要点总结
- KV Cache ≠ Context：前者是推理优化，后者是工程化可控的记忆
- 三个瓶颈决定上限：模型上下文长度、HBM 显存、大海捞针问题
- 没有银弹：不同场景选择不同方法，或组合使用
- 生产级推荐：方法 7（分层记忆）+ 方法 8（类OS管理）+ 方法 5（向量检索）
- Lost in the Middle：重要信息尽量放在上下文的开头或结尾
工程化落地建议：
- 初期：滑动窗口或压缩快速验证
- 中期：引入向量数据库实现语义检索
- 长期：构建分层记忆体系
- 大规模：考虑类OS内存管理