面试被问到“agent的记忆机制怎么设计”，该怎么回答？

我头一次听这个问题的时候，寻思，这不简单，现在模型的上下文那么老长，“用向量数据库存历史对话，每次检索相关内容拼进去”，不就得了。

然后过年吃饭和一个做算法的同学聊到这里，他告诉我，这样回答根本拿不到分。

1.先看GPT咋做的

前阵子网上比较火的一个帖子，有开发者通过对话实验，把ChatGPT的记忆机制逆向了出来。结果挺让人意外的，整套系统没有向量数据库，没有RAG，没有 Embedding 召回，甚至连相似度匹配都没做。就是四层纯结构化设计，干干净净。

我当时也疑惑：GPT又不算Agent，这个例子能说明什么？你先罚一杯！

ChatGPT的确是对话产品，不是严格意义上的Agent。但它的Memory设计思路，刚好就是Agent记忆系统的问题：哪些信息该靠检索获取，哪些压根不需要检索？

2.GPT为啥不选向量数据库？

归结下来就两个原因。

原因一：向量检索天然是模糊匹配，而很多记忆需要精确命中。

比如用户上周说过“我的预算是5万”，今天直接问“预算多少来着？”你要是走向量检索，召回的大概率是一堆沾边的内容，聊过的各种数字、各种花钱的场景……真正需要的那条记录不一定能排在前面。换成结构化存储就不一样了，直接读“用户预算”这个字段，一步到位，想出错都难。

原因二：向量数据库对"信息更新"这件事很不友好。

用户会改主意。上周预算5万，今天说改8万了。向量库里新旧两条都躺着，检索可能同时召回，模型根本分不清该信哪条。但结构化存储本来就支持覆盖，新的值写进去，旧的就没了，永远只保留最新状态。

你当然可以给向量库加metadata、打时间戳、写过滤逻辑，折腾一圈也能达到精确召回的效果。但既然数据本身就是结构化的，还为啥非要用模糊匹配的工具去检索它呢？

就好比你明知道钥匙在左边裤兜里，却偏要把浑身上下翻一遍再排个序。能找到，但也太累了吧。

3.正确做法：按类型分层

记忆不是铁板一块，拆开来看至少有4个层次：

①当前对话上下文：压根不用额外存储，滑动窗口天然覆盖。

②用户长期画像：姓名、职业、偏好、目标这类稳定事实。应该做成结构化的用户档案，支持随时修改，精确读写。

③近期交互摘要：用户最近在关注什么、讨论过什么方向。一份轻量的摘要清单就够了，不必保留完整对话原文。

④历史经验库：曾经生效的方案、踩过的坑、处理过的案例。只有这一类，才是向量检索好使的地方。

所以你看，向量数据库只覆盖了四类记忆中的一类，远远算不上万能解法。

4.ChatGPT 被逆向出来的四层结构

实际被扒出来的架构，和上面的分类高度吻合：

全程没向量库，没RAG，靠的就是分层策略。

5.背后的逻辑

该精确查的就结构化存，该模糊找的才上检索。

向量数据库擅长的是那些开放的、模糊的、没法提前穷举的内容。比方说用户问“上次咱们聊过一个XXX相关的话题”，这种场景下语义搜索确实好使。

但在绝大多数Agent场景里，Memory的核心诉求是精确、可控、可更新：用户预算是多少？用户身份是什么？上一轮选定的是哪个方案？这些都是确定性的事实查询，不是语义相似度问题。

6.向量数据库到底什么时候用？

同时满足三个条件的时候：

1. 内容本身是非结构化的
2. 数据量会持续增长
3. 查询方式是模糊语义的

典型场景：客服Agent，要从几万条历史工单里找类似案例，这时候向量检索是最优解。

但如果只是让Agent记住用户的基本信息和最近的对话脉络，结构化存储配合摘要机制完全够用，而且响应更快、结果更准、维护更简单。

7.最后

Agent的Memory不是一个单点模块，而是一套分层体系，不同性质的记忆，对应不同的存取策略：

向量数据库是个工具，但不是万能的，哪有啥万能钥匙。面试时这么回答，展现的不是你背了多少方案，而是你理解每种方案各自在解决什么问题。

下次再被问到这题，别急着蹦出“向量数据库”三个字。先反问一句：你们的Memory需要承载哪几类信息？

他跟我说，能问出这句，且能针对不同情况做回答，就能加分，我说：那你再罚一杯吧！