Day 008：Agent 记得越多越好吗？短期与长期记忆的底层逻辑

系列： 100 天系统学习 AI Agent 开发
当前阶段： Agent 基础与环境搭建
今日目标： 搞懂短期记忆与长期记忆的核心差异，建立记忆治理机制。

AI Agent 大模型 Agent开发 LangGraph

很多刚接触 Agent 开发的同学，在加上数据库之后都会有一种错觉：“我的 Agent 终于拥有长期记忆了，它可以记住一切！”

但实操下来往往会遇到这种尴尬场景：学习助手如果每次都问“你学到第几天了”，会显得很智障；可如果它把你随口抱怨的一句“我最近不想学 Python”永久保存，几个月后还在强行给你推 Java 教程，又会显得固执且不可理喻。

“记住一切”听起来很贴心，在工程实现上其实非常危险。

问题不在于有没有记忆，而在于：什么信息该记？保存多久？发生冲突听谁的？谁有权限修改？ 今天，我们就来拆解 Agent 的记忆系统。

💡 核心认知：别把聊天记录等同于记忆

很多新手有个误区，觉得放在内存里的叫短期记忆，写进 MySQL/向量数据库里的就叫长期记忆。其实根本不是一回事。真正的区别在于作用域和治理策略。

现在的我，在架构上至少会把记忆拆成这三层：

把一整段废话连篇的聊天记录无脑塞进向量数据库，不叫长期记忆，那叫制造上下文噪声和隐私负担。

🛠️ 实战拆解：一个学习 Agent 该怎么存信息？

我以咱们这个「学习助手」为例，盘点了一份记忆分类草案。大家在做自己的业务 Agent 时，可以直接套用这个逻辑来梳理需求：

这里隐藏了一个极其重要的工程细节：必须把“事实”和“推断”分开。
用户自己说的叫“事实”；系统根据几道错题推测出来的叫“推断”。推断出来的东西，必须保存证据和置信度，且优先级永远低于事实。

⚙️ 一条靠谱的记忆写入流水线

为了避免把垃圾数据和敏感数据写入记忆，在落盘前我们需要一条标准的流水线：

否

是

对话或任务事件

大模型提取候选记忆

是否必要且允许保存？
(敏感词/价值判断)

仅留在当前上下文

去重与冲突检查

用户确认或规则验证

带上来源、时间、TTL 落盘

检索时按作用域过滤

到期、修正或删除

如果你现在就想动手敲代码，别急着一上来就搞向量数据库（Vector DB）。先用一个普通的数据结构把约束字段定好。在 Python 里，你的记忆记录实体（Entity）至少应该是这样的：

1from dataclasses import dataclass
2from datetime import datetime
3from typing import Literal
4
5@dataclass
6class MemoryRecord:
7    user_id: str
8    namespace: Literal["profile", "learning", "preference"] # 隔离命名空间
9    key: str
10    value: str
11    source: str               # 来源：用户主动说 / 系统推测
12    created_at: datetime
13    confidence: float         # 置信度：推测的结果置信度要调低
14    expires_at: datetime | None = None  # TTL：很多记忆是会过期的
15    status: Literal["active", "superseded", "deleted"] = "active" # 软删除机制
16
17

在组装 Prompt 时，先按 namespace 隔离，再按相关性提取，最后检查 status 和 expires_at。

🤔 踩坑复盘：我目前还在纠结的边界

在设计这套系统时，我发现最棘手的问题是冲突解决机制。

偏好变了（比如以前喜欢 Python，现在喜欢 Go），我们可以直接用新记录覆盖老记录。但事实冲突却不能简单以“最新”为准。
比如：用户今天在聊天里吹牛说自己“Day 20 已经做完了”，但底层的进度系统查出来他只打卡到了 Day 8。这个时候 Agent 到底信谁？

我目前的暂定解法是：不同来源的信息要设定“可信等级”（系统 API 数据 > 用户随口说的数据）。遇到冲突时，Agent 不应该悄悄覆盖数据，而是把差异抛出来，向用户发起确认。

记忆系统的温度，不在于它像个舔狗一样每次都说“我记得你”，而在于它永远不会拿错误、过期或不该保存的信息，自作主张地替用户做决定。

📦 今日学习小结

老规矩，梳理成我们的 JSON 知识拼图，作为日后复盘的线索：

1{
2    "day": 8,
3    "topic": "记忆系统入门：短期记忆、长期记忆到底差在哪",
4    "why_it_matters": "毫无治理的全局记忆会变成上下文噪声和隐私负担。必须区分工作状态、短期上下文和长期记忆。",
5    "today_task": "定义了记忆实体的核心字段，明确了记忆写入流水线中的拦截、去重和过期规则。",
6    "pitfall": "将大模型推断的结论直接等同于用户事实。推断数据必须附带置信度且允许被事实覆盖。",
7    "next_question": "既然短期和长期记忆理清了，明天该看看主流框架（比如 LangGraph 的 Checkpointer）是怎么在工程上落地这套机制的？"
8}
9
10

✅ 读者自查清单：

• 你存记忆的时候，加上创建时间和 expires_at（过期时间）了吗？
• 你的系统能区分出“用户事实”和“模型推断”吗？
• 检索记忆时，你是全量丢给大模型，还是做过业务过滤了？

《Day 008：Agent 记得越多越好吗？短期与长期记忆的底层逻辑》 是转载文章，点击查看原文。