会话与长期记忆

• 聊天历史与长期记忆的本质区别：原始记录 vs 提炼资产
• 记忆四层：工作状态 / 偏好 / 事实 / 情景
• 各层的存储与生命周期管理

聊天历史只是"原始对话记录"，不等于长期记忆：历史无限增长、包含大量噪音（闲聊、重复、过期信息）、无法直接回答"用户喜欢什么"，且直接塞回上下文会膨胀成本、稀释注意力；长期记忆是"从历史中提炼的结构化知识"——经过筛选、去重、更新与时效管理的用户画像与事实，它小而精、可直接检索、跨会话复用。把历史直接当记忆是常见误区，会导致上下文爆炸与记忆失效（记住过期偏好）。

记忆按性质分四层：短期工作状态——当前任务/会话的临时上下文（正在做什么、已做到哪），生命周期随会话结束而结束，放会话状态存储，不需要长期保留；偏好记忆——用户稳定的倾向（沟通风格、偏好渠道、常用设置），低频更新、跨会话长期有效，放结构化数据库（或记忆服务）；事实记忆——用户提供的明确事实（姓名、地址、公司、子女数），高可信度、需用户确认后写入，放权威存储并带来源；情景记忆——用户经历的事件（"上周我去了 X"），带时间与上下文，用于个性化回应，放带时间戳的事件存储（可用向量检索）。分层要点：各层生命周期不同（会话级/长期）、可信度不同（推断 vs 确认）、存储与检索方式不同，设计时按层治理，避免"一锅烩"。

本题考察记忆的分层建模。回答要先论证"历史≠记忆"（噪音、膨胀、时效），再给出四层结构及各自的存储与生命周期。核心是"记忆是提炼的结构化资产，按生命周期与可信度分层管理"。

• 三种存储的特性：压缩摘要 / 语义检索 / 精确查询
• 各自的内容定位
• 组合查询的流程与路由

三种存储特性互补：摘要记忆（summary）——把长对话历史压缩为要点文本（用户是谁、讨论过什么、达成什么结论），适合存"对话精华"与长上下文的替代物，优点是密度高、可直接进上下文，缺点是粒度粗、丢失细节；向量检索记忆——把记忆条目嵌入为向量，支持语义相似度检索，适合存"情景型、开放式、难以精确匹配"的内容（"用户提到过的项目经历""之前讨论过的偏好表述"），按相关度召回；结构化数据库——按字段精确存储与查询，适合存"事实型、需要精确性与约束"的内容（姓名、会员等级、到期时间、授权状态），支持 SQL 式精确过滤与一致性保证。

组合查询的设计是"分层路由 + 多路召回 + 合并排序"：查询先按意图判断用哪类记忆——精确问题（"用户的会员等级"）直接查结构化库；开放式问题（"用户之前提过什么需求"）先向量检索召回候选，再按相关性过滤；对话场景中把"最近摘要 + 结构化关键事实 + 向量召回的相关情景"组合注入上下文。合并时去重（同一事实多个来源）与冲突消解，并按可信度与时效加权排序。工程上"结构化库存事实、向量库存情景、摘要存历史"是常见配置，查询层做统一接口（记忆服务）对外屏蔽存储差异。

本题考察记忆存储的组合设计。回答要讲清三种存储的特性与内容定位，再给出"意图路由 + 多路召回 + 合并排序"的组合查询流程。核心是"按内容性质选存储，按查询意图做路由"。

• 记忆元数据五要素：来源、置信度、时间、授权、过期
• 各类信息的记录方式
• 写入准则与治理闭环

记忆写入的元数据五要素：来源——这条记忆来自哪里（用户明确陈述/模型推断/系统数据/工具结果），来源决定可信度基础，记录来源 ID 与上下文引用，便于溯源与纠正；置信度——记忆内容的可信程度（用户确认 > 系统事实 > 模型推断），用分级（高/中/低）或分数表示，低置信度记忆不主动使用、需进一步确认；时间——记忆的产生时间与最后更新时间，用于时效判断与过期计算，情景记忆尤其依赖时间；用户授权——该记忆是否经用户同意写入与使用（哪些记忆可存、可用于什么目的），记录授权范围与授权时间，未授权的信息不得写入或只做脱敏处理；过期策略——记忆的有效期与失效条件（固定有效期、按类型默认期限、事件触发失效如"地址更新后旧地址作废"）。

写入准则：先分类（事实/偏好/情景/临时）再定元数据；事实性内容必须带来源并标记"待确认"直到用户或权威系统确认；推断内容显式标注为推断且低置信度；写入前做去重与冲突检查（与现有记忆比对，冲突时按规则处理）；授权与隐私检查（敏感信息脱敏、按最小化原则只存需要的字段）。治理闭环：记忆条目全生命周期可查（谁写的、依据什么、何时过期），定期清理过期与低价值条目，用户可查看与删除。

本题考察记忆写入的治理规范。回答要给出五要素元数据各自的记录要求，以及"分类→标注→校验→授权"的写入流程。核心是"记忆条目要自带来源、置信度与时效，写什么和怎么写都有据可查"。

