大模型后端长对话记忆架构全解析：从无状态到有状态

做后端的人都有过这种体验：用户和AI助手聊了三十轮，前二十轮里明明已经把需求背景、偏好、禁忌都交代清楚了，结果聊到第三十一轮，AI突然反问一句“您刚刚提到的那个项目背景，方便再描述一下吗？”当场血压就上来了。这不是模型笨，也不是Prompt写得不好，而是我们根本没给模型装“记忆”。大模型API本质上是一次无状态的函数调用——每次请求都是独立的推理过程，服务器不保存上一个请求的任何信息。所以长对话记忆设计，就是把“无状态”变成“有状态”，把一次性的对话延续成真正连续的多轮交互。

这一章我要讲的，就是大模型后端里长对话记忆的完整落地过程。从记忆到底该存什么、存在哪、怎么写入、怎么读取、怎么更新，到怎么评估这套记忆系统好不好用，我会结合自己做的几个真实项目，把架构选型和踩过的坑都拆开讲清楚。适合正在做AI应用后端、聊天机器人、Agent系统的工程师，也适合技术负责人评估记忆方案时做参考。内容偏工程实践，不涉及算法训练，看完能直接指导你设计自己业务的记忆链路。

1. 先想清楚：记忆系统到底要解决什么问题

1.1 无状态API带来的“失忆”困境

大模型接口的本质，是每次请求都独立推理。你传一段Prompt进去，模型给你返回一段文本，然后这次交互就结束了，服务器不会帮你记住任何东西。你可以把它想象成一个很聪明但得了短期失忆症的店员：每次你进店，他都微笑着问你“您好，今天想买什么？”——哪怕你五分钟前刚跟他说完你的预算和喜好。

所以早期的多轮对话实现，都是靠前端把所有历史消息原封不动地拼在一起，传给模型。这种方式在小规模、短对话的场景下能跑，但漫无边际地累积下去就会出现两个问题：

第一，上下文窗口是有限的。即便现在主流模型支持128K甚至200K的上下文，可如果用户一天聊了几百轮，光粘贴历史消息就可能把Token预算占满，模型根本没有余量认真推理。超过窗口上限就只能截断，而截断往往丢掉的恰恰是最早但最关键的信息。

第二，Token成本线性增长。很多商业模型按Token计费，历史消息全量传输意味着每一轮新对话都要为之前所有的内容付一次费。用户聊得越多，单轮成本越高，业务规模一大，这笔开销是撑不住的。

长对话记忆设计的本质，就是在“完整保存信息”和“控制上下文开销”之间找平衡。它不是简单地加个缓存，而是要做一套有策略的信息管理机制：什么信息必须长期留着，什么信息用一次就可以丢，什么信息需要压缩成摘要，什么信息要按需检索出来。

1.2 短期记忆与长期记忆的边界划分

设计记忆系统的第一步，是分清记忆的类型。很多新手上来就整一张大表，把所有对话全塞进去，这是不对的。短期记忆和长期记忆的目标、存储方式、读取策略完全不同，混在一起做，最后一定两头都做不好。

我习惯用一个很朴素的标准划分：短期记忆服务于“这一次会话的连续性”，长期记忆服务于“下一次会话的连贯性”。

短期记忆的典型内容，是当前对话里刚刚出现的上下文——用户上一句说的需求、刚才讨论的方案细节、还没执行完的任务状态。它更新极快，每轮对话都在变，生命周期短，通常只在这个会话内有效。

长期记忆则跨会话存在，它是用户反复表达出来的稳定信息——职业背景、行业偏好、表达风格、常去的城市、不喜欢的方式。这些东西不会因为一次会话结束就失效，反而应该在用户下次回来时第一时间被调用。

这两种记忆在存储介质和读写模式上天然不同，我后面会专门讲存储选型。这里只想强调：任何记忆系统设计，都应该先明确自己在做哪一种记忆，否则后续全乱套。

1.3 业务场景决定记忆策略

还有一个前置问题：你的产品到底需不需要复杂的记忆系统？不同的业务场景，对记忆的诉求差距非常大。

客服机器人需要的是“结构化事实记忆”——用户之前反馈过什么问题、订单号是多少、售后处理到哪一步了。这种记忆更偏业务数据，答案要准确，不能靠模型“回忆”，应该直接查库。

