Memory 是什么？
Q: Agent 里的 Memory 是什么？
A: Memory 是 Agent 保存和召回历史信息的机制。它解决的是多轮任务里模型不能只看当前输入，还要记住用户偏好、已完成步骤、关键事实和长期上下文。
面试回答：
Memory 不等于把所有聊天记录塞进 prompt。工程上要区分短期对话上下文、任务状态和长期记忆，并按需召回。
短期记忆和长期记忆
Q: 短期记忆和长期记忆有什么区别？
A:
| 类型 | 保存什么 | 生命周期 | 存储方式 |
|---|---|---|---|
| 短期记忆 | 当前会话、最近几轮对话、当前任务状态 | session 级 | Redis、数据库、内存 |
| 长期记忆 | 用户偏好、历史事实、长期项目背景 | 跨 session | 数据库、向量库、profile |
例子：
- 短期：用户刚才说“这份简历只投后端岗位”。
- 长期：用户偏好用中文写笔记、目标是 AI 应用开发面试。
上下文怎么管理？
Q: 多轮对话里怎么避免上下文丢失？
A: 我会把上下文拆成几类：
- Raw history：最近几轮原始对话。
- Summary：旧对话压缩摘要。
- Task state：当前目标、已完成步骤、待办事项。
- Retrieved memory：从长期记忆中召回的相关信息。
- Tool observations：工具调用结果。
关键点：
不同上下文的更新频率和重要性不同，不能全部用一种方式处理。
如何按需召回？
Q: 生成时 Memory 是不是都塞进 prompt？
A: 不是。长期记忆应该按需召回。
做法：
- 根据当前 query 提取检索关键词。
- 从 memory store 中召回相关记忆。
- 按 relevance、recency、importance 排序。
- 过滤过期或冲突记忆。
- 只把必要记忆放进 prompt。
面试回答：
Memory 召回和 RAG 很像，但对象不是外部文档，而是用户历史、任务状态和长期偏好。
Memory 怎么更新？
Q: 一次会话结束后，哪些信息应该写入长期记忆？
A: 不是所有内容都应该写入长期记忆。适合写入的内容：
- 稳定偏好：语言、格式、技术栈偏好。
- 持续目标：正在准备什么面试、做什么项目。
- 可复用事实：项目背景、技术选择、约束。
- 用户明确要求记住的信息。
不适合写入：
- 一次性闲聊。
- 临时状态。
- 敏感信息。
- 不确定推测。
怎么处理记忆冲突？
Q: 如果新记忆和旧记忆冲突怎么办？
A:
- 用时间戳判断新旧。
- 保留来源和置信度。
- 对明显变化的偏好覆盖旧值。
- 对重要冲突向用户确认。
- 不把推测当事实写入。
项目表达：
Memory 需要可更新、可删除、可解释。否则长期运行后会积累错误上下文，反而影响 Agent 决策。
终止条件
Q: Agent 怎么判断一次会话或任务结束？
A: 常见终止条件：
- 用户目标已经满足。
- 达到最大步骤数。
- 工具连续失败。
- 信息不足，需要用户补充。
- 风险动作需要人工确认。
- 模型判断继续执行没有收益。
面试里可以说：
Agent 不能无限循环。每个任务都应该有明确 success criteria、max steps 和 fallback path。
常见坑
Q: Memory 系统有什么坑？
A:
- 把所有历史都塞进 prompt，成本高且噪声大。
- 没有区分短期状态和长期偏好。
- 记忆不可删除，容易造成隐私问题。
- 旧记忆覆盖新事实。
- 召回太多无关记忆，干扰模型判断。
- 没有记录 memory 来源，无法解释为什么模型这么回答。