考察点
这道题出自 2026 年 Agent 高频面经（"Agent 怎么实现跨会话记忆？"），常和记忆系统设计连问。面试官想看你处理过两个矛盾的需求：既要"记住用户"让体验连贯，又要防止 A 项目的记忆串到 B 项目、A 用户的记忆漏给 B 用户。追问往记忆命名空间设计、多租户安全、旧记忆干扰新话题上走。
参考答案
跨会话记忆的基本回路
跨会话记忆就是长期记忆的读写回路套在会话生命周期上：
- 会话进行中：重要信息触发式写入长期记忆（用户偏好、明确事实）。
- 会话结束（或超时）：异步任务把整个会话提炼成情景记忆，去重后入库。
- 新会话启动：按 user_id 查出用户画像（全量，量小）加按当前意图召回相关记忆（top-k），组织成"已知信息"小节注入系统区。
- 会话进行中模型发现记忆不够，可以通过 search_memory 工具主动翻库。
这个回路跑通后，用户周二说过的偏好，周五新开会话时 Agent 还记得。
隔离的三层命名空间
不加隔离的跨会话记忆是灾难：用户在项目 A 里的技术栈偏好会被带进项目 B 的回答。我的做法是三层命名空间：
| 层级 | 内容 | 作用域 |
|---|---|---|
| 用户级 | 用户画像、通用偏好（回答风格、语言） | 该用户所有会话共享 |
| 项目/主题级 | 项目技术栈、领域知识、项目内决策 | 同项目会话共享，跨项目隔离 |
| 会话级 | 本次任务的中间状态 | 仅本会话，结束即归档或丢弃 |
每条记忆入库时打上 namespace 标签，召回时按"当前用户 + 当前项目"做元数据过滤，再走向量检索。用户级和项目级的注入策略也不同：用户级每次全量注入，项目级按相关性召回。
隔离失效的三种情况和防法
第一，话题漂移：同一个会话里用户从聊工作变成聊生活，旧上下文还在窗口里干扰。防法是检测话题切换主动清窗或 compact，把上一话题归档。
第二，记忆串项目：用户在项目 A 说"我们用 PostgreSQL"，被写成用户级记忆，项目 B 里 Agent 也默认 PostgreSQL。防法是写入时就定级——提炼 prompt 里要求判断这条信息是用户通用属性还是项目特定属性，拿不准的降级到项目级，宁可少共享。
第三，多租户泄漏：SaaS 场景下 A 用户的记忆被召回给 B 用户，这是安全事故。防法是硬约束：所有记忆读写路径强制带 user_id 过滤，过滤逻辑放在数据访问层而不是靠 prompt 自觉，再加读写审计日志。
共享与隔离的权衡
隔离越细，Agent 越"健忘"；共享越多，串味和隐私风险越大。原则：事实性的通用偏好尽量上浮到用户级（体验连贯），一切和具体任务上下文绑定的信息沉在项目级（避免误导），敏感信息（凭证、个人隐私）默认不写入长期记忆，写也要用户显式授权并可一键删除。
可能的追问
- 用户换了话题，旧记忆干扰新对话怎么办？——召回侧靠相关性过滤本来就排掉大部分；注入的记忆带时间和来源，模型能区分；顽固的在系统指令里声明"已知信息可能过时，以用户当前表述为准"。
- 记忆怎么过期？——写入带 TTL 或重要性衰减，长期未被召回的冷记忆定期清理；项目归档时整组记忆打归档标记停止召回。
- 用户要求"忘掉我的一切"怎么实现？——按 user_id 物理删除全层记忆并记录审计，GDPR 类合规场景这是必备能力，所以记忆 schema 从第一天就要按可删除设计。