做 Agent 做了大半年我最大的感受是模型能力已经不怎么卡脖子了真正卡脖子的是“记忆”。你看各家模型厂商拼命把上下文窗口从 8K 干到 128K、200K、1M好像只要窗口够大Agent 就无所不能。真到了生产环境你会发现窗口越大问题越大——用户多聊几轮或者接了几份长文档Agent 要么漏掉关键信息要么被上下文里的旧结论带偏甚至把两个互相矛盾的事实同时当作依据输出。这个问题靠堆参数是堆不出来的得换思路。我在两个真实的 Agent 项目里陆续落地了一套“记忆层”——把模型要用的长期记忆从上下文窗口里拆出去单独做抽取、整合、存储、检索四个环节。今天这篇就把整个设计和踩坑过程完整盘一遍聊聊为什么大上下文窗口解决不了问题以及记忆层每一环到底怎么落地。内容偏实战适合正在做 Agent 应用、知识库问答、自动化工作流的朋友也适合那些被“RAG 效果差”“上下文不够用”折磨过的人。1. 为什么大上下文窗口救不了你先说结论上下文窗口本质是“工作记忆”不是“长期记忆”。你让人记住一整本会议记录再回答“上周定了哪些待办”效果一定不如给一份整理好的会议纪要和待办清单。大模型也一样窗口再大它也只是“看了一遍原文”并没有真正把关键信息摘出来、整理好、放到一个随时能调用的地方。1.1 三个隐性成本token、延迟、注意力稀释第一个成本是钱。所有主流模型的计费都按 token 来把几千轮对话历史全部塞进窗口每次请求都在为历史买单。我算过一笔账一个日活 1000 的中频 Agent平均每轮对话携带 30K token 历史一天大概要消耗几千万 token。单看单价不贵放大到集群和生产环境成本直接翻好几倍老板的脸色也跟着变。第二个成本是延迟。输入 token 越长首字延迟就越明显。实测同一模型16K 上下文的首 token 延迟大概是 300 毫秒塞到 128K 以上直接翻到 1.5 秒开外。用户不会管你这是因为“历史信息多”他只觉得你的 Agent 变笨变慢了。第三个成本更隐蔽叫注意力稀释。“Lost in the Middle”这个现象已经被很多人复现过模型对长上下文中间位置的内容记忆效果明显差于开头和结尾。把一万行聊天记录全塞进去模型看到后面的用户问题时注意力早就被前面那些“上上周说过的话”“某次失败的工具调用报错”“用户随手发的表情包”分散掉了。关键约束条件反而成了少数派模型自然容易忽略它们。1.2 上下文污染比信息缺失更可怕信息缺失你还能察觉上下文污染是悄悄发生的。什么意思就是同一段历史里既有用户早期说的“我预算控制在 5000 以内”又有中期改口的“预算提到 15000 了”你全塞进窗口模型看到两个互相矛盾的约束它有概率选错那一边。做过 Agent 的人都知道这种错误极难复现——不是每次都错是带着旧信息干扰时偶尔错一次排查起来非常痛苦。另外闲聊和任务信息混在一起也是大问题。用户的原始对话里有大量噪音比如“今天天气不错”“这个按钮颜色好丑”这些对当前任务毫无价值但塞进窗口后模型不得不处理它们。我把这些现象统称为“上下文污染”不是上下文太少而是上下文太杂导致模型抓不住重点。1.3 人脑早就给了我们参考答案认知科学里有个经典概念叫工作记忆容量大约只有 4 到 7 个组块但它并不妨碍我们处理复杂任务。原因在于人脑有另一套系统——长期记忆容量近乎无限平时不占注意力只有需要时通过线索提取。你去咖啡店点单不会把十年前所有喝过的咖啡配方都调出来只会调用“今天想喝什么”和“这家店有什么”这两条相关信息。Agent 记忆层就是在做这件事让模型不再依赖把全部历史塞进窗口而是用一套外部系统决定“该记什么、怎么存、什么时候取”。上下文窗口未来就算做到 10M它解决不了“记忆的组织、更新、遗忘、检索”这些问题——这就像把仓库扩大一百倍不等于你每次都能快速找到需要的那把扳手。方向对了后面四件事才有意义。2. 记忆层四环节的整体设计思路记忆层不是单个组件而是一条流水线。我拆成抽取、整合、存储、检索四段每一段解决一个问题它们之间咬合紧密。你可以先把它理解为“人脑记忆的形成和提取过程”抽取从眼前发生的事情里挑出重要信息整合把这些信息跟已有的知识对上号消除矛盾存储分门别类放进不同的记忆仓库检索需要的时候把相关记忆快速找回来。2.1 四环节的闭环关系先看整体数据流。用户跟 Agent 对话原始消息进来后先做抽取识别出“用户偏好”“任务状态”“关键事件”等结构化信息抽取结果进入整合环节与已有的记忆条目做对齐、去重、更新然后统一写入存储层到下一轮对话检索环节根据当前问题从存储中召回相关记忆注入模型上下文让模型基于记忆做出回答回答结束后可能又触发了新的记忆抽取继续写回存储。这是一个不断循环的飞轮。很多团队在做记忆层时容易犯一个错误只做存储和检索不做抽取和整合。他们觉得“把对话历史存起来到时候向量检索不就行了”。这就是把记忆层做成了 RAG——没有结构化抽取向量库里存的就是原始文本检索出来的还是一片含混的信息。更麻烦的是没有整合环节同样的用户偏好被存了 100 条变体检索时不知道怎么选。2.2 设计原则记忆不是越多越好我见过有人把记忆层做成“数据库垃圾桶”什么内容都往里塞理由是好歹能兜底。结果系统上线后检索召回全是一堆噪音Agent 反而被自己的记忆干扰得严重。做记忆层的第一原则是克制。每一类记忆必须回答一个问题如果缺了这条记忆Agent 的行为会有什么不同如果没有不同这条记忆就不该存。按这个标准用户的一次性请求、临时闲聊、过期状态都可以直接丢弃或压缩。第二个原则是区分记忆类型。我在项目里通常分成三类情景记忆记录发生过什么事件比如“用户上周要求改版登录页”语义记忆记录用户稳定的偏好和知识比如“用户倾向于简洁风格”“公司内部业务系统叫 EAS”任务记忆记录当前任务执行到哪一步比如“正在生成季度报表已完成数据清洗下一步是可视化”。三类记忆的特性完全不同后续的存储策略和检索权重也会因此分化。2.3 架构选型先用简单方案跑通闭环记忆层最容易踩的坑是过度设计。第一版就上 Neo4j Milvus MinIO Redis 全家桶光部署和联调就花了大半个月业务还没验证就想把工程做完美。我给的建议是分三步走第一步用最朴素的方式跑通闭环比如把所有记忆条目塞进 PostgreSQL 的表里检索就用简单的关键词匹配第二步验证记忆层确实能解决“上下文不够用”“信息污染”这些核心痛点再逐步替换组件第三步等数据量上来再按需引入向量库和图数据库。上面说的“整体闭环”和“跑通最小原型”其实就是我下面要展开的抽取、整合、存储、检索四件事。我先按工序把它们过一遍每一节里会给出相关的工具、参数、还有遇到过的坑。3. 抽取记忆的入口决定记忆质量的上限抽取是记忆层的第一个环节也是最容易被低估的一环。很多人以为“抽取嘛就是让 LLM 输出一段 JSON”但真正落地时会发现抽取质量直接决定整个记忆层的上限。入口进的是垃圾后面存储检索做得再精出来的还是垃圾。3.1 核心抽取对象实体、事件、偏好、任务状态我一般把抽取对象分成四类每一类都有不同的规则和目标实体抽取人名、公司名、产品名、项目代号、地名等。比如用户说“我们最近接了一个叫蓝海的项目”要能把“蓝海”识别为项目实体。事件抽取谁在什么时间、什么地方、做了什么、结果如何。例如“周五下午 3 点和陈总开会确定了登录页改版的方案”。关系抽取实体与实体之间的关系比如“蓝海项目的负责人是王磊”“王磊是陈总的汇报对象”。用户偏好与约束用户明确表达过的偏好、限制条件。比如“图标不要圆角的”“报告里少放折线图”“成本不能超过两万”。任务状态当前正在执行任务的推进状态。比如“已完成数据清洗正在做模型训练预计明天出结果”。其中“用户偏好与约束”最容易被漏掉。模型天然更擅长抽取名词性实体却容易忽略那些藏在语气里的偏好比如“这个我不太喜欢”“还是按上次那样吧”。我的做法是单独设计一组偏好抽取 prompt让模型专门关注这类信息不跟通用实体抽取混在一起。实测下来偏好抽取的准确率从 60% 提到了 85% 左右。3.2 抽取方案选型从 prompt 到专用框架这一步不像想象中复杂核心选择其实只有两个要不要用外部抽取框架要不要引入小模型做前置抽取先说你最先能上手的方案——纯 Prompt 抽取。我把每轮对话发给 LLM让它输出一段固定结构的 JSON包含实体、事件、偏好、任务状态几类字段。这个方案在小项目里完全够用。问题在于格式稳定性模型偶尔会多输出字段、key 名字大小写变化、甚至返回不合法 JSON。所以生产环境里一定要加 JSON Schema 校验和重试机制不能直接信任模型的输出格式。第二个方案是用函数调用或受控生成。比如用 OpenAI 的 function calling 或 Anthropic 的 tool use 来限定输出结构。这样做的好处是模型不会自由发挥输出天然符合预期。我在多数项目里都采用这条路线成本略高一些但省下的清洗时间更多。第三个方案是引入专用知识抽取框架。例如 OneKE 这类面向中文知识抽取的框架能把非结构化文本转换成知识三元组适合对抽取结构化程度要求较高的场景。这样做的好处是不需要频繁调大模型成本低但需要准备标注数据做微调或适配。如果你只做实体识别GLiNER 这类轻量模型也值得关注它比传统 NER 支持更多自定义类别标签无需重新训练非常适合记忆层里的快速实体抽取。这里有个重要的经验抽取不该只“抓新”还要“盯变”。用户后面说的话跟前面冲突了这本身就是一个值得抽取的强信号。我专门设计了一条“变更抽取”规则新消息里的信息如果覆盖旧记忆会生成一个preference_changed事件。没有这一步整合环节就没有输入记忆永远都是第一次说法的复制品。3.3 抽取质量评估精确率和召回率都要看抽取的质量评估不复杂但必须有。我的评估维度有三个精确率抽取出来的信息里正确信息的比例。精确率低记忆层里会混入大量错误信息Agent 会被带偏。召回率该抽取的信息里被抽到的比例。召回率低会导致某些重要信息被漏掉Agent 在后续对话中“失忆”。格式合格率抽取结果是否符合预期结构这是最基础的一关。我给过一个内部标准精确率必须保证 90% 以上不然错误记忆累积到一定量系统会变得肉眼可见地“不靠谱”召回率允许在 75% 到 85% 之间因为漏掉几条信息还可以靠检索兜回来但错误信息很难被兜住。实操层面还有一个容易被忽略的动作把抽取结果暴露给用户看。比如在某些界面里让用户确认“你的偏好已记录不喜欢圆角图标”。这不仅能提升用户对 Agent 的信任感更重要的是用户亲自修正的信息是记忆层里置信度最高的记忆。系统应该给这类记忆更高的检索权重。4. 整合从零散信息到可用知识抽取完的信息是碎片这一步要把碎片拼成一张“可用的知识网络”。很多人把记忆层做成了 log 存储缺的就是整合。整合要解决的问题是同一实体的不同表述怎么合并矛盾的旧记忆怎么处理重复的信息怎么去重以及记忆如何随时间更新。4.1 实体对齐与冲突消解先看实体对齐。用户可能在早期说“我们公司的 CRM 系统叫云客”过几天又说“云客上有个客户跟进的问题”。如果系统不能把“云客”对齐到同一个实体检索时就会变成两个分裂的片段Agent 就无法形成完整的理解。我在项目里用两种方式做对齐一是用 embedding 计算相似度比如“云客系统”和“云客”两个文本片段在向量空间里的距离足够近就认为是同一个实体二是维护一个实体别名表把“云客”“CloudCRM”“公司的客户管理系统”这些说法映射到同一个实体 ID 上。第一版建议用别名表因为它可控性强不会出现向量误判。冲突消解更麻烦。用户上午说“预算控制在 5000 以内”下午说“预算提到 15000”。这时如果系统不做消解两条矛盾记忆都会存下来后续检索时模型就不知道听谁的。我的默认策略是时间戳优先 置信度加权。后出现的记忆在默认情况下权重更高但如果早期记忆来自用户显式确认比如表单勾选而新记忆只是对话中顺口一提我会保留旧记忆并标记一个“待确认”状态在下一次对话里向用户询问。这套规则看着简单却能解决大量实际矛盾。4.2 去重与合并去重不只是删除重复文本这么简单。我处理过这样一个真实场景用户在多轮对话里反复强调“客户段总很在意响应速度”这句话分别以不同变体出现有的长、有的短、有的加了上下文。如果都存下来检索时会出现十几条高度相似的记忆。这时需要先做语义去重再合并为一条规范记忆比如“客户段总的核心诉求是响应速度”并把多次出现的频次记下来。这个频次是很有价值的信号——被用户反复强调的内容在检索排序时应该加重权重。我做聚合时还习惯把“零散陈述”升级为“结构化结论”。例如系统发现用户多次提到某模块的加载速度慢就要生成一条结论性的记忆“用户反馈报表模块加载速度偏慢已提过至少三次”。这比每次存一条原始抱怨更有利于 Agent 理解用户的真实意图。4.3 记忆更新与遗忘机制记忆更新的核心是“变化检测”。我在抽取环节会专门标记“与新信息不一致”的旧记忆整合时把这些旧记忆标记为 superseded已取代而不是删除。这样有两个好处一是保住历史证据链二是后续如果用户再次变卦系统可以追溯“你之前说改成深色现在又说改回浅色”从而判断用户是口误还是在反复摇摆。遗忘机制同样重要。我见过不少团队的记忆表无限膨胀最后变成了谁也不看的死数据。让人工智能遗忘不只有“删除”一种方式更聪明的做法是降采样和摘要化。我会对超过 60 天的细粒度事件做一轮压缩把多个事件合并成一条摘要比如“用户在过去两个月里多次调整首页 banner 文案累计修改七次”原文保留在对象存储里只在必要时翻出来看。这样既保住了记忆的完整性又控制了检索空间的规模。5. 存储三层架构与工具选型记忆层的数据存储不能只用一种方案。我在项目里采用三层架构向量库负责语义记忆图数据库负责关系记忆对象存储负责原始证据。三者各有分工又互相配合。5.1 向量库语义记忆的支撑向量库存的是记忆条目的 embedding解决的核心问题是“语义相似度召回”。用户问“上次说的那个登录页的问题”系统要把“用户反馈登录页按钮不好点”这条记忆映射成 1024 维向量再通过相似度计算找回来。这个环节有两个关键决策embedding 模型选什么向量数据库选什么。embedding 模型方面中文场景我推荐先用 bge-m3 或 m3e 这类本地模型或者 OpenAI 的 text-embedding-3-small 也可以。为什么强调本地因为记忆数据往往涉及用户隐私走云端 API 的话一是成本二是数据合规问题。实测下来bge-m3 在中文语义相似度上的表现不输给主流闭源模型部署也不难。向量数据库方面我实际用过的方案有三种方案优点缺点适配场景pgvectorPostgreSQL 扩展复用现有数据库部署简单事务能力强海量数据下性能一般小流量、MVP 验证Milvus / Qdrant检索性能强、支持复杂过滤、可水平扩展独立组件运维成本高中等以上规模生产环境ES 自带向量检索与全文检索天然整合适合混合检索向量性能不如专用库配置复杂已有 ES 体系的团队小项目我建议直接从 pgvector 起步数据量大了再往 Milvus 迁移。不要为了“技术先进性”一上来就上重装备。倒不是说这些组件不好而是运维复杂度和业务收益不成比例。5.2 图数据库关系记忆的支撑如果 Agent 需要回答“这个客户跟哪些项目相关”“王磊和陈总是什么关系”“上线失败影响了哪些服务”这类问题纯向量库就力不从心了。向量库能告诉你“这句话和哪段记忆语义接近”但它不擅长沿着关系路径去查询。这时要用图数据库我用最多的是 Neo4j。图数据库里存的是实体节点和关系边。举例来说用户说过“蓝海项目的负责人是王磊”“王磊汇报给陈总”“上个月上线事故跟支付模块有关”这些事实可以被建模成三个实体节点和两条关系边。当用户问“上线事故跟谁有关”时图查询能沿着“事故节点 → 关联模块 → 负责人”路径一步找到答案而向量检索做不到这种多跳推理。有人会问那是不是每个记忆都要进图数据库不是。图表达的是一种额外维度——关系。我只把“实体关系”放进图里比如人物、组织、项目、事件之间的关系。而那些描述性的、缺乏明确关系结构的记忆比如“用户喜欢简洁风格”放在向量库里就够了。盲目把一切塞进图库最后查询会复杂到你怀疑人生。5.3 对象存储原始证据与附件对象存储是整个记忆层里最容易被无视、也最该先部署的组件。我用 MinIO 或者阿里云 OSS 这类 S3 兼容服务专门保存原始文档、图片、音视频片段。为什么需要它因为向量库里存的是 embedding图数据库里存的是结构化三元组它们都是“加工品”。加工品会丢失原始信息如果用户在后续对话里要求“把当时那张截图拿出来我看看”没有原始证据就无法满足。更实际的一个场景是多模态记忆。随着图文检索的热度上升Agent 需要记忆的不只是“用户提了什么要求”还包括“当时看到的界面长什么样”。我现在的做法是原始截图存到 MinIO提取出的文字和视觉描述存到向量库同时记录 MinIO 的对象 key。检索时通过对象 key 把原始图片拉回来在前端重新渲染。没有对象存储做底层支撑多模态 Agent 基本做不起来。对象存储还要特别注意生命周期管理。我在 MinIO 里配置了分层规则近期文件在标准存储超过 90 天的丢到低频目录某些非核心会话的原文直接按天清理。不然存储成本会随着记忆只增不减最后变成比 token 费还高的一项支出。5.4 数据模型设计建议存储层的核心是记忆单元表。无论底层用什么库我建议统一抽象出以下核心字段字段说明memory_id记忆唯一 IDagent_id所属 Agentuser_id所属用户memory_type记忆类型偏好/实体/事件/任务状态content规范化后的记忆内容文本embedding内容向量在向量库中source_id来源对话或文档 ID指向对象存储confidence置信度0-1created_at创建时间updated_at更新时间statusactive / superseded / archivedrelated_entities关联实体 ID 列表这套结构我习惯先落在 PostgreSQL 里作为唯一事实源向量库里的数据定期同步图数据库只存实体关系。三个存储之间通过 memory_id 和 source_id 关联而不是各存各的一份全量数据。这样的一致性维护负担小很多排查问题时也只需要从一个主库出发。6. 检索让记忆在正确的时间出现存储做得再好检索不出来等于白做。这个环节的常见问题是要么召回结果太少关键记忆找不到要么召回结果太杂噪音淹没关键信息要么时机不对该检索的时候没检索不该检索的时候乱检索。6.1 混合检索向量、关键词、图路径三管齐下纯向量检索有个很尴尬的问题对精确数字、专有名词、ID 类信息完全不敏感。比如用户问“那个 code 是 X-2024-001 的项目”如果你只靠 embedding 去搜很容易搜不到。因为 embedding 擅长语义匹配但不擅长“精确匹配”。我在项目里用的是三路混合检索每一路解决不同维度的召回向量召回解决“意思相近但措辞不同”的问题关键词召回解决“包含特定专有名词、编号、符号”的问题图路径召回解决“沿着关系链找记忆”的问题。三路召回后再做融合排序。最朴素的融合方式是加权融合对每条候选记忆把三路得分做归一化后按权重相加。权重根据场景动态调如果是开放式提问“帮我看看项目目前有什么风险”向量权重高一点如果问题里有明确的实体名比如“蓝海项目”关键词和图路径权重就该提高。LangChain-ChatChat 里集成 Neo4j 做三路混合检索是一个很典型的组合网上资料也比较多可以直接参考。6.2 重排与排序让最相关的那条记忆排在前面粗召回往往有几百条直接全塞进模型上下文还是会有污染。所以我在粗召回之后加了一层重排用 Rerank 模型对候选记忆逐条打分取 Top K 注入上下文。开源的 bge-reranker、GTE-Rerank 都可用实测效果明显好于纯用 embedding 分数排序。排序阶段还要叠加几个业务权重。第一是时间权重如果记忆是三个月前的可以适当降权用户最近明确表态“以后不要圆角图标”这条记忆的权重就应该高于上个月的偏好。第二是置信度权重用户显式确认过的记忆 模型自动抽取的记忆。第三是记忆类型权重用户偏好的权重通常高于一般事件记录。把这些因素做加权排序结果才贴近实际。6.3 触发式检索与主动召回检索时机怎么定我见过最简单的做法是每轮对话都检索。但这样做有副作用每轮都注入记忆模型上下文依然会被不必要的信息填充而且首字延迟会变高。我最后的方案是“三级触发”对话开始时只做一次轻量级检索注入用户的长期偏好每一轮用户消息进来后判断是否需要事件型记忆或任务型记忆按需触发检索任务里程碑时比如用户说“下一步”“重新做”强制做一次深度检索把与该任务相关的历史决策、约束、结果全部拉出来。这个三级触发机制不是一次就能调好的需要结合用户行为和 Agent 任务特征反复调试。比较好的验证方法是做 A/B 对比开检索和关检索分别跑一轮测试集看哪边回答准确率更高。我自己的经验是很多 Agent 在“用户说‘重新做’”时最需要记忆层把上次的执行方案、失败原因、踩过的坑全部带出来这一种触发场景给方案带来的提升最明显。检索结果注入的方式也有讲究。常见有三种塞进系统提示词、作为 few-shot 示例、作为工具上下文。我的偏好是用户偏好类记忆塞系统提示词关键历史决策类记忆作为背景文本放在上下文中间靠前的位置既避免污染又确保模型能看到。大量“原始对话切片”我一般不直接注入而是先做摘要或提炼结论这比原样粘贴更符合记忆层“整合”的初衷。7. 常见问题与排查技巧实录这一节是回忆过去几个月踩坑的总结。每个问题都是真实发生过的附上排查思路和解决手法不一定普适但希望能帮你在调试时少走弯路。7.1 ES 向量检索太慢有用户反馈 Agent 响应时间大幅上升我排查后发现耗时集中在 ES 的向量检索上。常见原因有三个HNSW 图参数没调优单个 shard 的数据量过大向量查询和过滤条件耦合执行导致无法利用索引加速。我当时的处理方式是先把 HNSW 的 M 和 ef_construction 调高以换召回率再根据实际数据量增加 shard 数或改用专门的向量库。另外一个重要优化是“先过滤后向量检索”把同用户的记忆先按 user_id 过滤到一个小集合再做 ANN 向量检索。这比在大集合里一次性做向量检索再过滤快得多。实际上很多 Agent 的记忆天然有 user_id / agent_id 隔离属性这种预过滤操作应该作为默认策略。7.2 Dify 知识库检索效果差很多人反馈 Dify 搭的知识库检索不准我也踩过。做 Agent 记忆层时我没有直接用 Dify但排查逻辑是相通的。Dify 检索效果差通常和这几个点有关分段大小不匹配embedding 模型不匹配没有启用 rerank。我当时遇到的具体问题是文档分段采用固定 500 字符切分结果一个关键知识被拦腰截断检索时语义信息丢失。后来改为按章节标题和段落语义切分检索准确率立刻改善。另外摘要型问题和细节型问题需要不同的分段规模这个参数不能拍脑袋定要按你的语料类型和用户提问模式去试。Rerank 带来的提升尤其明显开启之后 Top K 命中率基本能提升 20 个百分点以上。7.3 记忆冲突与陈旧记忆引发错误回答最典型的场景用户已经改口说“预算提到 15000 了”Agent 还顺着旧记忆说“按照 5000 以内来安排”。这个问题的根源在于整合环节没做好——旧记忆没有被标记为 superseded新记忆又没有明显更高的权重。我最后的解法是两层存储层每次写入新记忆时做一次字段级冲突检测如果发现同类型、同主体的新记忆自动把旧记忆标记为 superseded并把旧记忆的 confidence 全部降为 0.2检索层给活跃记忆和已取代记忆设置硬过滤默认只召回 statusactive 的记忆。这样旧结论就不会再冒出来了。还得强调一点superseded 的记忆要保留不要直接删除因为用户很可能再次变化并需要追溯历史。7.4 记忆无限增长容量与成本失控记忆层上线三个月后我发现向量库的容量快爆了存储成本也在上涨。排查后发现存量数据里约 60% 是三个月前的低价值记忆比如用户随口提过的、一次性的事件记录。解决办法就是前文提到的遗忘机制定期把超过 30 天的细粒度事件降采样为摘要原始详情移到低频对象存储中向量库里保留摘要条目。这样既保证了核心检索质量又把向量库的容量控制在了一倍以内。这条经验后来成了我的默认规则任何记忆写入时都要带上tll_policy直接决定这条记忆该永久保留、90 天后摘要化、还是 7 天后清理。没有回收机制的记忆层本质上只是另一个垃圾堆。8. 一点个人体会做了这么久的 Agent 记忆层我越来越觉得这事的核心难点根本不在于某个组件多先进而在于你怎么定义“对一段对话来说什么东西才是值得记住的”。不同业务场景答案完全不一样。客服 Agent 要记住的是用户身份、会员等级、近期诉求数据分析 Agent 要记住的是数据口径、报表偏好、指标定义个人助理 Agent 要记住的是日程、偏好、关系网络。你没法拿一套通用的记忆模型通吃所有场景。我的建议是第一版记忆层别追求大而全先选出业务里最重要的两类记忆跑通“抽取 → 整合 → 存储 → 检索”的闭环让用户真实感受到“Agent 记住了我说过的话”再逐步加记忆类型。技术上能用 PostgreSQL 加一个向量字段解决的事就别先上 Neo4j 和 Milvus。等数据量和查询复杂度确实上来了再迁移也不迟。最后分享一个我认为性价比最高的习惯给每条记忆加一个来源引用字段存储时保留它来自哪条对话、哪份文档、哪个时间点。这个字段平时可能用不上但一旦发现 Agent 回答错误你能顺着来源引回去判断是抽取错了、整合错了还是检索错了。我在记忆层排查时靠这个字段省掉的时间绝对比当初加字段花掉的多几十倍。可以说这个字段是整个记忆层里成本最低、回报最高的一笔投资。