一、为什么需要记忆
Transformer 本身是 无状态（Stateless） 的，每次推理只是 Prompt → LLM → Output，不会自动保存历史。没有记忆的 Agent 本质上只是"增强版 Prompt"。记忆系统让 Agent 具备 持续学习、长期规划、个性化 能力。
核心定位：Agent Memory 是 RAG 的进一步演化------RAG 检索外部知识，Memory 检索"自己的历史经验、用户信息和过去行为"。
二、记忆分层
按生命周期由短到长，分为三层：
1. 感知记忆（Sensory Memory）
当前这一次推理的 原始输入------用户发来的消息、工具刚返回的结果、检索召回的片段。它只在 prompt 组装的瞬间存在，LLM 一旦消费完就被丢弃，不做任何加工或保留。可以理解为"刚进眼睛还没进大脑"的信息。
2. 短期记忆（Short-term Memory）
对应 LLM 的 context window，承载当前任务的上下文：本轮对话历史、最近几步的工具调用结果、临时规划。它直接拼进 prompt 就能用，无需检索，但受 token 限制（如 128K），且会话结束就消失。它是 Agent "工作中"的思考空间。
3. 长期记忆（Long-term Memory）
跨会话持久化 的知识库，存放用户画像、历史经验、领域事实等。容量近似无限，但不能整体塞进 prompt，必须通过 语义检索 / 精确查询 召回相关片段后注入到短期记忆中使用。它是 Agent "成长"的载体。
对比表
| 类型 | 载体 | 容量 | 生命周期 | 访问方式 |
|---|---|---|---|---|
| 感知记忆 | 当前输入 | 极小 | 单次调用 | 即时访问 |
| 短期记忆 | 当前任务上下文 Context、最近对话 | 受 token 限制（通常 128K tokens） | 一次任务 | 直接读取 |
| 长期记忆 | 向量 / 关系数据库 | 无限 | 持久 | 语义检索 |
三、记忆的存储方式
记忆的存储方式覆盖 进程内 和 进程外 两类。进程内承载短期记忆，访问即时但易失；进程外承载长期记忆与跨请求状态，可持久化但需要检索。
3.1 进程内存储
① Prompt 上下文：每次推理时由调用方组装的输入，包括 System Prompt、用户消息、工具结果。它是 LLM 看到的全部信息源，随调用即拼即弃，不存在"修改"概念，只能在下一次调用时重新拼装。
② Context Window：LLM 一次推理能处理的 token 上限内的内容（通常 128K）。多轮对话的历史就堆在这里，直接读取无需检索，但容量有限------超过就要靠截断、摘要或外部存储承接。
3.2 进程外存储
① KV 存储（Redis）：键值对、极快读写、可设 TTL。介于短期与长期之间，典型用途是跨 HTTP 请求的会话历史、Agent 执行到第几步、限流去重。注意它不是"长期记忆"------TTL 一到就消失。
② 关系数据库（PostgreSQL / MySQL）：行列结构、支持事务与精确查询。适合存用户档案、订单、配置等强结构化、需要 JOIN 的数据。属于实体记忆的主力载体。
③ 向量数据库（FAISS / Milvus ）：把文本编码成向量后做相似度检索。适合存对话摘要、用户偏好、历史经验等模糊匹配的内容，是长期记忆中"语义召回"的核心。缺点是易出现召回错误和记忆污染。
④ 图数据库（Neo4j / Memgraph）：节点 + 边表示实体与关系，支持多跳推理。适合复杂关系网络，比如"用户 → 使用 → 框架 → 依赖 → 库"，是 2025+ 趋势中替代向量库做实体记忆的方向。
3.3 选型建议
- 需要精确查找的，使用 KV/SQL : 如用户档案、订单信息、配置项等
- 需要语义模糊匹配再上向量库 ：如对话历史、用户偏好、经验总结，等
- 关系复杂、需要推理时用图库：如社交关系、知识图谱等
四、记忆压缩策略 ⭐
问题：上下文（短期记忆）容量有限，一旦快满，必须压缩或淘汰旧内容，否则会超 token 限制或挤掉关键信息。
三种核心策略
| 策略 | 做法 | 适用场景 | 代价 |
|---|---|---|---|
| ① 滑动窗口 | 丢弃最旧的消息，保留最近 N 条 | 闲聊、短时任务 | 直接丢失早期信息 |
| ② 摘要压缩 | 用 LLM 把旧对话总结成一段话，大幅缩减 token | 长对话、需要保留脉络 | 摘要漂移、细节丢失 |
| ③ 重要性过滤 | 只保留关键信息（用户指令、重要结论），丢弃过程细节 | Agent 任务执行 | 需要打分机制 |
实际系统通常 组合使用：最近 K 轮保留原文（窗口）+ 旧对话摘要（压缩）+ 关键事实抽到外部记忆（重要性过滤）。