• 四种淘汰信号的语义与适用
• 综合评分与淘汰策略设计
• 淘汰的谨慎性：低风险优先，事实不随意删

四种信号各有作用：时间——情景记忆与临时信息随时间自然衰减（"上周的出行安排"两周后价值极低），按类型设默认有效期；访问频次——频繁被使用的记忆说明仍在发挥作用，长期不被访问的记忆（LRU 思想）优先淘汰，但"不常访问但重要"的事实（用户过敏史）不能按频次删；重要性评分——记忆带重要性权重（身份事实 > 临时偏好 > 闲聊信息），评分低的先淘汰；用户反馈——用户明确表示"别记住这个/这不重要"是最强信号，直接降权或删除。单一信号都有盲区，正确做法是综合评分：score = 时效性（越新越高）× 访问热度 × 重要性权重 × 用户反馈修正，低于阈值进入淘汰候选。

淘汰策略要谨慎分层：立即淘汰——用户明确要求忘记、被证伪的记忆（先删除或标记）；主动淘汰——低分条目达到阈值自动清理，但保留审计日志（删了什么、为什么）；降级保留——中等价值记忆不删除而是压缩/归档（从全文降为要点，从活跃库移到冷存储）；禁止淘汰——高可信事实（身份、健康、财务）除非用户要求或确证错误，否则不因"不常访问"淘汰。淘汰要与遗忘机制联动：用户行使"遗忘权"时，不仅是删除记忆条目，还要清理其派生的缓存与向量副本。衡量淘汰效果的指标：淘汰后用户满意度/回答准确率不下降、记忆命中率保持稳定。

本题考察记忆淘汰的策略设计。回答要分析四种信号的适用与盲区，给出综合评分与"立即删/主动删/降级/禁删"的分层策略。核心是"淘汰要分层谨慎，事实类记忆不因低频被误删"。

• 跨会话共享的价值与风险
• 用户授权：同意、范围、撤回
• 租户隔离：数据边界与越权防护

跨会话记忆共享让用户在新会话中不需要重复交代背景（"我之前说过我是某某公司"），但共享的前提是授权与隔离：用户授权——跨会话使用用户历史信息必须获得用户同意，授权要明确范围（哪些信息类别可跨会话使用、用于什么目的），并提供撤回机制（用户可关闭跨会话记忆或删除特定条目）；授权状态随记忆条目存储（每条记忆带"可跨会话共享"标记），未授权的记忆只在当前会话有效。

租户隔离是数据边界问题：多用户系统（个人用户之间、家庭/团队账号之间、多租户 SaaS 之间）的记忆必须按租户物理隔离——存储层按 tenant_id 分区（库/表/前缀），检索层强制带租户过滤条件（所有查询拼接 tenant_id，防 SQL 与向量检索串租户），记忆服务接口校验"请求者租户 = 记忆租户"，跨租户访问一律拒绝并告警。团队场景还要细分到"成员级可见性"（团队共享记忆 vs 成员私有记忆），权限模型按"租户 > 团队 > 成员 > 记忆类别"逐层收敛。实现上：记忆键包含租户与用户 ID（memory_key = tenant:user:category:id），缓存与向量索引同样带租户标签；越权防护要在"存储、检索、注入"三个环节都校验，防止只在入口校验、内部泄漏。

本题考察跨会话记忆的授权与隔离。回答要覆盖授权（同意、范围、撤回）与租户隔离（存储分区、检索强制过滤、接口校验）两个层面。核心是"共享是特例、隔离是默认，授权与隔离贯穿存储到注入"。

• 冲突的判定：同实体不同值、矛盾表述
• 优先级规则：新胜旧、高可信胜低可信、用户确认胜推断
• 审计与用户纠正机制

冲突判定：两条记忆指向同一实体（同一用户/项目/设置项）但值不同或语义矛盾（"用户地址是 A 市"与"用户地址是 B 市"）。优先级规则按三个维度：时间——新信息通常胜旧信息（用户刚说的覆盖之前说的），但"用户更早明确确认过的事实"与"最近模型推断"冲突时要谨慎（推断不能覆盖确认）；可信度——用户陈述/系统权威数据 > 模型推断 > 对话中的随口提及；类型——事实性信息优先于推测性信息。综合规则一般是"用户显式确认 > 新近用户陈述 > 系统权威数据 > 新近推断 > 旧推断"。

冲突处理流程：检测（写入时比对同实体已有记忆）→ 按优先级裁决（新值生效、旧值标记 superseded）→ 保留审计（冲突不删除历史：旧值保留在历史版本或标记"已被 X 时间的新信息覆盖"，可查"什么时候因为什么原因被替换"）→ 用户纠正：对关键冲突（身份、财务、偏好）主动向用户确认（"您之前的地址是 A，现在您提到 B，以哪个为准？"），用户纠正结果作为最高优先级写入并固化；对低风险冲突静默采用规则，但在记忆详情中允许用户查看与手动改。用户纠正要有闭环：用户手动修改的记忆打"user-corrected"标记，提高其权重并作为后续冲突裁决的优先依据。