写作助手需要的是“风格偏好记忆”——用户喜欢简洁还是华丽的文风，习惯用第一人称还是第三人称，有没有固定的术语表。这种记忆要靠长期对话里反复抽取和沉淀。

教育产品需要的是“学习进度记忆”——学生哪些知识点掌握了、哪些还在错、上次练习做到什么难度。这种记忆必须细粒度、可追溯，并且要随着学习进展动态更新。

同样是“长对话记忆”，落到不同业务上，存储结构、抽取逻辑、更新策略可能是完全不同的三套实现。我的建议是：先别急着写代码，把你业务里的“记忆单元”定义清楚，再谈架构。所谓记忆单元，就是系统里最小粒度的可存储信息，比如“用户偏好：喜欢简洁回复”“订单状态：已发货”这种(key, value, 时间戳, 置信度)结构。定义不清楚，后面谈什么都是空中楼阁。

2. 记忆写入：怎么决定什么东西值得记住

2.1 不是所有对话都值得写入记忆

明确了记忆要解决的问题之后，下一步就是怎么把对话里的信息变成记忆。这里最常见的错误，是“每轮对话都做信息抽取”——把每一句用户消息都交给模型提炼，结果抽出来的大量内容是噪音，比如“用户今天问了天气”“用户说了一句谢谢”。

我自己的经验是，记忆写入要有触发条件。通常这几类情况，才值得把内容沉淀成记忆：

一是用户明确陈述事实性信息。比如“我在一家跨境电商公司做运营”“我们主要做欧美市场”“我平时用Python比较多”。这类话是用户主动交代的背景，是长期记忆最优质的来源。

二是用户表达了稳定的偏好或禁忌。“我不喜欢太正式的语气”“请直接给结论，不要铺垫”“以后别再提那个方案了”。这些信息影响后续所有交互，价值极高。

三是关键任务节点。比如“我已经把代码推到仓库了，你帮我看一下接下来怎么部署”。这个动作本身可能是一次性的，但它是当前任务链条的重要状态，需要写进短期记忆。

四是用户的纠正行为。当用户说“不对，你理解错了”“我说的不是这个意思”时，往往意味着之前某个记忆项是错误的或需要更新的。这是记忆系统最重要的学习时机，说错过才记得牢。

触发条件确定后，才轮到信息抽取。抽取依赖大模型做结构化解析，可靠性和准确率都比正则好得多。正则适合格式固定的内容，但对话语言太灵活了——用户可能说“我不爱喝甜的”“别给我加糖”“我戒糖了”，表达方式千变万化，正则永远写不全。

2.2 用二次调用做结构化抽取

我自己常用的做法，是在对话流里加一个独立的抽取环节。主对话继续正常走，后端同时把当前轮次的用户消息喂给一个相对小型的模型，让它按照JSON模板输出抽取结果。

抽取模板大致长这样：

{ "user_facts": [ {"fact": "用户在跨境电商公司做运营", "confidence": 0.9} ], "preferences": [ {"preference": "喜欢直接给结论", "negative": false} ], "tasks": [ {"description": "检查代码部署方案", "status": "pending"} ], "corrections": [ {"original": "方案A可行", "updated": "方案A不可行，改用方案B"} ] }

注意置信度这个字段。早期我做记忆系统时就吃过亏，不管什么信息都一视同仁存进去，结果用户随口说的一句话被当成长期偏好，越记越偏。后来给每条记忆加了置信度，并且设了“多次验证才能升级为长期记忆”的机制——一次对话里提到的偏好，先存成短期候选记忆；同一信息在不同时间、不同语境下重复出现两三次，才把它固化到长期记忆里去。这样做牺牲了一点冷启动效率，但换来了长期的高质量。

抽取环节有两点要注意：一是抽取模型不一定要用旗舰大模型，用便宜的轻量模型就能完成，成本能省不少；二是抽取失败要能降级，比如模型超时或返回了非法JSON，后端要能兜底，不能让用户感知到额外延迟。

2.3 去重与更新：记忆不能越记越乱

有了抽取结果，写入存储之前还有个关键环节：去重和更新。

用户在不同轮次可能提到同一件事，但说法不一样。比如第一轮说“我在做跨境电商”，第五轮说“我主要负责欧洲站的选品”，这两条信息不是独立的——后者是对前者的补充。如果盲目都存进去，检索时可能拉出两条碎片，模型不知道到底以哪条为准。

