记忆生命周期：写入 · 存储 · 检索 · 遗忘 · 上下文治理

第一章把记忆定义成 agent 自己掌控的「写入 → 治理 → 读取」闭环。这一章把闭环拆成可单独施工的五个环节,每个环节都按同一套问法解剖:它通过什么机制实现目标,因此代价是什么,以及在什么条件下失效。这比照抄文档的 API 列表深一层——文档告诉读者"调 add() 写入记忆",这一章要回答"add() 内部跑了一次 LLM 抽取 + 一次 embedding,因此每写一条都付模型钱,而抽取漏掉承重事实时整条记忆链就断了"。

2.1写入:抽取 → 巩固 → 去重 → 冲突消解

写入不是把对话原样落库,而是把交流压成原子事实、并在落库瞬间和已有记忆完成对账。

底层机制(比文档深一层)

写入由一次 LLM 抽取驱动。系统不存原始消息,而是把「最新一轮交流 + 滚动摘要 + 近期若干条消息」一起喂给模型,让它吐出去情境化的原子事实(例:把"对,我上周把库从 Postgres 迁到 MySQL 了,折腾死了"抽成 用户的主数据库 = MySQL)。这一步抽取本身就是重要性过滤——填充 token 在这里被丢掉,不需要额外打分模型。

抽出候选事实后进入更新阶段:检索 top-s 条语义最近的已存记忆作为上下文,再让 LLM 用 function-calling 在四个动作里选一个——ADD(新事实)、UPDATE(已有事实的新值)、DELETE(被否定的旧事实)、NOOP(已知,不动)。这是 Mem0 在 2025-04 论文(arXiv 2504.19413)里的机制。注意算法在演化:Mem0 在 2026-04 的新算法转向单遍、ADD 优先的写入,减少每条候选的多次模型往返——但概念不变,写入永远要在「新事实 vs 已存」之间做决断。

冲突消解发生在写入时

这是整章第一个反直觉点。当新事实和已存事实矛盾("数据库 = MySQL" vs 旧的 "数据库 = Postgres"),消解在写入瞬间完成,而不是留到检索时再排序裁决。这是一条 write-once, read-many 的设计:矛盾在入口就被吸收,存储里任何时刻都只留一份当前为真的版本,于是每一次后续读取都不必重新裁决,也不会把两条互斥事实一起捞进 context。三种消解策略:

• recency-wins(默认):新事实覆盖旧的。适合状态变更类("Postgres → MySQL""搬到上海了"),实现最省——只看时间戳。
• source-wins:按来源可信度裁决(用户亲口说 > 网页抓取),需要每条记忆带 provenance 元数据。
• confidence-wins:按抽取置信度裁决,需要校准过的置信分,否则一个过度自信的错误抽取会顶掉一条正确旧事实。

代价

每写入一条都要付:一次 LLM 抽取调用 + 一次 embedding(给候选事实算向量,用于更新阶段的相似检索)。实体必须在这里归一到 canonical ID——"老王""王总""Wang"得指向同一实体——否则归一债务被推迟到读取时,每次查"老王"都要跨多种表面形式扇出召回。写入是把成本集中付一次的地方。

失败模式

两类静默失败:① 抽取漏掉承重事实——模型判一条关键信息为填充而丢弃,这条记忆从此不存在,且没有任何报错;② 错误合并实体——把"张伟(同事)"和"张伟(客户)"归一成一个 ID,之后两人的事实互相污染。两者都不会抛异常,只会在几周后表现为"agent 记错了"。

2.2存储:向量 / 图 / 混合

存储后端决定记忆能回答哪类问题——向量擅长"像什么",图擅长"和谁有关、当时是什么"。

底层机制(比文档深一层)

向量存储:事实存成 embedding,检索靠近似最近邻 + 时间戳衰减。便宜、可水平扩展、语义召回强。但它不编码关系——"A 是 B 的经理""X 导致 Y"这类边在纯向量里只能靠语义相似侧面碰运气,多跳查询("我经理的经理偏好什么")会失败,因为没有可遍历的边。

图存储(Zep / Graphiti,Neo4j 底):事实存成实体节点 + 带类型的边,关键是边带 bitemporal 双时间四个时间戳——valid_at / invalid_at(事实在现实世界里何时开始/失效)与 created_at / expired_at(这条记录在系统里何时写入/被取代)。这套双时间让"当前状态"可被精确查询且不产生陈旧幻觉:当"数据库 = MySQL"写入时,旧边"数据库 = Postgres"的 invalid_at 被打上时间戳而非物理删除。于是既能问"现在用什么库"(只取 invalid_at 为空的边),也能问"去年此时用什么库"(按时间点过滤)——两个答案都对。代价:每条 episode 摄入时要跑一次 LLM 实体+边抽取,延迟和成本都高于纯向量,还多一层图操作运维。

多数生产系统是 hybrid:向量库扛廉价的语义/新近召回,图层只承载真正需要关系或时序正确性的那部分事实。

失败模式

图存储的隐患是抽取错误静默累积:LLM 把"A 提到了 B"误抽成"A 汇报给 B"的边,这条错边不会报错,却会在日后每一次经过它的图遍历里传播错误结论。向量存储没有这个具体问题,但它的失败更直接——任何需要关系的问题都只能给出语义相近却逻辑错误的答案。

2.3检索:打分、精排,与 lost-in-the-middle

检索不是"召回越多越保险",而是一道精排问题——多塞一条无关记忆就是主动给模型递误导。

底层机制(比文档深一层)

经典打分把三个信号相乘再排序——这是 Park 等人《Generative Agents》(2023)给出的形式:

