长期记忆不是「把历史对话存起来」。在生产环境里，它更像一套数据管道和检索系统，目标很具体：
-
让 Agent 在跨天、跨周的任务里保持一致性（用户偏好、项目背景、关键决策不丢）。 -
让上下文成本可控（Token、TTFT、吞吐量别炸）。 -
让错误可被纠正、记忆可被编辑、可被遗忘（不然就是事故制造机）。
三个主要逻辑——记忆捕获、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 智能检索
别把「能搜到」当成「能用」，这是两回事。
很多记忆系统上线后表现很差，根因是：检索返回了一堆「看似相关」但没有操作价值的片段。工程上我会把检索拆成三段：
-
候选召回：向量相似度 / 关键词 / 结构化过滤（用户、项目、时间窗、标签）。 -
重排（rerank）：结合时间衰减、来源可信度、记忆类型优先级。 -
注入策略：怎么塞进 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 混合检索
先过滤，再相似度，再重排
非向量方案想要「像向量检索一样好用」，别上来就全文检索硬搜。最有效的顺序通常是：
-
结构化过滤（用户、项目、时间窗、标签、来源可信度） -
再做相似度/全文检索召回 -
最后重排（时间衰减 + 类型权重 + 去重）
这套顺序能把噪声压下去，查询也更可解释。
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 在长期任务中更一致、更便宜、更可靠。
以上。