我的方案是给记忆项设计“合并键”。每一类记忆有一个归属标识，比如“user_profile.occupation”“preference.style.tone”。新抽取出的事实进来后，先按归属标识查是否已有旧记忆：如果旧记忆存在且新旧内容不冲突，就合并成一条更完整的话术；如果新旧冲突，则用新内容覆盖旧内容，并保留版本号。这样既避免了碎片化，也保证了记忆更新的方向——用户新说的话，优先级永远高于旧话。

更新策略里还有个细节：同样的信息被重复提到，要记得提升置信度，而不是再存一条。置信度可以从0.6提升到0.8，从候选区升入长期区。系统要能识别这种重复信号，这是判断信息稳定性的高效方式。

3. 记忆存储：Redis、向量库还是关系库

3.1 三类存储的定位差异

聊到存储方案，避不开三个选择：Redis、关系型数据库、向量数据库。很多人问我哪个好，其实答案是各有各的用处，看你的记忆类型来定。

Redis适合做短期记忆和热数据缓存。特点是读写速度极快，支持给Key设置过期时间——完美匹配短期记忆“会话结束就失效”的特性。比如我会把“当前会话最近20轮原始对话”直接放Redis里，Key设计成session:{session_id}:recent_context，带TTL，会话结束自动消失。

关系型数据库适合做长期记忆的结构化管理。长期记忆是有用户维度的、需要审计和追溯的，而且往往要支持复杂的条件查询——“找出所有置信度大于0.8的风格偏好”。这类需求用Redis会很别扭，但用关系库就能清晰表达。用户表、记忆项表、版本表，按用户ID关联，天然支持事务和回滚。

向量数据库适合做语义检索。因为长期记忆的读取，很多时候不是精确查某个字段，而是“根据当前问题，找到语义上最相关的历史记忆”。比如用户随口说一句“上次那个部署方案遇到什么问题来着”，你没法用关键词检索“部署方案”，因为用户原话里未必有这四个字。把每一条长期记忆做向量化后存进向量库，用当前问题做相似度检索，就能把语义相近、但字面不相同的信息捞出来。

3.2 我实际用的混合存储架构

单独用一种存储扛不住全部需求，所以我的方案是混合架构，各取所长：

短期记忆用Redis，存最近N轮原始对话和轻量会话上下文，带TTL，过期自动清理。

候选记忆和长期记忆用关系库，存结构化字段——用户ID、记忆类型、内容、置信度、来源轮次、创建时间、更新时间、版本号。这是系统的“事实总账”，保证每一条记忆都可追溯、可审计。

向量库存长期记忆的语义向量，用于检索召回。每次关系库里的长期记忆有新增或更新，后端异步生成对应的向量索引。这里注意要异步，不能阻塞主对话链路。

对象存储或廉价存储服务存全量对话日志，用于离线分析和回溯。平时读不到，但如果线上出了事故，可以捞历史对话回来排查。

注意：短期记忆和高频读取的长期记忆，读写路径一定要走Redis缓存，关系库是底账。如果每轮对话都直查关系库做记忆读取，延迟会压不住。缓存过期或未命中的时候再回源查库，然后回填缓存。

3.3 隔离与脱敏：记忆也是敏感数据

记忆系统存储的是用户信息，天然涉及隐私。这个环节如果处理不好，再好的架构也白搭。

多租户隔离是底线。不同用户、不同业务线的记忆数据，存储上必须做逻辑隔离。最简单的做法是在记忆表里加owner_id字段，每个业务系统的读取只允许带自己的owner_id条件。有条件的话，不同业务线用不同的库表，物理隔离，避免一个业务线的异常逻辑影响另一个。

脱敏策略要前置。有一条铁律：密码、密钥、卡号、身份证号这类敏感字段，绝对不允许进入记忆系统。内容入库前先跑一遍脱敏服务，该遮蔽的遮蔽，该替换的替换。我见过有人把用户的API密钥当成“用户信息”记进长期记忆，结果在会话中被模型原样吐出来的事故，非常狼狈。

记忆数据也要做备份和审计。关系库还好说，很多团队忽略了向量库的备份。向量库一旦损坏，全部语义索引都要重建，成本很高。我的做法是定期导出全量记忆快照到对象存储，同时记录索引版本号，确保能按版本恢复。

