1. 先说结论Agent 记忆真正的瓶颈卡在“编码”那一刻如果你搭过带记忆能力的 Agent 系统可能会有一种很拧巴的体验向量库加了Embedding 接口调通了语义检索的 Top-K 也设好了测几个案例觉得“记忆还挺聪明”可跑上一段时间后就发现——它记住了一堆没用的东西需要的时候却想不起来甚至还会把旧信息当成新事实给你编出一个错得离谱的答案。这个问题我琢磨了很久。一开始我也以为是“存”出了问题是不是该用更好的索引后来又怀疑是“取”出了问题要不要换更强的重排序模型折腾一轮后我才反应过来——真正的坑根本不在两端而在“记进去的那一刻”。也就是说一条信息从原始对话流入记忆库的瞬间Agent 到底基于什么做决定决定了这个记忆系统最终是聪明还是摆设。把 Agent 记忆拆成“记—存—取”三段来看。存本质上是分块、向量化、写入数据库工程上已经非常成熟只要选型不太离谱基本不会出大乱子。取本质上是检索、重排序、拼装上下文虽然有一些调优空间但整体流程也是标准化的。真正没有任何标准答案的部分是“记”什么时候记、记什么、记多细、以什么形式记、怎么和旧记忆合并。这每一个子问题都直接影响“存”和“取”的上限。这就像一个人记笔记。给你一个无限大的硬盘也给你一个关键词搜索工具但如果记笔记的时候只是把整段对话原文丢进去既不分类也不筛选回头搜索时你大概率什么都找不着。“存”和“取”决定了你找东西的效率而“记”决定了你丢进去的东西到底能不能被找到、能不能被用上。这篇文章我想把“记进去”这一步拆开说说为什么它才是整个记忆系统的命门以及我在实际项目中是怎么重新设计这步流程的。2. 为什么“记进去”这么难“记”不是动作是一串决策2.1 “记”字背后藏着四个决策点很多人觉得“记”就是调一次接口把文本和 embedding 存进去。但这只是存储动作不是记忆决策。一个真正合理的“记进去”流程至少要在极短时间内完成四次判断第一次是判断“要不要记”。用户在对话里说的每句话并不是都能成为长期记忆。绝大多数内容是一次性指令比如“帮我查一下明天的天气”记下来没有任何意义。哪些信息值得沉淀为长期记忆这就是第一层筛选。第二次是判断“记成什么样”。一条原始对话里往往混杂着事实、意图、情绪、临时状态等多种信息。你不可能把整段原文都塞进去因为那样检索时噪声太大。必须做信息切分——这一段是对客观情况的描述那一段是用户表达的个人偏好另一段是尚在推进中的任务状态。不同类别适用不同的表示方式。第三次是判断“记到多细”。同样一个事实可以记成“用户喜欢简约风格”也可以记成“用户在2024年6月的一次对话中提到他喜欢简约风格的家装尤其偏好原木色和白色搭配”。太粗会损失可用细节太细会增加检索和整合的负担。粒度怎么取和你要用这个记忆的场景强相关。第四次是判断“怎么融入旧记忆”。新记忆不是孤立放进数据库就完事了它要么会和其他事实产生关联要么会和旧记录冲突要么应该替代旧版本。如果这一步不做记忆库很快就会变成一袋互相矛盾的信息碎片。这四次判断才是“记进去”的本质。存储接口只是一个执行末端真正的智能发生在写入之前。2.2 “存”与“取”是标准和流程问题“记”是语义问题为什么大家做记忆系统时会下意识去优化“存”和“取”因为这两端是纯粹的技术问题更可控。存得慢就缓存检索不准就换向量模型取了太多噪声就做重排序。这些都是有现成工具、有明确评价指标的问题调起来有反馈看得见效果。但“记进去”不是一个技术问题而是一个语义判断问题。它要求 Agent 理解当前对话的语境理解用户的表达习惯理解这个信息在未来可能的复用场景。你没法用一个通用的模板解决“这条信息重不重要”的判断因为重要性本身就是相对于具体任务、具体用户和具体时间窗口而言的。想象一个客服 Agent。用户在对话里提到“我明天要去机场接人希望能提前提醒我”。这句话里“明天要去接人”是一个有时间窗口的事件过了那一天就没用了“希望提前提醒”是一个服务偏好值得长期记住“机场接人”则是一个几乎不带长期价值的情境信息。如果这三层没有被区分开来全部混在一起存进去结果就是等真到了第二天Agent 可能想不起该提醒或者半年后还会在某个无关对话里莫名其妙地“提醒”用户接机场面非常尴尬。我见过一个团队踩过类似的坑。他们给一个会议纪要和任务追踪类的 Agent 加记忆系统开头只做了“原文分块向量化存储”效果很差每次开会内容越多后续的问答准确度反而越低。后来他们做了一层轻量的事件抽取把会议记录拆散成“结论”“待办”“决策原因”“人名关联”几类再入库效果立刻好转了。这个案例非常典型——存和取的代码一点没变只是改写了“记进去”的逻辑整个系统就从混乱走向了可用。2.3 “编码偏移”会把误差传递到后续所有环节我习惯把写入端的质量损失叫“编码偏移”。一旦信息在写入时发生了偏移——比如把一次性的临时状态错记成了长期偏好或把关键约束信息压进了一段噪声很大的上下文里——那么后面所有工作都会基于这个错误的编码展开。“存”端能做的只是忠实保存你给它的结果。如果你给了它一段极其混乱的文本它就只能把混乱向量化存成一个看起来很规则但其实内容很差的东西。“取”端就更冤了它只能按相关性挑出最像的几个片段如果写入时根本就没把关键信息单独切出来那任你重排序再精准它在原始数据库里也捞不到正确结果。所以记忆系统的问题从来不在末端而在源头。源头一旦歪了下游再怎么优化都只是努力放大一个有缺陷的信号。3. “记进去”那一刻到底该做什么四个核心动作拆解3.1 动作一把原始信息切分成类型明确的记忆单元流水账式地把整句对话存进去是最省事也最不明智的做法。我在实际项目里给写入流程加了一个前置步骤——把输入内容拆成几类固定格式的记忆单元。第一类是“事实”。比如“用户当前工作所在地是上海”“项目X的上线时间定在6月30日”这类信息是客观且相对稳定的适合存成结构化实体或三元组。第二类是“偏好”。比如“用户习惯在报告里使用数据图表”“比起视频用户更喜欢先看文字方案”这类信息表示了用户的偏好模式长期有效应该单独归类。第三类是“事件”。比如“3月20日用户和某供应商开过一次会初步确定合作意向”这类信息有明确的时间窗口过期之后基本失去价值。第四类是“状态”。比如“当前正在处理客户A的合同修订等待对方法务反馈”这类信息是任务推进过程中的中间状态随着任务结束就需要被标记为完成或直接失效。在代码层面我不建议在写入流程里塞一个巨复杂的抽取模型。对大多数场景用一条结构完整的 Prompt 让通用大模型先做分类和抽取再落库效果就已经足够稳定了。我在多轮迭代后倾向这样定义# 伪代码记忆写入前的信息抽取 MEMORY_EXTRACT_PROMPT 你是一个记忆管理器。请把以下对话内容拆分为记忆单元并标注类型。 类型定义 - FACT: 客观事实长期有效 - PREFERENCE: 用户偏好长期有效 - EVENT: 事件有时效窗口 - STATE: 当前任务状态任务结束后失效 对每个记忆单元输出为 JSON格式如下 {type: FACT, content: 用户工作所在地是上海, time_from: null, time_to: null} {type: EVENT, content: 3月20日与供应商初步确定合作意向, time_from: 2025-03-20, time_to: 2025-03-21} 对话内容 {conversation} 如果有人觉得“多了一步大模型调用会不会太重”我的经验是记忆写入是异步的它不需要像对话响应那样毫秒级完成。一次几百毫秒的抽取换来的是检索阶段从“大海捞针”变成“按类别点名”这笔开销值得。3.2 动作二判断“值不值得记”——重要性筛掉大部分噪声拆完类型后下一个问题是每条单元都能进长期记忆吗肯定是不能的。如果每条都进记忆库的噪声会迅速淹没信号丢了记忆系统的意义。我自己会维护一个非常简单的评判框架三个问题快速过一遍第一问未来还用不用得上一条“用户今天心情不好”的状态可能只对当前对话有影响转天就不值得再考虑了。而“用户对配色有明确偏好”这种信息几乎会在每一次设计方案对话里复用必须沉淀。第二问不记这条信息的代价是什么想象一下如果为了这句话在未来的某个场景里需要 Agent 重新向用户问一遍这个代价到底是“轻微的多问一句”还是“让人烦躁的反复确认”。代价越大越值得记。第三问这条信息会不会在短期内自动失效如果会就不该进长期记忆而应该进短期缓存或者会话状态。这套标准帮我把很多低价值信息挡在了门外。我见过不少系统记忆库疯狂膨胀几个月后已经塞了十几万条向量但真正要问的时候检索 Top-K 里前几条几乎全是废话。原因就是当时觉得“反正都存进去总有一条能用上”。事实证明这种想法只会让每条都不可用。如果你不确定某条信息该不该记可以先用一个保守策略宁可少记不要滥记。少记只是丧失一些便利滥记则会系统性摧毁检索精度。记忆库的第一原则是“纯度”而不是“体量”。3.3 动作三决定“记成什么样”——表示方式决定了未来的检索上限同一句话可以有完全不同的存储表示而不同的表示会直接决定将来能不能被检索出来。比较常见的表示方式有几种。一种是原文摘录好处是信息保真度最高不会因为改写丢失细节坏处是容易带噪声而且口语里的指代词、省略句会让孤立片段变得难以理解。另一种是重写归纳让模型把原文改写成一段结构清晰、脱离上下文也能单独理解的中性描述。比如原始对话是“对就那个蓝色的上次看的那个风格就挺好”重写归纳后可以是“用户认可上次沟通过的蓝色主题设计风格”。这种形式明显更适合入库——毕竟未来检索时你没法保证带上当时的上下文。第三种是结构化三元组适合事实类信息像知识图谱一样用“主谓宾”表达。比如“用户-偏好-蓝色主题”“项目X-上线日期-6月30日”。好处是抽取关系很容易做合并与去重坏处是表达能力有限处理模糊的、非事实类的记忆时非常吃力。最后一种就是常见的向量表示但它更适合作为检索手段而不是存储本体我是把它叠加在以上几种表示之上用的。我建议的组合拳是正文用重写归纳后的文本关键实体用结构化字段单列向量只作为检索索引。这样的话既保证了检索灵活性又保留了语义完整性还方便做实体的关联合并。3.4 动作四把新记忆“嵌入”旧记忆的网里而不是扔进去就完了“记进去”的最后一步不是写入数据库而是让它和已有记忆形成一张可用的网。不管用不用知识图谱技术你至少应该在逻辑上完成三件整合动作。同实体合并。如果新记忆里提到的主体在既有记忆里已经出现过那就应该把新信息挂接到那个既有的实体节点上而不是另起炉灶再造一个。否则同一个用户、同一个项目会被拆成好几份孤立记忆取的时候只能靠运气命中。旧信息过期处理。如果新记忆中提到的某个事实和旧记忆冲突比如用户已经搬家了旧记录还写着旧地址那么旧记录应当被执行过期标记而不是保留两条并陈的矛盾记录。我在系统里会给每条记忆维护一个状态字段被新信息取代的旧记录不会物理删除只是进入归档区避免后续检索到过时版本。冲突消解。当两条记忆内容不一致时需要有一条规则决定谁生效。我的默认策略是新信息优先于旧信息精确信息优先于模糊信息用户主动修正优先于 Agent 推断。实际运营下来这套优先级能解决大多数冲突场景。经过这四个动作一条信息才算真正“记进去”了。你可能会发现这套流程本质上是在做一个微型知识管理而不是简单堆一个数据库。4. 实操记录我给 Agent 重写“记进去”流程的全过程4.1 这次实践要解决的业务背景与重写目标当时我们团队接了一个面向企业客户的多 Agent 协作系统。这个系统的使用场景是客户内部的运营人员每天会和多个 Agent 协作处理项目推进、文档整理、竞品分析等内容。Agent 需要记住客户的行业背景、产品情况、沟通偏好、过往结论等信息以便在后续对话中提供不重复、有连续性的协作体验。最开始的版本大家的注意力都在“检索”上。我们实现了 RAG 流程把聊天记录直接切块、向量化、存进向量库然后每次对话前检索相关历史记录作为上下文。跑了一个月后用户的普遍反馈是“感觉你们这个系统记忆力时好时坏”“有时候它记得特别清楚有时候它连我说过什么都忘了”最要命的是“它有时候会把很早就已经过时的事情当成现在的状态还一本正经地来问我”。这些反馈给了我一个非常明确的信号问题出在写入端。信息记成了一团乱麻取的时候自然一团乱麻。于是我做了一次整体重写目标有三个第一从源头上对信息分类第二建立起“一次信息与长期记忆”的分离机制第三让记忆有生命周期能更新、能过期、能合并。在重写过程中存和取的代码几乎原封未动动的全是写入前的处理逻辑。4.2 一次信息与长期记忆的彻底分离在旧系统里所有对话内容都进同一个库检索时只能靠相似度硬扛。重写时我加了两个独立通道短期记忆区保存的是当前会话内有用的信息。比如“用户正在阅读方案第3页”“刚才已经确认了预算范围在30万以内”“刚刚给用户发过一个下载链接”。这些信息只对当前对话有意义一旦会话结束就可以丢弃或压缩。因为它们不需要做长期语义索引这部分只存原始文本和时间戳。长期记忆区保存的是跨会话仍有效的信息。比如“客户的决策委员会有3个人其中一个偏好财务视角”“客户所在行业近半年在密集做数字化转型”“用户明确表示不希望收到过于频繁的推送”。这些内容需要经过 3.1 到 3.4 的完整写入流程再进入结构化存储。这个分离带来的收益立竿见影。短期区帮助 Agent 维持当前对话的连贯性长期区则提供了跨会话的稳定知识背景两者不再互相污染。以前短期状态混在长期记忆里经常在后续对话中错误触发分离后这个现象几乎消失了。4.3 用“记忆预算”约束写入而不是放任信息涌入库中长期记忆的另一个问题是无限制膨胀。我在系统里引入了一个简单但有效的约束——记忆预算。每个用户每条独立的记忆单元都有大小和条数的限额。超过预算的新记忆必须先淘汰旧记忆或者和新记忆合并才有资格写入。这个设计看起来有点违反直觉——记忆不是越多越好吗但你换一个角度想Agent 每次对话前能塞进上下文的 token 量是有限的检索回来的上下文窗口也是有限的。如果记忆库里塞满了低价值信息真正有价值的信息反而没有位置。记忆预算的本质是强制要求记忆库保持高信息密度。实践中的操作方式是给每条长期记忆打了重要度评分与最后访问时间。当记忆总数超出阈值时会优先淘汰那些“重要度低且长时间没被访问过”的记录。这套机制运行久了记忆库就会自动沉淀出真正常用的内容。4.4 效果对比同一套“存”和“取”结果完全不一样重写后的系统上线之后我做了一组对比测试。先选了一些典型的旧案例分别让旧流程和新流程处理然后跑同样的检索问题。有一个对比特别能说明问题。旧流程中系统在初次对话后记住了这样一条信息——“用户提到大家对现有的报表工具不够满意”。这句话孤立存在没有任何前后文。后来用户问到“上回说的那个报表工具的问题你觉得根子在哪”旧流程检索出来后把这句话塞进去但答案依然显得很空因为它没有一个完整的上下文支撑。新流程下同样的对话内容被切分成了几条记忆单元“用户团队在用报表工具B”“用户团队认为报表工具B的导出速度慢”“用户期望新系统能替代报表工具的导出功能”“用户提到的报表问题与数据权限配置有关”。这几条事实被单独存入长期记忆区并和“用户所在团队”这个实体做了关联。再次检索时系统拿到的不是一个孤立句子而是一组相互关联的信息网回答质量直接上了一个台阶。存取的代码没有变变的只是“记进去时”的信息处理方式。这个对比让我彻底确认了记忆系统的智能上限在写入端就已经注定。5. 写入端的常见问题与排查技巧实录5.1 问题一记了等于白记——检索结果经常为空这类问题十有八九出在写入时的表示设计上。我排查过的一个典型案例是系统存的是对话原文的长向量提问时用的又是简短的自然语言两者在语义空间里的距离被拉得很远检索 Top-K 常常为空。解决办法是在写入端先生成一组“检索友好型”的改写文本把口语化的、带指代的表达转换成完整的中性描述。改写后的文本和用户提问的语义距离就小多了。排查这类问题时先确认的不是检索参数而是记忆库里的文本有没有做到“脱离上下文也能读懂”。5.2 问题二旧记忆和新事实互相打架这是另外一个高频坑。用户一开始说“我们优先考虑降低成本”过了两周改口说“现在成本不重要时间最重要”。旧系统会同时保留两条记录检索时两条都进上下文Agent 就会得出一个自相矛盾的回答。排查时我习惯先看记忆生命周期。我之前定的更新规则是新信息进入时先把同实体的旧记忆标记为“已过期”或“已被取代”再写入新版本。实际用下来自相矛盾的问题解决得很彻底。5.3 问题三记忆太多上下文被污染还有一类问题不是记不住而是记了太多没用的东西。打开上下文一看检索回来的五条记录里三条是噪声一条是错把旧状态当新事实的低效信息。上下文窗口再大也经不住这么浪费。解决思路是两处同时下手。一处是写入端的预算控制削减无用记忆的存量。另一处是提高检索端的门槛——提高 Top-K 的相似度阈值宁可偶尔漏掉一条相关记忆也不要反复用噪声污染答案。这个平衡在系统里的表现是对准确率要求高的项目把阈值调高对发散性要求高的场景把阈值放宽。5.4 独家技巧设计一个简单有效的“回读测试”我分享一下自己用的一个有效小技巧——回读测试。它不需要什么复杂工具只是个思维习惯每当系统写入一批新记忆时提醒自己做一个假想场景如果未来某个时刻用户问到这个信息检索词大概长什么样然后拿这个检索词去实际测试看能不能从库里把这个记忆捞出来。捞不到说明写入时对这条信息的编码方式不够友好应当调整后再写入。做记忆系统的这几个月我最大的体会是不要迷信“先存后取”的工程直觉。记忆的智能不在数据库里不在索引参数里而在信息被写进去的那一刻。那一次小得几乎看不见的取舍判断决定了这个系统最终是聪明的还是笨的。如果你手头的 Agent 也出现了“记了像没记”的症状别急着换库、换模型先把“记进去”这一步拆开审视一遍。大多数时候真正缺的不是存储容量和检索能力而是从对话到长期信息之间的那层设计与判断。