本题考察记忆冲突治理。回答要给出时间/可信度/类型三维优先级规则、审计保留（旧值不删只标记）与用户纠正闭环。核心是"冲突裁决可解释、历史可追溯、用户有最终修正权"。

• 用户记忆四权：查看、修改、导出、遗忘
• 遗忘的级联删除：主存储、缓存、向量副本、派生数据
• 四权实现的合规与技术要点

用户记忆四权的实现：查看——提供记忆管理界面（按类别/时间列出记忆条目及来源，可搜索），这是其他权利的基础；修改——用户可编辑记忆内容，修改后更新主存储并重新生成相关索引，冲突规则按"用户手动修改最高优先级"处理；导出——按可读格式（JSON/CSV）导出用户全部记忆，导出要完整（含元数据：来源、时间），是数据可携带权（数据可移植性）的落地；遗忘（删除）——用户要求删除后，不仅删除主存储条目，还要级联清理所有副本：缓存（Redis 等）、向量索引中的嵌入向量、日志中的派生摘要、以及记忆的引用（对话历史里引用的记忆链接失效处理）。

级联删除的技术要点：删除要"先标记后清除"（先标记 deleted 防止读取窗口期泄漏，再异步清理副本，最后硬删除），全链路确认删除完成（对账：删除前后比对检索结果）；向量库的删除按主键映射（memory_id → 向量 ID）定位清除，避免"删了文本忘了向量"导致仍能被召回；分布式缓存主动失效（删除事件广播）；合规上遗忘要有审计记录（何时、哪个用户的哪些数据被删除、依据什么请求），并与外部系统（如 CRM 里的记忆副本）协调。设计上建议"删除走统一记忆服务"——所有读写副本都通过该服务，删除时服务统一发布级联事件，杜绝绕过服务直接改存储。

本题考察记忆的数据主体权利实现。回答要给出四权的功能设计与遗忘的级联删除机制（主存储、缓存、向量、派生数据），核心是"删了主存储不等于删干净，副本级联与对账验证缺一不可"。

• 三类质量指标的定义与计算公式
• 记忆评估集的构建：以用户确认为真值
• 评估流程与持续监控

三类核心指标：记忆准确率——记忆条目与真实事实一致的比率，定义为"与真值一致的记忆条目数 / 总条目数"，按条目类型分算（事实、偏好、情景各自准确率），注意区分"写入即准"与"用时才暴露"（召回后由用户反馈确认）；冲突率——系统内同实体矛盾记忆的比例（"存在冲突的实体数 / 总实体数"），冲突率反映记忆更新与合并机制的健康度，检测方法是对同实体条目做一致性校验（同字段多值、语义矛盾）；幻觉记忆率——模型编造的记忆（无来源依据的记忆）占全部记忆的比例，判定方法是核对"记忆的来源引用是否存在且支撑内容"，无来源或来源不支撑的记为幻觉。

评估集构建以"用户确认事实"为真值：从真实对话中提取记忆候选，对每条记忆找"用户确认锚点"（用户明确陈述、用户更正、用户确认过的系统事实），组成三元组（记忆内容、来源上下文、真值标签：正确/错误/已过时）；评估集要覆盖不同记忆类型、不同来源可信度与冲突场景；指标计算方式：把记忆系统在测试会话中写入/更新/召回的条目与真值比对，统计准确率与幻觉率；持续监控——线上按抽样（人工标注 + 用户反馈回收）维护滚动真值集，观察指标漂移（如幻觉率上升通常与提示词改动或模型升级有关）。这套评估让记忆系统像模型一样"可评测、可回归、可优化"。

本题考察记忆系统的质量评估。回答要给出三类指标的定义与度量方法，以及以用户确认为真值的评估集构建。核心是"记忆系统要有可量化的质量指标与持续评估机制，不能只靠感觉"。

• 同步写入与异步写入的取舍
• 失败/超时时的降级策略：不阻塞对话
• 防静默丢失：重试、队列、对账、告警

取舍原则是"对话主流程不能被记忆写入绑架"：同步写入适合必须立即生效的关键记忆（用户明确说"记住我的地址"——这次会话内后续就要用到），但同步写会增加对话延迟且把记忆系统故障传导给对话；异步写入适合大多数后台记忆（从对话自动提炼的偏好、情景），对话先回复用户，记忆后台落库。实践做法：关键记忆同步（短超时，如 500ms），普通记忆异步；异步写通过消息队列缓冲，不占对话链路。

失败与超时的处理：写入失败或超时时，对话主流程"降级跳过"而非"阻塞等待"——先完成用户回复，记忆写入标记为失败进入重试队列；但"降级跳过"不等于"静默丢弃"：要防止记忆静默丢失，机制包括——重试（失败条目进队列，指数退避重试，重试上限内补齐）；对账（定期比对"应写入的记忆"与"实际写入的记忆"，缺失的补写或告警）；死信与告警（重试耗尽进入死信队列，触发告警与人工处理，统计丢弃率）；用户可见的确认（关键记忆写入成功后明确告知用户"已记住"，写入失败时提示"暂时没能记住，稍后重试"）。核心指标是"记忆写入成功率与丢弃率"要纳入监控，任何静默丢弃都视为事故。异步写入的积压也要监控（队列长度、延迟），积压过多时降级为"先写最新记忆、旧记忆合并"。

