Agent Basic / 06
Memory 设计模式
“Memory” 是 Agent 领域里最容易被神化的词之一。
很多介绍会直接说：
- Agent 需要记忆
- 给它加个 memory 就更智能了
但如果不先拆清楚，最后很容易把几种完全不同的东西混在一起：
- 当前任务状态
- 会话上下文
- 长期偏好
- 外部知识库
它们都和“记住信息”有关，但并不是同一层东西。
先分清三类东西
1. State
这是当前任务执行过程中的结构化状态。
例如：
- 当前分析到哪一步
- 已经查过哪些数据
- 中间结果是什么
- 是否满足结束条件
这更像执行现场，而不是“记忆人格”。
2. Short-term Memory
这是当前会话中保留下来的上下文。
例如：
- 前几轮对话内容
- 当前用户刚才补充的约束
- 本轮任务中暂时需要保留的信息
它主要服务于当前任务连续性。
3. Long-term Memory
这是跨会话、跨任务仍然有价值的信息。
例如：
- 用户偏好
- 历史决策习惯
- 某类任务的长期背景资料
它更接近“长期沉淀的信息”。
为什么很多系统其实不需要长期记忆
这是一个很现实的问题。
很多 Agent 场景只需要：
- 当前任务状态
- 当前会话上下文
就已经足够了。
如果你一上来就做长期记忆，很容易遇到这些问题：
- 召回了不相关信息
- 旧信息污染当前任务
- 记忆更新逻辑混乱
- 很难知道该忘什么
所以不要因为“Memory 听起来高级”就盲目上长期记忆。
一个更实用的设计顺序
建议优先级通常是：
- 先设计好
State - 再处理会话内上下文
- 最后再考虑是否真的需要长期记忆
也就是说，很多所谓 memory 问题，本质上其实是 state 没设计好。
常见的 Memory 设计模式
模式 1：对话窗口保留
最简单的方式就是保留最近几轮消息。
优点：
- 简单
- 上手快
问题：
- 长任务容易撑爆上下文
- 历史信息结构化程度低
模式 2：摘要式记忆
把前面内容压缩成摘要，只保留关键结论。
优点：
- 节省上下文
- 适合长会话
问题：
- 摘要本身可能失真
- 被压掉的信息可能后面又重要
模式 3：结构化状态存储
把任务进度和中间结果保存在明确字段里。
优点：
- 可调试
- 可恢复
- 适合工作流和 Agent 系统
问题：
- 设计成本高一点
模式 4：检索式长期记忆
把长期信息存到数据库或向量库，需要时再召回。
优点：
- 不必一直塞进上下文
- 适合长期积累信息
问题：
- 召回相关性很难永远稳定
- 容易把“知识库检索”误当成“记忆”
Memory 和 RAG 不是一回事
这是一个高频误区。
RAG 解决的是：
- 如何从外部知识中取回相关内容
Memory 更关注的是：
- 系统应该记住哪些和当前主体相关的信息
两者可以结合，但不能混成一件事。
例如：
- 用户偏好更像长期记忆
- 某篇市场研究报告更像外部知识
设计 Memory 时最应该问的问题
- 这条信息是当前任务状态，还是长期信息
- 它需要跨会话保留吗
- 它如果过期了，会不会误导系统
- 它应该完整保留、摘要保留，还是只在需要时检索
如果这些问题不问清楚，memory 只会让系统更乱。
小结
Memory 不是一个魔法模块，而是一套信息保留策略。
在大多数 Agent 系统里，先把状态设计清楚，比急着做长期记忆更重要。
真正要做 memory 时，也要先区分：
- 当前状态
- 会话连续性
- 长期信息沉淀
下一篇建议继续看：