Agent Memory 架构拆解：别再把向量库当唯一记忆系统

长期 Agent 记忆不是 RAG，而是要能维护证据、版本和生命周期的数据系统。

Agent 的记忆能力很容易被做成一个轻量 RAG：把历史消息切块、生成 embedding、写进向量库，提问时召回 Top-K，再塞回 prompt。这个方案适合 MVP，成本低，链路也清楚。

但它解决的是"找相似文本 "，不是"维护长期状态 "。一旦 Agent 开始跨会话工作，记忆里会同时出现旧事实、新事实、临时偏好、冲突记录、工具执行轨迹和过期任务状态。系统如果只会追加，不会判断有效期、证据来源和冲突关系，后面出错只是时间问题。

真正的 Agent Memory 更像一个数据系统 。它要负责写入、索引、检索、版本、淘汰、合并和审计。向量库可以是入口，但不能承担所有职责。

Memory Layer：先划清记忆系统的边界

一个可运行的记忆系统至少有四类动作：表示、落库、抽取、检索，再加上一件经常被低估的事：长期维护。

图：从原始交互到 Agent 决策上下文的记忆链路

这张链路图里，最关键的不是用了哪种数据库，而是每一步有没有清楚的责任边界。抽取层决定什么能进入记忆；表示层决定记忆长什么样；存储层决定它能被怎样查询；维护层决定它在几个月之后是否还可信。

如果把这些动作都压缩成"写向量库、查向量库"，系统会很快遇到三个问题：查到了相似内容但不是当前有效内容；召回了一条证据但缺少完整上下文；新旧事实并存时只能让模型临场猜哪个是真的。

图：一条长期记忆如何同时保留文本、证据、状态和索引

Representation：记忆不是只有一段文本

记忆的逻辑表示决定了后续能力的上限。简单事实句好写、好读，但很难稳定处理字段过滤和局部更新；向量适合语义相似召回，却不适合解释"为什么这条记忆有效"；图结构能表达实体、关系和时间，但需要更好的抽取质量和 schema 设计。

记忆表示	适合什么	不适合什么	工程判断
文本片段、事实句、摘要	快速落地，和 LLM 上下文兼容	精确过滤、冲突检测、字段级更新	适合早期系统，但要保留证据来源
向量表示	语义近似召回、模糊问题匹配	版本判断、实体关系、可解释性	适合作为召回入口，不适合当唯一事实源
图或树结构	实体关系、时间线、层级摘要	抽取噪声高、schema 成本高	适合长期画像、关系推理和时序查询
复合记忆对象	多检索器共用同一条记忆	对象迁移、兼容性、维护复杂	生产系统更常见，但需要治理机制

更稳妥的做法是把一条记忆做成复合对象：有自然语言描述，也有时间戳、来源、原始证据、embedding、实体字段和状态标记。这样同一条记忆既能被向量检索召回，也能被 SQL 按时间过滤，还能被图遍历接入关系推理。

这听起来麻烦，但它解决的是后期返工问题。embedding 模型换了可以重建向量；schema 改了可以迁移字段；摘要错了可以回放原始事件。前提是底层证据没有丢。

图：记忆路由把不同访问模式分发给不同存储后端

Storage：单引擎很干净，多引擎才接近真实负载

存储层通常有三种形态。第一种是上下文内暂存，把记忆放在 prompt 或 KV cache 里，延迟低，但容量和持久化能力有限。第二种是单一专用引擎，比如 Vector DB、Graph DB、Relational DB 或文件存储。第三种是多引擎组合，通过 Memory Router 把不同形态的数据写到不同后端。

图：Memory Router 如何连接向量、图、SQL、缓存和原始日志

多引擎不是为了炫技。用户偏好需要版本和有效期，工具任务需要 trace 顺序，跨会话问答需要证据扩展，低延迟助手需要轻量缓存。把这些访问模式都塞进一个向量库，最后会变成一堆检索参数和 prompt 规则的补丁。

