🧑💻 面试官：怎样让 Agent 记住用户偏好？
🙋♂️ 我：把偏好保存下来，在后面的会话中按需检索，再放进模型的上下文。
🧑💻 面试官：用户以前说喜欢 Python，今天说“这次演示用 TypeScript”，要覆盖吗？
🙋♂️ 我：这可能只是本次任务的要求，不能直接改掉长期偏好。
🧑💻 面试官：那他说“以后都用 TypeScript”呢？两条记忆一起被搜出来，模型应该信哪条？
长期记忆不是一个只进不出的聊天仓库。要让它有用，必须知道一条信息属于谁、什么时候有效，以及何时应该失效。
面试速答（60 秒版）
Agent 的长期记忆，是把跨会话仍然有用的信息保存下来，并在后续任务需要时取用，不是把所有聊天都永久保存。
设计时，我会给记忆记录用户、适用范围、来源、更新时间和有效状态。比如“默认使用 Python”是长期偏好，“这次演示用 TypeScript”则只影响当前任务。
如果用户明确说以后改用 TypeScript，就更新对应偏好，并让旧值不再作为当前有效记忆参与检索，而不是简单追加第二条。表达不清楚、又会影响后续行为时，需要确认。
读取时，先按用户和范围过滤，再选相关内容放进上下文。同时还要处理并发更新、过期和删除，避免旧缓存继续返回已经失效的信息。
最后，记忆只能帮助个性化和任务衔接，不能成为执行高风险动作的授权依据。
知识点详解：从“记住一句话”到维护有效信息
先区分长期偏好与当前要求
假设咱们正在做一个编程学习助手。用户之前说：“以后给我示例，默认用 Python。”
这句话适合保存为长期偏好，因为它明确指向后续任务。第二天，用户又说：“今天要给前端同学演示，这次用 TypeScript。”
如果系统直接覆盖默认语言，下次用户没有说明语言时，也会得到 TypeScript 示例。这不是记忆更及时，而是把临时要求误当成长期变化。
所以，先判断信息的适用范围：当前回答、当前任务、某个项目，还是之后所有相关会话。这个判断不清楚，后面采用多好的向量数据库都无法补救。
在这个例子中，本次任务按 TypeScript 执行，长期偏好仍是 Python。它们不是矛盾的两个事实，而是在不同范围内生效。
一条可维护的记忆，需要存什么？
不必一开始设计庞大的“记忆大脑”。对于明确的偏好，用一条结构化记录就能解决很多问题。
| 字段 | 假设值 | 用来解决什么问题 |
|---|---|---|
| 所属用户 | user-17 | 防止不同用户混用记忆 |
| 记忆键 | preferred_example_language | 知道更新的是哪一个偏好 |
| 值 | Python | 当前默认选择 |
| 适用范围 | 编程学习中的代码示例 | 防止扩大到所有任务 |
| 来源 | 用户明确表达，对话 msg-8 | 能核对它为什么被记住 |
| 版本与状态 | v1，有效 | 处理更新和失效 |
这些字段是本文的设计示例，并非框架强制要求。LangChain 的长期记忆文档提供了按命名空间存取和检索数据的能力，但什么值得记、怎样合并冲突，仍然需要应用制定规则。
有些信息是模型推断出来的，例如“用户可能是初学者”。这类推断应该和用户明确表达分开，不能不加说明地变成长期事实；确实没有必要保存时，就不要写入。
用户真正改口时，更新同一个事实
接下来，用户明确说：“我之后主要学前端了，以后的示例默认用 TypeScript。”
这次就不是临时覆盖。系统可以把同一用户、同一范围内的语言偏好更新为 TypeScript，记录新来源与版本，并让旧值退出当前有效集合。
旧版本是否保留历史，要看产品需要和数据保留规则。即使为了排错保留，也不能让普通记忆检索继续把它作为当前偏好返回。
这也是“只追加向量”容易出问题的地方：新旧两句话语义都很相关，检索可能把它们一起找出来。仅按相似度排序，并不能判断哪句话已经被替代。
因此，检索前后需要有明确的有效性过滤。简单偏好可以直接按键读取，不一定使用向量检索；只有自由文本经验、跨主题材料等内容，才更需要语义检索帮助找到候选。
对于向量索引与主记录分开保存的系统，索引更新可能有延迟。可以在返回候选之后，再按主记录的有效状态核对，避免旧向量仍然命中时把过期内容交给模型。
读取出来之后，也不能无条件执行
下次用户问一个 Python 项目的问题，即使当前默认偏好已经是 TypeScript，也应该尊重具体项目和本次要求，而不是机械地按照偏好切换语言。
长期偏好用于补充没有说清楚的默认选择，不应该覆盖用户当前明确的任务条件。
同样，如果记忆中写着“用户不喜欢反复确认”，也不能由此推导出“可以不确认就删除文件”。操作授权需要根据当前任务和服务端策略判断。保存的信息再像用户原话，也不能直接扩展系统权限。
在多用户系统中，用户标识要从可信会话获取，不能让模型随意填一个用户编号去检索别人的记忆。命名空间有助于组织数据，但访问控制仍然需要应用落实。
更新与删除，要验证到实际读取
可以设计一段连续对话来测试：先设置 Python 偏好，再临时使用 TypeScript，随后修改长期默认，最后要求删除这个偏好。每一步之后，都发起一个新会话，看最终输入和回答是否符合预期。
“删除成功”的检查，也不能只看主表里少了一行。还要检查语义索引、缓存、后台总结任务是否会再次把旧值带回来。保留日志与备份的策略也应提前说明，不能把“不再用于回答”宣传成“所有副本已立即物理清除”。
面试官继续追问
两个会话同时更新偏好，怎么办？
可以用版本号检查避免旧任务覆盖新值：更新时说明基于哪个版本，版本已经变化就重新读取、判断。不要只按后台任务完成时间选择“最新”，因为更早开始的旧对话可能反而更晚写入。
用户只说“Python 看烦了”，要自动改偏好吗？
这句话不能直接证明他以后都要换语言。可以调整当前回答，或者在影响后续默认选择之前询问。若产品允许推断性记忆，也应标注不确定性、限制生效范围，并提供查看和纠正方式。
长期记忆是不是保存得越多越好？
不是。无关、过期或错误记忆会增加检索干扰，也会带来隐私和维护成本。应该围绕产品目标保存必要内容，并允许用户控制。评价时看它是否减少重复说明、是否产生错误沿用，而不只看记住了多少条。
面试速记卡
- 写入标准：保存跨会话仍有价值的信息，不把全部聊天当记忆。
- 范围判断：临时要求与长期偏好分开处理。
- 更新方式：更新同一事实的有效版本，不只追加相似文本。
- 读取过程：过滤用户、范围和有效状态，再选入当前上下文。
- 安全边界：记忆可以提供背景，不能代替当前授权。