4. 记忆读取与拼装：怎么用好有限的上下文窗口

4.1 上下文窗口是稀缺资源

存储写好了，接下来是读取。这一步直接决定了模型“看到的”内容是什么样，也直接决定回复质量。

很多工程师容易产生误解，觉得既然做了记忆系统，那历史就应该全部保留下来。实际上，记忆系统的核心使命恰恰是“不保留全部”。上下文窗口是稀缺资源，每一轮对话，模型能看到的Token总数是固定的。假设你用128K窗口的模型，其中系统提示词占了2K，用户当前问题可能占1K，那么留给历史记忆的空间大概有100多K。如果你把过去五百轮对话全塞进去，确实塞得下，但模型的注意力会被大量无关历史稀释，反而干扰对当前问题的推理。

我自己的经验，是把读取策略设计成三个层次叠加，由稳定到灵活，按优先级逐层拼装进最终Prompt。

4.2 三层读取策略：系统提示词层、摘要层、滑动窗口层

第一层，系统提示词层，承载长期稳定的用户画像。用户最核心、置信度最高的记忆——职业背景、沟通偏好、明确禁忌——固定拼装进系统提示词里。因为系统提示词的优先级最高、位置最靠前，模型从第一步就“认识”这个用户。这一层的信息量要克制，控制在1K Token以内，只放最重要的画像信息。

第二层，摘要层，承载历史对话的压缩信息。从第二轮对话开始，系统就可以把早期的对话内容交给大模型生成摘要，存成“会话摘要”。当新的对话进来时，摘要会持续增量更新——把新对话的关键信息合并进已有的摘要里。最终放进Prompt的是一个几百Token的摘要，而不是几千Token的原始对话。摘要要控制压缩率，好的摘要在保住关键情节的同时，把表达性的内容全部剔除。

第三层，滑动窗口层，保留最近N轮原始对话。最近的对话信息粒度最细，很多关键细节——用户刚说的数据、上一轮模型给出的承诺——都在原始文本里。这一层不压缩、不抽取，原样保留，按最近优先排列。窗口大小根据模型上限动态计算，比如128K上下文的模型，最近10轮原始对话通常就够用了。

三层拼装完，最终Prompt的结构是：系统提示词（含核心画像） → 会话摘要 → 检索到的相关长期记忆 → 最近对话滑动窗口 → 当前用户输入。

4.3 按需检索：用语义记忆补齐细节

上面三层覆盖的是“稳定的”和“渐变的”信息，但用户的问题可能随时涉及到某个很久以前的具体细节。这时候就要靠语义检索去“按需召回”。

召回路径是这样：拿到当前用户问题，先做一层意图判断——这个问题是否涉及历史事实。如果不涉及，就没必要做检索，省一次查询。如果涉及，则对问题做向量化，去向量库召回Top-K条相关记忆。

召回之后的“重排”是很多人忽略的环节。向量相似度只是第一道筛选，纯靠它排序会有不少误伤——语义接近但实际无关的片段会混进来。我的做法是召回两倍数量的候选（比如Top20），然后做一个轻量重排：关键词重合度加分、时间近者加分、置信度高者加分、与当前问题主题类别匹配者加分。最终取Top5拼进Prompt。

5. 记忆的更新与遗忘：让系统学会“翻篇”

5.1 用户纠正时的记忆修改

记忆不是写进去就完了，它必须能改、能失效、能“翻篇”。

最典型的场景就是用户纠正。用户说“我上次说的那个方案不对，换个思路”，这意味着记忆系统里某个旧记忆作废了，新记忆要覆盖旧记忆。这个逻辑说起来简单，实现上却要小心。我早期直接删除旧记忆，结果发现用户可能只是针对某一句话做更正，而不是否定全部相关历史。比如用户说“那个方案不对，但我们讨论的预算范围不变”，删掉整条旧记忆就误伤了有效信息。

后来我改成“状态标记+新记忆写入”的方式：旧记忆不物理删除，只标记为superseded状态，同时写入新的记忆项，并通过supersedes_id字段建立关联。这样旧信息仍然可追溯，新信息即时生效，而且如果发现误伤，还能找回上一版。这个设计在我排查线上记忆混乱问题时帮了很大忙。

5.2 过期记忆的清理策略

记忆如果没有清理机制，长期运行下来一定会臃肿。用户半年前说过“我喜欢喝美式咖啡”，现在可能早换成“我只喝冷萃了”，半年里三百条临时性记忆混杂在一起，检索时噪音极大。