当然，多引擎也会带来代价：写入路由、跨存储一致性、索引重建、查询编排、审计日志都要单独设计。所以选型时不要问"哪个记忆系统最好"，先问 Agent 的主要负载是什么。

Extraction：写入前就要决定什么值得记住

Agent 的原始轨迹包括多轮对话、工具调用、任务结果、环境反馈和中间推理痕迹。它们不能无脑进入长期记忆。写太少，关键事实丢失；写太多，后续检索被噪声拖垮。

抽取方式	做法	优点	风险
原始序列保留	直接保留近期对话、任务轨迹或递归摘要	成本低，信息不容易被抽取阶段误删	噪声多，依赖长上下文和注意力
自由语义抽取	从文本中抽出事实句、偏好、事件描述	粒度更清楚，适合轻量长期记忆	事实边界不稳定，冲突处理困难
结构化抽取	按 JSON、三元组、事件 schema 输出	方便过滤、更新、图谱写入	schema 成本高，错误会结构化沉淀

一个实用的写入策略是分层保留：原始事件日志作为事实源，派生事实作为检索加速层，结构化状态作为任务恢复层。摘要、embedding、图谱关系都可以重算，原始证据一旦丢了，系统就只能相信自己当时抽取出来的二手信息。

这里最怕的是把"摘要更干净"误认为"记忆更可靠"。摘要能减少 prompt 噪声，但它也会压扁细节。对于长期运行的 Agent，证据链比短期上下文整洁更重要。

Retrieval：Top-K 只是入口，不是答案

Memory Retrieval 不能简化成向量 Top-K。很多问题需要的不是一条最相似的记忆，而是一组能拼起来的证据。

一个更可靠的检索流程通常分两步：先定位入口，再扩展证据。入口可以是用户、实体、会话、任务、工具调用或时间点；扩展可以沿着时间线、图关系、任务 trace 或同一会话继续找。

图：不同问题类型对应不同检索路径

实验结论也支持这个判断。在 LoCoMo 的证据级召回中，SimpleMem 的 Recall@1 最高，达到 39.0；但当预算放到 Recall@5 和 Recall@10，A-MEM 达到 69.5 和 85.9，MemTree 达到 59.7 和 80.5。早早命中一条相关证据，不代表回答所需证据已经齐了。

这也是生产系统里经常需要混合检索的原因：先用 SQL 做时间过滤，再用向量召回语义候选，必要时走图遍历，最后用 reranker 或 LLM 做证据组装。代价是延迟和调参成本会上升，所以不同问题应该走不同路径，而不是所有查询都跑最重链路。

图：版本、有效期和冲突处理决定长期记忆是否可信

Lifecycle：长期记忆最怕"还记得，但记错了"

长期记忆的风险不是单纯遗忘，而是系统保留了大量事实，却不知道哪些还有效。用户已经取消偏好，Agent 还继续推荐；任务已经推进到下一步，Agent 还拿旧状态做决策；同一实体有多个版本，系统把它们同时召回。

维护机制	解决的问题	设计要点
时间戳多版本	新旧事实并存、历史可追溯	使用 `valid_from`、`valid_to`、状态标记管理当前有效性
容量驱逐	记忆无限膨胀	按访问时间、重要性、衰减函数或任务价值淘汰
语义合并	碎片事实过多、重复冲突	用 LLM 合并、去重、补充，但必须保留原始证据
参数化更新	高频经验沉淀进模型	适合稳定模式，不适合频繁变化的事实

把新旧事实都 append 到向量库，然后在 prompt 里要求模型"自行判断当前有效事实"，这不是记忆系统，这是把系统正确性外包给模型临场发挥。

更好的方式是让数据层先给出候选范围：哪些事实当前有效，哪些已经失效，哪些互相冲突，哪些只是历史记录。LLM 可以参与判断，但不应该是唯一的版本控制器。

Benchmark：效果、证据和延迟要一起看

