做过AI Agent项目的朋友应该都有过这种体验第一天测试的时候你反复告诉它你的偏好和技术背景它都能给出非常贴合的反馈第二天接着测它好像完全失忆了把前一天约定好的东西忘得干干净净。这个现象在业内被调侃为“金鱼记忆”它不是某个模型的个例而是所有Agent在走向生产环境时都必须跨过的一道坎。这一篇是“走进AI Agent”系列的第三篇主题就一句话让Agent记住你。我会把记忆这件事完整拆开——记忆分哪几种、底层架构怎么设计、用向量数据库怎么落地一套可用的记忆系统以及记忆管理、隐私安全这些实操中绕不开的坑。不管你是刚上手Agent开发的工程师还是正在规划智能助手的产品经理这篇内容应该都能给你提供可以直接拿走的方案。1. 为什么AI Agent需要“记住你”1.1 没有记忆的Agent就像每天重置的记事本先还原一个真实场景。假设你要做一个企业内部的智能客服Agent员工每天都会问“年假还剩几天”“报销流程怎么走”。如果Agent没有记忆它每次都要反复确认“请问您是哪个部门的”“您之前问过这个问题吗”。这种体验在第一次用的时候可能还能接受但连续使用一周之后用户内心只剩一个感受这东西就是个带对话界面的搜索框。技术的核心痛点在于大模型的上下文窗口是有限的而用户与Agent的交互不是一次性买卖它是一段持续的关系。这就好比一个真人助理如果每次见你都问“你好我是谁”你一定会怀疑他是不是脑子不好使。Agent也一样没有记忆就无法在时间维度上形成连续性而连续性恰恰是个性化服务的基础。从工程角度看没有记忆还会带来一个很实际的问题重复劳动。用户每次都要重新描述需求Agent每次都要重新理解上下文这不仅浪费用户的耐心还成倍消耗Token费用。我之前做过一个粗略统计在完全没有记忆设计的Agent里大约有30%到40%的Token开销用在了重复澄清和重新理解用户意图上。换句话说把记忆做好对成本优化的贡献可能比换一个更便宜的模型还要直接。1.2 记忆是Agent从工具走向助理的分水岭目前市面上大多数Agent严格意义上只能算“工具”而不是“助理”。工具的特点是你给我输入我给你输出我们之间没有历史关系。助理的特点是我了解你的习惯、懂得你的偏好、知道你过去做过什么决定并能基于这些积累主动给出更合适的建议。举个例子同一个Agent无记忆状态下你问“帮我安排明天上午的会议”它只能机械地把会议加到日程里。有记忆状态下它知道你是晨型人知道你的重要合作伙伴通常需要提前一天收到会议邀请知道你过去不喜欢把会议安排在周三上午——这些私有信息综合起来它给出的安排就会明显更贴合你的工作习惯。这就是我对“助理”这个概念的朴素理解。记忆能力还直接决定了Agent能不能完成多步骤的复杂任务。一次任务往往不是一轮对话能搞定的中间可能隔了几天可能穿插了用户临时插入的其他问题。如果Agent每次只能看到当前这一轮输入它就永远无法真正理解“整体目标”。只有当它记住任务的上下文和阶段性结果才能像人一样把一个长周期的事情持续推进下去。1.3 记忆设计需要回答的核心问题给Agent设计记忆本质上是在回答三个问题记什么、怎么存、怎么取。“记什么”涉及信息筛选策略不是所有对话都值得记要识别出那些对后续交互有长期价值的用户偏好、事实和决策“怎么存”涉及存储选型是放Redis做短期状态还是放向量数据库做语义检索“怎么取”则涉及召回策略当用户发来一段新消息时如何从记忆库中精准捞出最相关的那部分内容而不是把一大堆无关记忆一股脑塞进上下文。这三个问题缺一不可。只解决存储不解决筛选记忆库会迅速被噪声淹没只解决取不解决存就等于没有记忆。后面我会围绕这三个问题逐个展开把整套设计思路和代码实现完整过一遍。2. 记忆的分类别把“记住”想得太简单2.1 短期记忆上下文窗口里的“即兴表演”短期记忆最直观的形态就是大模型的上下文窗口。你发一条消息模型在这条消息之前看到的所有对话历史就是它的短期记忆。这个记忆的特点是快、短暂、容量严格受限。在工程实现上短期记忆通常由Agent运行时框架自动维护比如LangChain里的ChatMessageHistory或者自己维护一个messages数组。问题在于如果把所有历史都无脑塞进去上下文窗口很快就会爆。以GPT-4等主流模型为例即使提供了很大的上下文窗口当历史消息数量超过一定阈值后模型对早期内容的关注度会明显下降出现所谓“迷失在中间”的现象。所以短期记忆也需要管理。最简单的方式是滑窗裁剪只保留最近N轮稍微讲究一点的做法是摘要压缩把早期的对话内容用模型提炼成一段摘要作为新的上下文元素参与后续推理。两种方式各有优劣滑窗实现简单但会丢失早期关键信息摘要压缩效果好但会引入额外的一次模型调用。我个人的经验是在对话轮次不超过20轮时优先用滑窗超过之后再用摘要压缩兜底。2.2 长期记忆从“会忘事”到“有积累”长期记忆要解决的是跨会话、跨天甚至跨月的持久化问题。用户今天告诉Agent“我习惯喝美式咖啡”这个信息如果不落到长期存储里明天Agent就会忘掉。长期记忆的载体通常是外部存储系统它需要对Agent来说像一个外挂的人脑海马体。在设计长期记忆时最关键的一点是要区分“事实型记忆”和“交互型记忆”。事实型记忆是用户的静态属性和偏好比如“用户叫张三坐标上海工作是后端开发”这类信息变化频率低适合用结构化的方式存储和更新。交互型记忆是用户与Agent之间发生过的历史交互记录比如“上周二用户咨询过数据库迁移方案最后选择了TiDB”这类信息更适合用非结构化文本保存并通过语义检索的方式按需召回。很多人在刚开始做Agent记忆时最容易犯的一个错误就是只设计了短期记忆以为上下文窗口够大就能解决一切。实际上只要Agent的使用周期超过一天长期记忆就不可避免它是Agent从“能用”走向“好用”的关键基础设施。2.3 参考人脑的三种记忆类型为了更好地理解Agent记忆的分工我们可以参考认知科学里对人脑记忆的一种分类方式语义记忆、情境记忆和程序性记忆。语义记忆对应的是“用户是谁、世界是什么样”的事实性知识比如用户的姓名、职业、兴趣爱好。这类记忆的特点是通用、稳定适合用键值对或结构化数据库来保存。情境记忆对应的是“某个时间、某个场景发生了什么”的经历比如“上周五用户让我帮他写过一封辞职信”。这类记忆带有明确的时间属性和场景属性适合用文本记录加元数据比如时间戳、会话ID来保存。程序性记忆对应的是“怎么做一件事”的步骤和技能比如Agent学会的“当用户提到方案评审时必须附上风险清单”这类记忆往往是Agent根据用户反馈动态积累的规则。把这三类记忆分清楚最大的好处是便于确定各自的存储方案和更新策略。语义记忆用结构化存储情境记忆用向量检索程序性记忆用规则模板。这比我刚开始做时把所有内容一股脑塞进同一个向量库要清晰得多。3. Agent记忆系统架构一条主线串起整个流程3.1 记忆系统的四个核心模块一套完整的Agent记忆系统我会拆成四个层来看感知层、存储层、检索层和应用层。感知层负责从用户的对话中识别出值得记住的信息。它既可以是规则驱动比如匹配“我喜欢”“我习惯”“记得”等关键词也可以是由模型驱动用另一个Prompt让LLM来抽取关键信息。存储层负责把提炼出来的记忆落到物理存储中比如用户画像落到MySQL或PostgreSQL对话片段落到向量数据库。检索层负责在用户发起新请求时从存储层中找出最相关的记忆内容返回给Agent。应用层则负责把检索到的记忆与大模型本身的上下文组装在一起生成最终的Prompt。这四个层之间的关系是自下而上的依赖关系感知层负责输入存储层负责沉淀检索层负责召回应用层负责使用。很多Agent项目做不好记忆问题往往出在感知层——“什么都想记”或者“什么都没抽出来”。3.2 存储方案选型从Redis到向量数据库记忆存储的选型取决于记忆的类型和访问方式。下面我整理了实践中比较常见的选择方便你对比参考。存储方案适用记忆类型核心优势主要限制推荐场景Redis短期状态、临时变量读写快、支持TTL过期无语义检索能力会话状态、Token计数MySQL/PostgreSQL用户画像、事实型记忆结构化查询、事务一致不支持语义相似搜索用户属性、偏好配置pgvector事实型语义型混合兼具SQL和向量索引需要结合PostgreSQL使用中小规模项目Chroma/FAISS情境记忆、对话片段轻量、本地部署简单运维能力较弱个人项目、原型验证Milvus大规模对话记忆分布式、高并发部署运维成本较高生产环境大规模使用从我的实操经验看选型没有绝对的“最好”只有“够不够用”。如果你的Agent主要做单机部署、用户量在千级以下Chroma或FAISS完全够用如果是要支撑上万用户同时在线且记忆量会持续膨胀那还是早点上Milvus或云上的向量数据库服务比较稳妥。另外一个比较讨巧的方案是直接用pgvector把关系数据和向量数据都放在同一个PostgreSQL实例里省去维护两套存储的麻烦中小团队我比较推荐这个方式。3.3 记忆回路的完整流程记忆不是存进去就完事了它是一条完整的回路。我把这个回路概括成五个步骤感知与抽取监听用户消息分析哪些信息值得写入记忆。结构化与编码将记忆内容转成适合存储的格式并生成对应的Embedding向量。存储与索引写入向量数据库建立索引附加元数据用户ID、时间、类型等。检索与召回根据当前用户输入从记忆库中召回Top-K相关记忆。组装与应用将召回到的记忆与对话历史一起拼装进Prompt交给大模型推理。其中第2步的Embedding编码是容易被忽略的关键点。如果Embedding模型选得不好或者没有针对领域文本做微调那么即使存进去再多记忆检索阶段也会因为语义相似度计算不准而“捞不起来”。我建议在中文场景下优先考虑开源的BGE系列或M3E系列模型它们对中文语义的支持比很多通用英文Embedding模型更友好。4. 实战让Agent记住你的用户画像4.1 技术栈与准备工作前面铺垫了这么多接下来进入实战环节。我以“让Agent记住用户画像”为例完整跑一遍记忆系统的落地过程。这个案例也是很多Agent产品的第一站先记住用户是谁再讨论更高阶的记忆能力。我用的技术栈如下OpenAI的text-embedding-3-small作为Embedding模型Chroma作为向量数据库Python作为开发语言。选这个组合的原因是简单、轻量、不依赖额外服务适合作为入门理解记忆链路的最小骨架。如果你已经在上线项目里跑可以把Chroma换成pgvector或Milvus代码思路完全一致。安装依赖很简单pip install chromadb openai在开始写代码之前还需要准备好OpenAI的API Key并确认它可以访问Embedding接口。如果团队使用的是其他模型服务商只要对方提供Embedding接口逻辑是通用的改一下SDK调用即可。4.2 核心代码实现Embedding与存储先定义一个通用的记忆工具类它负责两件事把文本转成向量把向量和原文一起写入向量库。import os import time from openai import OpenAI import chromadb client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) chroma_client chromadb.PersistentClient(path./agent_memory) collection chroma_client.get_or_create_collection( nameuser_memory, metadata{hnsw:space: cosine} ) def embed_text(text: str) - list[float]: resp client.embeddings.create( modeltext-embedding-3-small, inputtext ) return resp.data[0].embedding def save_memory(user_id: str, content: str, memory_type: str fact, extra_meta: dict | None None): vector embed_text(content) memory_id f{user_id}_{memory_type}_{int(time.time() * 1000)} metadata { user_id: user_id, memory_type: memory_type, timestamp: int(time.time()) } if extra_meta: metadata.update(extra_meta) collection.add( ids[memory_id], embeddings[vector], documents[content], metadatas[metadata] )这里有几个细节值得解释。首先hnsw:space设置成cosine意味着我们用余弦相似度来度量向量之间的语义距离这对文本语义检索来说是默认且稳妥的选择。其次metadata里保存了用户ID、记忆类型和时间戳这为后面做按用户过滤和时间衰减提供了基础。最后documents保存的是原始文本这是为了在召回后能直接把原文塞进Prompt而不用再从Embedding向量反解文本。4.3 检索与召回让Agent在对话前想起“你是谁”记忆写进去了自然要能捞出来。检索的输入有两个当前用户说的一句话以及当前用户的ID。前者用来计算语义相似度后者用来限定只检索这个用户的记忆避免串数据。def retrieve_memory(user_id: str, query: str, top_k: int 5) - list[dict]: query_vector embed_text(query) results collection.query( query_embeddings[query_vector], n_resultstop_k, where{user_id: user_id} ) memories [] for doc, meta in zip(results[documents][0], results[metadatas][0]): memories.append({ content: doc, timestamp: meta.get(timestamp), memory_type: meta.get(memory_type) }) return memories这里where{user_id: user_id}的作用是做一个精确过滤从源头避免“多用户串记忆”的问题。很多初学向量数据库的开发者经常忽略这个过滤条件结果所有用户的记忆混在一起检索出来的内容驴唇不对马嘴。这是我在项目里排查过N次的低级错误真的不需要踩第二次。检索出来的记忆怎么用最常见的做法是把它们拼进System Prompt。这样模型在正式回答用户之前就已经“想起”了与当前问题相关的用户历史信息。def build_prompt(user_id: str, user_query: str) - str: memories retrieve_memory(user_id, user_query) memory_block \n.join( f- [{m[memory_type]}] {m[content]} for m in memories ) system_prompt ( 你是一个具备长期记忆能力的智能助手。\n 以下是关于该用户的长期记忆请基于这些信息提供个性化回答\n f{memory_block} ) return system_prompt这套流程跑通之后Agent就具备了最基本的记忆能力它能通过向量检索找到“用户之前说过什么偏好”并把这个偏好作为背景知识放进当前对话。4.4 记忆更新机制别让旧信息覆盖新信息有了存储和检索还不够记忆系统还面临一个很实际的问题用户是会变的。上周他告诉你“不用加糖”这周他体检完决定戒糖如果Agent还用上周的记忆回答“加一份糖浆”那就翻车了。处理这个问题的常用策略是“版本叠加而不是覆盖”。我不建议直接把旧记忆删除因为用户在某一时刻表达的信息在特定场景下仍然有参考价值更稳妥的做法是为同一类记忆加时间戳在检索召回时优先返回最新记录。具体实现上可以在元数据里增加一个version字段每次用户表达类似偏好时递增版本号检索时按版本号倒序取最新的一条。如果团队人手充足更精细的做法是加一个“记忆置信度”的字段只有当同一个信息被用户在不同时间至少确认过两次以上才被标记为高置信度记忆。这个思路在个性化推荐系统里很常见放在Agent记忆场景里同样适用。5. 让记忆更聪明检索优化与上下文组装5.1 Top-K选择如何避免记忆检索变成噪声第一次完整跑通记忆链路的时候我一度很兴奋直接给Agent塞了10条相关记忆。结果模型回答的上下文确实“丰富”了但回答质量反而下降了因为它同时看到了三条互相矛盾的旧记忆和两条与新问题无关的泛泛之交。问题出在Top-K的选择上。K值设置太大记忆库会把一些边缘相关的内容也捞出来成了Prompt里的噪声K值设置太小又可能遗漏关键信息。从我和团队的实践来看K值在3到5之间是比较稳妥的甜区。如果你的Agent本身具备很强的上下文理解能力上限可以放到8如果上下文窗口本身比较小那就更保守一些。除了K值还可以在检索后做一次简单的条件过滤。比如在当前对话主题明显是“技术选型”时把memory_type为“临时闲聊”的记忆直接丢弃只保留与主题强相关的记忆。这个规则虽然朴素但在工程上非常有效。5.2 时间衰减让近期记忆占据更高权重人类记忆有个特点就是会遗忘越是久远的事情细节越模糊。Agent记忆系统虽然不需要真的遗忘但为了让检索结果更贴近当前场景我们应该给时间因素设置一个合理的权重。一个简单有效的做法是把检索打分和时效性分值做加权融合我把它叫做Dynamic Recency Scoringimport math def dynamic_recency_score(memories, similarity_weight0.7): now time.time() for m in memories: # 假设每条记忆都有一个 age_in_days age_days (now - m[timestamp]) / 86400 recency_score math.exp(-age_days / 30) # 30天衰减周期 # similarity是这条记忆和当前query的余弦相似度范围通常在0~1之间 m[final_score] similarity_weight * m[similarity] (1 - similarity_weight) * recency_score return sorted(memories, keylambda m: m[final_score], reverseTrue)这个公式里的30天衰减周期是我常用的默认值实际操作中可以按产品节奏调整如果Agent服务于高频场景比如每天都会打开的个人助理衰减周期可以缩到7天如果是低频企业服务比如每月只用一次的人事系统衰减周期可以拉长到90天。5.3 上下文组装记忆是辅助不是主角把记忆拼进Prompt时很多人容易走极端恨不得把所有记忆全部塞给模型。实际上正确的姿势是用记忆“增强”上下文而不是用记忆“淹没”上下文。我建议把Prompt按模块分层最前面是系统角色的基础定义然后是本次对话的核心目标再然后是与当前问题直接相关的记忆块最后是用户的当前输入和历史若干轮对话。控制每个模块的长度让大模型把主要注意力放在“当前到底要回答什么问题”上而记忆只是提供隐性的背景支撑。还有一个小细节如果检索到的记忆与你预期的相似度阈值相差太远宁可空置记忆模块也不要强行塞入。记忆给出错误背景信息对回答质量的伤害远大于“没有背景信息”。5.4 记忆合并与去重防止碎片化用户在同一件事上说了很多句话如果每句话都生成一条记忆记忆库很快就会充满碎片化内容。比如用户说“我平时喜欢喝美式”“加班的时候得靠咖啡续命”“最近喝的有点多想少喝点”如果这三句话分别入库检索时会把三条都捞出来但每一条都不是完整的用户画像。更合理的做法是在感知层做记忆合并。可以先抽取出用户画像的三要素“实体”“属性”“值”。第一个实体是用户属性是咖啡偏好值是“喜欢美式”第二个实体是用户属性是健康目标值是“减少咖啡摄入”。在写入时先检查是否已经存在相似主题的旧记忆如果存在就用新的内容更新旧记忆的向量和文本而不是新增一条。这个合并逻辑用向量库的相似度检索就能实现在写入前先用当前文本检索一次同类记忆如果相似度超过0.85就认为是在更新已有记忆复用原来的记忆ID覆盖写入。这个方法我实测效果很好能显著减少记忆库的无序增长。6. 记忆安全与隐私保护别忘了底线6.1 记忆数据的脱敏处理Agent记住用户越多的信息说明它的个性化能力越强但同时也意味着它手里攥着越来越多的用户隐私。在真实项目里记忆数据往往会包含手机号、邮箱、家庭住址、身份证号等敏感字段。如果这些内容原封不动地写进向量库和日志里一旦发生泄露后果非常严重。我的建议是第一道防线放在感知层在信息抽取阶段就对敏感字段进行识别和脱敏。简单的方式是维护一个敏感词正则表比如手机号、邮箱的匹配规则命中后用占位符替代原文再入库更稳妥的方式是用一个独立的敏感信息分类模型做过滤或者调大模型的命名实体识别能力来标注PII字段。无论哪种方式核心原则都是向量库里尽量避免直接存储可识别的明文隐私信息。6.2 用户遗忘权与记忆分级管控做面向C端用户的Agent产品时一定绕不开用户隐私合规。一个比较常见的误解是“用户删除了聊天记录就等于删除了Agent的记忆”。实际上如果记忆已经进入向量库它并不会随聊天记录删除而自动消失。所以我会在设计阶段就预留一个delete_memory(user_id)接口并在产品层面提供“清除记忆”的开关。考虑到很多国家地区都有数据被遗忘权的相关规定尽早把这个功能做进去总比事后补救要省力。另外一个相对进阶的做法是记忆分级把记忆分为普通记忆和敏感记忆两类敏感记忆在写入时额外加密在检索时也需要通过权限校验才能读取。6.3 避免记忆串号与越权读取多用户场景下的记忆隔离是一个必须刻进骨子里的原则。前面我提到在检索时要用where{user_id: user_id}来过滤这不只是一句代码技巧更是一条安全底线。如果用户ID的过滤条件缺失A用户就可能通过一次语义检索看到B用户的记忆内容这在任何场景下都是重大事故。我曾见过一个Agent项目的联调环境里出现过类似问题原因是记忆写入时user_id字段有的存的是内部ID、有的存的是用户昵称导致过滤条件形同虚设。解决方法是统一规定记忆元数据的user_id必须使用系统的唯一用户标识不允许使用昵称或者自定义字符串。这类约定最好写进团队规范而不是靠记忆力。7. 常见问题与避坑实录7.1 检索不到记忆的排查思路“Agent完全想不起用户说过什么”是我被问到最多的问题。排查这类问题建议按下面的顺序走一遍。先确认记忆是否真的写入成功了——去向量库里查一下这个用户的记忆数量如果数量为0问题出在写入环节去看看感知层是否抽取到了信息如果数量不为0再查检索语句的过滤条件看看where条件里用的user_id和写入时是否一致如果过滤条件也没问题那就调低相似度阈值或者增大Top-K排除是阈值设置过严导致的漏召回。还有一个常见坑是Embedding模型不一致。写入用的是OpenAI的text-embedding-3-small检索时如果切换成了另一个Embedding模型向量空间的分布就不一致相似度计算自然不准。所以一个基本原则是同一套记忆库确保写入和检索始终使用同一个Embedding模型。7.2 记忆污染导致回答质量下降记忆污染的意思是Agent记住了错误或过时的信息并在后续对话里把它当成了事实基础。最常见的产生原因是感知层的抽取规则写得过于激进把用户的随口吐槽“我讨厌用Excel管理项目”直接抽取成就职偏好这显然是过度解读。针对这个问题我的建议是引入记忆确认机制对于可能影响Agent后续行为的强记忆先在当前对话里向用户确认一次“您希望我以后默认使用甘特图而不是Excel来管理项目吗”只有得到肯定答复才写入长期记忆。虽然这会多花一轮交互但对于准确性要求高的Agent来说非常值得。7.3 记忆存储膨胀与性能下降随着使用时间变长记忆库的条目数量会持续增长检索延迟也会随之恶化。有一个前置手段是在写入时就做好分类和分区把不同用户的记忆拆到不同的Collection或Partition里这样用户量增加后检索依然只需要在当前用户的分区内进行而不是扫全库。另一个手段是定期做记忆清理。对一些时间超过半年、相似度重复度高、且日常检索几乎不会被命中的记忆可以转入冷存储或者直接删除。清理的规则可以做成定时任务每个季度跑一次确保记忆库长期保持“瘦且精”的状态。7.4 多模态与多Agent场景下的记忆共享如果你的Agent不只有一个而是有一组Agent协同工作——比如一个负责日程一个负责邮件一个负责客服——它们之间如果各自维护一套独立的记忆就会出现“左脑不知道右脑在想什么”的尴尬局面。我建议在这种情况下把记忆抽离成一个独立的记忆服务所有Agent共享同一个记忆API按Agent类型做读写权限隔离。这种架构看起来多了一层服务但在实际运维中能省掉大量“不同Agent之间信息不对齐”的麻烦。就比如用户上午在客服Agent里说了“我月底要出差一周”下午日程Agent安排会议时如果能读到这条记忆就不会再把会议排在月底。这种跨Agent的记忆联动才是Agent生态真正价值最大的地方。我个人在实际项目里最大的体会是记忆系统的建设没有一劳永逸的方案它更像是一个需要持续运营的数据产品——从抽取到存储从检索到清理每一步都要结合真实使用情况反复调优。刚开始做的时候不用追求大而全先把用户画像这一条最简单的链路跑通再逐步加入对话历史、任务状态、业务流程这些更高阶的记忆类型。你完全可以从今天这篇框架出发先做一个能记住用户名字和偏好的最小版本在真实反馈里一步步把记忆做得更智能。
做过AI Agent项目的朋友应该都有过这种体验第一天测试的时候你反复告诉它你的偏好和技术背景它都能给出非常贴合的反馈第二天接着测它好像完全失忆了把前一天约定好的东西忘得干干净净。这个现象在业内被调侃为“金鱼记忆”它不是某个模型的个例而是所有Agent在走向生产环境时都必须跨过的一道坎。这一篇是“走进AI Agent”系列的第三篇主题就一句话让Agent记住你。我会把记忆这件事完整拆开——记忆分哪几种、底层架构怎么设计、用向量数据库怎么落地一套可用的记忆系统以及记忆管理、隐私安全这些实操中绕不开的坑。不管你是刚上手Agent开发的工程师还是正在规划智能助手的产品经理这篇内容应该都能给你提供可以直接拿走的方案。1. 为什么AI Agent需要“记住你”1.1 没有记忆的Agent就像每天重置的记事本先还原一个真实场景。假设你要做一个企业内部的智能客服Agent员工每天都会问“年假还剩几天”“报销流程怎么走”。如果Agent没有记忆它每次都要反复确认“请问您是哪个部门的”“您之前问过这个问题吗”。这种体验在第一次用的时候可能还能接受但连续使用一周之后用户内心只剩一个感受这东西就是个带对话界面的搜索框。技术的核心痛点在于大模型的上下文窗口是有限的而用户与Agent的交互不是一次性买卖它是一段持续的关系。这就好比一个真人助理如果每次见你都问“你好我是谁”你一定会怀疑他是不是脑子不好使。Agent也一样没有记忆就无法在时间维度上形成连续性而连续性恰恰是个性化服务的基础。从工程角度看没有记忆还会带来一个很实际的问题重复劳动。用户每次都要重新描述需求Agent每次都要重新理解上下文这不仅浪费用户的耐心还成倍消耗Token费用。我之前做过一个粗略统计在完全没有记忆设计的Agent里大约有30%到40%的Token开销用在了重复澄清和重新理解用户意图上。换句话说把记忆做好对成本优化的贡献可能比换一个更便宜的模型还要直接。1.2 记忆是Agent从工具走向助理的分水岭目前市面上大多数Agent严格意义上只能算“工具”而不是“助理”。工具的特点是你给我输入我给你输出我们之间没有历史关系。助理的特点是我了解你的习惯、懂得你的偏好、知道你过去做过什么决定并能基于这些积累主动给出更合适的建议。举个例子同一个Agent无记忆状态下你问“帮我安排明天上午的会议”它只能机械地把会议加到日程里。有记忆状态下它知道你是晨型人知道你的重要合作伙伴通常需要提前一天收到会议邀请知道你过去不喜欢把会议安排在周三上午——这些私有信息综合起来它给出的安排就会明显更贴合你的工作习惯。这就是我对“助理”这个概念的朴素理解。记忆能力还直接决定了Agent能不能完成多步骤的复杂任务。一次任务往往不是一轮对话能搞定的中间可能隔了几天可能穿插了用户临时插入的其他问题。如果Agent每次只能看到当前这一轮输入它就永远无法真正理解“整体目标”。只有当它记住任务的上下文和阶段性结果才能像人一样把一个长周期的事情持续推进下去。1.3 记忆设计需要回答的核心问题给Agent设计记忆本质上是在回答三个问题记什么、怎么存、怎么取。“记什么”涉及信息筛选策略不是所有对话都值得记要识别出那些对后续交互有长期价值的用户偏好、事实和决策“怎么存”涉及存储选型是放Redis做短期状态还是放向量数据库做语义检索“怎么取”则涉及召回策略当用户发来一段新消息时如何从记忆库中精准捞出最相关的那部分内容而不是把一大堆无关记忆一股脑塞进上下文。这三个问题缺一不可。只解决存储不解决筛选记忆库会迅速被噪声淹没只解决取不解决存就等于没有记忆。后面我会围绕这三个问题逐个展开把整套设计思路和代码实现完整过一遍。2. 记忆的分类别把“记住”想得太简单2.1 短期记忆上下文窗口里的“即兴表演”短期记忆最直观的形态就是大模型的上下文窗口。你发一条消息模型在这条消息之前看到的所有对话历史就是它的短期记忆。这个记忆的特点是快、短暂、容量严格受限。在工程实现上短期记忆通常由Agent运行时框架自动维护比如LangChain里的ChatMessageHistory或者自己维护一个messages数组。问题在于如果把所有历史都无脑塞进去上下文窗口很快就会爆。以GPT-4等主流模型为例即使提供了很大的上下文窗口当历史消息数量超过一定阈值后模型对早期内容的关注度会明显下降出现所谓“迷失在中间”的现象。所以短期记忆也需要管理。最简单的方式是滑窗裁剪只保留最近N轮稍微讲究一点的做法是摘要压缩把早期的对话内容用模型提炼成一段摘要作为新的上下文元素参与后续推理。两种方式各有优劣滑窗实现简单但会丢失早期关键信息摘要压缩效果好但会引入额外的一次模型调用。我个人的经验是在对话轮次不超过20轮时优先用滑窗超过之后再用摘要压缩兜底。2.2 长期记忆从“会忘事”到“有积累”长期记忆要解决的是跨会话、跨天甚至跨月的持久化问题。用户今天告诉Agent“我习惯喝美式咖啡”这个信息如果不落到长期存储里明天Agent就会忘掉。长期记忆的载体通常是外部存储系统它需要对Agent来说像一个外挂的人脑海马体。在设计长期记忆时最关键的一点是要区分“事实型记忆”和“交互型记忆”。事实型记忆是用户的静态属性和偏好比如“用户叫张三坐标上海工作是后端开发”这类信息变化频率低适合用结构化的方式存储和更新。交互型记忆是用户与Agent之间发生过的历史交互记录比如“上周二用户咨询过数据库迁移方案最后选择了TiDB”这类信息更适合用非结构化文本保存并通过语义检索的方式按需召回。很多人在刚开始做Agent记忆时最容易犯的一个错误就是只设计了短期记忆以为上下文窗口够大就能解决一切。实际上只要Agent的使用周期超过一天长期记忆就不可避免它是Agent从“能用”走向“好用”的关键基础设施。2.3 参考人脑的三种记忆类型为了更好地理解Agent记忆的分工我们可以参考认知科学里对人脑记忆的一种分类方式语义记忆、情境记忆和程序性记忆。语义记忆对应的是“用户是谁、世界是什么样”的事实性知识比如用户的姓名、职业、兴趣爱好。这类记忆的特点是通用、稳定适合用键值对或结构化数据库来保存。情境记忆对应的是“某个时间、某个场景发生了什么”的经历比如“上周五用户让我帮他写过一封辞职信”。这类记忆带有明确的时间属性和场景属性适合用文本记录加元数据比如时间戳、会话ID来保存。程序性记忆对应的是“怎么做一件事”的步骤和技能比如Agent学会的“当用户提到方案评审时必须附上风险清单”这类记忆往往是Agent根据用户反馈动态积累的规则。把这三类记忆分清楚最大的好处是便于确定各自的存储方案和更新策略。语义记忆用结构化存储情境记忆用向量检索程序性记忆用规则模板。这比我刚开始做时把所有内容一股脑塞进同一个向量库要清晰得多。3. Agent记忆系统架构一条主线串起整个流程3.1 记忆系统的四个核心模块一套完整的Agent记忆系统我会拆成四个层来看感知层、存储层、检索层和应用层。感知层负责从用户的对话中识别出值得记住的信息。它既可以是规则驱动比如匹配“我喜欢”“我习惯”“记得”等关键词也可以是由模型驱动用另一个Prompt让LLM来抽取关键信息。存储层负责把提炼出来的记忆落到物理存储中比如用户画像落到MySQL或PostgreSQL对话片段落到向量数据库。检索层负责在用户发起新请求时从存储层中找出最相关的记忆内容返回给Agent。应用层则负责把检索到的记忆与大模型本身的上下文组装在一起生成最终的Prompt。这四个层之间的关系是自下而上的依赖关系感知层负责输入存储层负责沉淀检索层负责召回应用层负责使用。很多Agent项目做不好记忆问题往往出在感知层——“什么都想记”或者“什么都没抽出来”。3.2 存储方案选型从Redis到向量数据库记忆存储的选型取决于记忆的类型和访问方式。下面我整理了实践中比较常见的选择方便你对比参考。存储方案适用记忆类型核心优势主要限制推荐场景Redis短期状态、临时变量读写快、支持TTL过期无语义检索能力会话状态、Token计数MySQL/PostgreSQL用户画像、事实型记忆结构化查询、事务一致不支持语义相似搜索用户属性、偏好配置pgvector事实型语义型混合兼具SQL和向量索引需要结合PostgreSQL使用中小规模项目Chroma/FAISS情境记忆、对话片段轻量、本地部署简单运维能力较弱个人项目、原型验证Milvus大规模对话记忆分布式、高并发部署运维成本较高生产环境大规模使用从我的实操经验看选型没有绝对的“最好”只有“够不够用”。如果你的Agent主要做单机部署、用户量在千级以下Chroma或FAISS完全够用如果是要支撑上万用户同时在线且记忆量会持续膨胀那还是早点上Milvus或云上的向量数据库服务比较稳妥。另外一个比较讨巧的方案是直接用pgvector把关系数据和向量数据都放在同一个PostgreSQL实例里省去维护两套存储的麻烦中小团队我比较推荐这个方式。3.3 记忆回路的完整流程记忆不是存进去就完事了它是一条完整的回路。我把这个回路概括成五个步骤感知与抽取监听用户消息分析哪些信息值得写入记忆。结构化与编码将记忆内容转成适合存储的格式并生成对应的Embedding向量。存储与索引写入向量数据库建立索引附加元数据用户ID、时间、类型等。检索与召回根据当前用户输入从记忆库中召回Top-K相关记忆。组装与应用将召回到的记忆与对话历史一起拼装进Prompt交给大模型推理。其中第2步的Embedding编码是容易被忽略的关键点。如果Embedding模型选得不好或者没有针对领域文本做微调那么即使存进去再多记忆检索阶段也会因为语义相似度计算不准而“捞不起来”。我建议在中文场景下优先考虑开源的BGE系列或M3E系列模型它们对中文语义的支持比很多通用英文Embedding模型更友好。4. 实战让Agent记住你的用户画像4.1 技术栈与准备工作前面铺垫了这么多接下来进入实战环节。我以“让Agent记住用户画像”为例完整跑一遍记忆系统的落地过程。这个案例也是很多Agent产品的第一站先记住用户是谁再讨论更高阶的记忆能力。我用的技术栈如下OpenAI的text-embedding-3-small作为Embedding模型Chroma作为向量数据库Python作为开发语言。选这个组合的原因是简单、轻量、不依赖额外服务适合作为入门理解记忆链路的最小骨架。如果你已经在上线项目里跑可以把Chroma换成pgvector或Milvus代码思路完全一致。安装依赖很简单pip install chromadb openai在开始写代码之前还需要准备好OpenAI的API Key并确认它可以访问Embedding接口。如果团队使用的是其他模型服务商只要对方提供Embedding接口逻辑是通用的改一下SDK调用即可。4.2 核心代码实现Embedding与存储先定义一个通用的记忆工具类它负责两件事把文本转成向量把向量和原文一起写入向量库。import os import time from openai import OpenAI import chromadb client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) chroma_client chromadb.PersistentClient(path./agent_memory) collection chroma_client.get_or_create_collection( nameuser_memory, metadata{hnsw:space: cosine} ) def embed_text(text: str) - list[float]: resp client.embeddings.create( modeltext-embedding-3-small, inputtext ) return resp.data[0].embedding def save_memory(user_id: str, content: str, memory_type: str fact, extra_meta: dict | None None): vector embed_text(content) memory_id f{user_id}_{memory_type}_{int(time.time() * 1000)} metadata { user_id: user_id, memory_type: memory_type, timestamp: int(time.time()) } if extra_meta: metadata.update(extra_meta) collection.add( ids[memory_id], embeddings[vector], documents[content], metadatas[metadata] )这里有几个细节值得解释。首先hnsw:space设置成cosine意味着我们用余弦相似度来度量向量之间的语义距离这对文本语义检索来说是默认且稳妥的选择。其次metadata里保存了用户ID、记忆类型和时间戳这为后面做按用户过滤和时间衰减提供了基础。最后documents保存的是原始文本这是为了在召回后能直接把原文塞进Prompt而不用再从Embedding向量反解文本。4.3 检索与召回让Agent在对话前想起“你是谁”记忆写进去了自然要能捞出来。检索的输入有两个当前用户说的一句话以及当前用户的ID。前者用来计算语义相似度后者用来限定只检索这个用户的记忆避免串数据。def retrieve_memory(user_id: str, query: str, top_k: int 5) - list[dict]: query_vector embed_text(query) results collection.query( query_embeddings[query_vector], n_resultstop_k, where{user_id: user_id} ) memories [] for doc, meta in zip(results[documents][0], results[metadatas][0]): memories.append({ content: doc, timestamp: meta.get(timestamp), memory_type: meta.get(memory_type) }) return memories这里where{user_id: user_id}的作用是做一个精确过滤从源头避免“多用户串记忆”的问题。很多初学向量数据库的开发者经常忽略这个过滤条件结果所有用户的记忆混在一起检索出来的内容驴唇不对马嘴。这是我在项目里排查过N次的低级错误真的不需要踩第二次。检索出来的记忆怎么用最常见的做法是把它们拼进System Prompt。这样模型在正式回答用户之前就已经“想起”了与当前问题相关的用户历史信息。def build_prompt(user_id: str, user_query: str) - str: memories retrieve_memory(user_id, user_query) memory_block \n.join( f- [{m[memory_type]}] {m[content]} for m in memories ) system_prompt ( 你是一个具备长期记忆能力的智能助手。\n 以下是关于该用户的长期记忆请基于这些信息提供个性化回答\n f{memory_block} ) return system_prompt这套流程跑通之后Agent就具备了最基本的记忆能力它能通过向量检索找到“用户之前说过什么偏好”并把这个偏好作为背景知识放进当前对话。4.4 记忆更新机制别让旧信息覆盖新信息有了存储和检索还不够记忆系统还面临一个很实际的问题用户是会变的。上周他告诉你“不用加糖”这周他体检完决定戒糖如果Agent还用上周的记忆回答“加一份糖浆”那就翻车了。处理这个问题的常用策略是“版本叠加而不是覆盖”。我不建议直接把旧记忆删除因为用户在某一时刻表达的信息在特定场景下仍然有参考价值更稳妥的做法是为同一类记忆加时间戳在检索召回时优先返回最新记录。具体实现上可以在元数据里增加一个version字段每次用户表达类似偏好时递增版本号检索时按版本号倒序取最新的一条。如果团队人手充足更精细的做法是加一个“记忆置信度”的字段只有当同一个信息被用户在不同时间至少确认过两次以上才被标记为高置信度记忆。这个思路在个性化推荐系统里很常见放在Agent记忆场景里同样适用。5. 让记忆更聪明检索优化与上下文组装5.1 Top-K选择如何避免记忆检索变成噪声第一次完整跑通记忆链路的时候我一度很兴奋直接给Agent塞了10条相关记忆。结果模型回答的上下文确实“丰富”了但回答质量反而下降了因为它同时看到了三条互相矛盾的旧记忆和两条与新问题无关的泛泛之交。问题出在Top-K的选择上。K值设置太大记忆库会把一些边缘相关的内容也捞出来成了Prompt里的噪声K值设置太小又可能遗漏关键信息。从我和团队的实践来看K值在3到5之间是比较稳妥的甜区。如果你的Agent本身具备很强的上下文理解能力上限可以放到8如果上下文窗口本身比较小那就更保守一些。除了K值还可以在检索后做一次简单的条件过滤。比如在当前对话主题明显是“技术选型”时把memory_type为“临时闲聊”的记忆直接丢弃只保留与主题强相关的记忆。这个规则虽然朴素但在工程上非常有效。5.2 时间衰减让近期记忆占据更高权重人类记忆有个特点就是会遗忘越是久远的事情细节越模糊。Agent记忆系统虽然不需要真的遗忘但为了让检索结果更贴近当前场景我们应该给时间因素设置一个合理的权重。一个简单有效的做法是把检索打分和时效性分值做加权融合我把它叫做Dynamic Recency Scoringimport math def dynamic_recency_score(memories, similarity_weight0.7): now time.time() for m in memories: # 假设每条记忆都有一个 age_in_days age_days (now - m[timestamp]) / 86400 recency_score math.exp(-age_days / 30) # 30天衰减周期 # similarity是这条记忆和当前query的余弦相似度范围通常在0~1之间 m[final_score] similarity_weight * m[similarity] (1 - similarity_weight) * recency_score return sorted(memories, keylambda m: m[final_score], reverseTrue)这个公式里的30天衰减周期是我常用的默认值实际操作中可以按产品节奏调整如果Agent服务于高频场景比如每天都会打开的个人助理衰减周期可以缩到7天如果是低频企业服务比如每月只用一次的人事系统衰减周期可以拉长到90天。5.3 上下文组装记忆是辅助不是主角把记忆拼进Prompt时很多人容易走极端恨不得把所有记忆全部塞给模型。实际上正确的姿势是用记忆“增强”上下文而不是用记忆“淹没”上下文。我建议把Prompt按模块分层最前面是系统角色的基础定义然后是本次对话的核心目标再然后是与当前问题直接相关的记忆块最后是用户的当前输入和历史若干轮对话。控制每个模块的长度让大模型把主要注意力放在“当前到底要回答什么问题”上而记忆只是提供隐性的背景支撑。还有一个小细节如果检索到的记忆与你预期的相似度阈值相差太远宁可空置记忆模块也不要强行塞入。记忆给出错误背景信息对回答质量的伤害远大于“没有背景信息”。5.4 记忆合并与去重防止碎片化用户在同一件事上说了很多句话如果每句话都生成一条记忆记忆库很快就会充满碎片化内容。比如用户说“我平时喜欢喝美式”“加班的时候得靠咖啡续命”“最近喝的有点多想少喝点”如果这三句话分别入库检索时会把三条都捞出来但每一条都不是完整的用户画像。更合理的做法是在感知层做记忆合并。可以先抽取出用户画像的三要素“实体”“属性”“值”。第一个实体是用户属性是咖啡偏好值是“喜欢美式”第二个实体是用户属性是健康目标值是“减少咖啡摄入”。在写入时先检查是否已经存在相似主题的旧记忆如果存在就用新的内容更新旧记忆的向量和文本而不是新增一条。这个合并逻辑用向量库的相似度检索就能实现在写入前先用当前文本检索一次同类记忆如果相似度超过0.85就认为是在更新已有记忆复用原来的记忆ID覆盖写入。这个方法我实测效果很好能显著减少记忆库的无序增长。6. 记忆安全与隐私保护别忘了底线6.1 记忆数据的脱敏处理Agent记住用户越多的信息说明它的个性化能力越强但同时也意味着它手里攥着越来越多的用户隐私。在真实项目里记忆数据往往会包含手机号、邮箱、家庭住址、身份证号等敏感字段。如果这些内容原封不动地写进向量库和日志里一旦发生泄露后果非常严重。我的建议是第一道防线放在感知层在信息抽取阶段就对敏感字段进行识别和脱敏。简单的方式是维护一个敏感词正则表比如手机号、邮箱的匹配规则命中后用占位符替代原文再入库更稳妥的方式是用一个独立的敏感信息分类模型做过滤或者调大模型的命名实体识别能力来标注PII字段。无论哪种方式核心原则都是向量库里尽量避免直接存储可识别的明文隐私信息。6.2 用户遗忘权与记忆分级管控做面向C端用户的Agent产品时一定绕不开用户隐私合规。一个比较常见的误解是“用户删除了聊天记录就等于删除了Agent的记忆”。实际上如果记忆已经进入向量库它并不会随聊天记录删除而自动消失。所以我会在设计阶段就预留一个delete_memory(user_id)接口并在产品层面提供“清除记忆”的开关。考虑到很多国家地区都有数据被遗忘权的相关规定尽早把这个功能做进去总比事后补救要省力。另外一个相对进阶的做法是记忆分级把记忆分为普通记忆和敏感记忆两类敏感记忆在写入时额外加密在检索时也需要通过权限校验才能读取。6.3 避免记忆串号与越权读取多用户场景下的记忆隔离是一个必须刻进骨子里的原则。前面我提到在检索时要用where{user_id: user_id}来过滤这不只是一句代码技巧更是一条安全底线。如果用户ID的过滤条件缺失A用户就可能通过一次语义检索看到B用户的记忆内容这在任何场景下都是重大事故。我曾见过一个Agent项目的联调环境里出现过类似问题原因是记忆写入时user_id字段有的存的是内部ID、有的存的是用户昵称导致过滤条件形同虚设。解决方法是统一规定记忆元数据的user_id必须使用系统的唯一用户标识不允许使用昵称或者自定义字符串。这类约定最好写进团队规范而不是靠记忆力。7. 常见问题与避坑实录7.1 检索不到记忆的排查思路“Agent完全想不起用户说过什么”是我被问到最多的问题。排查这类问题建议按下面的顺序走一遍。先确认记忆是否真的写入成功了——去向量库里查一下这个用户的记忆数量如果数量为0问题出在写入环节去看看感知层是否抽取到了信息如果数量不为0再查检索语句的过滤条件看看where条件里用的user_id和写入时是否一致如果过滤条件也没问题那就调低相似度阈值或者增大Top-K排除是阈值设置过严导致的漏召回。还有一个常见坑是Embedding模型不一致。写入用的是OpenAI的text-embedding-3-small检索时如果切换成了另一个Embedding模型向量空间的分布就不一致相似度计算自然不准。所以一个基本原则是同一套记忆库确保写入和检索始终使用同一个Embedding模型。7.2 记忆污染导致回答质量下降记忆污染的意思是Agent记住了错误或过时的信息并在后续对话里把它当成了事实基础。最常见的产生原因是感知层的抽取规则写得过于激进把用户的随口吐槽“我讨厌用Excel管理项目”直接抽取成就职偏好这显然是过度解读。针对这个问题我的建议是引入记忆确认机制对于可能影响Agent后续行为的强记忆先在当前对话里向用户确认一次“您希望我以后默认使用甘特图而不是Excel来管理项目吗”只有得到肯定答复才写入长期记忆。虽然这会多花一轮交互但对于准确性要求高的Agent来说非常值得。7.3 记忆存储膨胀与性能下降随着使用时间变长记忆库的条目数量会持续增长检索延迟也会随之恶化。有一个前置手段是在写入时就做好分类和分区把不同用户的记忆拆到不同的Collection或Partition里这样用户量增加后检索依然只需要在当前用户的分区内进行而不是扫全库。另一个手段是定期做记忆清理。对一些时间超过半年、相似度重复度高、且日常检索几乎不会被命中的记忆可以转入冷存储或者直接删除。清理的规则可以做成定时任务每个季度跑一次确保记忆库长期保持“瘦且精”的状态。7.4 多模态与多Agent场景下的记忆共享如果你的Agent不只有一个而是有一组Agent协同工作——比如一个负责日程一个负责邮件一个负责客服——它们之间如果各自维护一套独立的记忆就会出现“左脑不知道右脑在想什么”的尴尬局面。我建议在这种情况下把记忆抽离成一个独立的记忆服务所有Agent共享同一个记忆API按Agent类型做读写权限隔离。这种架构看起来多了一层服务但在实际运维中能省掉大量“不同Agent之间信息不对齐”的麻烦。就比如用户上午在客服Agent里说了“我月底要出差一周”下午日程Agent安排会议时如果能读到这条记忆就不会再把会议排在月底。这种跨Agent的记忆联动才是Agent生态真正价值最大的地方。我个人在实际项目里最大的体会是记忆系统的建设没有一劳永逸的方案它更像是一个需要持续运营的数据产品——从抽取到存储从检索到清理每一步都要结合真实使用情况反复调优。刚开始做的时候不用追求大而全先把用户画像这一条最简单的链路跑通再逐步加入对话历史、任务状态、业务流程这些更高阶的记忆类型。你完全可以从今天这篇框架出发先做一个能记住用户名字和偏好的最小版本在真实反馈里一步步把记忆做得更智能。