score = w1 * semantic_similarity(query, mem)   # 语义相似度: 和当前 query 多像
      + w2 * recency_decay(now - mem.last_access) # 新近度: 越近权重越高 (指数衰减)
      + w3 * importance(mem)                       # 重要性: LLM 给的 1-10 评分
# 取 top-k 后再过一遍 rerank 交叉编码器, 精排出真正进 context 的几条

三个信号各自堵一类漏:只用 recency 会把旧的关键事实("用户对花生过敏")挤出去;只用 similarity 会捞出话题相近的 distractor。importance 这一项要么靠 LLM 给每条记忆打 1–10 分(细腻但每写一条多一次模型调用),要么退化成写入时的二元重要性门(省钱但粗)。打分取 top-k 后,rerank(交叉编码器对 query-记忆对重新精排)再砍一刀,这一步比"召回更多候选"更能提质量。

lost-in-the-middle:位置本身就是一个信号

就算检索到了对的记忆,放在 context 的哪个位置也影响模型能否用上它。Liu 等人的 lost-in-the-middle 实验揭示注意力呈 U 形:开头和结尾的信息被可靠使用,放在中段的关键信息准确率掉 30% 以上。更尖锐的是 Chroma《Context Rot》(2025)的发现:单独一条 distractor 就能实测压低准确率,且随 context 变长复合放大——"检索太多"是主动误导,不是无害稀释。

代价与失败模式

三因子打分 + rerank 的代价是每次检索多一轮计算(尤其 LLM 重要性评分和交叉编码器 rerank)。失败模式是权重失衡:recency 权重过高 → 旧的承重事实被埋;similarity 权重过高 → distractor 涌入。而最隐蔽的失败是上面那条——团队以为"召回率高 = 检索好",于是放大 top-k,结果亲手把准确率拉低。

2.4遗忘:有界记忆才有用

遗忘不是存储满了才做的清理,而是让"被记住"重新变得有信号的主动机制——什么都记等于没有有用的可记。

底层机制(比文档深一层)

遗忘不是单一开关,而是五种可叠加的驱逐/降权机制:

• 按语义类别设 TTL:不同类记忆配不同存活时长。姓名、过敏史这类身份事实 TTL = ∞;"当前任务进度"这类 TTL 是小时级。关键是 TTL 由语义类别决定,不是一刀切的时间。
• 检索分数加权衰减:按 §2.3 的检索分做 LRU / 新近加权,长期低分的记忆逐渐降权直至驱逐。
• 访问频率强化:被反复检索命中的记忆调高保留权重——用得多的留得久。
• 衰减曲线:平时按指数衰减(Ebbinghaus 遗忘曲线的工程化);一旦遇到矛盾事实,对旧事实做阶跃衰减(骤降而非缓降),让被推翻的旧值快速退场。
• 摘要即遗忘:把一批细节记忆压成一条摘要,本身就是一种有损遗忘——细节没了,主旨留下。

代价

遗忘机制本身要消耗:维护衰减分、跑周期性驱逐扫描、给每条记忆记访问计数。更微妙的代价是调参难——TTL 和衰减率设激进了误删,设保守了又回到无界。这没有普适最优值,得按记忆类别和业务容错分别定。

失败模式

典型失败:衰减驱逐了一条很少被引用、但关键的事实。比如"客户要求所有发票抬头用全称"这条规则半年才用一次,在 LRU 加权下分数一直很低,某次扫描里被驱逐——下次开发票时 agent 不再记得,直接违约。这类失败的诱因恰恰是"低访问频率"被当成"低价值"的代理指标,而二者并不等价。

2.5上下文治理:给 context window 做 GC

上下文治理是对 working memory(也就是 context window 本身)的在线垃圾回收——在塞满之前主动腾地方,而不是等溢出。

底层机制(比文档深一层)

两种主流手段:

• compaction(压缩):模型摘要自己的历史并就地替换它。把前 N 轮对话/工具结果压成一段摘要,用摘要顶掉原文,腾出 token。这是 Anthropic《Managing context》(2025-09)里的 compaction 机制。
• memory-tool(记忆工具):agent 把笔记写到 context 之外的文件里(例:Anthropic 的 memory tool 对 /memories 目录做 create/read/update/delete),需要时再读回。等于给 working memory 加了一块可分页的"外存"——这正是第三章 §s31 要展开的分层虚拟上下文的雏形。

为什么必须提前 compact:LLM 推理的 prefill 阶段要把整个 context 过一遍,这一步的延迟随 context token 数增长。若等到 context 接近上限才压缩,前面好几轮已经在为臃肿的 context 付高延迟。工程实践是设一个阈值(如 80%)就触发,而非等到 100%。

失败模式:没有写屏障的 GC

对 compaction 最尖锐的批评是把它类比成"没有写屏障的垃圾回收"。常规 GC 有写屏障保证不会回收仍被引用的对象;compaction 没有这层保护——它靠 LLM 判断"哪些历史可以摘要掉",而模型会静默丢掉承重细节(把一个后面还要用到的关键参数压没了),或制造悬空引用(摘要里提到"如前所述的方案 B",但方案 B 的定义已被压缩掉,下游再引用时无从解析)。这类损坏不报错,只在几轮后表现为 agent"忘了自己刚说过的关键约束"。

2.6把五环节连起来看

五个环节不是孤立的工序,而是同一条设计哲学在不同位置的反复出现:把成本前置、把矛盾在入口吸收、把"被保留"维持成一个有信号的稀缺状态。写入时消解矛盾(而非检索时),遗忘和治理时主动收缩(而非等溢出)——这两个时机选择共同决定了系统是随时间攒矛盾、攒噪声,还是攒出一份干净、有界、当前为真的记忆。下面这张代价对照把贯穿全章的几条权衡放在一起: