AI Agent 的长期记忆：我在工程落地里踩过的坑、做过的取舍

长期记忆不是「把历史对话存起来」。在生产环境里，它更像一套数据管道和检索系统，目标很具体：

  1. 让 Agent 在跨天、跨周的任务里保持一致性（用户偏好、项目背景、关键决策不丢）。
  2. 让上下文成本可控（Token、TTFT、吞吐量别炸）。
  3. 让错误可被纠正、记忆可被编辑、可被遗忘（不然就是事故制造机）。

三个主要逻辑——记忆捕获、AI 压缩、智能检索。

说人话就是：数据结构怎么定、写入怎么做、分层怎么做、检索怎么做、什么时候该忘。

1. 先把「长期记忆」拆成三类

在很多团队里，长期记忆失败不是模型问题，是定义问题：同一个「memory」里混了用户画像、任务状态、项目知识、工具日志，最后检索噪声大到不可用。

我更愿意按「用途」拆，而不是按「存储介质」拆：

1.1 用户长期记忆

用户长期记忆每次都要注入的「稳定事实」。

长期记忆的定义：长期、可编辑的核心记忆，记录稳定属性（姓名、目标、经历、偏好等），并且「每次对话都会强制注入」。

这里我会很强硬地加两条工程规则：

  • 必须可审计：能回答「这条记忆从哪轮对话来的」「谁写入的」「什么时候写入的」。
  • 必须可逆：用户一句「从记忆中删除」要能删干净；内部也要支持 GDPR/合规那种 purge。

更新方式有两种，但优先级不同：

  • 显式更新：用户说「记住这个」「删掉这个」这种，优先级最高，直接写。
  • 隐式更新：模型检测到符合标准的事实（如 OpenAI 的标准），默认同意自动添加。
    对于隐式更新，我的态度偏保守：宁可少记，不要乱记。乱记比不记更致命，后面纠错成本很高。

1.2 任务记忆

任务记忆是会过期的「状态」

它属于长期记忆系统，但不属于「永久」。例如：

  • 一个多天的排障进度（已验证什么、下一步计划）
  • 某个 PR 的讨论结论（直到 merge 前都重要，merge 后可降温）

这类记忆如果不做 TTL，很快就把检索污染掉。任务记忆一定要有生命周期。

1.3 事件/操作记忆

这也可以叫做过程记忆，这是为检索服务的「轨迹」。

这类通常来自工具调用、文件读写、运行日志。它的价值是：当用户问「你刚才改了哪几个文件」「上周我们为什么选了 A」时，Agent 能把证据拿出来。

它的问题也最大：写入频率极高、噪声极多。这类我默认做分层：热层保最近、冷层做压缩归档，别全塞进同一个向量索引里。

2. 记忆系统的三段式管道

捕获 → 压缩 → 检索（注入）

2.1 记忆捕获

简单来说就是谁来写、写什么、写到哪。

捕获层我建议按「事件源」拆：

  • 对话事件：用户输入、模型输出（或关键片段）、会话元信息（时间、会话 ID、主题）。
  • 工具事件：工具名、参数、返回、影响面（写了哪些文件、改了哪些配置、跑了哪些命令）。
  • 用户显式指令：强制写/删/改的指令，这条要走单独通道，避免被摘要吞掉。

以 Claude-Mem「五大生命周期钩子」为例，是一个比较实用的策略，原因是它把捕获点固化在生命周期上，不靠「模型想起来了」这种玄学。

钩子名称 触发时机 核心作用
context-hook 会话启动时 注入最近记忆作为上下文
new-hook 用户提问时 创建新会话并保存提示词
save-hook 工具执行后 捕获文件读写等操作记录
summary-hook 会话结束时 生成 AI 摘要并持久化存储
cleanup-hook 停止指令时 清理临时数据

我自己的经验：save-hook 和 summary-hook 之间一定要有边界。
save-hook 捕获「事实与证据」（做过什么、改过什么）。summary-hook 产出「压缩后的可读结论」（为什么这么做、后续计划）。混在一起，后面做检索融合会很痛。

2.2 AI 压缩

简单来说就是压什么、怎么压、压到什么粒度

压缩不是「把 10 轮对话变 200 字」这么简单。压缩的核心目标只有两个：

  • 降低注入成本：上下文窗口里留给推理的空间要足够。
  • 提高检索可控性：检索返回的 chunk 必须信息密度高、噪声低。

比较典型的做法：每隔 10 轮触发 summary agent，把前 10 轮压成 200 字摘要并替换历史。这里可能会有一个坑：摘要如果不带结构，后面无法做检索约束。

我更偏好把摘要拆成固定字段（即使最终还是自然语言）：

  • 「目标/约束」
  • 「关键决策 + 理由」
  • 「未决问题」
  • 「下一步」
  • 「证据索引」（指向原始事件/日志的 ID）