本题考察记忆写入的可靠性设计。回答要讲清同步/异步的分场景取舍、失败降级（不阻塞对话）与防静默丢失（重试、对账、告警、可见性）三件套。核心是"降级可以，静默丢失不可以"。

• 写入侧防护：最小化采集与脱敏
• 存储侧防护：加密与密钥管理
• 检索侧防护：访问控制与注入控制

写入侧——最小化原则：只采集完成任务所需的最少字段（用户问"推荐餐厅"不需要记身份证号），对可选敏感字段默认不采集，采集前告知用途；脱敏：写入前识别敏感信息（PII、密钥、财务数据），按类型处理——不存储（密钥、密码绝不入记忆）、脱敏存储（手机号 138****5678）、标记存储（明确标注"敏感"字段）；识别用规则 + 模型辅助（实体识别），识别结果要定期校验防漏。存储侧——加密：记忆库整体加密（静态加密 + 传输加密），敏感字段级加密（字段级密钥），密钥用 KMS 管理并定期轮换；隔离：敏感记忆单独分区存储，与普通记忆物理或逻辑隔离；日志脱敏：记忆相关的日志不打明文（检索记录只记 hash）。

检索侧——访问控制：检索接口校验调用者身份与授权（谁能读哪类记忆、谁能读哪个用户的记忆），按"最小必要"返回字段（检索某用户偏好时不返回其联系方式）；上下文注入控制：注入给模型的记忆只含任务必需且已授权的部分，敏感字段在注入前做"按需降级"（本会话需要手机号时才注入且标记用途）；审计：敏感记忆的读写全部记录（谁、何时、哪类字段、用于什么请求），异常访问（与任务无关的敏感读取）告警；模型输出侧：禁止模型把敏感记忆复述到无关上下文（输出过滤），防止敏感信息经生成结果外泄。整体原则：敏感信息"能不存就不存、存了就最小化、用了就脱敏、读走就留痕"。

本题考察记忆安全的全链路防护。回答要按写入、存储、检索三个环节展开最小化、脱敏、加密、访问控制的具体做法。核心是"安全覆盖从采集到注入的全链路，任何环节漏了都白搭"。

• 两种记忆的查询模式差异：精确 vs 语义
• 存储与索引的匹配：结构化 vs 向量
• 混合架构与统一访问层

应该使用不同的存储与索引，因为两者的查询模式根本不同：事实型记忆（姓名、偏好、设置）是"当前态快照"——用户只关心"现在值是什么"，查询是精确的（按字段查、值唯一、可更新覆盖），适合结构化数据库（或键值/文档库），字段可加约束、支持精确过滤与一致性（唯一性、引用完整性），索引用 B-tree/哈希（按用户 ID + 类别 + 字段）；情景型记忆（事件、经历）是"历史流"——用户会问"我上次提到过什么""上周发生了什么"，查询是语义的（相关而非精确匹配）、带时间维度、数量可能很大，适合向量索引（嵌入语义检索）加时间过滤器，或用事件表 + 全文/向量混合索引。

混合架构的要点：两类记忆通过统一的"记忆服务"对外暴露（按记忆类型路由到对应存储），同一实体的"事实"与"相关情景"可关联（用户地址是事实，搬家记录是情景，检索地址时可附带相关情景做上下文）；事实的更新要影响情景的理解（旧地址情景重标注"已过时"）；查询时按意图路由：精确问题查结构化、开放问题查向量、复合问题两路召回合并。存储分离的好处是各自按查询模式优化（结构化库保证事实的一致性与更新性能，向量库保证情景的召回质量），避免"全塞向量库导致事实查询不可靠"或"全塞数据库导致语义检索不可用"。

本题考察记忆存储的分型设计。回答要讲清两种记忆的查询模式差异（精确 vs 语义）与对应存储选型，再给出统一访问层与关联设计。核心是"按查询模式匹配存储，事实要可靠、情景要可召回"。

• 幻觉记忆的成因：从对话过度推断、无依据断言
• 检测方法：来源校验、冲突发现、用户反馈
• 修正机制：删除/降级/纠正闭环

幻觉记忆的成因：模型从用户一句话过度推断（用户说"这家店不错"被记成"用户喜欢所有川菜"）、把假设当事实写入（"用户可能想要 X"被记为"用户想要 X"）、以及来源引用为空或与内容不符（记忆说"用户提到过 A"但对话历史中并无记录）。检测方法四类：来源校验——每条记忆必须带来源引用（对话 ID + 原文片段或系统依据），写入时校验引用存在且内容支撑（无引用或引文不支持即判定可疑）；冲突发现——幻觉记忆常与已有事实冲突（记成"用户在深圳"但用户确认过在上海），冲突检测可捕获；用户反馈——对话中用户明确纠正（"我没说过那个"）是强信号，反馈回流到该条记忆标记为错误；抽样审计——按比例人工抽检记忆条目，统计幻觉率并归因。

