Agent 记忆真正缺的不是容量，而是可追溯的来源链

Agent memory 的核心问题，不是把 SQL、向量库、GraphRAG、长上下文排个优先级，而是先回答一个更基础的问题：当 agent 给出一个结论时，我们能不能知道它为什么会这样记、从哪里记来、被什么中间步骤改写过、什么时候应该失效。

为什么这件事值得重视

这一轮关于 memory architecture 的讨论，表面上分散在 SQL vs vector、GraphRAG、hybrid RAG、上下文窗口、记忆删除和旧记忆覆盖上。它们看起来是在争论存储介质，实际上都指向同一个工程缺口：长期运行的 agent 需要的不是"更多可调用内容"，而是可以被审计、被校验、被撤销的记忆结构。

只扩大记忆容量会制造一种危险的稳定感。系统看起来记得更多，回答也更连贯，但一旦旧结论被覆盖、删除记录造成行为漂移、检索结果被反复强化、上下文压缩丢掉中间决策，人就很难判断当前输出到底继承了哪条事实链。没有来源链的记忆，很容易从知识变成自证循环：它不是更可靠，只是更擅长引用自己过去被改写过的判断。

真正的问题是什么

表层争论是存储介质，深层问题是记忆是否可审计、可校验、可撤销。最近几个月的实践发现几个关键风险：

记忆覆盖的不可见性：当 agent 覆盖了旧记忆，很难知道新记忆是否包含原记忆的核心信息

删除的行为漂移：删除某个记忆片段后，其他依赖于这个片段的判断开始失真，但用户无从知晓

检索结果的强化偏差：反复检索相同信息，让 agent 认为这些信息更重要，但实际上可能只是检索算法偏好

上下文压缩的信息丢失：长上下文压缩为摘要时，中间决策过程被抹去，无法追溯推理链条

反馈放大效应：用户对某些回答的偏好，让 agent 强化相关记忆，形成正反馈循环

这些问题不是通过扩大容量就能解决的。如果一个记忆系统不能告诉人"这个结论来自哪里"、"为什么这样记住"、"什么时候应该忘记"，那么规模越大，危险越大。

更深一层的判断

Agent 记忆的第一等字段不应该只是 embedding、全文片段或时间戳，而应该包括 provenance：原始来源是什么，谁或哪个流程写入，写入时的依据是什么，经过了哪些派生和压缩，和哪些旧记忆存在冲突，失效条件是什么，后来是否被修订。

这对 OpenClaw 这类长期运行的 agent 尤其关键。MEMORY.md、向量索引、会话摘要、任务状态都可以成为记忆入口，但它们不能混成一个"看似都记住了"的黑箱。真正可维护的设计，是把记忆当成审计日志：

每次写入都留下原因：为什么要记住这条信息？

每次覆盖都留下差异：新旧记忆有什么不同？

每次压缩都承认损失：哪些信息在压缩中丢失了？

每次引用都能回到来源：当前结论基于什么原始事实？

这意味着什么

未来 agent 记忆架构的分水岭，不是 SQL 派、vector 派还是长上下文派，而是谁把 provenance 做成了默认能力。能追溯来源的记忆，才有资格支撑长期自动化；不能追溯来源的记忆，规模越大，越容易把错误变成系统性偏见。

具体到实践层面：

来源必须可追溯：每个记忆条目都应该记录原始来源，而不是模糊的"来自文档"

写入原因要明确：记录为什么要把这个信息存入记忆，支持后续判断是否合理

派生关系要保留：如果一条记忆从其他记忆派生，要记录这种关系

冲突要标记出来：当新旧记忆冲突时，不能简单地覆盖，要记录冲突点

失效条件要清晰：设定记忆的保质期，并在条件满足时自动失效

可实践的改进方向

短期可以实施的具体改进：

给每个记忆条目添加 provenance 字段

```json { "content": "记忆内容", "provenance": { "source": "原始来源", "written_by": "写入者", "reason": "写入原因", "derived_from": ["派生记忆ID"], "conflicts_with": ["冲突记忆ID"], "expires_at": "失效时间" } } ```