我的清理策略分三层：

第一层是TTL过期。短期记忆Redis里的Key天然带过期时间，这个不用多说。

第二层是置信度衰减。长期记忆不能无限久地保持高置信度。用户说的某条偏好，如果半年没被重新提及，也没有交互行为验证，置信度会按月衰减。衰减到阈值以下，这条记忆就从“活跃状态”降级为“归档状态”，不再参与检索，但保留在库里以备未来重新激活。

第三层是定期批处理。每天凌晨跑一次记忆清理任务，扫描所有记忆项，做三件事：删除TTL到期的短期记忆、将置信度过低的长期记忆归档、合并内容重复的记忆项。

注意：清理任务一定要设计成幂等操作，并且要有开关和灰度开关。我在实际项目里曾经因为清理逻辑写了一个小的条件判断错误，批量标记了不该归档的记忆，当天线上用户反馈“AI忘了我的偏好”。那次事故之后，所有清理任务都先出报告、确认无误再执行。

5.3 记忆合并与沉淀

最后一个更新逻辑是“沉淀”。用户在不同时间表达过相同方向的偏好，系统应该把它们合并成一条更稳定、更有代表性的记忆。

比如用户第一轮说“尽量简短一点”，第十五轮说“这次回复别太长”，第三十轮说“三句话讲完就行”，三条表述不同但本质相同。系统应该识别出它们属于同一语义簇，合并成一条：“用户偏好简短回复，多次表达，置信度0.9”。这种沉淀后的记忆，比任何单条原始记忆都可靠。

我自己的实现是：将关键词和语义向量相近的记忆项，定期做聚类分析。聚类结果人工抽检后，自动生成更高层级的“画像记忆”，覆盖原来分散的碎片记忆。

6. 评估体系：怎么知道记忆系统做得够不够好

6.1 离线评估：构造回归测试集

记忆系统做得对不对，不能靠拍脑袋。一定要有评估环节。

我推荐的第一个方式是离线评估。人工构造一批带有“记忆需求”的对话测试集。比如这样一个测试用例：第一轮用户说“我叫李明，在一家做智能家居的公司工作，负责产品运营”，后续隔了很多轮之后，用户问“我公司的业务方向是什么？”——模型应该在不需要用户重复的前提下答出“智能家居”。

测试集里要覆盖几类关键场景：跨多轮信息保持、用户中途纠正、跨天回到会话、相似语义的不同表述、携带情感色彩的信息（如“我不喜欢某品牌，以后别提它”）。每个用例标注标准答案，跑回归测试时拿测试集灌进对话系统，计算记忆命中率——也就是无需重复陈述、模型能正确复述历史事实的比例。准确率、召回率也要盯，特别是“该记住的没记住”和“不该记住的瞎记”这两类错误，原因完全不同。

6.2 线上观测：指标要落地

离线测试只证明“理论上没问题”，真正好不好用，要看线上指标。

我最看重四个线上指标：

第一是“重复陈述率”。用户在一轮对话里，主动重复之前已经交代过的信息的次数。如果记忆效果好，这个数应该很低——用户不需要反复交代背景。我见过加了记忆系统后这个指标明显下降的案例，但要注意它也可能因为用户本身话多而波动，需要结合会话长度做归一化。

第二是“记忆召回率”。用户问了一个涉及历史信息的问题，系统能不能把相关信息正确召回并注入Prompt。这个可以通过每次检索的日志来统计，看实际召回的Top-K里有多少是与问题语义相关的。

第三是“上下文截断率”。因为窗口不够，导致Prompt被强制截断的比例。加了记忆系统以后，这个指标应该稳定在低位。如果发现某类业务场景下截断率依然很高，说明分层压缩策略还没做到位。

第四是“用户反馈信号”。用户点踩、要求重说、或者直接评论“你忘了我刚才说的”，这些都是记忆系统失效的直接证据。把这部分信号采集下来，定期聚类分析，你会发现很多离线测试覆盖不到的长尾问题。

6.3 实测的一组效果对比

拿我自己做的一个问答机器人项目举例，纯Prompt拼接的方案和加了记忆系统的方案，在50轮长对话场景下的对比数据很直观：