修正机制：分级处理——可疑记忆标记"未验证"并降级（不主动使用、不注入上下文）；用户纠正或有证据证伪的记忆直接删除（或标记 superseded），删除同步清理向量副本；根因修正——统计幻觉记忆的共性（集中在哪类推断、哪个提示词阶段产生），调整记忆提炼的提示词（要求"只记用户明确陈述的事实，推断必须标注"）、提高写入门槛（低置信度推断不入库或转人工确认）；闭环评估——幻觉记忆率作为记忆质量指标持续监控，修正后验证指标下降。核心原则：记忆写入"宁缺毋滥"，无法溯源的内容不入库。

本题考察幻觉记忆的治理。回答要讲清成因、四类检测方法与分级修正机制（降级、删除、根因调整）。核心是"来源可溯是记忆可信的基础，宁可少记不可乱记"。

• 压缩保留的信息类别：实体、承诺、偏好、待办
• 压缩的粒度与信息密度平衡
• 压缩与原始历史的衔接

记忆压缩要保留五类关键信息：实体——用户提到的关键对象（人、公司、项目、产品）及其属性与关系（"用户是 X 公司采购负责人"），这是后续对话的指代基础；承诺——用户或系统做出的承诺与约定（"周五前给方案""已约好周二开会"），遗漏承诺是压缩最常见的信息丢失；偏好——稳定的倾向与禁忌（"不喜欢电话沟通""不吃辣"），偏好是跨场景复用的高价值信息；待办与进行中事项——未完成的任务、悬而未决的问题；关键数据与决定——结论（"已确定用 A 方案"）与重要数字（预算、时间节点）。反过来说，闲聊、寒暄、重复内容、已过时的细节（具体到分钟的行程）可以不保留。

压缩的实现要点：压缩时机——上下文接近阈值或会话阶段切换时触发；压缩方式——用模型生成结构化摘要（按实体/承诺/偏好/待办分区），而不是流水账复述；压缩要与原始历史衔接——摘要可追溯（每个摘要条目带来源对话区间），必要时（用户深挖细节）能回查原始记录；多轮压缩——长对话多次压缩时新摘要要继承旧摘要的关键信息（摘要的摘要，防信息逐轮衰减）；校验——压缩后做一次"关键信息完整性"检查（原历史中的实体、承诺是否都在摘要中），缺失补录。压缩本质是"有损但保重点"的降维，重点是识别哪些信息在未来对话中有复用价值。

本题考察记忆压缩的信息选择。回答要给出五类必留信息（实体、承诺、偏好、待办、结论）与可丢弃内容，再讲压缩的时机、可追溯与完整性校验。核心是"压缩以未来复用价值为判据，承诺与实体最易丢失也最重要"。

• 记忆与历史的关系定位：独立系统而非子集
• 两者差异：提炼 vs 原始、更新 vs 追加
• 冲突时的优先级与证据链

记忆是独立系统，不是历史的子集：历史是"原始记录"，只追加、不变更，忠实但含噪音；记忆是"提炼的活资产"，会更新、会淘汰、会合并，可以包含"历史里没有的东西"——比如从多轮对话归纳出的偏好（没有任何一轮单独表达过完整偏好）、外部系统导入的事实、用户在其他渠道的信息。反过来，记忆也不是历史的全集（不会保留闲聊细节）。两者是"原材料"与"产品"的关系：历史是原始证据，记忆是从中提炼并持续维护的结构化产品。

冲突时的优先级：一般情况下"新记忆优先于旧历史"——记忆反映的是用户最新状态，历史是过去的快照（用户昨天说地址是 A，今天更新为 B，应以记忆 B 为准）；但"用户纠正"要双向生效：用户说"我之前说的不对"时，既要更新记忆，也应在历史中标注更正（历史不可改但可加更正标记）。更精细的规则：直接证据优先——用户最近的明确陈述 > 记忆中的推断条目；用户主动纠正 > 记忆当前值；记忆与历史冲突且无用户新输入时，以"更新更晚且有来源依据"者为准，并保留冲突记录供审计。工程上记忆条目带"最后更新时间 + 来源引用"，冲突仲裁可回溯到历史证据链。

本题考察记忆与历史的关系建模。回答要论证"独立系统而非子集"（更新性、提炼性、外部来源），再给出冲突仲裁规则（新记忆优先但用户纠正双向生效）。核心是"历史是证据、记忆是结论，结论更新但证据可追溯"。

• 记忆按敏感度分级：核心 / 偏好 / 行为
• 分级授权的设计与用户体验平衡
• 授权状态的存储与撤回

记忆按敏感度与用途分三级：核心记忆（身份信息、财务、健康、联系方式）——最敏感，需要"明示同意"（用户主动授权，可单独开关，如"是否保存我的地址"），默认不采集；偏好记忆（沟通偏好、内容偏好、习惯）——中等敏感，需要"知情同意"（告知用途后默认开启，用户可关闭），如"根据您的偏好推荐内容"；行为记忆（使用行为、交互习惯）——低敏感但涉及隐私，需"选择同意"（默认关闭或明确告知后开启，如"记住您常看的板块"）。分级原则：敏感度越高，授权门槛越高、默认越保守、用途限制越严。

