AI Agent的“记忆”到底怎么落地？我快被Context绕晕了

说实话你这问题太真实了，我上周刚把项目从纯向量检索改成“短期缓存+长期摘要”两层结构，短期存原始对话，长期用LLM按用户维度压缩成结构化档案，价格人名这些硬信息单独抽出来存字段，效果比单靠向量好不少。不过召回不准这块，我怀疑是embedding切分粒度的问题，试试按意图段落切而不是固定窗口，可能关联性强很多。你那个“川菜”的例子，感觉更像缺个实体链接层，把辣、川菜这类词先映射到统一概念再检索，命中率会上去。

试试短期用摘要+关键实体单独存，长期才落向量库，川菜那句靠意图识别先触发场景再查记忆。

我之前也踩过一模一样的坑，全量塞历史消息这条路走不通是必然的，后面你会发现连system prompt都被挤没了。我现在的做法是分三层来管：最近几轮对话原样保留，再往前用滚动摘要压，硬事实（价格、人名、偏好这种）单独抽成结构化KV存起来，每次按需拼进prompt。向量召回不准这事儿，我觉得根子不在向量本身，而是你拿整句去embedding，语义太散了，得先把用户话里的实体和意图抽出来再做检索，命中率会高很多。至于图结构，我试过一阵子，关系推理确实香，但维护成本高得离谱，除非你的场景真的强依赖多跳关联，不然别轻易上。生产环境我现在是Redis做短期缓存加Postgres存长期记忆，简单粗暴但稳，外挂数据库这事儿真没必要抵触。

这个思路不错，收藏了。

我之前也踩过这个坑，纯向量召回对“我喜欢吃辣”这种偏好类信息确实不敏感，因为语义相似度算出来跟“川菜”差挺远。后来我改成混合方案：短期对话用滑动窗口加摘要，硬信息（人名、价格、偏好）单独抽成结构化字段存Redis，向量库只负责模糊回忆。召回时先走结构化匹配再补向量结果，准确率提升挺明显。不过图结构我没试过，好奇在跨会话长期记忆上是不是真比关系库好用？

我们项目里现在用的是分层方案，短期记忆直接放对话窗口，超了就摘要加实体抽取兜底，人名价格这些硬信息单独存结构化字段。向量召回不准大概率是没做改写和重排，用户那句“那家川菜”其实得先补全指代再检索。长期记忆扔Postgres加pgvector就够了，图数据库除非关系特别复杂，不然维护成本真扛不住。

你这问题太真实了，我去年做客服Agent的时候也卡在记忆这块好久。纯塞历史肯定不行，后来我们是short-term用滑动窗口加关键实体提取，long-term才走向量库，但向量召回确实得加一层rerank，不然“我喜欢吃辣”这种偏好根本匹配不到川菜。摘要压缩我也踩过坑，价格人名丢了就是事故，后来改成结构化抽取，把硬信息单独存成KV，摘要只负责语气和意图。图结构听起来很美，但维护成本高，除非你的实体关系特别密集，否则不如老老实实分层：会话缓存、用户画像、事实库三张表。外挂数据库是必须的，但别指望一个向量库解决所有召回，混合检索加规则过滤才是生产可用的底线。