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证据链比短期上下文整洁更重要。RetrievalTop-K 只是入口不是答案​Memory Retrieval 不能简化成向量 Top-K​。很多问题需要的不是一条最相似的记忆而是一组能拼起来的证据。一个更可靠的检索流程通常分两步先定位入口再扩展证据。入口可以是用户、实体、会话、任务、工具调用或时间点扩展可以沿着时间线、图关系、任务 trace 或同一会话继续找。图不同问题类型对应不同检索路径实验结论也支持这个判断。在 LoCoMo 的证据级召回中SimpleMem 的 Recall1 最高达到 39.0但当预算放到 Recall5 和 Recall10A-MEM 达到 69.5 和 85.9MemTree 达到 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.0Cognee 的 ROUGE-L F1 到 35.3LoCoMo 长对话精确问答混合过滤、证据扩展MemOS 的 Exact Match 达到 11.5temporal slice 中达到 8.9DB-Bench 状态化执行原始轨迹、操作顺序、任务状态Long Context 的 EM 为 48.2MemoChat 的 Task Success Rate 为 55.4Knowledge Update / Temporal Reasoning版本管理、时间关系、冲突处理Zep 在 Knowledge Update 上 Substring EM 为 44.4、ROUGE-L F1 为 36.8Cognee 在 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 场景里它更像一块索引而不是整套记忆。推荐阅读Hermes 上下文压缩架构长任务 Agent 不失忆的几个关键设计Agent 评测系统架构从指标分层到 GT/Judge 闭环的工程化落地团队落地 Agent 工程化 Loop 的一些必看小技巧Agent 工程化新底座用 CLI 契约层打通 HTTP 接口与业务能力Agent Loop 架构拆解让 AI Agent 自己跑完验收闭环