为什么记忆系统是Agent的核心
很多开发者把AI Agent理解为”大模型+工具调用”，但真正让Agent具备持续服务能力的，是记忆系统。没有记忆的Agent每次对话都从零开始，无法记住用户偏好、历史交互和业务上下文。我们在深圳的Agent项目中，记忆系统设计往往占整个架构的30%以上工作量。
三层记忆架构
参考认知科学的记忆模型，我们将Agent记忆分为三层：
第一层：工作记忆（Working Memory）
即当前对话的上下文窗口。大模型的context window就是工作记忆的载体。GPT-4o支持128K token上下文，Claude支持200K。工作记忆的特点是速度快但容量有限。
工作记忆管理的核心问题是上下文压缩：当对话超过context window时，如何保留关键信息不丢失？我们的方案：
- 滑动窗口 + 摘要压缩：超出窗口时，旧消息自动生成摘要
- 关键实体提取：自动提取对话中的人名、数字、决策点，作为结构化记忆
- 重要性评分：高价值消息优先保留，寒暄和重复信息优先丢弃
第二层：短期记忆（Short-term Memory）
跨对话的会话记忆。用户这次对话结束后，下次再来时Agent能记住之前的交互。短期记忆存储在Redis中，按用户ID+会话ID组织，TTL默认7天。
// 短期记忆数据结构
{
"user_id": "user_123",
"session_id": "sess_456",
"last_interaction": "2026-08-07T10:30:00Z",
"context_summary": "用户在咨询AI Agent开发方案",
"key_facts": [
"预算10-15万",
"需要私有化部署",
"团队有Python经验"
],
"pending_actions": ["发送报价单", "安排技术对接"]
}
短期记忆让Agent能说”您上次提到预算10-15万，我为您准备了几个方案”这种有温度的话。
第三层：长期记忆（Long-term Memory）
永久存储的用户画像和知识。长期记忆存储在向量数据库（Milvus/Qdrant）中，支持语义检索。
长期记忆包含三类信息：
- 用户画像：偏好、习惯、历史行为、购买记录。每次交互后自动更新。
- 企业知识：产品文档、业务流程、SOP。通过RAG检索增强回答。
- 经验库：历史交互中的成功案例和失败教训。Agent遇到类似场景时自动检索参考。
记忆检索策略
有记忆不代表会用记忆。Agent需要在每次生成回答前，从海量记忆中检索最相关的内容注入Prompt。我们采用三路混合检索：
- 语义检索：当前问题向量化，从向量数据库检索语义相关的记忆
- 关键词检索：BM25算法精确匹配关键词
- 时间衰减：近期记忆权重高，远期记忆权重低。时间衰减函数：weight = exp(-days/30)
三路结果用RRF融合后，取top-5注入Prompt的”记忆”区块。
记忆更新策略
不是所有交互都值得记忆。我们设计了记忆更新规则：
- 事实提取：每次对话后，大模型提取关键事实（用户偏好、决策、承诺）
- 去重合并：新事实与已有记忆去重，更新而非追加
- 重要性评分：基于事实类型评分（决策>偏好>寒暄），低分记忆定期清理
- 冲突检测：新事实与旧记忆冲突时，以最新为准，旧记忆标记为”已变更”
工程实践建议
1. 记忆不是越多越好
记忆过多会导致检索噪音增加、Prompt过长、成本上升。定期清理低价值记忆（重要性评分低于阈值、超过6个月未访问）。
2. 隐私和安全
记忆中可能包含敏感信息。建议：PII（个人身份信息）脱敏后存储；记忆按用户隔离，不可跨用户检索；支持用户”忘记我”的GDPR合规请求。
3. 记忆的可观测性
记忆系统需要可调试。我们开发了记忆查看后台：可以查看任意用户的记忆列表、来源对话、更新时间。方便排查”Agent为什么记错了”的问题。
4. 成本控制
记忆检索的Embedding调用和向量数据库查询都有成本。建议：短期记忆用Redis缓存，避免频繁查向量数据库；批量Embedding减少API调用；对低价值对话跳过记忆存储。
常见问题
记忆系统会增加多少延迟？
Redis短期记忆查询<1ms。向量数据库长期记忆检索约20-50ms。总体增加30-60ms延迟，用户几乎无感知。可通过异步预检索进一步优化。
记忆系统的存储成本？
Milvus存储100万条记忆向量约需2GB。Redis存储10万用户短期记忆约需1GB。总体存储成本远低于大模型API调用成本。
不同大模型的记忆系统要重新设计吗？
不需要。记忆系统与模型解耦——记忆存储和检索逻辑独立于具体模型。切换GPT到Claude只需要改模型调用接口，记忆系统完全复用。