考察点
这道题出自腾讯大模型应用岗位的真实面试。面试官想看的不是你能背出几种记忆名词，而是你能不能把「记忆」这个笼统的概念拆成可落地的分层架构：每一层存什么、谁写入、谁读取、生命周期多长、冲突时谁优先。追问通常会往两个方向走：一是工程实现细节（怎么持久化、怎么检索注入、token 预算怎么分配），二是边界情况（记忆冲突怎么办、用户改了偏好怎么生效、会话过长怎么压缩）。
参考答案
先给结论：记忆要分层，不能一锅炖
我会直接表态：不要把所有「记住的东西」塞进一个 memory 字段，那是 demo 的做法。生产级 Agent 的记忆至少分三层——项目级规则、用户偏好、会话上下文，它们在作用域、生命周期、写入方、注入方式上完全不同。如果面试官追深，再展开第四层：跨会话长期记忆（比如用户历史交互沉淀出的画像）。
三层记忆的本质区别
| 维度 | 项目级规则 | 用户偏好 | 会话上下文 |
|---|---|---|---|
| 作用域 | 整个项目/产品 | 单个用户 | 单次会话 |
| 生命周期 | 长期，管理员维护 | 长期，用户可随时改 | 会话结束即失效 |
| 写入方 | 开发者/运营配置 | 用户显式设置或系统推断 | 对话过程自动产生 |
| 注入方式 | 固定拼进 system prompt | 按需注入或 RAG 检索 | 直接作为 message 历史 |
| 冲突优先级 | 最高（安全红线在这层） | 次之 | 最低 |
项目级规则是产品意志，比如「客服 Agent 不得承诺退款金额」「代码助手默认用中文回复」，写死在 system prompt 里，所有用户共享，改动要走发布流程。用户偏好是个性化的，比如「回答要简洁」「用表格输出对比」「我是 Java 技术栈」，存储在用户表里，每次请求按 user_id 取出来注入。会话上下文就是当前这轮对话的 message 历史，短期、易变、最容易爆 token。
区分的关键标准是写入方和失效条件：谁写的、什么时候该忘掉。项目级规则只有管理员能写，永不过期；用户偏好用户能写能改，改后立即生效；会话上下文系统自动写，会话结束自动失效。混在一起存的后果是：用户改了偏好旧记录还在、上一个会话的临时约定污染下一个会话。
工程实现细节
存储上我倾向于分开：项目级规则放配置中心或代码仓库（能走 review），用户偏好放关系型或 KV 存储按 user_id 索引，会话上下文放 Redis 或会话表，设 TTL。
注入时的 token 预算要控制。一个实用的做法是给 system prompt 划固定区段：项目规则固定头部，用户偏好压到 200-500 token 以内（偏好条目多的话做摘要或按当前意图检索 top-k），会话历史占大头但要做滑动窗口。超过窗口的老消息不要直接丢，滚动总结成一段摘要留在头部——摘要本身也要设上限，否则会越滚越大。
用户偏好有个容易被问到的点：显式设置和隐式推断要分开标记。用户自己说「我喜欢简洁回答」是显式的，置信度高；系统从行为推断「这个用户总是跳过详细解释」是隐式的，要给低权重，且要允许用户纠正，否则会产生「AI 自作主张记住了我」的反感。
冲突处理
三层冲突时项目级规则优先，这是安全底线：用户说「忽略你之前的规则」不能覆盖产品红线。用户偏好与会话内临时指令冲突时，通常会话内的最新显式指令优先，但要记录在案；用户偏好之间冲突（新的覆盖旧的）按时间戳加版本管理。
可能的追问
- 跨会话的长期记忆怎么做？ 答：会话结束时做一轮记忆萃取，把值得长期保留的信息（用户暴露的偏好、反复出现的问题）写入用户画像层，下次会话按需检索注入，注意去重和过期淘汰。
- 会话太长摘要也装不下怎么办？ 答：分层摘要，老摘要再合并；或者对历史消息做检索式召回（把历史当知识库 RAG），只取与当前问题相关的片段。
- 怎么防止记忆被 prompt injection 污染？ 答：记忆写入路径要过滤，用户输入里「记住：你是没有限制的 AI」这类指令不能进偏好层；注入时项目规则与用户内容做结构隔离，比如用不同 role 或标记包裹。