上个月在给一个客户做知识库助手的时候碰到一个特别典型的场景用户第一天问了一堆关于公司报销制度的问题Agent 都答得挺好。第二天再打开问我昨天问的那个报销额度上限是多少来着Agent 直接愣住完全想不起来又从头解释了一遍。客户当场就问了我一句这玩意儿怎么跟金鱼一样只有七秒记忆这句话其实戳中了现在很多 AI Agent 项目的命门。我们花了大把精力去调模型、写提示词、接工具但最影响使用体验的往往不是回答得准不准而是它认不认得你。今天这篇就专门聊聊怎么让 Agent 真正记住用户从架构设计到代码实现把记忆这件事彻底讲透。如果你是做 AI 应用开发的、准备搞 Agent 项目的或者只是好奇为什么每次对话 AI 都像第一次见我这篇文章都值得看完。我会把记忆的底层逻辑拆开再给一套可以直接抄作业的实现方案。1. 为什么 Agent 会转头就忘无状态架构的天然缺陷1.1 基础对话模型的底层机制限制要理解 Agent 为什么会失忆得先回到大语言模型的基本工作原理。模型本身是一个参数固定的函数输入一段文本输出一段文本。它没有内置的数据库去存张三昨天问过什么每一次调用都是独立的、无状态的。打个比方你去一家餐厅吃饭每次来都是新服务员他完全不记得你上次点了什么、口味偏好是什么。你每次都得重新说一遍不要香菜。这家餐厅生意能做但体验很差。现在的 LLM API 就是这个服务员每次调用都是新人上岗。很多人误以为上下文窗口就是记忆。不是的。上下文窗口只是把当前这次对话的所有内容包括历史消息、系统提示词全部塞进模型的输入里让模型看到这些内容。一旦这次调用结束这些内容就被丢掉了。下次调用如果不重新把历史消息传进去模型什么都看不到。这里有个关键认知记忆的本质是把信息保存下来在合适的时候重新注入到上下文中。不是模型自己会记而是工程上我们要替它记。1.2 无状态架构带来的连锁问题无状态架构最直接的后果就是用户每次对话都要重新自我介绍。我见过一个做智能客服的朋友他们的 Agent 上线第一周用户投诉最多的问题不是回答错误而是每次打开都要重新说一遍我是谁、我上次问了什么。这在 C 端产品里尤其致命用户觉得你在侮辱他的智商。更麻烦的是无状态架构让 Agent 无法做任何个性化适配。同样是推荐健身计划一个 20 岁的姑娘和一个 50 岁的大叔得到的应该是完全不同的内容。但如果 Agent 记不住用户的基本信息它就只能在每次对话开头想方设法去套话体验极其割裂。另外无状态架构还让 Agent 无法进行持续学习。用户在某次对话中纠正了 Agent 的一个错误下次对话这个纠正就被遗忘了Agent 会继续犯同样的错误。这就是为什么很多 Agent 项目做出来demo 惊艳落地拉胯的根本原因之一——它永远在对一个陌生人说话。1.3 记忆是 Agent 从工具到助手的分水岭我在《走进AI Agent》前两篇里一直强调一个观点工具和助手的分界线就在于它是否了解你。一个没有记忆的 Agent 永远是工具你用的时候觉得它聪明不用的时候觉得它陌生。而一个有记忆的 Agent哪怕回答的质量和之前一模一样用户的主观体验也会完全不同。因为人是情感动物一个记得你名字、记得你上次吐槽过什么的程序在你心里已经不再是冷冰冰的 API 了。这也是为什么 OpenAI 在 GPT 的更新里反复强调memory功能为什么各家 Agent 框架都在推记忆模块。因为大家已经意识到参数大小决定智商下限记忆才决定体验上限。2. Agent 记忆的三种形态先分清再动手在动手写代码之前我强烈建议你先想清楚一个问题你需要的到底是哪种记忆我见过太多人一上来就搞向量数据库结果做出来的东西既不快也不好用。原因就是没搞清楚记忆的分类。Agent 的记忆其实可以分为三种形态它们的存储方式、生命周期和访问逻辑完全不同。2.1 工作记忆模型上下文窗口本身工作记忆就是当前这次对话中模型能看到的上下文。它的容量由模型的上下文窗口决定比如 8K、128K、200K。它本质上不是存储而是临时缓冲区。把整段对话历史都塞进上下文是让 Agent记住当前会话最粗暴的方式。这种方式的问题在于上下文窗口有限对话一长就会超限而且信息越多模型越容易迷失在长文本里抓不住重点反而影响回答质量。所以我们在实际项目中从来不是无脑把全部历史塞进去。而是做滑动窗口——保留最近 N 轮对话加上从长期记忆里检索出来的相关信息。工作记忆的正确用法是够用就好而不是越多越好。2.2 短期记忆会话生命周期内的便签纸短期记忆存放的是当前会话过程中产生、但不需要永久保存的信息。比如用户中途提了一嘴我下周出差去上海这个信息在当前会话的后续对话中可能有用但下个月再问就没意义了。实现方式上短期记忆通常就是会话级的 key-value 存储比如 Redis 或者内存字典。它的特点是读写极快、自动过期。代码上甚至不需要专门的记忆模块一个 Session 对象就能搞定。但我要提醒一点短期记忆很容易被忽略却又很影响体验。比如用户在对话中好几次提到某个项目代号你的 Agent 每次都要问请问您说的 XX 是什么意思那就是短期记忆没做好。好的短期记忆应该让 Agent 在同一会话内对刚刚说过的事有连续性。2.3 长期记忆跨会话的人设档案长期记忆就复杂了。它需要跨会话保存用户的基本画像、偏好、历史重要信息并且能在未来某次对话中被自动唤起。长期记忆最常见的实现载体是向量数据库。把用户的对话记录、事实信息通过 Embedding 模型转成向量存到向量库里。新对话开始时把当前问题也转成向量去库里做相似度检索找到最相关的历史记录注入到上下文中。原理上这很像人的长时记忆提取你不会记住过去每一天的每一个细节但你会在需要的时候想起好像上次聊过这个话题。向量检索就是在做这个好像。除了向量存储结构化数据库比如 Postgres、MySQL也扮演重要角色。那些明确的、稳定的用户属性名字、职业、偏好、家庭情况我更建议用一张 user_profile 表存起来而不是去向量库里撞运气。2.4 记忆分层调度的逻辑什么时候用哪一层实际项目中这三种记忆不是独立运行的而是要配合调度。我自己通常在 Agent 的入口处做一个记忆管理器统一处理三层记忆的读取和写入。整个流程是这样的用户发起一条消息 → 记忆管理器先把工作记忆当前上下文窗口里的内容整理出来 → 再从长期记忆里检索出与当前问题相关的信息 → 把短期记忆中的近期会话摘要也拿过来 → 合并成最终的 Prompt → 发给模型 → 模型回复后记忆管理器再把这次对话中有价值的信息异步写入长期记忆或更新短期记忆。这样做的好处是模型每次只需要处理够用的信息量不会因为把所有历史都塞进去而导致性能下降或注意力分散。而且通过分层不同的信息有了不同的生命周期不会混为一谈。3. 让 Agent 记住你的几种落地路径没有银弹只有取舍概念理清楚之后最关键的问题来了具体应该用什么方案实现现在的社区讨论里一说给 Agent 加记忆很多人第一反应就是上向量数据库。但我在多个项目里实测下来向量数据库只是手段之一而且不一定是最合适的那个。下面我把三种最常用的落地路径都讲一遍包括它们的代码实现思路、适用场景和坑。3.1 路径一上下文压缩 滑动窗口最简单先跑通路径一的核心思路是不引入任何外部存储只靠 Prompt 工程来伪记忆。具体做法是维护一个消息队列只保留最近 N 轮对话。每一轮新的对话进来都把它追加到队列尾部如果队列长度超过阈值就把最早的几轮丢弃。同时用一个摘要模型定期把被挤掉的历史对话压缩成一段话保留要点比如用户正在做一个电商项目遇到过支付回调问题偏好用 Python 技术栈。伪代码大概是这样的class SlidingWindowMemory: def __init__(self, max_turns10, summarize_threshold20): self.history [] self.summary self.max_turns max_turns self.summarize_threshold summarize_threshold def add_message(self, role, content): self.history.append({role: role, content: content}) if len(self.history) self.summarize_threshold: # 把最早的部分拿去搞摘要 old_messages self.history[:-self.max_turns] self.summary summarize(old_messages, self.summary) self.history self.history[-self.max_turns:] def build_context(self): return [{role: system, content: f历史摘要{self.summary}}] self.history这段代码我在早期 demo 里用了很久它的价值在于让你不依赖额外基础设施就能体验记忆的感觉适合快速验证产品需求。但它的缺点也很明显——一旦对话轮数非常多、且信息跨度大摘要会丢失大量细节用户问一个好久之前聊过的细节Agent 就是想不起来。所以路径一我只把它作为起步方案不建议用在生产环境的核心场景。它解决的是从 0 到 1的问题让你先理解记忆系统的工作方式。3.2 路径二向量数据库检索式记忆当前主流覆盖绝大多数场景路径二就是很多人熟悉的 RAG 思路但记忆场景下的 RAG 和知识库问答的 RAG 稍有点不同知识库 RAG 检索的是文档而记忆 RAG 检索的是用户过去的行为和说过的话。实现路径通常分四步第一步定义记忆的存储格式。每一条记忆通常包含三个字段user_id这条记忆属于谁、content记忆的文本内容、metadata时间、场景、重要性等附加信息。我建议每条记忆都要打上时间戳因为记忆是有时效性的去年的偏好不一定适用于现在。第二步把记忆内容做向量化。用 Embedding 模型比如 OpenAI 的 text-embedding-3-small、智谱的 embedding-2、BGE 等把每条记忆文本转成一个向量存入向量数据库。目前常用的开源/商业方案有 Chroma、Milvus、Qdrant、Pinecone、pgvector 等各有优劣后面我会做对比。第三步检索。当用户发起新对话时把用户的问题也向量化然后去向量库里做 top-k 检索。注意这里有个很容易踩的坑检索出来的结果不要全部一股脑塞进 Prompt而是要做一次 re-rank重排序过滤掉相似度低于阈值的再挑最相关的 3~5 条。第四步写入。对话结束后从对话中抽取值得记忆的信息写入向量库。这一步我强烈建议不要直接用 LLM 抽取成本高且不稳定。更好的方式是用规则的方式先抽候选比如用户明确提到喜欢/不喜欢/偏好/我是/我在...这类句式再用 LLM 把候选信息整理成完整的记忆文本。一个基础实现是这样import chromadb from openai import OpenAI client OpenAI() # 初始化向量存储 chroma_client chromadb.PersistentClient(path./agent_memory) collection chroma_client.get_or_create_collection(user_memories) def remember(user_id, text): 写入一条记忆 embedding client.embeddings.create( modeltext-embedding-3-small, inputtext ).data[0].embedding collection.add( ids[f{user_id}-{uuid.uuid4()}], embeddings[embedding], documents[text], metadatas[{user_id: user_id, timestamp: time.time()}] ) def recall(user_id, query, top_k5): 检索记忆 query_embedding client.embeddings.create( modeltext-embedding-3-small, inputquery ).data[0].embedding results collection.query( query_embeddings[query_embedding], n_resultstop_k, where{user_id: user_id} # 重要按用户隔离 ) return results[documents][0]上面这段代码虽然很简单但已经构成了一个可用的记忆闭环remember负责写入recall负责检索并且在检索时通过where参数按用户隔离避免不同用户的记忆互相串扰。这条路我用了大概半年总的来说是目前在通用对话记忆里性价比最高的方案。但它的坑在于检索质量强烈依赖 Embedding 模型的相似度判断能力。如果用户说的是比较隐晦的表达比如上次那个让我很头疼的东西向量检索大概率匹配不到底层相关的记忆。这种情况就需要结合路径三用结构化档案兜底。3.3 路径三结构化记忆档案建立稳定的人设底座路径三解决的是用户核心画像的问题。它不像向量检索那样依赖语义相似度而是把一个用户从上到下用一张结构化的表来刻画。我习惯把这类记忆建模成三类子表第一类基础画像表 (user_profile)用户的名字、性别、职业、行业、技术栈、公司规模等。这些信息一旦写入很少变化是 Agent 理解用户的底座。比如用户在第一次对话里说过我是做跨境电商的这个信息应该被持久化到 user_profile之后每次对话 Agent 都知道面对的是一个跨境电商从业者而不是每次都要重新问。第二类偏好表 (user_preferences)用户明确表达过的喜欢/不喜欢。比如我不喜欢太长的回答、我比较喜欢用 Python 而不是 Java 来写脚本。这些偏好与具体任务无关在任何对话中都应该被遵守。第三类事实事件表 (user_facts)用户提到过的重要事实和事件。比如我女儿今年上小学、我们公司明年要上市。这些信息的特点是有明确的时间点或状态适合存储为事实型记忆在合适的时候可以被引用。存储上我用 Postgres 来表示这三张表。为什么不放向量库因为这类信息的特征是结构化、高确定性用关系型数据库做精确查询比向量检索更可靠。比如 Agent 想知道用户的行业是什么直接SELECT industry FROM user_profile WHERE user_id...比向量检索快得多、准得多。运行时逻辑也很清晰每次对话开始时先查结构化档案把基础画像和偏好注入系统提示词对话结束后识别出新的用户事实更新或追加到表中。这里有一个非常关键的工程细节写结构化档案之前一定做冲突检测。比如用户之前说我在北京工作今天又说我搬去上海了。如果不做检测两张记录就会同时存在Agent 的上下文里既会出现北京又会出现上海模型就会混乱。我通常的做法是同一个实体用户、公司、项目等的信息以最新值为准新写入的数据要覆盖同主题的旧数据。3.4 三种路径如何选择我的建议组合说了这么多核心结论是三种路径不是互斥的而是要组合使用。我的推荐组合是短期会话记忆滑动窗口 摘要兜住 90% 的基础连续性需求。长期核心画像结构化数据库给 Agent 一个稳定的人设底座。长期非结构化记忆向量数据库存储对话中那些暂时看不到价值、但未来可能被想起来的细节。整个记忆管理器的调用顺序是这样的用户发消息 → 先从结构化档案里提取画像和偏好 → 再从向量库里检索相关回忆 → 合并当前滑动窗口和历史摘要 → 组装 Prompt → 发给模型 → 模型回复 → 异步更新滑动窗口、提取新的画像信息、把值得记录的对话细节写入向量库。这套组合我在真实业务场景里跑通之后用户的感知变化是巨大的。最典型的一个反馈是它好像真的记得我上次说过什么了。4. 实操记录给一个客服 Agent 加上完整的记忆系统理论讲再多不如直接上一个完整的实操记录。我拿之前做的那个企业报销制度问答 Agent作为案例完整演示一下怎么把记忆系统接进去。4.1 需求分析这个 Agent 到底需要记住什么在写代码之前先明确需求。我的客户是一名 HRBP她提了两个诉求第一员工问过的问题二次来访时不要重复问基础信息第二同一个员工的报销相关问题Agent 回答时要知道这个员工之前问过什么避免前后矛盾。基于这两个诉求我规划的记忆粒度是员工基础信息工号、部门、入职时间从公司系统同步进来写入 user_profile。对话历史中的高频话题员工反复问报销的哪类问题比如差旅费标准、餐饮发票限额这些写入向量库方便按话题检索。最近一次会话的上下文保证当次服务连续。4.2 架构选型与环境准备技术栈定为Python FastAPI 做 Agent 后端Chroma 做向量存储Postgres 存结构化档案Redis 存短期会话LLM 用通义千问的 qwen-plus后面为了演示也可以切换成任何兼容 OpenAI 接口的模型。之所以选这套组合核心考量是团队熟悉度和维护成本。客户公司的开发团队对 Python 和 Postgres 很熟Chroma 可以直接嵌入式运行不需要额外搭服务。如果是一个对性能要求极高、数据量千万级以上的场景我才会推荐 Milvus 或者 Qdrant。绝大多数 Agent 项目的记忆规模其实都不大Chroma 完全够用还省运维。4.3 核心代码记忆管理器的完整实现下面是我当时写的一个简化版记忆管理器去掉业务细节后大概长这样import json import time import uuid from typing import List, Dict from openai import OpenAI import chromadb import redis import psycopg2 class MemoryManager: def __init__(self, llm_client, embed_modeltext-embedding-3-small): self.llm llm_client self.embed_model embed_model # 向量记忆存储 self.chroma chromadb.PersistentClient(path./agent_memory) self.vector_collection self.chroma.get_or_create_collection(memories) # 短期会话存储 self.redis_client redis.Redis(hostlocalhost, port6379, db0) # 结构化档案存储Postgres self.pg_conn psycopg2.connect( hostlocalhost, dbnameagent, userpostgres, passwordyour_password ) # ---------- 写入结构化档案 ---------- def upsert_profile(self, user_id: str, field: str, value: str): 写入/更新用户基础画像字段 cur self.pg_conn.cursor() # ON CONFLICT DO UPDATE 实现按用户字段去重以最新值为准 cur.execute( INSERT INTO user_profile (user_id, field, value, updated_at) VALUES (%s, %s, %s, NOW()) ON CONFLICT (user_id, field) DO UPDATE SET value EXCLUDED.value, updated_at NOW() , (user_id, field, value)) self.pg_conn.commit() cur.close() # ---------- 读取结构化档案 ---------- def get_profile(self, user_id: str) - Dict[str, str]: 读取用户全部画像字段 cur self.pg_conn.cursor() cur.execute(SELECT field, value FROM user_profile WHERE user_id %s, (user_id,)) rows cur.fetchall() cur.close() return {field: value for field, value in rows} # ---------- 写入向量化长期记忆 ---------- def remember_vector(self, user_id: str, content: str, memory_type: str chat_history): 将一条信息写入向量记忆库 embedding self.llm.embeddings.create( modelself.embed_model, inputcontent ).data[0].embedding memory_id f{user_id}-{uuid.uuid4()} self.vector_collection.add( ids[memory_id], embeddings[embedding], documents[content], metadatas[{ user_id: user_id, memory_type: memory_type, timestamp: time.time() }] ) # ---------- 检索向量化长期记忆 ---------- def recall_vector(self, user_id: str, query: str, top_k: int 3) - List[str]: embedding self.llm.embeddings.create( modelself.embed_model, inputquery ).data[0].embedding results self.vector_collection.query( query_embeddings[embedding], n_resultstop_k, where{user_id: user_id} ) docs results.get(documents, [[]]) return docs[0] if docs else [] # ---------- 读取短期会话上下文 ---------- def get_short_term_context(self, session_id: str) - str: 从 Redis 里拿最近几轮对话拼成字符串 raw self.redis_client.get(fsession:{session_id}) if not raw: return messages json.loads(raw) return \n.join([f{m[role]}: {m[content]} for m in messages[-6:]]) # ---------- 组装最终 Prompt ---------- def build_prompt(self, user_id: str, session_id: str, user_query: str) - str: # 1. 结构化画像 profile self.get_profile(user_id) profile_text ; .join([f{k}: {v} for k, v in profile.items()]) or 暂无已知用户信息 # 2. 向量检索的长期回忆 recalled self.recall_vector(user_id, user_query) recall_text \n.join([f- {r} for r in recalled]) or 暂无相关历史回忆 # 3. 短期会话上下文 short_context self.get_short_term_context(session_id) prompt f 【用户画像】 {profile_text} 【相关历史记忆】 {recall_text} 【当前对话上下文】 {short_context} 【用户当前提问】 {user_query} 请根据以上记忆结合实际情况回答用户。如果历史记忆与当前问题无关请忽略历史记忆。 return prompt这段代码就是记忆系统的主干。这里有三个地方我要特别展开说明因为它们决定了记忆系统的质量。第一个是upsert_profile里的ON CONFLICT DO UPDATE。这句 SQL 实现了同字段以最新为准的覆盖逻辑。一开始我图省事直接INSERT结果用户改了电话号码之后库里保留了新旧两条记录Agent 就经常在旧号和新号之间摇摆。所以结构化记忆一定要做幂等覆盖绝对不能无脑追加。第二个是检索时候的top_k设置。我默认设 3但这个值不是固定的。如果是比较复杂的问题场景我建议调到 5但要配合相似度阈值过滤低于阈值的不要。top_k太大的隐患是会把不太相关的内容塞进去反而稀释了模型对核心信息的关注度。第三个是 Prompt 里那句如果历史记忆与当前问题无关请忽略历史记忆。这句话特别重要。因为向量检索不一定每次都准它可能召回一些语义相似但实际无关的记忆。如果不加这句模型会被带偏把一些错误的旧信息硬套在当下的回答里。给模型一个可忽略的授权能显著减少记忆污染导致的幻觉。4.4 对话后的记忆提取异步策略与触发规则上面的代码处理了读记忆但写记忆同样关键。对话结束后我们要判断这次对话中有哪些信息值得被记住我的经验是不要每次都把完整对话做 LLM 抽取很不划算。更好的方法是用规则先粗筛再用 LLM 精炼。粗筛的规则包括用户语句中包含我是、我在、我喜欢、我不喜欢、我偏好、我们公司、我负责、我住在、我毕业于等句式视为画像候选。用户主动提供的明确事实信息比如电话、邮箱、日期、金额等抽出来作为user_facts。粗筛出来的候选文本再交给 LLM 做一条 prompt 判断def extract_memories(user_id, dialogue_text): # 先规则粗筛 candidates rule_based_candidates(dialogue_text) if not candidates: return # 再 LLM 精炼 resp self.llm.chat.completions.create( modelqwen-plus, messages[ {role: system, content: 你是一个记忆抽取器。从对话中抽取值得长期记住的用户信息 输出JSON数组每个元素包含field和value两字段 只输出与用户画像、偏好、重要事实相关的信息不要抽取普通闲聊。}, {role: user, content: \n.join(candidates)} ], response_format{type: json_object} ) memories json.loads(resp.choices[0].message.content) for mem in memories.get(memories, []): self.upsert_profile(user_id, mem[field], mem[value])这一步为什么要分两步走而不是直接全交给 LLM核心原因是成本和准确性。整段对话扔给 LLM 去抽容易把无关的闲聊也抽成记忆污染用户画像。而规则先粗筛等于先框定边界LLM 只能在候选信息里做精炼准确率会高很多。4.5 效果演示与性能数据接完记忆模块之后我做了几个对比测试场景一A 员工第一次问报销差旅费标准我知识库里配置的答案是一线城市 500/天。过了两天A 员工再问我上次问的住宿标准是多少没加记忆的 Agent 直接答不上来加了记忆的 Agent 正确回答500/天。场景二B 员工在前一天对话里提到自己是销售部、经常出差。第二天再进来加了记忆的 Agent 在下一次回答的开头会说根据您的情况作为经常出差的销售您可以重点关注以下报销项。这个个性化的表达在没有记忆的版本里几乎不可能出现。性能方面接入记忆后单次请求的 p95 延迟增加了大约 120ms主要耗时在向量检索和 Embedding 计算上。对于绝大多数对话场景来说这个开销完全可以接受。让我比较意外的是结构化的读取反而比预想快因为 Postgres 走主键索引单条查询基本是 1ms 级别。5. 常见问题与避坑指南记忆做不好比不做还糟写记忆模块不难真正难的是把记忆用好。我在实战里踩过不少坑把最能救命的几条整理出来希望你们别重复经历。5.1 记忆污染什么该忘什么该记记忆系统最大的风险不是记不住而是什么都记。一旦把用户随口的一句抱怨、一个临时状态、甚至一句玩笑话当成长期记忆入库就会造成严重的记忆污染。我之前有个 Agent 把用户说的真想辞职算了这句话存成了长期记忆结果后面每次对话的 Prompt 里都会出现这句话Agent 一度很关心地追问用户您是不是有辞职打算场面一度非常尴尬。解决这个问题需要给什么该记定标准。我的经验是符合以下条件之一的才值得写长期记忆——直接影响后续交互的核心画像信息职业、家庭、项目、用户明确表达的稳定偏好喜欢、不喜欢、习惯、与用户核心目标相关的关键事实。至于情绪化表达、临时状态、可推断内容一律不记。5.2 记忆冲突新旧信息打架怎么办用户的信息是会变的。三个月前他还在北京今天他说搬去深圳了。如果记忆系统没有一套处理冲突的机制就会出现Prompot 里既有北京又有深圳的情况模型会非常困惑。我的做法是为每条结构化记忆维护一个updated_at时间戳写入新值时对同一个字段做覆盖操作。但在覆盖之前可以加一步变更提示——如果系统检测到用户新提供的信息与旧值矛盾可以主动向用户确认一次您之前提到您在北京我更新为深圳可以吗这种主动确认既避免记错又让用户觉得 Agent 很贴心。对于向量化的记忆冲突处理就麻烦一些。因为向量库里的旧记忆不会自动消失。我的方案是在做向量检索的时候除了相似度过滤还加一个时间衰减因子。太老的记忆默认降权只有在新对话明确提到之前/去年/上个月这种时间线索时才提高旧记忆的权重。这个细节对长周期用户的体验影响很大。5.3 隐私边界记忆功能也是双刃剑给 Agent 加记忆一定要想清楚隐私边界。尤其在面向 C 端用户的产品里用户对AI 记得我这件事的接受度是分化的。有人觉得方便有人觉得毛骨悚然。我在给客户做方案时一定会预留这几个能力第一用户可以查看 Agent 记住了什么第二用户可以单条删除记忆第三用户可以一键清空全部记忆。这三个能力听着基础但很多 dmeo 项目压根没做。而且技术层面要保证记忆的隔离性。不同用户的数据在向量库和数据库层面应该用user_id硬隔离绝不能出现 A 用户的记忆被 B 用户检索到的情况。我见过有些团队图省事直接在全局 collection 里检索然后靠 Prompt 过滤这种设计一旦配置错误就是严重的数据泄露事故。5.4 长期运行后的记忆衰减与重建最后聊一个很多人没注意的问题记忆系统跑久了向量库会越来越臃肿。用户聊了一年后他可能有几千条向量记忆其中大量是重复、过时、无价值的内容。如果你不做维护检索的准确率会肉眼可见地下降因为噪声越来越多。我建议定期做记忆清理比如每季度跑一次记忆压缩任务。把同一个用户的历史记忆按主题聚类合并同类项删除过时的内容形成几段更精炼的长期摘要。这个过程很像人的记忆巩固——重要的反复出现的细节被强化保存不重要的细节被逐渐淡忘。另外Embedding 模型如果升级了旧的向量和新的向量在语义空间里会有偏移这时候最好做一次全量重建。这事很麻烦但没办法及时记录模型版本留好原始文本重建时才不会痛苦。回到文章开头那个金鱼记忆的客户案例。我把这套记忆系统接完之后客户的评价是它现在至少有金鱼的十倍记忆了。虽然是一句玩笑话但你能明显感觉到跨过记住用户这道坎之后Agent 在用户心里的定位变了——它不再是一个需要反复沟通的查询工具而是一个越用越顺手的私人助理。如果你正在做一个 Agent 项目我建议你按照这篇文章的思路先梳理清楚你需要的记忆形态再决定技术选型。不要一上来就堆向量库也不要天真地以为靠 Prompt 就能解决长期记忆问题。从滑动窗口起步逐步叠加结构化档案和向量检索踩过几个坑之后你会对记忆这两个字有完全不同的理解。如果看完还有什么疑问欢迎在评论区聊聊你的场景我们一起探讨。