意项
39.91M · 2026-03-23
长期记忆不是「把历史对话存起来」。在生产环境里，它更像一套数据管道和检索系统，目标很具体：
三个主要逻辑——记忆捕获、AI 压缩、智能检索。
说人话就是：数据结构怎么定、写入怎么做、分层怎么做、检索怎么做、什么时候该忘。
在很多团队里，长期记忆失败不是模型问题，是定义问题：同一个「memory」里混了用户画像、任务状态、项目知识、工具日志，最后检索噪声大到不可用。
我更愿意按「用途」拆，而不是按「存储介质」拆：
用户长期记忆每次都要注入的「稳定事实」。
长期记忆的定义：长期、可编辑的核心记忆，记录稳定属性（姓名、目标、经历、偏好等），并且「每次对话都会强制注入」。
这里我会很强硬地加两条工程规则：
更新方式有两种，但优先级不同：
任务记忆是会过期的「状态」
它属于长期记忆系统，但不属于「永久」。例如：
这类记忆如果不做 TTL，很快就把检索污染掉。任务记忆一定要有生命周期。
这也可以叫做过程记忆，这是为检索服务的「轨迹」。
这类通常来自工具调用、文件读写、运行日志。它的价值是：当用户问「你刚才改了哪几个文件」「上周我们为什么选了 A」时，Agent 能把证据拿出来。
它的问题也最大：写入频率极高、噪声极多。这类我默认做分层：热层保最近、冷层做压缩归档，别全塞进同一个向量索引里。
捕获 → 压缩 → 检索（注入）
简单来说就是谁来写、写什么、写到哪。
捕获层我建议按「事件源」拆：
以 Claude-Mem「五大生命周期钩子」为例，是一个比较实用的策略，原因是它把捕获点固化在生命周期上，不靠「模型想起来了」这种玄学。
| 钩子名称 | 触发时机 | 核心作用 |
|---|---|---|
| context-hook | 会话启动时 | 注入最近记忆作为上下文 |
| new-hook | 用户提问时 | 创建新会话并保存提示词 |
| save-hook | 工具执行后 | 捕获文件读写等操作记录 |
| summary-hook | 会话结束时 | 生成 AI 摘要并持久化存储 |
| cleanup-hook | 停止指令时 | 清理临时数据 |
我自己的经验：save-hook 和 summary-hook 之间一定要有边界。 save-hook 捕获「事实与证据」（做过什么、改过什么）。summary-hook 产出「压缩后的可读结论」（为什么这么做、后续计划）。混在一起，后面做检索融合会很痛。
简单来说就是压什么、怎么压、压到什么粒度
压缩不是「把 10 轮对话变 200 字」这么简单。压缩的核心目标只有两个：
比较典型的做法：每隔 10 轮触发 summary agent，把前 10 轮压成 200 字摘要并替换历史。这里可能会有一个坑：摘要如果不带结构，后面无法做检索约束。
我更偏好把摘要拆成固定字段（即使最终还是自然语言）：
这样检索返回摘要时，Agent 能快速判断「这段能不能用」，也能在需要时回溯证据。
别把「能搜到」当成「能用」，这是两回事。
很多记忆系统上线后表现很差，根因是：检索返回了一堆「看似相关」但没有操作价值的片段。工程上我会把检索拆成三段：
「渐进式披露策略」是当前比较流行的注入策略，这比「Top-k 全塞」靠谱太多了：
Level 1: 最近 3 条会话摘要（约 500 tokens）
Level 2: 相关观察记录（用户主动查询）
Level 3: 完整历史检索（mem-search 技能）
Level 1 覆盖 80% 的连续对话场景；Level 2 把「更多细节」交给用户意图；Level 3 才动用重检索，避免每轮都把成本打满。
文件、知识库、数据库都是可以选的。
最强的可控性，最差的并发与检索体验
文件的优势是「简单到不会出错」：
缺点也有：
如 OpenClaw 的设计：每日日志 + MEMORY.md 精选长期存储。它这个方案我很喜欢，原因是它把「噪声」和「精选事实」隔离开了。
一个「看起来保守，但极其工程」的方案：
如果捕捉对话每个细节，代理每次加载上下文会消耗更多 Token，杂音会降低响应质量。
MEMORY.md 这种「精选」必须有准入机制。靠人手维护能跑，但团队一大就维护不过来。可以整一个「重要性评分系统」，先打分，再决定进不进精选层。
适合「稳定知识」，不适合「高频写入」
知识库适合 SOP、产品手册、FAQ、架构决策记录这种相对稳定的内容。它的问题是写入链路通常偏离线：采集、清洗、切分、建索引。你要它承接「每次工具调用写一条」这种场景，很快会把 ingestion 管道压垮。
KB 承接 semantic memory（语义知识），别拿它硬扛 episodic/event memory。
能抗并发、能做权限、能做检索，但我们要付出工程代价
数据库我会再分两类：
user memory 这种「必须可控」的内容，优先放结构化 DB；event/episode 的检索层再用向量 DB 或混合检索。把所有东西都向量化，后面治理成本会很高。
向量数据库把记忆从只读变可写后，需要考虑三个具体的工程问题。
这里最容易走偏。很多团队一开始恨不得「全量记录」，结果两周后发现：
我的判断维度是：时间、频率、类型，这三者会冲突。我会在应用层做一个更硬的分层打分：
Milvus 的 TTL 和时间衰减，可以用用，不是核心策略。原因很简单：TTL 只能删时间，删不了噪声。噪声是「内容不该进来」，不是「该不该过期」。
按时间切、按访问频率、按用户标注来降冷。「分层」可以，但是：分层的单位别用「向量库的 collection」随便拍脑袋，要用有我们自己的「记忆类型」。
我通常会至少拆三层：
这个结构配合「渐进式披露」很顺：默认只碰热层，必要时升级到温层/冷层。成本曲线能压得住。
关键矛盾：agent memory 要实时写入，但向量索引构建需要时间；每条写都重建索引太贵，批量建索引又导致新数据搜不到。
在工程上解这个矛盾的思路：
把「可立即检索」和「可长期高精检索」拆开 新写入先进入一个轻量的「增量区」（delta store），可以是：
内存缓存 + 简单向量结构（甚至先不建复杂索引）
或者一个专门的「实时 collection」，索引参数偏向写入吞吐
后台异步合并（Compaction） 到一定量再合并进主索引（main store），这时构建更重的索引结构。
检索时双查 先查 delta，再查 main，最后融合去重。这样用户刚执行的操作，下一轮一定能搜到，不靠运气。
如果只用一个 collection 硬扛实时写入 + 高精检索，基本会卡在「要么写不动，要么搜不准」之间来回摆。
我倾向于「结构化事实 + 混合检索」
user memory 和一部分 task memory，用结构化存储更稳，理由：
向量化适合「相似性召回」，不适合「事实的最终真相」。
这样拆：
KV + 版本 + 来源，每条 user memory 至少需要：
然后注入策略是：每轮只注入白名单 key。别把整个用户画像 dump 进 prompt。
文档型存证 + 可选向量索引
工具调用日志、文件变更记录，我更愿意先当「证据」存好（文档型或日志系统），向量索引只是加速检索的手段。这样即使向量库挂了，还有可追溯的事实来源。
先过滤，再相似度，再重排
非向量方案想要「像向量检索一样好用」，别上来就全文检索硬搜。最有效的顺序通常是：
这套顺序能把噪声压下去，查询也更可解释。
注入策略比检索算法更重要
很多人把精力都花在「embedding 模型选哪个」「Top-k 设多少」，上线后发现效果波动很大。
实际可能是：注入策略决定了下限。
「渐进式披露」已经是很好的骨架。我补两条我认为必须做的工程约束：
每轮对话给记忆注入多少 token，要有硬预算。例如：
预算不固定，线上成本就不可控；更糟的是上下文挤压推理空间，模型会「看起来记住了」，实际输出质量下降。
宁可不注入，也别注入矛盾
最常见的事故是：用户改了偏好（比如语言、格式、技术栈），旧记忆还在注入，Agent 开始精神分裂。
工程上必须有冲突策略：
AI Agent 的长期记忆不是「把历史对话都存起来」，而是一套以可控、可维护、可纠错为目标的数据管道与检索系统——先明确记忆类型（用户稳定事实、任务状态、事件证据）并分层治理，再用“捕获 → AI 压缩 → 智能检索/注入”三段式把信息从高频噪声提炼成可用上下文；存储上用结构化数据库承载可编辑的用户/任务事实，用日志/文档留存证据，并按需用向量索引做语义召回与冷热分层，避免写入与索引、噪声与成本之间的失控；
效果上不要迷信 Top‑k，把注入预算、渐进式披露、冲突处理当作系统下限；
运维上把缓存、摘要、显式记忆工具、TTL/衰减与合规删除做成一等能力，并用成本、质量与安全指标持续观测迭代。
最终目标不是「记得更多」，而是让 Agent 在长期任务中更一致、更便宜、更可靠。
以上。