分级管理的实现：授权状态独立存储（记忆条目挂授权标签：核心/偏好/行为 + 授权状态 + 授权时间与范围），注入与使用记忆时按授权过滤（未授权的级别不注入、不用于对应用途）；授权与用途绑定（核心记忆只能用于明示的用途，不得泛化使用）；用户体验平衡——授权向导按级别渐进询问（先问核心、再问偏好），允许"批量管理"与"按条撤回"；撤回机制——用户撤回某级授权后，该级记忆立即停用（不再注入），并按"遗忘"流程删除或封存（取决于用户选择）；撤回不影响审计（保留授权变更记录）。合规上，分级授权记录要完整留存，作为"同意管理"的证据。

本题考察记忆授权的分级设计。回答要给出三级记忆的授权门槛（明示/知情/选择同意）与实现（授权标签、按级过滤、撤回机制）。核心是"敏感度决定授权门槛，授权可分级、可撤回、与用途绑定"。

• 两类存储的定位差异：用户记忆 vs 业务事实
• 划界原则：谁的数据、谁维护、谁负责
• 重叠数据的同步与冲突处理

划界的核心是"数据的所有权与权威性"：权威业务数据库（CRM、订单库、用户库）保存"业务事实"——订单状态、账户余额、会员等级，是系统的单一事实源（source of truth），由业务系统维护、事务保证一致性；MCP Memory 等记忆服务保存"对话语境与用户画像"——用户的偏好、习惯、跨会话上下文，服务于对话个性化，不需要强事务一致性。两者的数据不重叠：业务数据"不写入记忆库"（订单状态变化由业务系统负责，记忆库只存"用户提到过什么"）；记忆数据"不进业务库"（偏好不污染业务数据模型）。

重叠与边界情况：需要"业务事实 + 记忆"结合使用时（推荐场景：用户偏好 × 订单历史），按需查询两者再合并，不互相复制；用户画像中涉及业务数据引用（"用户是高级会员"）时，记忆只存"引用"（会员等级字段的引用），实际值实时查业务库，避免双写不一致；同步需求（用户改地址）时，业务库是权威（改地址走业务系统），记忆库中的地址只是"用户对话中提到过的表述"，过期自动失效。划界的工程意义：避免"记忆库与业务库双写不一致"的经典问题——谁拥有数据谁维护，记忆服务永远不试图成为业务事实源。跨系统整合时用"记忆服务 + 业务 API"组合，而不是把业务数据塞进记忆库。

本题考察记忆与业务数据的边界设计。回答要讲清"业务库存事实、记忆库存语境"的所有权划分，以及重叠数据的引用与实时查询原则。核心是"记忆服务不做业务事实源，引用不复制，双写必乱"。

• "记错人"的成因：串租户、串用户、陈旧记忆
• 四类日志的排查路径
• 根因定位与修复闭环

"记错人"（Agent 把 A 的信息当成 B 的）的成因主要有三类：串用户——记忆键错误或检索未带用户过滤（把别人的记忆注入当前会话）；串租户——多租户隔离失效；陈旧记忆——用户信息已更新但记忆未更新（用了旧地址、旧偏好）。排查要从四类日志入手：命中日志——本次对话注入了哪些记忆条目、这些条目属于哪个用户（检查 memory_id 归属与注入时的 user_id 是否一致，串用户会直接暴露）；写入日志——检查错误信息是什么时候被写入的、写入时引用的来源上下文（找"写入时就错了"还是"后来被更新丢的"），以及写入时的用户归属；冲突日志——同实体记忆是否有新旧冲突未裁决（旧值未标记 superseded 导致检索到旧值）；淘汰日志——检查该条记忆是否本应被淘汰（过期信息未清理，被错误注入）。

排查流程：复现（记录出问题的会话与注入清单）→ 沿注入清单回查命中日志（注入来源）→ 命中正确则回查写入/冲突日志（记忆本身的正确性与新旧）→ 定位到环节（检索过滤、写入归属、更新/淘汰缺失）→ 修复（修正检索过滤、清理错误条目、补齐冲突裁决与淘汰）→ 加防护（同类问题的监控：跨用户注入率、陈旧记忆命中率、冲突未决数）。工程上为四类日志统一加"用户 ID + 记忆 ID"维度索引，支持一键回溯"这条记忆从写入到被使用的全生命周期"。

本题考察记忆问题的排查方法论。回答要给出三类成因与四类日志的排查路径，以及"复现-回溯-定位-修复-防护"的闭环。核心是"四类日志构成记忆全生命周期，记错人必能在某类日志里现形"。

• 过期信息的识别：时效字段、更新信号、类型规则
• 清理策略：失效标记、降级、删除
• 防回潮：检索过滤与上下文注入控制

过期信息的识别三类信号：时效字段——带最后更新时间或有效期的记忆，超过期限自动进入过期候选（旧地址在用户更新新地址后立即过期）；更新信号——同实体出现新值（新地址写入时旧地址标记过期）；类型规则——按记忆类型定生命周期（临时计划 1 周、偏好 90 天、事实按确认时间）。清理策略分层：失效标记——过期记忆先标记 inactive（不删除，保留审计），确保检索时不可见；降级——仍有参考价值的过期信息（"用户 2023 年在上海"）降级为"历史记录"，只在用户明确问历史时可用；删除——确认无用的过期条目物理删除并清向量副本。

