Agent Memory 不只是聊天记录：手搓三大记忆系统

最近把 Agent 往"能长期使用"的方向做时，我发现一个特别影响体验的问题：

Agent 会回答，不代表 Agent 记得。

比如昨天告诉它：

"我是 Java 后端，正在准备秋招，最近重点学习 Agent。"

今天重新开一个会话，再问：

"我接下来该学什么？"

如果 Agent 又从"什么是大模型、什么是 Python"开始讲，体验其实很差。

所以 Memory 真正解决的问题不是"保存聊天记录"，而是：

让 Agent 能记住重要信息，并在合适的时候把它重新拿出来影响当前决策。

1. 三种记忆，到底有什么区别？

我现在比较推荐用一个很简单的方式理解：

text 复制代码

短期记忆：刚刚聊了什么？
长期记忆：这个用户长期有什么重要信息？
语义记忆：系统以前知道过哪些相关知识？

短期记忆

保存当前会话上下文：

text 复制代码

用户：我想学习 Agent
Agent：你有 Java 基础吗？
用户：有，主要做后端

这种记忆最适合 Redis。

它解决的是：

当前任务不能断片。

长期记忆

例如：

text 复制代码

用户：我主要使用 Java
用户：我正在准备秋招
用户：我更喜欢 Markdown 输出

这些信息可能跨越很多会话，所以不能只放在当前上下文里。

它解决的是：

下次见面，不需要重新认识用户。

语义记忆

再比如企业知识库：

text 复制代码

报销制度
产品文档
项目开发规范
历史会议资料

这类内容通常不是某个用户的"个人经历"，而是可被检索的知识。

它解决的是：

模型不知道，但系统里有资料。

2. 真正难的不是"存"，而是"记什么"

很多初学者做 Memory，第一反应是：

python 复制代码

save(conversation)

然后把所有聊天全存下来。

这很快会出问题。

比如：

text 复制代码

"今天好累"

大概率没有长期保存价值。

但：

text 复制代码

"我正在准备 Java 后端秋招"

明显值得保留。

所以实际系统通常需要一个：

text 复制代码

Memory Extractor

流程变成：

text 复制代码

用户对话
   ↓
Agent 完成任务
   ↓
Memory Extractor
   ↓
判断哪些信息值得长期保存
   ↓
保存 / 更新 / 丢弃

这一步其实比数据库设计更重要。

3. 手搓一个最小版

先不用框架，直接自己实现。

短期记忆

python 复制代码

class ShortMemory:
def __init__(self, max_size=20):
    self.messages = []
    self.max_size = max_size
def add(self, role, content):
self.messages.append({
"role": role,
"content": content
})
self.messages = self.messages[-self.max_size:]
def get(self):
return self.messages</code></pre>
这个版本已经能解决"上下文太长"的第一步问题。
4. 长期记忆再加一层
可以先用 MySQL 保存：
id
user_id
content
memory_type
created_at
updated_at
importance
例如：
memory.save(
user_id=10001,
content="用户主要使用 Java",
memory_type="profile"
)
下一次用户提问前：
memories = memory.search(user_id=10001)
得到：
用户主要使用 Java
用户正在准备秋招
用户正在学习 Agent
然后再把真正相关的内容拼进上下文。
5. 语义记忆为什么要上向量数据库？
当长期记忆越来越多：
500 条
5000 条
5 万条
直接关键词查询会越来越不好用。
比如存的是：
"用户主要使用 Java 开发后端系统。"
现在用户问：
"我有后端开发基础，怎么开始学 Agent？"
两个句子的字面词不完全一样，但语义明显相关。
所以可以：
Memory
↓
Embedding
↓
Vector DB
↓
相似度检索
↓
找到相关记忆
这就是语义记忆最核心的思路。
向量数据库可以使用：
Milvus
Qdrant
pgvector
Elasticsearch
不管换哪一个，核心思路都是：把可检索的信息转换成向量，再根据当前问题召回相关内容。
6. 最终 Agent 怎么把 Memory 用起来？
真正的 Agent Loop 可以变成：
用户问题
↓
读取短期记忆
↓
检索相关长期记忆
↓
检索相关知识
↓
Context Builder
↓
LLM
↓
回答 / 调用 Tool
↓
Memory Extractor
↓
更新长期记忆
所以最终给模型的上下文，不应该只有：
user_input
而应该更像：
当前问题
+
当前会话
+
相关用户记忆
+
相关知识
+
Tool 返回结果
这也是 Agent 和普通聊天机器人的一个明显区别。
7. Memory 怎么判断有没有效果？
不要只统计"数据库里存了多少条"。
我更建议看这几个指标。
记忆命中率
真正有用的记忆召回次数
/
总召回次数
回答相关性
有 Memory 和没有 Memory 时，回答是否更符合用户背景。
重复询问率
Agent 重复询问用户背景的次数
/
总会话次数
一次任务完成率
加入 Memory 后，用户是否更少需要纠正 Agent。
例如：
无 Memory：72%
有 Memory：86%
这类数据才真正能说明 Memory 有价值。
8. 一个非常容易忽略的问题：记忆也会"过期"
假设用户以前说：
我主要写 Python
半年以后变成：
现在工作主要写 Java
如果只是一直 INSERT：
Python
Java
以后 Agent 可能自己都不知道该信哪个。
所以 Memory 系统真正成熟以后，必须考虑：
新增
更新
合并
删除
过期
冲突解决
这也是为什么我觉得 Memory 更像一个真正的后端子系统，而不是一个"聊天记录表"。
最后：把 Memory 当成 Agent 的"经验层"
现在可以把 Agent 重新拆一下：
LLM
↓
负责理解和推理
Memory
↓
提供历史经验
RAG
↓
提供外部知识
Tool
↓
负责执行动作
Agent
↓
把这些能力组合起来完成任务
所以我现在对 Agent Memory 的理解是：
不是让 AI 什么都记住，而是让 AI 在未来真正需要的时候，能找到过去重要的信息。
真正做项目时，可以先完成一个最小闭环：
短期 Memory
→ 长期 Memory
→ 语义检索
→ Context 注入
→ 记忆提取
→ 记忆更新
跑通以后，再考虑压缩、重排序、记忆衰减、权限、评测等高级能力。这样学习会比一上来啃复杂框架容易很多。