这样检索返回摘要时，Agent 能快速判断「这段能不能用」，也能在需要时回溯证据。

2.3 智能检索

别把「能搜到」当成「能用」，这是两回事。

很多记忆系统上线后表现很差，根因是：检索返回了一堆「看似相关」但没有操作价值的片段。工程上我会把检索拆成三段：

  1. 候选召回：向量相似度 / 关键词 / 结构化过滤（用户、项目、时间窗、标签）。
  2. 重排（rerank）：结合时间衰减、来源可信度、记忆类型优先级。
  3. 注入策略：怎么塞进 prompt，塞多少，塞哪一层。

「渐进式披露策略」是当前比较流行的注入策略，这比「Top-k 全塞」靠谱太多了：

Level 1: 最近 3 条会话摘要（约 500 tokens）
Level 2: 相关观察记录（用户主动查询）
Level 3: 完整历史检索（mem-search 技能）

Level 1 覆盖 80% 的连续对话场景；Level 2 把「更多细节」交给用户意图；Level 3 才动用重检索，避免每轮都把成本打满。

3. 存储介质怎么选

文件、知识库、数据库都是可以选的。

3.1 文件

最强的可控性，最差的并发与检索体验

文件的优势是「简单到不会出错」：

  • 人可以直接打开改
  • Git 可以审计、回滚
  • 灾备简单

缺点也有：

  • 并发写很麻烦（锁、冲突、合并）
  • 检索靠你自己做索引，否则就是 grep
  • 很难做多租户隔离、权限控制（你当然可以做，但成本会涨）

如 OpenClaw 的设计：每日日志 + MEMORY.md 精选长期存储。它这个方案我很喜欢，原因是它把「噪声」和「精选事实」隔离开了。

一个「看起来保守，但极其工程」的方案：

  • 第一层：每日日志，按日期整理，记录会话发生的事情、决策结果、未来可能相关的信息。
  • 第二层：**MEMORY.md 本身**，作为精选长期存储库，保存应永久保留的信息；也记录对代理错误的修正。

如果捕捉对话每个细节，代理每次加载上下文会消耗更多 Token，杂音会降低响应质量。

MEMORY.md 这种「精选」必须有准入机制。靠人手维护能跑，但团队一大就维护不过来。可以整一个「重要性评分系统」，先打分，再决定进不进精选层。

3.2 知识库

适合「稳定知识」，不适合「高频写入」

知识库适合 SOP、产品手册、FAQ、架构决策记录这种相对稳定的内容。它的问题是写入链路通常偏离线：采集、清洗、切分、建索引。你要它承接「每次工具调用写一条」这种场景，很快会把 ingestion 管道压垮。

KB 承接 semantic memory（语义知识），别拿它硬扛 episodic/event memory。

3.3 数据库

能抗并发、能做权限、能做检索，但我们要付出工程代价

数据库我会再分两类：

  • 结构化数据库（关系型/文档型）：适合 user memory（key-value、可编辑、可审计）、任务状态、权限控制。
  • 向量数据库：适合 episodic memory 的语义检索，但会带来你参考内容里提到的三个工程问题。

user memory 这种「必须可控」的内容，优先放结构化 DB；event/episode 的检索层再用向量 DB 或混合检索。把所有东西都向量化，后面治理成本会很高。

4. 向量数据库的使用逻辑

向量数据库把记忆从只读变可写后，需要考虑三个具体的工程问题。

4.1 问题一：需要记住什么？

这里最容易走偏。很多团队一开始恨不得「全量记录」，结果两周后发现：

  • 索引膨胀
  • 检索噪声上升
  • 成本上涨
  • 用户抱怨「你记错了」的次数增加

我的判断维度是：时间、频率、类型，这三者会冲突。我会在应用层做一个更硬的分层打分：

  • 硬规则拦截：明显不该记的直接丢
    例如临时文件、一次性下载缓存、明显含敏感信息的内容（看合规策略）。
  • 重要性打分：符合候选条件的打分
    分数来自：任务相关性、用户显式标记、重复出现次数、工具影响面（改了配置文件通常比分割日志重要）。
  • 落层策略：分数决定写入热/冷、决定是否进入精选层（例如 MEMORY.md）。

Milvus 的 TTL 和时间衰减，可以用用，不是核心策略。原因很简单：TTL 只能删时间，删不了噪声。噪声是「内容不该进来」，不是「该不该过期」。

4.2 问题二：怎么分层存储？

按时间切、按访问频率、按用户标注来降冷。「分层」可以，但是：分层的单位别用「向量库的 collection」随便拍脑袋，要用有我们自己的「记忆类型」。

我通常会至少拆三层：

  • 热层：最近 N 天的事件 + 最近几条摘要
    目标是低延迟、写入快、检索稳定。热层可以索引轻一些，宁可召回多一点，再靠重排过滤。
  • 温层：近期项目周期内的关键摘要、关键决策、纠错记录
    读多写少，索引可以更重，提升精度。
  • 冷层：长历史归档
    主要用于追溯，默认不参与每轮检索，只在用户明确追问或系统置信度不足时启用。