整体对用户体感的影响，最直接的是“对话变连贯了”。用户不再需要重复说明背景，系统也能够在聊到几十轮之后，准确回忆起对方在最初轮次提到的细节。这不只是体验提升，对客服、咨询、教育等场景来说，直接关系到业务转化效率。

7. 常见问题与排查技巧实录

7.1 记忆写入风暴

有段时间我上线了“每轮都做信息抽取”的逻辑，结果线上监控一看，主对话接口的P99延迟从800毫秒直接飙到2.3秒，Token成本翻了快一倍。原因是每一轮对话都额外调了抽取模型，而且抽取模型和主模型存在串行依赖，用户等待时间线性叠加。

排查思路：先加日志确认延迟都花在哪里，再把抽取链路改成完全异步——主对话先返回，抽取任务放到消息队列里慢慢跑。同时也在入口处加了规则前置过滤：先用简单规则判断这一轮是否可能包含值得记忆的信息，不满足直接跳过抽取。这套组合下来，延迟恢复到基线水平，记忆写入质量反而提升了，因为过滤掉了大量无效抽取。

7.2 检索召回的内容不相关

语义检索用得久了才发现，向量相似度不等于“当前真正需要的信息”。用户问“刚才那个方案部署到哪个环境了”，向量的语义重心容易偏向“部署”，把一堆“如何部署”的通用知识捞上来，而不是具体这次会话里的上下文。

排查思路：一是加重排分数里关键词命中的权重，让精确字面匹配有更高的优先级；二是加入“会话锚点”信息——当前会话ID、最近几轮摘要，在检索前先压缩候选范围；三是对召回的每条记忆打一个“时效相关度”分，时间越近、和当前对话主题越接近，排序越靠前。

7.3 摘要越压越大

摘要压缩是三层策略里最容易失控的一环。我在项目初期做过一个自动增量摘要，本来是压缩历史对话，结果摘要模型每更新一次，就在旧摘要后面追加一段，几十轮之后摘要本身的Token数比原始对话还多。

排查思路：给摘要设硬性上限，比如最多500 Token。新增信息进来时，先做“摘要重写”而不是“摘要追加”，把旧摘要和新信息合并后重新压缩。定期检查摘要的压缩率，如果原有内容损失严重，考虑分层摘要——近期的详细摘要+早期的极简摘要。

7.4 多轮后模型开始“人格分裂”

有几次用户反馈，聊到后半段，模型一会儿说自己“很了解用户”，一会儿又对用户的基本信息表示不确定。查了日志才发现，是长期记忆里的老信息和短期记忆里的新信息发生了冲突——用户早期说“我住在上海”，系统Prompt里写着“上海”，但用户最新一轮说“我上个月搬去杭州了”，摘要里又写着“杭州”。

排查思路：给记忆项增加版本链，新版本引用旧版本，并在拼装Prompt时做一次基础的一致性检查——如果同时出现互相矛盾的画像信息，强制采用最新版本，并且把旧版本标注为superseded。这个逻辑看起来简单，但能避免大量“AI前后矛盾”的低级体验问题。

7.5 记忆系统上线后没有效果

还有一种情况——上了整套记忆系统后，跑了一个月A/B实验，用户体验指标没有明显变化。

这种情况我遇到过，排查后发现原因往往是：业务场景本身不需要长对话记忆。比如用户每次过来问的都是标准化问题，三句话内解决，根本不存在“跨轮依赖”。这时候上记忆系统是负优化——白白增加了延迟和成本。

所以后来我养成了一个习惯：先做数据排查，统计真实用户会话的平均轮数、重复陈述的频次、跨会话回访的比例，确认业务真的有记忆需求，再做架构设计。

做记忆系统这几年，我越来越觉得它不像是一个功能模块，而更像一套“数据治理”逻辑的延伸。它本质上是在回答几个问题：什么值得记住、以什么形式记住、什么时候该回忆起来、什么时候该忘掉。把这些想清楚，架构再复杂也不会乱。

我个人实际中的体会是：不要一上来就追求高大全的记忆框架，先从一个最小的闭环跑通——把最近的对话短期记忆存下来，让用户在100轮内保持连贯，这就已经比大多数产品好用了。再从用户反馈里发现真实需求，逐步叠加长期记忆、语义检索、主动遗忘这些能力。踩过几次坑之后你会明白，记忆系统的上限不是技术，而是对用户真实使用模式的理解深度。