记忆
很多候选人会把“聊天历史”“RAG”“长期记忆”混成一个概念，这一页就是专门用来拆边界的。面试里一旦这几个概念讲混，后面关于召回、写入、清理和用户删除的问题就会越答越乱。
读这一页时，建议始终抓住三个区分轴：容量和机制、知识和状态、写入和召回。先用短答版把层次背顺，再用深答版补“污染是怎么来的、为什么要分层、哪些信息根本不该写进去”，这样用户一追问，你能立刻把问题拉回到正确框架里。
高频题
1. Agent 的记忆和上下文窗口有什么区别？
题目：既然模型调用时都会带上下文，为什么还需要单独谈记忆？
面试官想听什么：你能不能把模型接口限制和上层系统设计拆开讲，而不是把“历史很多”直接等于“记忆很好”。
短答版：上下文窗口是单次模型调用能接收多少输入的限制，记忆则是跨调用保存、筛选和召回信息的策略。前者是模型能力边界，后者是系统设计问题。
深答版：
展开深答版
这题的本质是区分“容量”和“机制”。上下文窗口只是模型单次调用时能看到多少输入，它回答的是“模型这次最多能读多少”；记忆系统回答的则是“哪些信息值得跨调用保留、什么时候召回、怎样注入当前任务”。
所以“有很多历史”不等于“有记忆能力”。系统可以存非常多的历史，但真正高质量的记忆设计，关键在于筛选、组织和调用，而不是一股脑把旧内容塞进 prompt。上下文更像一次会话的可见桌面，记忆更像跨回合的长期状态管理。
工程上，如果只靠拼接历史，成本会高、噪声会多、相关性会越来越差；但如果完全不做记忆，又会失去长期连续性。你可以记成：
上下文是一次看见多少，记忆是长期决定记住什么。追问方向：如果把所有历史都直接拼进去，会遇到哪些问题？
2. 短期记忆和长期记忆该怎么分？
题目：你怎么区分 session 内记忆和跨 session 记忆？
面试官想听什么：你是否知道不同信息生命周期不同，不能把所有信息放进一个统一存储桶里。
短答版：短期记忆主要服务当前任务，强调局部连续性；长期记忆用于跨会话保留稳定事实、偏好和长期状态。分层的意义是把临时上下文和长期事实拆开治理。
深答版：
展开深答版
这题的核心判断是，不同信息的生命周期不一样，所以不能放在一个桶里统一处理。短期记忆更像当前 session 的工作台，重点是让任务不断档；长期记忆更像用户画像或系统账本，重点是跨会话依然成立、依然有复用价值。
一般来说，任务中间状态、局部推理、暂时结论更适合放短期层，因为它们随任务结束就可能失效；用户偏好、稳定约束、组织规则、长期配置更适合放长期层，因为它们会跨 session 持续影响行为。真正难的不是存哪里，而是判断这条信息到底是“暂时有用”还是“长期成立”。
工程上，分层会增加一点设计复杂度，但能明显降低污染和误召回。常见误区是把所有历史都持久化成长期记忆。你可以记成：
短期记忆保连续，长期记忆保稳定。追问方向：哪些信息适合长期保存，哪些应该过期？
3. RAG 和记忆系统是不是一回事？
题目：如果系统已经有向量检索了，还需要记忆层吗？
面试官想听什么：你能不能把“知识检索”和“状态连续性”这两条线分开，不会把所有检索都叫记忆。
短答版：RAG 更偏知识召回，目标是从外部语料里找材料；记忆系统更偏状态连续性，目标是保留关于用户、任务和历史过程的信息。它们可以共用检索技术，但解决的问题不同。
深答版：
展开深答版
这题本质上是在分清“知识”和“状态”。RAG 解决的是知识可达性问题，也就是需要时怎么把外部文档、知识库、代码库里的材料找回来；记忆系统解决的是连续性问题，也就是这个用户、这个会话、这个任务之前发生了什么，后面还要不要延续。
它们底层可能都会用检索技术，但概念上不是一回事。企业文档、产品手册、FAQ 这类更像 RAG；用户偏好、任务阶段、上次结论、长期约束更像记忆。一个管“世界里有什么知识”，一个管“系统和用户之间已经积累了什么状态”。
工程上，如果把所有内容都丢进一个检索池，系统会失去类型边界，很难做精确召回和生命周期治理。你可以记成：
RAG 取外部知识，记忆保内部状态。追问方向：用户偏好、任务状态、企业知识库这三类信息分别该放哪？
4. 记忆污染是怎么发生的？
题目：为什么 Agent 的长期记忆越多，不一定越聪明？
面试官想听什么：你是否理解记忆系统最大的难点在质量治理，而不是存储容量。
短答版：如果记忆写入没有筛选，错误信息、过时信息和局部上下文就会被反复召回，污染后续决策。记忆系统真正难的不是能不能存，而是该存什么、删什么、降权什么。
深答版：
展开深答版
这题的核心判断是，记忆污染通常来自“低质量写入 + 无差别召回”。只要系统把临时猜测、过时事实、用户随口一句话甚至错误总结都写成长期记忆，后续模型就会把这些噪声反复当真，问题会越用越重。
污染不只是“记错了”，还包括版本冲突、来源不清、语义不完整和失效信息继续高频出现。也就是说，记忆最危险的地方不是能不能存下来，而是错误一旦沉淀，会被后面的回答持续放大。
工程上，真正有效的治理手段通常发生在写入前和召回前，比如写入门槛、来源标记、版本信息、时间衰减和删除策略。你可以记成：
记忆污染不是存太少，而是错的东西被长期当真。追问方向：你会用哪些机制降低污染风险？
5. 记忆召回怎么做得更稳？
题目：如果召回太多无关记忆，会影响回答质量，你怎么处理？
面试官想听什么：你有没有一套实际的治理抓手，而不是只会说“优化召回”。
短答版：我一般会从写入筛选、召回排序、类型分层和时间衰减四个方向下手。先减少垃圾写入，再给召回结果加来源和置信度，最后控制注入量，避免稀释模型注意力。
深答版：
展开深答版
这题本质上在问“记忆系统怎么从能用变成好用”。更稳的召回不是靠某一个神奇算法，而是靠整条链路一起治理：写入时减少垃圾内容，召回时按类型和相关性排序，注入时控制数量和格式。
这里最容易忽略的是，召回不仅要看相关性，还要看可信度。高度相关但来源不可靠、版本过旧、没有用户确认的信息，同样可能把系统带偏。所以稳定召回的关键，不只是找到“像”的信息，而是找到“既相关又值得信”的信息。
工程上，分层检索、去重、时间衰减和注入限额都会增加一点复杂度，但通常比“多召回一些让模型自己挑”更稳。你可以记成：
稳召回 = 少垃圾写入 + 好排序 + 少量高价值注入。追问方向：为什么“少量高相关召回”通常比“大量历史拼接”更有效？
扩展题
6. 记忆写入策略该怎么定？
题目：用户说过的话很多，你怎么决定哪些要写成长期记忆？
面试官想听什么：你是不是知道长期记忆的难点首先在写入门槛，而不是先把一切存下来再说。
短答版：我不会默认全量写入，而是按稳定性、复用价值和风险来判断。只有跨会话还成立、后续大概率会用到、且误写成本可控的信息，才值得入长期记忆。
深答版：
展开深答版
这题核心在写入策略，而不是存储技术。一个实用思路是先做类型判断，再做价值判断：稳定偏好、长期目标、账户约束这类跨会话仍然有效的信息适合写入；临时情绪、一次性任务细节、模型猜测则不该直接持久化。
真正的难点是写入门槛。长期记忆一旦写错，会被后续任务持续放大，所以默认策略最好是保守，而不是先全量存下来再慢慢清。漏写的代价通常只是连续性变弱，错写的代价却是长期污染。
工程上，严格写入会少记一些内容，但系统会更稳；宽松写入看似更聪明，长期通常更脏。长期记忆不是缓存池，而是高价值事实层。
追问方向：如果用户一句话里既有稳定偏好也有临时诉求，你会怎么拆？
7. 用户要求忘记某些信息时，系统该怎么处理？
题目：如果用户说“把我之前的偏好删掉”，你觉得记忆系统需要做到什么程度？
面试官想听什么：你能不能把删除请求从“前端提示一下”上升到真正的数据治理问题。
短答版：至少要做到可定位、可删除、可验证，并且区分在线服务不再使用和底层存储真正清理。只是在 prompt 里说“别再提了”不算完成删除。
深答版：
展开深答版
这题重点是“忘记”不能只做表面屏蔽。一个合格方案首先要知道这条记忆落在哪里，被哪些索引、缓存、摘要或派生表示引用过，然后才能决定是硬删除、软删除还是墓碑标记。
这里要特别区分两类数据：用户记忆和合规留痕。前者的目标是后续不再被召回、不再影响模型；后者可能出于审计要求需要受控保留，但访问边界和用途必须不同，不能拿“审计日志还在”来假装用户删除没问题。
工程上，彻底清理链路会更复杂，但它直接关系到用户信任和误召回风险。只在 prompt 里说“别再提了”，不算真正的删除方案。
追问方向：哪些派生表示必须同步清理，哪些留痕数据应该走单独的保留策略？
8. 记忆的 ownership 边界怎么划？
题目：用户信息、任务状态、团队知识都能叫“记忆”，到底谁有权创建、修改和删除？
面试官想听什么：你是否真的理解 ownership，不只是把数据分层，而是能讲清写入 authority 和治理责任。
短答版：我会先定义 owner，再定义谁能对该域做增删改。用户私有记忆应主要由用户或受托代理更新，任务状态由任务执行链路维护，共享知识由组织侧流程治理，不能谁方便谁就写。
深答版：
展开深答版
这题核心不是“放哪”，而是“谁说了算”。同样叫记忆，用户偏好、会话摘要、任务状态、团队规则的 owner 完全不同，所以写入 authority 和删除责任也不能一样。
用户私有记忆不该被另一个用户或普通共享流程随意改写；组织规则也不能被一次模型总结直接覆盖。只要 ownership 没定义清楚，系统就很容易出现错域写入、越权更新和责任不清的问题。
工程上，给每个记忆域定义 owner、写权限和删除责任，会增加一点治理复杂度，但这是系统长期可控的基础。记忆系统不仅要会召回，还要能回答“这条记忆是谁的，谁能改，谁来删”。
追问方向：如果模型自动总结想写入长期记忆，哪些域必须额外审批或确认？
9. 过时记忆和版本冲突怎么处理？
题目：如果系统记住“用户喜欢 A”，后来用户又明确改成“现在改用 B”，你怎么避免旧记忆继续影响回答？
面试官想听什么：你能不能把记忆当成会演化的数据，而不是写进去就永远有效的事实。
短答版：我会把记忆设计成可版本化、可失效的记录，而不是只存一段文本。新信息到来时，要能覆盖、降权或标记旧版本失效。
深答版：
展开深答版
这题考的是你是否理解“记忆不是静态事实仓库”。偏好、配置、规则都可能变化，所以记忆不该只是存一段文本，而应该带上时间、来源、状态甚至 superseded 关系，表示谁覆盖了谁。
如果只把记忆当自然语言文本塞进向量库，很难处理“旧的还像真话，但已经不该用了”的情况。系统最后就会把新旧偏好一起召回，让模型自己猜哪个应该信，这其实是在把治理问题推给模型。
工程上，版本管理会增加一些元数据和更新逻辑，但能明显减少冲突召回。冲突记忆默认不该并列成同级事实，这是一条很重要的判断线。
追问方向：你会优先用时间戳、显式版本号，还是状态位来解决冲突？
10. 记忆要不要带置信度？
题目：如果一条记忆来自模型总结，而不是用户明确表达，你会怎么使用它？
面试官想听什么：你能不能区分“事实”“推断”“猜测”，并把这种差异体现在系统设计里。
短答版：我不会只看一个 confidence 字段，而是先看来源类型、证据强弱、有没有用户确认。置信度可以有，但只是辅助信号，不能假装成精确真值。
深答版：
展开深答版
这题核心不是“要不要打分”，而是要不要把不同证据强度混成同一种事实。用户明确陈述、系统结构化配置、模型总结、第三方同步数据，这几类来源的可靠性本来就不同，不该被一视同仁地注入模型。
如果系统只依赖一个看起来很精确的 confidence 数值，反而容易制造假确定性，因为这个分数本身也常常只是估出来的。比单一分数更重要的，其实是来源类型、证据强弱、有没有用户确认，以及是否存在冲突版本。
工程上，低证据记忆可以先保留成候选线索，但不该直接升级成高优先级事实。系统真正需要区分的是“事实”“推断”“猜测”，而不是只打一个分。
追问方向：哪些记忆即使相关，也必须等用户确认后才能升级为稳定事实？
11. 用户私有记忆和共享记忆怎么共存？
题目：在团队产品里，既有用户个人偏好，也有团队共享规则，你怎么避免两者互相覆盖？
面试官想听什么：你是否能处理“多层记忆同时存在”时的优先级，而不是只会说做权限隔离。
短答版：我会把它当成 merge policy 问题来处理，而不是单纯的隔离问题。共享记忆给默认上下文，私有记忆给个体覆盖，冲突时按预先定义的优先级合并。
深答版：
展开深答版
这题重点是“共存时怎么决策”，不是“谁能写”。共享记忆通常承载团队规则、组织知识和默认配置，私有记忆承载个人偏好和个体历史，它们在同一次回答里经常会同时生效。
所以系统必须提前定义 merge policy，而不是临场让模型自己判断。比如安全和合规约束优先级最高，共享规则提供默认值，用户偏好只能在允许范围内覆盖默认值。没有这套合并规则，系统就会在多条相关记忆之间摇摆，行为看起来时而个性化，时而失忆。
工程上，显式 merge policy 会增加一点实现复杂度，但它直接决定系统行为是否可预测、可解释。共存不是简单隔离，而是要有冲突解决机制。
追问方向：如果用户偏好和团队规范冲突，最终以谁为准？
12. 记忆已经被污染了，怎么清理？
题目：如果上线后发现系统记住了很多错的、脏的、过时的信息，你会怎么救？
面试官想听什么：你有没有治理闭环，还是只会在设计时谈“尽量别写错”。
短答版：我会分三步做：先止血，暂停高风险写入和召回；再定位污染来源和影响范围；最后批量清理、重建索引，并补上规则防止再次发生。
深答版：
展开深答版
这题考的是故障恢复能力。真正的记忆系统必须假设污染迟早会发生，所以要预先设计回滚和清污手段，比如按时间窗、来源、类型、版本批量失效，必要时重算摘要、重建索引。
清理不只是删掉原始错误记录，还要处理它派生出来的摘要、缓存、排序特征和召回痕迹。否则表面上删了，行为上却还是不稳，因为污染已经扩散到了其他层。
工程上，可回溯、可批量修复的治理链路会增加一些存储和运维成本，但这是长期系统的保险。没有写入审计和 lineage，连脏东西怎么进去的都查不清，就谈不上真正清理。
追问方向：如果不能停机，你会怎么做在线清理和灰度修复？