Agent 的“记忆”到底该怎么做？我现在只保留这三类-洪萨配资

作者:WiseAgent小而美智能体架构师

在 Agent 开发的早期，我也犯过很多“贪大求全”的错误。那时候，看到向量数据库（Vector DB）就像看到了救世主，恨不得把用户说的每一句话、系统的每一次日志都塞进去，美其名曰“全息记忆”。结果呢？系统上线后，不仅 Token 消耗如流水，更致命的是“信噪比”极低。

当上下文窗口被无关紧要的废话填满时，LLM（大语言模型）的推理能力会显著下降。这就是学术界常说的“Lost in the Middle”现象——给的越多，它越糊涂。而且，检索回来的内容经常似是而非，导致严重的幻觉。

经过几个项目的填坑和重构，我现在的架构设计原则非常简单：记忆不是存储，而是为了更精准的计算。在我的工程实践中，我砍掉了那些花里胡哨的“无限记忆”，只保留了这三类最核心、最可控的记忆形态。

第一类：短期记忆（Session Context）—— 它是“缓存”，不是“日志”

这是最基础的，当前对话窗口内的历史记录。很多新手直接把List<Message>往 Prompt 里塞，直到 Token 溢出。

我的工程判断：短期记忆的核心矛盾是“上下文长度”与“注意力分散”之间的博弈。你不能指望模型读完 50 轮对话还能精准记得第 3 轮的一个细节。

我现在怎么做：

滑动窗口（Sliding Window）是底线，但不够。我通常只保留最近的 N 轮（比如 10 轮）原始对话。
关键信息“快照化”。我不会依赖 LLM 去翻历史记录找“用户叫什么名字”或“刚才选了哪个套餐”。
1. 在每一轮对话结束时，我会用一个轻量级模型（甚至就是写死的正则或 NLP 工具）提取关键实体（Slot），更新到一个结构化的 State 对象中。
2. 下一轮对话时，Prompt 里放的不是冗长的聊天记录，而是这个精简的 State JSON。
定期总结（Summarization）。如果对话过长，触发一个后台任务，把前 20 轮对话压缩成一段 100 字的摘要，替换掉原始 Log。

别把 LLM 当成翻旧账的会计，它记不住。把非结构化的对话实时“坍缩”成结构化的状态，才是正解。

第二类：长期记忆（User Profile）—— 它是“数据库”，拒绝“向量化”

这是很多 Agent 系统最容易翻车的地方。很多人喜欢把用户的个人信息、偏好、历史订单都变成向量存进 Chroma 或 Milvus。这是工程上的大忌。为什么？因为向量检索是概率性的（基于相似度），而业务数据要求是确定性的。当用户问“我的手机号是多少”时，你通过向量检索可能会找出一个“相似”的号码（比如前一位用户的），这在生产环境中是绝对的事故。

我的工程判断：对于事实性、属性类的数据，SQL和KV存储永远比向量数据库可靠。

我现在怎么做：

结构化画像。用户的 ID、权限等级、会员状态、硬性偏好（如“只看五星级酒店”），这些必须存在 MySQL 或 Redis 里。
显式注入。在构建 Prompt 时，通过代码逻辑直接查询数据库，将这些字段以 Key-Value 的形式硬编码进 System Prompt。
1. Bad Case:让 LLM 去向量库里搜“用户的会员等级”。
2. Good Case:代码查库 ->user_level: "VIP"-> 拼接到 Prompt。
动态更新。这类记忆的更新必须由确定的业务逻辑触发（比如调用了update_profile工具），绝对不能由 LLM 自己“感觉”应该更新了就去改库。

事实不容模糊。凡是能用 SQL 查出来的，绝不用 RAG。

第三类：程序性记忆（SOP & Knowledge）—— 它是“外挂”，不是“大脑”

这类记忆指的是 Agent 执行任务所需的知识库（RAG）和标准作业程序（SOP）。早期的做法是把所有公司文档切片扔进库里。结果发现，Agent 经常检索到过期的文档，或者把 A 产品的操作手册用在 B 产品上。

我的工程判断：RAG 的难点不在于 Retrieve（检索），而在于治理。垃圾进，垃圾出。

我现在怎么做：

知识分层。我不再维护一个大一统的向量库，而是按场景切分。
1. 处理“退款”意图时，只挂载“售后政策”的知识库。
2. 处理“技术支持”意图时，只挂载“API 文档”的知识库。
3. 这需要在中控层（Controller）做精准的路由。
SOP代码化。很多团队试图把复杂的业务流程写在 Prompt 里让 LLM 记下来。这是不可靠的。
1. 我会把 SOP（比如：先验资，再下单，后发货）写成代码逻辑（Code）或工作流（Workflow）。
2. Agent 的“记忆”里只需要知道当前处于 SOP 的哪一步（Step 2），以及下一步该调哪个工具。流程的跳转逻辑，由代码约束，不由模型记忆。