防"回潮"的关键在检索与注入环节：检索时默认过滤 inactive 与过期条目（查询条件带"有效期 >= 当前时间"或"状态 = active"），向量检索同样过滤（按元数据过滤）；注入上下文时只注入 active 条目，历史条目绝不主动注入；同时建立"过期清理任务"——定期扫描记忆库，把到期条目批量处理，而不是等到检索时才碰上（检索时"发现过期"只是兜底）；监控过期条目的占比（过高说明更新机制失效）。核心目标是"上下文里只出现当前有效的信息"，过期信息不清理就会在检索时被召回、在注入时占上下文，造成"记错"与浪费。

本题考察过期记忆的治理。回答要给出三类识别信号、三级清理策略（标记/降级/删除）与检索注入环节的过滤。核心是"清理不仅靠删除任务，更要靠检索与注入的默认过滤防回潮"。

• 异步写入的失败与积压场景
• 补偿与对账机制
• 关键事实的保障与可见性

异步记忆写入的失败与积压场景：消费者处理慢导致队列积压、写入重试耗尽进死信、消息丢失（队列确认问题）——这些都会造成"用户说了关键事实，但记忆库里没有"。补偿与对账机制：重试补偿——失败条目指数退避重试，区分瞬时失败（重试）与持久失败（参数问题，检查数据后重试或丢弃并告警）；死信处理——重试耗尽进死信队列，人工或自动分析后决定补写或丢弃，丢弃率纳入监控；对账任务——定期比对"会话中应提取的记忆"与"记忆库实际条目"：以对话为源，重放记忆提炼（或对比提取日志与写入日志），发现"应写未写"的条目补写；对账频率与延迟目标挂钩（关键事实分钟级、普通记忆小时级）。

防止"关键事实永久缺失无人察觉"的保障：关键事实识别——对记忆分级（用户明确要求记住的、身份财务类为关键），关键事实的写入要求"确认"（写入成功回执，失败立即告警并重试，不允许进死信静默丢弃）；可见性——记忆面板展示"待写入/写入失败/已补写"状态，用户可见"我告诉你的 X 已保存/暂未保存"；监控——记忆写入成功率、积压队列长度、死信数、对账差异数为核心指标，异常触发告警；审计——每次失败与补偿都有记录，可回溯"哪条记忆何时写入失败、何时被补上"。目标是不存在"用户说过但系统永远不知道"的黑洞。

本题考察异步记忆写入的可靠性闭环。回答要覆盖重试/死信/对账三层补偿机制与关键事实的确认式保障。核心是"异步不等于不保障，关键事实要有回执与对账，失败要被看见"。

• 共享层次的划分：个人 / 团队 / 家庭
• 各层记忆的可见性与写入权限
• 隐私边界与冲突处理

共享层次按"数据的归属与用途"划分：个人层——私人的偏好与事实（个人健康、私人日程、个人聊天记录），只属于该用户，其他成员不可见；团队层——团队协作相关的记忆（项目背景、客户信息、团队约定），团队内成员共享，用于协作一致性；家庭层——家庭公共事务（家庭日程、家庭购物清单、共同联系人），家庭成员共享。设计要点：每层记忆有独立的可见性（谁能读）与写入权限（谁能写）——个人层仅本人读写；团队层成员可读，写入按角色（谁都有权更新团队记忆，但关键修改要留痕）；家庭层类似团队层但范围限定家庭成员；个人与共享层的"重叠"要显式处理——用户个人记忆提到家庭事务时，默认不自动升为共享。

隐私边界：共享层的记忆不自动包含成员的个人记忆（共享家庭日历不会让全家看到某成员的私人偏好）；成员对共享记忆也可设置"仅部分可见"（有些家庭事项只让特定成员看）；退出团队/家庭时，共享记忆归团队/家庭所有，个人无权带走，但个人产生的私有记忆仍归个人。冲突处理：共享层的同实体记忆由谁更新要约定（如家庭地址由管理员维护），成员更新共享记忆要记录操作者与审计。技术实现：记忆键带"归属域"（user/team/family + ID），检索按当前上下文过滤可见域，注入时按"当前用户可访问的层"组装。核心原则：共享是"把某类数据开放给某类人"，每一条记忆都要明确归属与可见范围。

本题考察多用户记忆的共享边界。回答要给出三层划分与各自的读写权限、隐私边界（共享不吞并个人）与退出处理。核心是"每条记忆都有归属域，共享是显式开放而非默认全见"。

• 错误写入的场景：撤回未删、删除失败、双写不一致
• 一致性校验的方法：对账、标记比对、测试检索
• 告警与自动修复

