把所有对话按用户 ID 存下来，再做 embedding，通常就被叫作“长期记忆”。这个方案演示很快，生产问题也来得快：用户改了偏好，旧片段仍被召回；一句推测被当成事实；删除账户后，向量索引里还残留副本。
Memory DB 不是消息归档的别名。它要管理记忆如何产生、依据什么、何时有效、与谁冲突、能否被检索、何时遗忘。原始经历、提炼事实和检索索引承担不同职责，不能混在一张 conversations 表里。
邓明瑞 / 纯粹
Memory DB 不是一张 conversations 表：把事实、经历和索引分开建模
Agent Memory 不要只存对话摘要：事实、偏好与运行状态是三种数据
Agent Memory 最常见的实现，是每隔几轮让模型总结对话，把摘要写进向量库。这样很快会混进三类完全不同的数据：用户所在城市这类事实、偏好中文回答这类偏好、任务执行到第三步这类运行状态。它们的正确性、有效期和删除规则并不相同。
我会先拆数据模型，再谈 embedding/召回。事实需要来源和时间，偏好需要用户可见可改，运行状态需要强一致的 checkpoint。三层都可以进入上下文，但不能共用“相似度高就拿出来”的读写规则。
