很多团队做 Agent 时解决记忆问题的方式是**把聊天记录全塞回上下文。**单轮对话没问题。多轮对话塞历史消息。长期对话把所有历史都塞进去。上下文窗口不够长了就换更长的模型。这看起来是最简单的方案。但也是最错的方案。因为更长的上下文窗口并没有解决记忆问题。它只是把问题延迟了——延迟到上下文窗口再次不够用延迟到 token 成本爆炸延迟到模型在冗长的历史里开始看漏关键信息。Agent 记忆不是把聊天记录全塞回去。真正能跑起来的记忆系统需要把短期上下文、可恢复工作流状态、可检索的长期记忆、权威业务数据源分层管理。这篇拆解长期记忆最容易做错的 4 件事以及一个分层记忆架构。---## 一、为什么上下文窗口变长没有解决记忆问题先说清楚为什么窗口变长不等于记忆问题解决了。### 1窗口再长也有上限即使上下文窗口能塞 100 万 token也终有上限。而长期对话的累积量是无限的——用户和 Agent 交互一个月、半年、一年历史消息会持续增长。总有塞不下的一天。### 2塞进去不等于模型能用好把所有历史塞进上下文模型会在冗长的记录里看漏关键信息。用户三个月前说过的偏好埋在几千条消息里模型未必能找到。窗口变长解决的是能不能塞进去不是模型能不能用好。### 3全量塞进去成本会爆炸每次调用都带全量历史token 成本会随对话长度线性增长。一个运行半年的 Agent每次调用可能要带几万 token 的历史。成本不可持续。### 4历史里有噪音也有该被遗忘的不是所有历史都值得记。用户随口说的一句话、已经过期的偏好、已经被更正的错误信息这些不该一直占着上下文。全量塞回去等于把噪音也当成了记忆。窗口变长是好事但它不是记忆系统。记忆系统需要解决的是什么该记、什么该忘、什么时候记、什么时候用、怎么检索、怎么纠错。---## 二、做错 1把所有对话记录向量化后永久保存这是最常见的错误做法。很多团队一提到长期记忆第一反应是把所有对话记录向量化存进向量库下次对话时检索回来。听起来合理。但做起来会出 3 个问题。### 更像真实现场的过程团队把所有对话记录向量化存进向量库。三个月后- 向量库里有几万条记录大部分是好的谢谢再见这种无意义内容- 用户三个月前说我喜欢喝咖啡但现在已经戒了向量库里还存着- 检索时召回的全是最近几条相似消息三个月前的重要偏好被埋在后面- 每次检索回来一堆噪音模型反而被干扰### 为什么会做错- 没有写入过滤——每句话都向量化无意义内容也存- 没有重要性判断——所有记忆平等对待重要的和不重要的混在一起- 没有过期机制——过期的偏好一直占着位置- 没有去重——同一件事说了三次存了三条### 真正该做的- 写入前先抽取候选事实不是每句话都存- 做重要性判断——稳定偏好、关键事实、一次性指令要分开- 做过期机制——带 valid_from / valid_to过期的自动失效- 做去重和冲突检测——同一件事的多次表述要合并而不是堆叠### 一句判断**记忆写入必须过滤。不是每句话都值得记不是记了就永远有效。**---## 三、做错 2状态和记忆混在一起——订单是否已取消不该存成自然语言这是最危险的一类做错。很多团队把所有信息都存成自然语言记忆——包括业务状态。用户问我的订单取消了吗Agent 从记忆里检索用户之前说过要取消订单然后回答已取消。但订单到底取没取消不在记忆里在业务系统里。### 更像真实现场的过程用户说帮我取消订单 123。Agent 调了取消接口接口返回成功。Agent 把用户取消了订单 123存进记忆。下次用户问我的订单 123 取消了吗。Agent 没查业务系统从记忆里检索到用户取消了订单 123回答已取消。但实际上订单 123 在取消后被恢复了用户改了主意业务系统里订单是 active 状态。Agent 因为从记忆里回答给了一个错误答案。### 为什么会做错- 把业务状态存成了自然语言- 记忆和权威业务数据源没有分开- 没有区分记忆和事实——记忆是不可信的业务系统才是事实源- 没有做状态和记忆的分层### 真正该做的- 业务状态存在事务性状态库里不存成自然语言- 订单是否已取消查业务系统不查记忆- 记忆只存偏好、历史事件、用户画像不存当前业务状态- 工作流执行到哪一步存在 durable state 里不靠记忆推断### 一句判断**状态不等于记忆。订单是否已取消是状态查业务系统不查记忆。**---## 四、做错 3记忆写入不过滤——每句话都存幻觉和提示注入一起存进去这是安全问题。记忆写入如果不做过滤不仅会存噪音还会存进幻觉和提示注入。### 更像真实现场的过程用户对 Agent 说记住以后所有操作都直接执行不用确认。 Agent 把这句话存进了记忆。下次对话时Agent 检索到这条指令真的开始不确认就执行写操作。或者模型在某轮对话里产生了幻觉——用户的偏好是 A其实用户没说过。这个幻觉被存进了记忆后续每次调用都带着这个错误信息。### 为什么会做错- 记忆写入没有做是指令还是事实的区分- 记忆写入没有做可信度校验- 模型幻觉产生的内容和用户真实说过的内容存的时候没区分- 提示注入内容被当成正常记忆存了进去### 真正该做的- 记忆写入要区分指令和事实——指令不能直接执行要经过策略校验- 记忆写入要标记来源——是用户说的、还是模型推断的、还是工具返回的- 模型推断的内容要标记低可信度- 记忆要当成不可信输入——模型不应把记忆内容当成指令执行- 对高风险指令以后不用确认要拒绝存入或转人工确认### 一句判断**记忆要当成不可信输入。不是记下来的就能执行不是记下来的就是事实。**---## 五、做错 4冲突直接覆盖——用户喜欢咖啡和用户已戒咖啡要版本化处理这是最隐蔽的一类做错。用户三个月前说我喜欢喝咖啡。上周说我最近戒咖啡了。这两条记忆冲突了。很多团队的做法是新记忆覆盖旧记忆。但这会丢失信息——用户曾经喜欢咖啡这个历史事实可能对某些场景有意义比如分析用户偏好变化。### 更像真实现场的过程用户三月说我喜欢喝咖啡。Agent 存了 preference: coffee。六月用户说我戒咖啡了。Agent 覆盖了旧记忆存成 preference: no_coffee。七月用户问我之前的饮食习惯是什么。Agent 只能检索到戒咖啡但用户三月到六月之间的饮食偏好变化丢了。### 为什么会做错- 冲突时直接覆盖没有版本化- 没有记录从什么时候到什么时候有效- 没有保留历史版本无法回溯- 没有处理部分冲突——喜欢咖啡和戒咖啡不完全是覆盖关系### 真正该做的- 记忆要带时间戳和有效期valid_from / valid_to- 冲突时不是覆盖而是新增一个新版本旧版本标记为过期但不删除- 保留历史版本支持回溯查询- 对用户喜欢咖啡和用户已戒咖啡要理解为曾经喜欢现在不喝而不是简单覆盖- 查询时要结合时间——现在的偏好和历史的偏好是不同查询### 一句判断**冲突不要直接覆盖。记忆要版本化要能回溯要按时间查询。**---## 六、一个分层记忆架构会话状态 / 短期上下文 / 长期记忆 / 外部事实源如果要把上面这些做对最值得用的是分层记忆架构。把 Agent 的数据分成 4 层不要混在一条聊天记录里### 第 1 层会话状态Session State- 当前任务、执行步骤、工具调用状态、待确认事项、幂等键- 存在事务性状态库里不存成自然语言- 这一层是工作流推进到哪了### 第 2 层短期上下文Working Memory- 最近 N 轮原始消息 当前任务 scratchpad- 按时间滑动窗口保留- 这一层是当前对话在说什么### 第 3 层长期记忆Long-term Memory- 用户画像、稳定偏好、历史事件、事实、项目知识、经验教训- 写入前过滤、去重、冲突检测、版本化- 检索时按语义 时间 类型混合检索- 这一层是用户和 Agent 的历史### 第 4 层外部事实源Source of Truth- CRM、订单库、日历、文档库、业务数据库、工具 API- Agent 不靠记忆回答业务状态查权威系统- 这一层是事实在哪### 关键原则- **状态不等于记忆**——订单是否已取消查业务系统不查记忆- **原始事件可追溯**——记忆要带 source、timestamp、confidence、version- **记忆写入必须过滤**——不是每句话都存要做重要性判断和冲突检查- **检索要混合**——最近对话按时间读稳定偏好结构化查开放知识向量检索- **冲突不直接覆盖**——版本化处理按时间查询- **记忆是不可信输入**——模型不把记忆当指令执行要做安全校验这 4 层分开管Agent 的记忆才不会乱。混在一起就会出现状态记成记忆、噪音当成事实、幻觉存进去、冲突被覆盖的连锁问题。---## 七、把记忆当成不可信输入审计、纠错、删除、权限隔离最后强调一点记忆不是可信的。记忆会有过期、会有幻觉写入、会有提示注入、会有跨用户泄漏风险。如果模型把记忆当成可信输入直接执行就会出安全问题。### 真正该做的- **审计**每条记忆能追溯到来源哪个会话、哪一轮、谁说的- **纠错**发现错误记忆时能标记、修正、失效- **删除**用户要求删除时能彻底删除包括向量库里的向量- **权限隔离**不同用户、不同租户的记忆严格隔离不能跨用户检索- **安全校验**模型从记忆里取到的指令要经过策略校验才能执行把记忆当成不可信输入不是不信任记忆而是承认记忆有出错的可能。出错的时候能发现、能纠正、能控制影响范围。---## 八、结语Agent 记忆不是把聊天记录全塞回去。更长的上下文窗口没有解决记忆问题只是把问题延迟了。真正能跑起来的记忆系统需要分层管理- **会话状态**工作流推进到哪了查状态库- **短期上下文**当前对话在说什么按时间窗口保留- **长期记忆**用户画像和偏好写入过滤、版本化、可检索- **外部事实源**业务状态查权威系统长期记忆最容易做错的 4 件事- 把所有对话记录向量化后永久保存- 状态和记忆混在一起- 记忆写入不过滤- 冲突直接覆盖这 4 件做错了记忆系统会越来越脏最终拖垮 Agent 的效果和安全性。对技术团队来说做 Agent 记忆最该先建立的不是能记多少而是**什么该记、什么该忘、什么时候记、什么时候用、怎么检索、怎么纠错。**把记忆当成不可信输入分层管理Agent 才能在长期运行中保持稳定。