错误写入的典型场景：用户撤回授权或要求删除，但删除流程某环节失败（主库删了、向量副本没删；或删除任务失败但状态被标记为已删）——造成"应该消失的记忆仍能被检索到"。一致性校验方法：删除对账——删除任务执行后，反向验证：按 memory_id 查询主库与各副本（缓存、向量索引），确认全部清除，未清除的进入修复队列；状态比对——记忆条目的"预期状态"（用户撤回 → 应删）与"实际状态"（检索可见）比对，定期扫描全量或抽样，发现"已撤回仍可见"即异常；测试检索——用测试查询（包含已删记忆的关键词/向量）验证删除生效，防止"索引过期但内容还在"。

发现后的处理：告警分级——单条异常告警（通知记忆团队人工处理），批量异常（说明系统性问题，如删除管道故障）触发高优告警与暂停删除相关功能；自动修复——对未删除的副本重新执行删除（幂等），修复后再次对账确认；根因修复——分析删除失败原因（依赖服务超时、级联遗漏）并补齐机制；审计——错误写入事件（何时、哪条、为何未删、何时修复）记录完整。核心指标：删除一致性率（删除请求中"实际检索不可见"的比例）纳入监控，低于阈值告警；用户侧：用户撤回后短时间内验证"记忆已不可见"，把一致性承诺做到用户可感知。

本题考察删除一致性的验证。回答要给出错误写入场景、三类校验方法（对账、状态比对、测试检索）与告警修复闭环。核心是"删除要验证、撤回要可感知、不一致要自动修"。

• 双写不一致的成因与危害
• 单一事实源与单向同步原则
• 同步机制与冲突仲裁

双写不一致的成因：同一信息（客户联系方式、工单状态）同时写在 Agent 记忆与 CRM/工单系统，两处独立更新，任何一处的直接修改或失败都会造成两边不同步（CRM 更新了，记忆还是旧的，或反之）。避免的核心原则是"单一事实源 + 单向同步"：确定每个数据字段的权威归属——客户主数据（联系方式、公司信息）以 CRM 为权威，工单状态以工单系统为权威，Agent 记忆只保存"对话语境"（用户怎么称呼这个客户、上次聊了什么），不复制权威数据；需要权威数据的场景（对话中要展示客户信息）从 CRM 实时查询或读缓存，不写入 Agent 记忆。

对必须跨系统的数据（如"用户要求把备注加到 CRM"），走"事件驱动的单向同步"：Agent 只向 CRM 发起操作（经 CRM API），由 CRM 落库并返回结果，Agent 记录"操作结果"而非"数据本身"；CRM 数据变化通过 webhook/事件流通知 Agent 侧（如"客户联系方式已变更"），Agent 侧更新其引用或标记缓存失效——同步方向明确（权威→依赖方），不搞双向互写；冲突仲裁：两边都有数据时以权威系统为准，记忆侧不一致的条目标记过期或失效；同步失败要重试与告警。工程结论：Agent 记忆是"语境层"，业务系统是"事实层"，语境层永远不成为事实的第二副本。

本题考察 Agent 记忆与外部系统的一致性问题。回答要讲清双写成因、单一事实源与单向同步原则、事件驱动同步机制。核心是"不复制权威数据、只同步变更事件，双向互写必乱"。

• 三种写入策略的语义与成本
• 策略组合：重要性 + 授权 + 场景
• 写入策略与记忆质量的平衡

三种写入策略：每次都写——每轮对话结束都把新信息写入记忆（Mem0 的默认模式类似，自动提取并写入），优点是实时、不丢信息，缺点是写入量大、噪音多（闲聊也被写入）、检索质量下降、存储成本高，适合信息密度高且存储便宜的场景（简单原型、短会话）；按重要性写——先判断信息价值再决定是否写入（重要性评分：是否新事实、是否影响未来对话、是否用户明确陈述），只写高价值记忆，优点是记忆库精、检索准、成本低，缺点是可能漏写（判断失误）且判断本身有模型成本，适合生产环境的长期记忆（Mem0/Letta 都支持添加过滤与自定义写入逻辑）；按用户授权写——只写用户明确允许的信息（授权级别控制：核心事实需明示同意才写，推断信息默认不写或写入后标记），优点是合规与隐私安全，缺点是记忆建立慢、冷启动体验差，适合隐私敏感场景（金融、医疗、欧洲市场合规）。

生产实践是组合策略：按重要性写（高价值才入库）+ 按授权写（敏感信息按授权级别）+ 关键事实"每次都写"（用户明确说"记住"，必须写入并确认）；Letta 强调记忆分层（核心记忆/存档记忆），写入时按"是否影响长期行为"分层，核心层精写、存档层宽写；Mem0 支持自定义写入器（先过滤后写入）与"删除/更新"操作保持记忆新鲜。写入策略的效果评估：记忆命中率、写入条目的后续复用率（写了的记忆有多少真正被用到）、幻觉记忆率——指标驱动调优（如"复用率低"说明写得太宽，收紧重要性过滤）。核心原则：写入是"为了未来复用"的投资，不是"记录一切"的义务。

本题考察长期记忆系统的写入策略选型。回答要讲清三种策略的语义、成本与适用场景，并给出"重要性 + 授权 + 关键事实必写"的组合策略。核心是"写入策略决定记忆库的精度与成本，指标驱动调优"。