记忆系统没有单一最优架构。不同任务的胜出方案并不一致。

评测场景	更占优的能力	典型结果
LongMemEval 跨会话长记忆	结构化组织、长期证据定位	Zep 的 LLM Judge Accuracy 到 48.0；Cognee 的 ROUGE-L F1 到 35.3
LoCoMo 长对话精确问答	混合过滤、证据扩展	MemOS 的 Exact Match 达到 11.5；temporal slice 中达到 8.9
DB-Bench 状态化执行	原始轨迹、操作顺序、任务状态	Long Context 的 EM 为 48.2；MemoChat 的 Task Success Rate 为 55.4
Knowledge Update / Temporal Reasoning	版本管理、时间关系、冲突处理	Zep 在 Knowledge Update 上 Substring EM 为 44.4、ROUGE-L F1 为 36.8；Cognee 在 Temporal Reasoning 上 Substring EM 为 18.7、ROUGE-L F1 为 35.8

长上下文也不能替代记忆组织。模型能塞进更多历史，不代表它能稳定找到正确证据。LoCoMo 上，Embedding RAG 的 Answer F1 随证据距离拉大从 37.1 掉到 7.4；关系组织或层级整理更强的系统表现更稳。

成本也不能只看查询一次有多慢。写入、合并、索引重建、跨存储同步都会吃掉预算。LightMem 的 Normalized Utility 为 48.3，平均操作延迟 3.67 秒；MemTree 的 Utility 为 63.5，延迟 15.9 秒；MemoryOS 的 Utility 到 82.0，延迟也到 28.6 秒；Cognee 和 Zep 的 Utility 超过 84 时，延迟分别超过 116.5 秒和 155.1 秒。

这些数字说明一件事：更重的记忆系统确实可能带来更高效用，但不一定适合所有在线场景。低延迟助手、复杂研究 Agent、工具执行 Agent 和长期个人画像系统，不应该共用一套记忆链路。

Engineering Takeaways：生产级 Agent Memory 的三层底座

如果从零设计一个偏生产可用的 Agent Memory，我会先做三层。

第一层是原始事件日志。用户消息、助手回复、工具调用、任务结果、时间戳、来源和证据链都要保留。它是后续摘要、向量、图谱、状态表的事实源。

第二层是多种派生视图。同一份历史可以有向量索引用于语义召回，有事实表维护用户画像，有任务状态表支持工作流恢复，有图关系支持实体和事件推理，也有摘要帮助快速定位上下文。

第三层是查询编排。系统要先判断问题类型，再选择检索路径。最新状态走版本过滤；跨会话问题先定位实体或会话，再扩展证据；工具任务优先回放 trace；低延迟问答走轻量索引，避免每次都触发全局图遍历。

场景	主要风险	设计重点
用户画像、长期偏好	旧事实和新事实混在一起	实体绑定、版本、有效期、冲突处理
跨会话问答	证据分散，单条召回不足	入口定位后做证据扩展
工具执行 Agent	丢失操作顺序和中间状态	完整 trace、可回放、可审计
低延迟助手	维护和检索成本过高	局部更新、轻量索引、减少全局重组

评测也要跟着变。只看最终回答分数不够，还要看写入覆盖率、证据召回率、证据组装能力、更新正确性、长周期漂移和维护成本。Agent Memory 是长期运行系统，不是一次性 benchmark。它必须能解释、能观测、能回放。

结语：向量库是入口，不是记忆系统

Agent Memory 的第一阶段看起来像检索，第二阶段就会暴露出数据系统问题：事实会过期，偏好会改变，证据会分散，索引会重建，成本会变成产品约束。

所以，**一个可靠的记忆系统不应该只追求"召回相似内容"**。它要保留原始证据，构建派生视图，理解版本语义，按问题类型编排查询，并用生命周期管理控制记忆膨胀。

向量库当然有价值。只是到了长期 Agent 场景里，它更像一块索引，而不是整套记忆。