这个结构配合「渐进式披露」很顺：默认只碰热层，必要时升级到温层/冷层。成本曲线能压得住。

4.3 问题三：写入频率与速度怎么定？

关键矛盾：agent memory 要实时写入，但向量索引构建需要时间；每条写都重建索引太贵，批量建索引又导致新数据搜不到。

在工程上解这个矛盾的思路：

  • 把「可立即检索」和「可长期高精检索」拆开
    新写入先进入一个轻量的「增量区」（delta store），可以是：

    • 内存缓存 + 简单向量结构（甚至先不建复杂索引）
    • 或者一个专门的「实时 collection」，索引参数偏向写入吞吐
  • 后台异步合并（Compaction）
    到一定量再合并进主索引（main store），这时构建更重的索引结构。
  • 检索时双查
    先查 delta，再查 main，最后融合去重。这样用户刚执行的操作，下一轮一定能搜到，不靠运气。

如果只用一个 collection 硬扛实时写入 + 高精检索，基本会卡在「要么写不动，要么搜不准」之间来回摆。

5. 非向量数据库怎么做长期记忆

我倾向于「结构化事实 + 混合检索」

user memory 和一部分 task memory，用结构化存储更稳，理由：

  • 可编辑（update/delete）是常态操作
  • 需要强一致（至少单用户维度）
  • 需要权限、审计、脱敏、导出、合规删除

向量化适合「相似性召回」，不适合「事实的最终真相」。

这样拆：

5.1 User Memory

KV + 版本 + 来源，每条 user memory 至少需要：

  • key（例如 coding_lang）
  • value（例如 Python）
  • source（显式指令 / 隐式提取 / 管理后台）
  • updated_at
  • version（解决「多次修改」与「回滚」）
  • confidence / policy tag（是否允许自动注入、是否敏感）

然后注入策略是：每轮只注入白名单 key。别把整个用户画像 dump 进 prompt。

5.2 Event/Log

文档型存证 + 可选向量索引

工具调用日志、文件变更记录，我更愿意先当「证据」存好（文档型或日志系统），向量索引只是加速检索的手段。这样即使向量库挂了，还有可追溯的事实来源。

5.3 混合检索

先过滤，再相似度，再重排

非向量方案想要「像向量检索一样好用」，别上来就全文检索硬搜。最有效的顺序通常是：

  1. 结构化过滤（用户、项目、时间窗、标签、来源可信度）
  2. 再做相似度/全文检索召回
  3. 最后重排（时间衰减 + 类型权重 + 去重）

这套顺序能把噪声压下去，查询也更可解释。

6. 长期记忆的「可用性」核心

注入策略比检索算法更重要

很多人把精力都花在「embedding 模型选哪个」「Top-k 设多少」，上线后发现效果波动很大。

实际可能是：注入策略决定了下限。

「渐进式披露」已经是很好的骨架。我补两条我认为必须做的工程约束：

6.1 注入预算必须固定

每轮对话给记忆注入多少 token，要有硬预算。例如：

  • 用户长期记忆：固定 100～300 tokens（只放稳定事实）
  • 最近摘要：固定 300～800 tokens
  • 检索片段：固定 500～1500 tokens（按任务重要性动态）

预算不固定，线上成本就不可控；更糟的是上下文挤压推理空间，模型会「看起来记住了」，实际输出质量下降。

6.2 记忆冲突处理

宁可不注入，也别注入矛盾

最常见的事故是：用户改了偏好（比如语言、格式、技术栈），旧记忆还在注入，Agent 开始精神分裂。

工程上必须有冲突策略：

  • 同一 key 的多版本：只注入最新版
  • 多来源冲突：显式指令 > 管理后台 > 隐式提取
  • 低置信度记忆：默认不注入，只在用户问到时提供候选并求确认

7. 小结

AI Agent 的长期记忆不是「把历史对话都存起来」，而是一套以可控、可维护、可纠错为目标的数据管道与检索系统——先明确记忆类型（用户稳定事实、任务状态、事件证据）并分层治理，再用“捕获 → AI 压缩 → 智能检索/注入”三段式把信息从高频噪声提炼成可用上下文；存储上用结构化数据库承载可编辑的用户/任务事实，用日志/文档留存证据，并按需用向量索引做语义召回与冷热分层，避免写入与索引、噪声与成本之间的失控；

效果上不要迷信 Top‑k，把注入预算、渐进式披露、冲突处理当作系统下限；

运维上把缓存、摘要、显式记忆工具、TTL/衰减与合规删除做成一等能力，并用成本、质量与安全指标持续观测迭代。

最终目标不是「记得更多」，而是让 Agent 在长期任务中更一致、更便宜、更可靠。

以上。