Agent的记忆系统

一、为什么需要记忆

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 "成长"的载体。

对比表

三、记忆的存储方式

记忆的存储方式覆盖进程内和进程外两类。进程内承载短期记忆，访问即时但易失；进程外承载长期记忆与跨请求状态，可持久化但需要检索。

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 限制或挤掉关键信息。

三种核心策略

实际系统通常组合使用：最近 K 轮保留原文（窗口）+ 旧对话摘要（压缩）+ 关键事实抽到外部记忆（重要性过滤）。