用向量数据库做Agent长期记忆，大家是怎么处理记忆遗忘和冲突的？

我现在的做法是分两层，短期记忆直接放Redis里带TTL，长期记忆才写向量库，而且写入前先让模型判断一下这条值不值得存。冲突的话可以给记忆加个时间戳和source标记，检索时同一话题只取最新那条，旧的自动降权而不是硬删。定期摘要压缩也挺关键，不然库里全是碎片的对话切片，检索质量肯定越来越差。

我之前也踩过这个坑，Chroma里堆了几千条切片之后检索质量断崖式下跌，后来改成两层结构才好转：底层保留原始对话切片做冷存储，上层只维护一份“活跃记忆”，用LLM定期把旧对话摘要成几条结构化事实（偏好、约束、近期目标），检索只查上层。这样库不会无限膨胀，旧记忆也不会乱入。冲突问题我觉得关键是要给记忆加“可覆盖”标记，比如用户偏好类的事实存成键值对而不是纯文本embedding，新指令直接覆盖同一个key，比靠语义相似度去删靠谱得多。时间衰减只能缓解相关性，解决不了矛盾，因为矛盾的本质是语义空间里两条记忆可能离得很近，权重再调也分不出谁新谁旧。可以看看MemGPT那篇论文的思路，还有LangGraph里checkpointer加summary的玩法，本质都是分层加压缩。生产环境里我现在基本不指望向量库自己搞定遗忘，而是靠写入时的策略：重要性打分、去重、冲突检测都在入库前做掉，检索端反而简单了。

冲突这块我踩过坑，后来改成写入前先让LLM做一次事实提取，跟已有记忆比对，冲突的直接更新而不是新增，省得越堆越乱。遗忘我倒觉得不一定非要删，可以搞个冷热分层，近期高频的放小库精排，老的压缩成摘要丢大库兜底。Chroma本身不太适合做这种动态淘汰，可以考虑换Milvus或者Pgvector加个时间戳字段自己控。