AI 智能体为什么总“记性不好”？一张图看懂 Memory 设计全景
适用读者：计算机、软件、人工智能相关专业的专科及以上毕业生，以及对大模型应用开发感兴趣的产品经理、创业者。
阅读收益：掌握 AI Agent “记忆”到底指什么、如何分类、怎么落地、常见坑在哪，以及目前主流开源框架的取舍。
文章长度：≈3.2 万字字符（中文约 6 500 字）
1. 开场白：为什么刚聊完就“失忆”？
“上周我不是把收货地址改到上海了吗？怎么又寄到北京去了？”——如果你用过接入大模型的客服或购物助手，大概率遇过这种尴尬。
根源很简单：
-
大模型本身 stateless（无状态） -
每次调用都是一次全新计算，不会自动记住 上一轮甚至上一句的内容
想让 Agent 像人类一样“有记忆”，需要开发者手动把“过去发生过的事”在合适的时机喂回模型。于是就有了 Agent Memory（智能体记忆） 这一整套设计范式。
2. 先对齐语义：Memory、Memories、Agentic Memory 傻傻分不清？
| 常见说法 | 到底指什么 | 举例 |
|---|---|---|
| Memory（记忆能力） | 一套“编码-存储-提取”机制 | 把用户喜欢的颜色存进数据库，并在后续对话里主动使用 |
| Memories（记忆片段） | 被存储下来的具体信息 | “用户喜欢蓝色”这句话被写成向量或文本，躺在库表里 |
| Agentic Memory | 由 Agent 主动调用工具 来管理记忆 | Agent 自己判断“这句话很重要，我要写进长期记忆” |
一句话：
Memory 是系统能力；Memories 是数据本身；Agentic Memory 强调“Agent 自己管记忆”。
3. 两大阵营：人类类比派 vs 工程实现派
目前行业里有两种给记忆分类的思路，不必纠结谁“更正宗”，理解各自场景即可。
3.1 人类类比派（CoALA 论文）
把人的记忆系统搬到 Agent 身上：
| 记忆类型 | 存储了什么 | 人类例子 | Agent 例子 |
|---|---|---|---|
| 工作记忆（Working） | 当前上下文 | 正在对话 | 本轮对话历史 |
| 语义记忆（Semantic） | 事实/概念 | 水在 0°C 结冰 | 用户狗名 Henry |
| 情景记忆（Episodic） | 事件/经历 | 十岁生日去六旗 | 上次计算 1+1 失败 |
| 程序记忆（Procedural） | 方法/技能 | 骑自行车 | 系统提示里写“先反问再回答” |
3.2 工程实现派（Letta 提出）
从“ token 流”视角出发，不强行拟人：
| 记忆模块 | 存放位置 | 说明 |
|---|---|---|
| Message Buffer | 上下文窗口 | 最近 N 条原始对话 |
| Core Memory | 上下文窗口内可编辑块 | 由 Agent 主动增删改，如“用户生日” |
| Recall Memory | 外部数据库 | 原始对话全量日志，可搜索 |
| Archival Memory | 外部数据库 | 经提炼、摘要后的高价值信息 |
两派对照速览：
-
CoALA 的“工作记忆” ≈ Letta 的 Message Buffer + Core Memory -
CoALA 的“长时记忆” ≈ Letta 的 Recall + Archival -
但 Letta 把“原始对话”与“摘要后知识”拆成两条表，方便检索策略差异化
4. 生命周期：一条信息如何在系统里“流动”？
-
用户输入 → 进入 Message Buffer（工作/短时记忆） -
Agent 判断“是否值得长期保存” -
是 → 调用工具写入外部库（Recall/Archival） -
否 → 仅留在 Buffer，后续可能被摘要或丢弃
-
-
下次对话先按策略从外部库检索 → 把相关片段重新注入上下文 → 继续交互
核心挑战：
-
什么时候写？（热路径 hot-path 还是后台 batch） -
写什么？（全文、摘要、还是结构化三元组） -
怎么删？（信息过时、地址变更、兴趣转移）
5. 短时记忆：上下文窗口的“精简化”技巧
5.1 直接截断
把最早的消息踢出去，最简单也最粗暴。
缺点：可能丢掉关键系统指令或用户偏好。
5.2 滚动摘要
每轮把历史对话用模型自己总结成 1-2 句，再丢弃原始消息。
优点：省 token；缺点：摘要错误会累积。
5.3 token 预算法
给“系统指令”“用户偏好”“多轮对话”分别设置 token 上限，超了就用摘要或向量检索替换。
适合对延迟 & 成本极敏感的场景。
6. 长时记忆：外部存储的四大操作
| 操作 | 目的 | 举例 |
|---|---|---|
| ADD | 新增信息 | 用户新养了一只猫，写入宠物档案 |
| UPDATE | 修正/合并 | 用户搬家，把地址字段覆盖新值 |
| DELETE | 删除失效 | 用户取消订阅，把过期营销偏好清除 |
| NOOP | 什么都不做 | 当前闲聊没有可提炼的新事实 |
工程提示：
-
用唯一 ID（user_id + 场景键）做幂等，防止重复写 -
给每条记忆加“时间戳+置信度”，方便后续“遗忘”策略
7. 热路径 vs 后台：什么时候写记忆？
7.1 热路径（Explicit Memory）
Agent 在对话当下就调用工具写库。
-
优点：实时性强，用户体验顺滑 -
难点：需要小模型或规则判断“哪些信息值得写”，容易误判
7.2 后台批处理（Implicit Memory）
对话结束或按固定间隔统一抽取。
-
优点：可用更重型的 NLP 模型做摘要/去重，准确率高 -
缺点：实时性弱，用户下次再来可能看不到最新偏好
混合打法
-
对“高价值信号”（地址、手机号、 allergy 等）走热路径 -
对“兴趣标签、情感极性”走后台批处理，兼顾成本与效果
8. 实现选型：到底把记忆放哪？
| 媒介 | 场景 | 备注 |
|---|---|---|
| 列表（Python list） | 当前会话历史 | 开发最快，重启即失 |
| 文本/Markdown | 系统指令、人物设定 | 例如 Claude 的 CLAUDE.md |
| 关系型 DB | 结构化事实 | 生日、地址、订单号 |
| 向量 DB | 相似度检索 | 用户兴趣、开放式描述 |
| 图数据库 | 多跳关系 | 社交关系、供应链 |
9. 开源框架速览：谁已经帮你铺好路？
| 框架 | 特色 | 地址 |
|---|---|---|
| mem0 | 专注“记忆层”，支持多用户、多会话 | mem0.ai |
| Letta（原 MemGPT） | 把 Core/Recall/Archival 做成一等公民 | letta.com |
| Cognee | 主打数据管道+自动摘要 | cognee.ai |
| Zep | 长时记忆+合规遗忘 | getzep.com |
| LangGraph | 用图编排记忆更新逻辑 | docs.langchain.com |
| Google ADK | 官方会话+记忆管理 | google.github.io/adk-docs |
选框架时三问
-
是否支持热路径工具调用？ -
有无内置“更新/删除”API，而非只能追加？ -
多用户隔离、权限、GDPR 删除能做到什么粒度？
10. 代码片段：最小可运行示例（Python 伪代码）
以下代码仅表达关键步骤，可直接迁移到 mem0 或 Letta 的 SDK
# 1. 初始化记忆层
from mem0 import Memory
m = Memory(user_id="alice", api_key="xxx")
# 2. 热路径写入
def hot_path_memory(user_msg, assistant_msg):
# 简单规则：出现“我的地址”即认为关键信息
if "我的地址" in user_msg:
m.add(user_msg, metadata={"type": "address"})
# 3. 会话中调用
user_input = "我的地址是上海市浦东新区"
assistant_reply = "好的，已记录您的地址。"
hot_path_memory(user_input, assistant_reply)
# 4. 下轮对话前先检索
memory_snippets = m.search("地址", top_k=3)
system_prompt = f"以下是用户相关记忆:\n{memory_snippets}\n请基于以上信息回答。"
11. 翻车案例：不管理记忆的后果
| 场景 | 结果 | 原因 |
|---|---|---|
| 电商客服 | 重复索要收货地址 | 没有 UPDATE 机制，用户改掉后仍读旧数据 |
| 医疗问诊 | 把 A 药品过敏记成 B 药品 | 未做置信度打分，直接写入 |
| 社交陪聊 | 越聊越慢，token 费用翻倍 | 只追加不摘要，上下文无限膨胀 |
12. 当前最难的两大坑：延迟 & 遗忘
12.1 延迟
-
每次交互都先做向量检索 → 写库 → 再生成，RT 增加 200~800 ms -
缓解：异步写库、缓存热点记忆、用本地轻量模型做路由
12.2 遗忘（自动化删除）
-
规则简单：按“时间 TTL”或“用户主动指令”删除 -
规则复杂：检测冲突、过时、负面偏好，需要小模型做“是否废弃”二分类 -
合规：GDPR、个人信息保护法要求“可删除”，必须记录数据源血缘
13. FAQ：你可能还会问这些
Q1. 把整条对话都存下来不就行了？
→ 存储成本好解决，但“检索精度”和“隐私合规”会崩。全量日志≠可高效利用的记忆。
Q2. 向量数据库一定需要吗？
→ 如果只做“键-值”类事实（生日、地址），传统 DB 足够。向量检索适合开放式描述、兴趣标签。
Q3. 记忆越多效果越好？
→ 恰恰相反，噪声会稀释关键信息。需要“质控”机制：摘要、置信度、去重、生命周期。
Q4. 同一用户换设备怎么办？
→ 用 user_id 打通，而不要用设备 ID。记忆层必须做“账号级”聚合。
Q5. 多语言场景要注意啥？
→ 写入时统一语言或存多语言副本；检索时同样做语言检测，否则会出现“英文问、中文答”错位。
14. 如何评估记忆系统的好坏？
| 指标 | 定义 | 目标值 |
|---|---|---|
| 命中率 | 用户问题可被记忆回答的比例 | >60%（垂类） |
| 准确率 | 记忆内容与实际一致 | >95% |
| 平均延迟 | 从提问到返回含记忆的答案 | <600 ms |
| 遗忘合规率 | 用户删除请求及时执行 | 100% |
| 成本占比 | 记忆模块花费 / 总调用成本 | <15% |
15. 小结：一张图带走核心框架
┌-----------------------------┐
│ 用户输入 │
└-------------┬---------------┘
▼
┌-----------------------------┐
│ 上下文窗口（工作记忆） │
│ - Message Buffer │
│ - Core Memory 可编辑块 │
└-----┬-------------┬---------┘
▼ ▼
摘要/删除 显式工具调用
│ │
▼ ▼
┌-----------------------------┐
│ 外部长期记忆 │
│ - Recall 原始对话 │
│ - Archival 摘要知识 │
│ - 结构化 DB / 向量 DB / 图 DB │
└-----------------------------┘
记忆系统的终极使命：
让 Agent 在“成本可控、合规可删、延迟可接受”的前提下，像人类一样记住该记的、忘记该忘的。
16. 下一步学习路线
-
把本文伪代码换成你偏好的框架（mem0/Letta）跑通 -
给系统加上“更新-删除”UI，让真实用户试玩一周 -
收集命中率、延迟、误记忆案例，迭代摘要 & 检索策略 -
读 CoALA 原文 + Letta Blog，体会“人类类比”与“工程 token”双轨思路 -
跟踪 GDPR/CCPA/中国 PIA 最新案例，确保“可遗忘”真正落地
没有记忆的 AI 只是“一次性工具”；
拥有记忆，却不懂遗忘，又会变成“垃圾场”。
掌握“流动-摘要-更新-删除”闭环，你的 Agent 才配得上“智能体”三个字。
祝你构建出记得住、忘得掉、反应快、还合规的 AI 伙伴！
