做AI对话产品最尴尬的时刻不是模型回答错而是用户觉得自己在对着一堵墙说话。我做的智能体“想想”早期版本就是这样新开了一个对话用户说“昨晚我们已经讨论过项目排期你直接继续就行”结果“想想”一脸茫然地反问“哪个项目”气得用户当场关掉了页面。这种无状态对话本质上不是模型能力问题而是产品设计没有给模型接上记忆的器官。其实“直接把整段对话历史塞进上下文”是很多团队的第一步试完基本都会发现两个问题第一是token成本涨得飞快第二是模型在长历史里抓不到重点甚至会重复已经确认过的错误信息。真正要解决的是“记忆的挑选和组织”哪些内容必须记住哪些可以忘记哪些要在特定时刻被重新唤醒。这篇文章用“想想”这个项目作为实例把我验证过的三层记忆架构、写入和检索链路、画像标签对输出个性化的作用以及上线以后踩到的工程坑完整拆一遍。不管你是正在做智能体产品还是做AI客服、本地助手还是自己搭过RAG框架这篇都应该能帮你少走几个月的弯路。1. 无状态对话的困局为什么“多聊几轮”和“记住用户”是两码事有个周六我打开自己做的智能体“想想”想让它帮我查天气。先问了一句“今天还会下雨吗”它回答完后我紧接着说“顺便帮我把昨天列的那份周末清单延期到下周日”。结果它愣了一下反问我什么清单那份清单是我在第3轮对话里给它的而我当时已经新开了一个会话所有上下文归零。那一刻我的反应和真实用户一模一样生气想卸载。这个场景特别典型。很多团队会误以为“对话系统只要上下文窗口够大就能记住很多东西”但用户要的记忆必须是跨会话、跨时间的。用户默认AI应该像一个人一样记得昨天说过什么、上次纠缠过什么话题、自己是什么口味。一旦AI做不到产品的信任感瞬间崩塌。所以我在“想想”立项的时候就把目标定得很清楚让智能体拥有记忆然后围绕这个记忆能力做出千人千面的体验。1.1 最省事的方案为什么跑不通一开始团队内部讨论过最简单粗暴的方案既然现在大模型上下文窗口越来越大那把用户过去全部聊天记录拼到每一次请求里不就行了我们真的在实验环境里跑过。把最近10轮、30轮、50轮历史分别拼接进Prompt结论是轮次越多首包延迟越来越明显单次调用成本直线上升而且模型在超过一定长度之后开始注意力漂移。最明显的例子是一个用户在对话中先要求“用口语化风格”过了一段又要求“还是用正式语气”当系统把50轮历史全部塞进去时模型很可能会把两条指令都当成当前生效状态最后生成的内容既不够口语、也不够正式完全四不像。这说明单纯的文本拼接只是把历史数据“喂”给模型并没有让模型真正拥有被组织过的记忆。模型就像是面对一堆没整理过的纸质档案明明每个字都在却不知道当前办事要看哪一份。1.2 记忆系统真正要处理的三件事顺着这个失败实验我把记忆问题重新定义成三件事记什么、怎么取、什么时候忘。记什么指的不是全量录音而是从对话里筛选出值得长期保存的事实和偏好怎么取指检索也就是在用户发起新对话时能从积累的记忆里快速捞出当前最相关的几条什么时候忘则是指记忆的更新与淘汰用户改主意了、时间过期了、内容被删了系统得能消化掉。这三件事是完整闭环任何一环掉了记忆系统都会变成灾难。如果只做写入不做检索你就是帮用户存了一堆垃圾如果只做检索不做淘汰旧记忆会不断污染新判断如果只做淘汰不控制写入又会发现该记的没记不该记的塞了一大堆。后面几部分我会按照这三件事逐层展开。2. 记忆建模的第一次取舍三层结构而不是一份聊天日志很多人一想到记忆系统第一反应就是建一张大表字段是user_id、content、time把所有用户说过的话往里塞。前期数据少还能跑数据量一大就乱套。因为对话里既有暂时性的上下文比如“把第2条改一下”也有长期的事实比如用户说过“我每周三健身”还有用户表达风格的偏好比如“回复短一点别用表情包”。这三类信息的生命周期完全不同混在一张表里检索的时候会互相干扰导致既查不准、也更新不了。所以我最终把“想想”的记忆设计成了三层会话层、事实层、画像层。会话层负责当前任务的临时上下文事实层负责长期有用的个人化信息画像层负责沉淀用户特征标签。三层各干各的物理存放可以分开逻辑上必须清晰。2.1 三层分别存什么会话层的典型内容是当前对话里的临时约定。比如用户刚说“接下来我们讨论预算表”这条信息只在本次会话内有效下一个新会话就不该再自动带上。实现上一般放在内存或Redis里设置一个几小时到几天的过期时间。会话层不用做复杂向量化直接保留最近若干轮原始消息即可组件越轻越好。事实层是记忆系统的主战场。用户提到自己的工作、家人、爱好、目标、曾经明确表达过的需求这些内容会被抽取、总结再转成向量存入向量数据库。比如用户说“我明年打算换工作正在准备后端面试”这条事实会被提炼成一条结构化记忆等到用户以后再聊到面试、简历、刷题时它就能被召回出来。画像层则更像用户画像标签表。比如“互联网从业者”“喜欢简洁回复”“深夜活跃”“目前关注求职”。画像层不需要每轮都写它是从事实层里低频聚合出来的结果通常以键值对或标签表的形式存在。2.2 存储选型的对照记忆层典型内容更新频率物理存储读取方式会话层最近几轮对话、临时任务每轮对话内存/Redis直接拼接事实层用户长期事实、历史需求异步抽取写入向量库 关系库语义召回画像层兴趣标签、风格偏好低频聚合KV/标签表规则注入这个选型不是一步到位的。我最早甚至没有单独画像层只有会话层和事实层后来发现在做个性化输出时向量召回出来的内容粒度太细碎了。比如用户问“帮我写一封请假邮件”向量召回可能捞出来用户上次请假的具体日期却不知道用户总体上偏好什么语气。画像层就像一个大颗粒度的粗索引先粗筛整体风格再用事实层细召回具体片段两者配合系统才有机会做到千人千面。2.3 三层能不能合并成两层有些项目为了省事会把会话层也并到事实层里让向量库处理一切。我试过之后不太建议。原因是会话层的实时性要求和事实层完全不一样会话层要求零延迟、读取稳定、不能因为向量检索波动就丢掉当前任务的上下文而事实层允许几十毫秒的检索延迟。另外会话层信息写入频繁如果一并进行向量化成本会成倍增加。实际上会话层完全可以只做滑动窗口缓存等到需要沉淀时再做一次抽取和向量化。还有一个容易犯的错误是把用户主动删除的记忆也留在向量库里。删除操作必须同步到所有存储层至少也要做逻辑删除标记。不然用户越删越觉得产品不懂自己。3. 记忆闭环的工程实现写入、检索、遗忘一个都不能少架构想清楚之后真正决定系统能不能用的是工程细节。不少团队把记忆系统做成了一个只写不读的储物间天天都在存真正用的时候却捞不到对的。问题往往不在模型而在写入、检索、遗忘三个链路没有串起来。我在“想想”里把这部分做成了一条完整的流水线。3.1 记忆写入先判断值不值得记住一段对话产生了要不要把其中一部分存成长期记忆我的原则是不是所有对话都值得记住。如果什么都存检索噪声会大得离谱最终伤害的是核心召回效果。所以写入之前要先做一次判断。我用了一个很轻量的LLM评分调用让模型判断这句话里是否包含新事实、新偏好还是只是临时闲聊。只有在判定为需要记忆时才做抽取、总结、向量化、入库。下面是一个简化示意# memory_judge.py 的简化示例 class MemoryJudge: def __init__(self, llm, embedder): self.llm llm self.embedder embedder def process(self, user_id: str, message: str): # 1. 先判断是否值得记忆 decision self.llm.complete( f以下是用户对AI智能体说的一句话。 判断这句话中是否包含需要长期记住的信息。 包含新事实、明确偏好、用户当前目标、反对或修正过的内容。 不包含临时指令、闲聊、无实质信息的客套。 只回答 NEED_REMEMBER 或 SKIP。\n用户说{message} ) if decision.strip() ! NEED_REMEMBER: return None # 2. 抽取结构化记忆内容 structured self.llm.complete( 从这句话中抽取出一个简洁的长期记忆条目 类型是 fact(事实)、preference(偏好)、goal(目标) 之一。 输出 JSON{type: ..., content: ...} ) # 3. 向量化 embedding self.embedder.encode(structured) return { user_id: user_id, content: structured, embedding: embedding, created_at: now(), last_access_at: now(), access_count: 0, }这个判断过程看起来简单但阈值很关键。太保守关键信息老是漏太激进后面检索全是垃圾。我们实验室当时随机抽了500条真实对话语料做标注把判定准确率调到90%以上才放行。如果你正在做类似系统建议先抽语料做一次人工校准别凭感觉设Prompt。3.2 记忆检索从几千条记忆里捞出最相关的几条记忆检索的目标是在用户新发起一轮对话时从该用户积累的几百甚至几千条记忆片段里捞出最该出现在当前Prompt里的几条。我用的方式不是单纯向量相似度而是把向量相关度、画像匹配度、时效新鲜度三者融合起来打分。def recall_memory(user_id, query, profile_tags, top_k5): query_embedding embedder.encode(query) # 初筛按向量相似度取候选集 candidates memory_store.query( user_iduser_id, query_embeddingquery_embedding, top_k30 ) # 重排融合三个维度打分 for item in candidates: vec_score cosine_similarity(query_embedding, item.embedding) tag_score tag_overlap(item.content, profile_tags) time_score 1.0 / (1.0 hours_since(item.last_access_at) / 24.0) final_score 0.6 * vec_score 0.3 * tag_score 0.1 * time_score item.score final_score candidates.sort(keylambda x: x.score, reverseTrue) return candidates[:top_k]这里最值得展开说的是时间新鲜度。很多记忆系统只做向量相似度结果用户三个月前随口提过的一个话题被误当成当前重点捞了回来。加一个时间衰减项之后这种情况明显减少。但时间衰减也不能给太高权重不然用户的长期核心偏好又容易被短期热点压制。我最终调成了0.1算是平衡点。还有一个容易被忽略的细节检索结果不要一股脑全塞给模型。我一般只取Top 3到5条记忆注入Prompt宁可少给也不要贪多。因为记忆条目和当前问题可能只是语义相关不是真的有用喂得太多反而分散模型注意力。大批量记忆召回只是中间结果真正进Prompt的一定是精挑细选后的极小集合。3.3 遗忘与更新防止记忆腐化记忆和人的记忆一样也会腐化。用户三年前喜欢深夜蹦迪今年可能已经转成早睡早起用户上个季度说讨厌吃辣这季度可能开始尝试川菜。系统如果死守着旧记忆用户稍微聊一点新话题就会觉得自己被贴了旧标签。我在工程上做了一套遗忘机制核心是两个规则。第一个是长期未访问衰减一条记忆如果超过设定时间未被任何对话召回重要性分定期下降直到被清理。第二个是冲突覆盖用户如果明确表达了新偏好并否认旧偏好旧记忆会被标记失效而不是简单追加一条矛盾记录。def evict_if_needed(user_id, memory_store): # 每天定时任务扫描一次 expired memory_store.scan( user_iduser_id, conditionlast_access_at now - INTERVAL 90 DAY AND access_count 3 ) for item in expired: memory_store.soft_delete(item[memory_id])这个阈值一定要根据业务灵活调整。比如我们的产品是工具类智能体用户生命周期短90天不访问基本可以判定过时如果是情感陪伴类产品用户可能一年前的一条关键记忆仍然很重要就不该这么激进。4. “千人千面”的落地画像标签如何驱动回复差异记忆如果只是让智能体在用户提到“你之前说过”时有反应那还远远不够。记忆真正带来的产品价值是让同一个问题在不同用户那里得到不同味道的答案。这就是“千人千面”的核心。要做到这一点不能只靠事实层召回画像层必须真正参与到Prompt组装中。4.1 从记忆里提取画像标签画像标签是从事实层聚合出来的。最简单的做法是定期跑一次批量任务把每个用户最近积累的事实记忆喂给LLM让它输出若干标签。比如用户多次提到“在公司做产品经理”“经常熬夜”“最近在改版”输出标签就可能是产品从业者、夜猫子、当前关注产品改版。标签不追求多追求稳定和克制。我一般控制在10个以内超过10个就会开始互相矛盾。比如“喜欢简洁回复”和“喜欢详细分析”同时出现说明提取逻辑有问题要么是用户在不同场景确实有不同要求要么是抽取时误读了上下文。遇到这种情况我宁可用时间新鲜度去压旧标签也不要让矛盾标签同时进入Prompt。4.2 动态Prompt组装每家智能体底层模型可以完全一样但最终用户感受到的差异来自Prompt里的记忆注入。我在“想想”里维护了一个动态Prompt模板每次请求前先用用户画像和召回记忆填充槽位再发给模型。你是智能体“想想”请根据以下信息回答用户的问题。 【用户画像】 {{profile}} 【核心记忆】 {{memories}} 【最近几轮对话】 {{recent_history}} 【用户当前问题】 {{query}} 要求在回答时自然参考上述记忆但不要刻意复述记忆内容。这里有个小技巧模板里不要写“如果记忆与问题无关则忽略”这种空泛的话模型往往不会严格执行。更好的方式是在召回侧就把无关内容过滤掉让进入Prompt的记忆尽量都是高相关片段。Prompt层面只负责“利用这些信息”过滤责任放在检索侧。4.3 同一个问题两种完全不同的回答用户问“周末有什么适合一个人去的地方”如果画像层显示用户平时喜欢安静、常去书店智能体会推荐城市书店、美术馆、独立咖啡馆如果画像层显示用户有孩子、周末基本陪娃智能体会推荐亲子公园、科技馆、短途自驾路线。模型只有一套Prompt里的画像不同输出就完全不一样。这个体验一旦做出来用户是非常敏感的。有用户曾经在反馈里写过一句让我印象很深的话“它好像真的知道我是谁。”这句话背后靠的其实就是画像层和记忆召回而不是玄学。只要把画像标签做得准确、把记忆召回做得克制任何智能体都能复现这种效果。5. 上线后踩过的坑召回噪声、隐私边界与离线评估任何系统上线前都是理想状态上线后才开始面对真实世界的毒打。记忆系统更是如此。我在“想想”上线半年里踩过不少坑下面这几个最有代表性。5.1 召回噪声是最容易翻车的地方最开始我以为向量召回已经够准了结果发现一个特别常见的问题向量召回会把两条语义相似但实际上互相冲突的记忆同时返回。比如用户上个月说“最近在减肥晚上不吃主食”本周说“最近健身增肌晚餐要加碳水”两条记忆语义上都和“吃饭”相关被同时召回后模型想融合它们反而生成了一句前后矛盾的建议。对策是在每次写入或更新时对同类事实做冲突检测。如果用户对同一主题给出了新说法旧条目直接降权标为过期。另外检索返回的条目要限制数量宁可只给两条高度一致的记忆也不要硬凑五条互相打架的内容。实测下来召回条数从Top 10压到Top 5后回答矛盾率降了不少。5.2 隐私边界记忆越强用户越需要可控记忆能力越强用户对隐私的担忧也会成比例上升。这不仅是合规问题更是信任问题。我们做了三件事第一提供记忆详情页用户可以查看系统记住了自己哪些信息第二提供一键清除用户能删除指定标签或全部长期记忆第三在写入阶段做敏感信息拦截身份证号、银行卡、完整家庭住址这类明显个人敏感信息不进向量库。做拦截的时候要注意不要用正则硬匹配就完事。有些用户会用间接表述比如“我家在某某小区旁边”“我女儿在某某学校上学”。更靠谱的方案还是用LLM做敏感度分类同时人工抽检漏网样本持续迭代Prompt。隐私设计的核心不是让系统“看不见”而是让用户随时可以叫停。5.3 离线评估与线上指标判断记忆系统好不好不能只看“用户多聊了几轮”。我们维护了一个小型评估集包含50条需要调取旧记忆才能回答的对话以及30条需要避免被旧记忆干扰的对话。每天离线跑一次记录两个指标命中率和误伤率。命中率是正确召回并利用记忆的比例误伤率是在不需要记忆时错误参考了旧记忆的比例。线上观察指标也要跟着变化。除了对话轮次和留存之外我会额外看用户主动删除记忆的频率以及“你又不记得了”“我不是说过了吗”这类负面反馈的收录量。这两个指标比任何离线指标都真实。如果删除频率偏高说明写入策略太激进如果负面反馈偏高说明召回策略太弱用户明显感觉AI没长脑子。5.4 最后一句话留给工程复杂度记忆系统不是越重越好。我见过一上来就规划秒级实时画像、全量记忆图谱、多路召回融合的团队结果项目三个月还出不了可用版本。真正稳妥的顺序是先做简单的用户摘要缓存让同一个用户在连续几次会话里能共享基础信息再补事实层用向量库把关键信息打通然后加画像层让个性化输出成为可能最后才是重排序、冲突检测、遗忘机制这些锦上添花的能力。顺序反了踩坑时你连根因都找不到。我在实际项目中最深的体会是记忆系统的价值不在于“记住多少”而在于“该想起来的时候能不能想起来该忘的时候能不能忘干净”。一句话说完容易把这句话拆成写入、检索、遗忘三个闭环再和画像层联动起来才是真正能做出千人千面体验的路径。