X记录空间前言
很多开发者第一次做 AI Agent 时，都会自然地把记忆理解成：
messages[]
用户说一句。
AI 回一句。
然后：
messages.push(...)
最后把整个 messages 数组发送给模型。
这种方式在 Demo 阶段没有问题。
但随着：
- 对话轮数增加；
- Agent 能调用工具；
- 用户数量增长；
问题会越来越明显。
例如：
- Token 成本失控；
- 上下文越来越长；
- 模型开始遗忘重点；
- 多任务互相污染；
- Agent 回答越来越不稳定。
实际上。
真正成熟的 Agent，不会只有一种记忆。
它通常会拥有：
Working Memory
Short-term Memory
Long-term Memory
Semantic Memory
Tool Memory
这些记忆共同组成 Agent 的 Memory Architecture。
为什么需要记忆系统？
人类的大脑并不是：
全部记住。
全部参与思考。
而是：
工作记忆负责当前任务。
长期记忆保存经验。
无关信息自动遗忘。
AI Agent 也是如此。
如果所有内容都放进 Prompt。
最终：
上下文长度会无限增长。
模型质量反而下降。
因此：
记忆系统的核心目标不是记住更多。
而是：
让模型在正确的时候看到正确的信息。
Working Memory
工作记忆。
负责：
当前任务。
例如：
最近：
10～20 条消息。
特点：
- 高频访问；
- 生命周期短；
- Token 消耗最大；
例如：
当前正在开发：
Node.js + Redis + Docker
这些信息应该存在 Working Memory。
而：
三天前讨论的：
Vue3。
其实已经没有必要参与当前推理。
推荐实现
Redis。
原因：
- 毫秒级访问；
- 自动过期；
- 高并发；
通常：
TTL：
30 分钟。
或者：
2 小时。
Short-term Memory
短期记忆。
负责：
当前 Session。
例如：
用户正在开发 AI Chat。
技术栈：
Node.js
Redis
Nginx
目标：
支持 Streaming。
这些信息不需要每轮重新分析。
但也没必要永久保存。
Summary Memory
最常见实现：
摘要。
例如：
用户正在实现 AI Chat。
技术栈：
Node.js
Redis
Cloudflare
当前问题：
Streaming 输出优化。
长度：
200～500 token。
可以覆盖：
几十轮对话。
Long-term Memory
长期记忆。
保存：
稳定偏好。
例如：
使用 TypeScript
使用 Vue3
不喜欢 Redux
喜欢 Feature First
特点：
变化慢。
生命周期长。
不会每轮都参与推理。
只有相关时：
Embedding 检索。
按需加载。
Semantic Memory
语义记忆。
保存：
知识。
例如：
项目结构。
代码库。
文档。
FAQ。
通常结合：
RAG。
向量数据库。
实现。
Tool Memory
很多 Agent 都会调用：
- Git
- 文件系统
- 数据库
- API
这些结果不应该进入长期记忆。
推荐：
临时保存。
TTL：
几分钟。
任务结束自动清理。
否则：
Tool Output 很容易污染上下文。
Episodic Memory
类似：
事件记忆。
记录：
昨天修复了 Redis Bug。
上周重构了 Auth 模块。
适合：
开发 Agent。
代码 Agent。
未来：
这一层会越来越重要。
多层记忆架构
推荐：
Current Question
↓
Working Memory
↓
Summary Memory
↓
Long-term Memory
↓
Semantic Memory
↓
LLM
而不是：
All Messages
↓
LLM
Memory Retrieval
不要：
全部加载。
推荐：
按需召回。
例如：
当前问题：
Redis
只召回：
Redis 相关长期记忆。
而不是：
全部用户信息。
Memory Compression
未来的重要方向。
长对话：
压缩。
摘要。
保留：
关键事实。
删除：
噪音。
真正优秀的 Agent。
一定拥有：
遗忘能力。
总结
记忆系统决定了 Agent 的上限。
未来 AI 产品的竞争。
很可能不再只是模型竞争。
而是：
Memory Architecture 的竞争。
谁能让模型在有限上下文里看到最重要的信息。
谁就能构建更稳定、更聪明的 Agent。
