大模型长短期记忆系统设计与落地分析报告
- 大模型长短期记忆系统设计与落地分析报告
-
- [1. 结论摘要](#1. 结论摘要)
- [2. 长短期记忆的核心分类](#2. 长短期记忆的核心分类)
-
- [2.1 短期记忆](#2.1 短期记忆)
- [2.2 中期记忆](#2.2 中期记忆)
- [2.3 长期记忆](#2.3 长期记忆)
- [3. 主流设计方案对比](#3. 主流设计方案对比)
- [3.1 方案一：滑动窗口 + 对话摘要](#3.1 方案一：滑动窗口 + 对话摘要)
- [3.2 方案二：向量数据库长期记忆](#3.2 方案二：向量数据库长期记忆)
- [3.3 方案三：结构化记忆表](#3.3 方案三：结构化记忆表)
- [3.4 方案四：MemGPT / Letta 多层记忆模型](#3.4 方案四：MemGPT / Letta 多层记忆模型)
- [3.5 方案五：Zep / Graphiti 时间知识图谱记忆](#3.5 方案五：Zep / Graphiti 时间知识图谱记忆)
- [3.6 方案六：LangGraph / LangMem 状态 + 记忆框架](#3.6 方案六：LangGraph / LangMem 状态 + 记忆框架)
- [4. 推荐落地架构](#4. 推荐落地架构)
- [4.1 总体架构](#4.1 总体架构)
- [4.2 记忆写入流程](#4.2 记忆写入流程)
-
- [写入判断 Prompt 示例](#写入判断 Prompt 示例)
- [4.3 记忆读取流程](#4.3 记忆读取流程)
- [5. 存储设计建议](#5. 存储设计建议)
-
- [5.1 最小可行版本](#5.1 最小可行版本)
- [5.2 企业增强版本](#5.2 企业增强版本)
- [6. 记忆表设计](#6. 记忆表设计)
-
- [6.1 user_memory](#6.1 user_memory)
- [6.2 memory_event](#6.2 memory_event)
- [6.3 memory_embedding](#6.3 memory_embedding)
- [7. 算法与策略](#7. 算法与策略)
- [7.1 记忆重要性评分](#7.1 记忆重要性评分)
- [7.2 记忆遗忘机制](#7.2 记忆遗忘机制)
- [7.3 冲突检测](#7.3 冲突检测)
- [7.4 召回重排序](#7.4 召回重排序)
- [8. 不同场景选型建议](#8. 不同场景选型建议)
- [9. 本地客户端落地方案](#9. 本地客户端落地方案)
- [10. 分阶段实施路线](#10. 分阶段实施路线)
- [11. 推荐最终方案](#11. 推荐最终方案)
- [12. 实施优先级建议](#12. 实施优先级建议)
- 相关文档
- 总结
大模型长短期记忆系统设计与落地分析报告
1. 结论摘要
大模型本身是无状态的，所谓"记忆"本质上是围绕上下文窗口、外部存储、检索、摘要、偏好沉淀、事实更新和权限控制构建的一套工程系统。
推荐落地方案：
text
短期记忆：会话上下文 + 滑动窗口 + 摘要压缩
中期记忆：任务态 / 会话态 Memory，例如当前项目、当前流程、用户目标
长期记忆：用户画像 + 事实记忆 + 偏好记忆 + 历史事件 + 知识库
检索层：向量检索 + 关键词检索 + 图谱检索 + 重排序
治理层：记忆写入审核、过期机制、冲突检测、用户可管理对于企业级智能体，不建议只用"向量库 + 历史聊天记录"实现长期记忆。更合理的架构是：
text
原始事件层 → 记忆抽取层 → 记忆分类层 → 存储层 → 检索层 → 上下文组装层 → 反馈更新层2. 长短期记忆的核心分类
2.1 短期记忆
短期记忆指模型当前任务中马上需要使用的信息，通常位于 Prompt 或上下文窗口内。
典型内容：
- 当前用户问题
- 最近几轮对话
- 当前任务目标
- 当前工具调用结果
- 临时变量
- 当前页面状态
- 当前工作流状态
适合存储方式：
- 内存缓存
- Redis
- 会话上下文表
- LangGraph State
- Agent Runtime State
优点：
- 响应快
- 实现简单
- 与当前任务强相关
缺点：
- 容量有限
- 会话结束后容易丢失
- 长对话会出现上下文污染
2.2 中期记忆
中期记忆是跨多轮任务但不一定永久保存的信息。
典型内容：
- 当前项目背景
- 当前用户正在完成的流程
- 最近一次需求分析结论
- 当前表单填写状态
- 当前代码生成上下文
- 最近上传文件的摘要
适合场景：
- 项目经理智能体
- 编程助手
- 投研助手
- 工作流编排助手
- 多轮任务执行 Agent
建议存储：
text
session_id
user_id
task_id
memory_type
content
summary
created_at
expired_at
source
confidence中期记忆需要设置 TTL，例如 7 天、30 天，避免长期污染。
2.3 长期记忆
长期记忆是跨会话、跨任务持续生效的信息。
可以拆成四类：
| 类型 | 内容 | 示例 |
|---|---|---|
| 事实记忆 | 关于用户或业务的稳定事实 | 用户是 Java 架构师 |
| 偏好记忆 | 用户长期偏好 | 喜欢 Markdown、偏落地方案 |
| 情景记忆 | 过去发生过的交互事件 | 上次分析过智能体开发规范 |
| 程序性记忆 | Agent 自身行为规则 | 回答技术方案时先优化问题再分析 |
长期记忆不能无脑写入，需要判断：
text
是否长期有效？
是否会影响未来回答？
是否用户明确要求记住？
是否敏感？
是否可能过期？
是否与已有记忆冲突？3. 主流设计方案对比
3.1 方案一：滑动窗口 + 对话摘要
原理
保留最近 N 轮对话，超过窗口后对历史对话进行摘要。
text
最近对话 → 直接进入 Prompt
较早对话 → 总结为摘要
更早对话 → 归档或丢弃优点
- 实现成本最低
- 不依赖复杂基础设施
- 适合普通聊天机器人
- 对短任务效果不错
缺点
- 摘要会丢细节
- 摘要错误会长期污染后续对话
- 不适合精准事实追踪
- 不适合复杂任务和跨会话记忆
实现成本
低。
适用场景
- 普通客服
- 简单助手
- 单会话任务
- 低成本 MVP
不适合
- 长期用户画像
- 企业知识助手
- 多项目上下文管理
- 金融、医疗、法律等高准确性场景
3.2 方案二：向量数据库长期记忆
原理
将历史对话、文档、用户偏好切片后生成 Embedding，存入向量库，回答时按相似度召回。
text
对话 / 文档 → Chunk → Embedding → Vector DB → TopK Recall → Prompt常用组件
- Milvus
- Qdrant
- Weaviate
- Chroma
- pgvector
- Elasticsearch vector search
优点
- 实现相对简单
- 适合语义检索
- 对文档问答、知识库问答有效
- 工程生态成熟
缺点
- 容易召回相似但不正确的内容
- 对时间顺序、事实更新、关系推理较弱
- 不擅长处理"这个事实已经过期"
- 用户画像容易碎片化
- 需要额外重排序和过滤
实现成本
中低。
适用场景
- 文档问答
- 知识库助手
- 客服知识检索
- 代码库问答
- 企业制度查询
不适合
- 强时间线记忆
- 复杂人际 / 业务关系
- 高频变化的用户状态
- 需要事实冲突检测的场景
3.3 方案三：结构化记忆表
原理
不直接保存自然语言片段，而是将记忆抽取为结构化字段。
示例：
json
{
"user_id": "u001",
"memory_type": "preference",
"key": "response_style",
"value": "prefers practical Markdown reports",
"confidence": 0.92,
"source": "conversation",
"created_at": "2026-06-23",
"updated_at": "2026-06-23"
}优点
- 可控性强
- 易管理、易删除、易审计
- 适合用户偏好和画像
- 便于权限控制
- 便于产品化展示
缺点
- 抽取规则需要设计
- 复杂语义不易结构化
- 需要维护 Schema
- 新场景扩展需要改模型或规则
实现成本
中等。
适用场景
- 用户偏好记忆
- 个人助手
- 企业 Copilot
- 金融投顾助手
- 工作流智能体
推荐 Schema
sql
CREATE TABLE user_memory (
id BIGINT PRIMARY KEY,
user_id VARCHAR(64),
memory_type VARCHAR(32),
memory_key VARCHAR(128),
memory_value TEXT,
source_type VARCHAR(32),
source_id VARCHAR(128),
confidence DECIMAL(5,4),
importance_score DECIMAL(5,4),
status VARCHAR(16),
created_at TIMESTAMP,
updated_at TIMESTAMP,
expired_at TIMESTAMP
);3.4 方案四：MemGPT / Letta 多层记忆模型
原理
将大模型上下文类比为操作系统内存管理：
text
Core Memory：核心记忆，始终放入上下文
Recall Memory：历史对话，可检索
Archival Memory：长期归档，可搜索Agent 可以通过工具主动读取、写入、更新记忆。
优点
- 适合长对话
- 适合自主 Agent
- 记忆分层清晰
- 能把"上下文管理"变成 Agent 自身能力
- 支持长周期任务
缺点
- 实现复杂度较高
- Agent 自主写记忆可能出错
- 需要严格限制写入权限
- 需要记忆审计和回滚机制
实现成本
中高。
适用场景
- 长期个人助手
- 自主任务执行 Agent
- 编程 Agent
- 研究型 Agent
- 多天持续任务
落地建议
不要让模型完全自由写长期记忆，建议加一层 Memory Controller：
text
Agent 提议写入 → Memory Controller 判断 → 敏感信息过滤 → 冲突检测 → 入库3.5 方案五：Zep / Graphiti 时间知识图谱记忆
原理
把对话、事实、实体、关系、时间有效性组织为时间感知知识图谱。
text
事件 Episode → 实体 Entity → 事实 Fact → 关系 Edge → 有效时间 Valid Time例如：
text
用户 A --偏好--> Markdown 报告
用户 A --正在做--> 智能体记忆系统设计
该事实有效期：2026-06-23 起优点
- 擅长复杂关系
- 擅长时间变化
- 支持事实失效
- 更适合企业级 Agent Memory
- 能处理"以前是这样，现在变了"的问题
缺点
- 实现复杂
- 图谱构建成本高
- 需要实体消歧
- 需要图数据库或图计算能力
- 对团队工程能力要求高
实现成本
高。
适用场景
- 企业知识智能体
- CRM 智能助手
- 金融投研助手
- 项目管理 Agent
- 多系统业务助手
- 需要时间线推理的场景
不适合
- 简单聊天机器人
- 低成本 MVP
- 业务关系很简单的应用
3.6 方案六：LangGraph / LangMem 状态 + 记忆框架
原理
将 Agent 的运行状态和长期记忆拆开管理：
text
State：当前任务执行状态
Memory Store：长期语义、情景、程序性记忆
Graph Workflow：控制 Agent 执行流程优点
- 非常适合工作流型 Agent
- 状态可控
- 易于调试
- 适合多节点、多工具、多步骤任务
- 可以和 RAG、数据库、工具调用组合
缺点
- 框架学习成本较高
- 需要设计状态图
- 对简单应用略重
- 仍需自己设计记忆写入策略
实现成本
中高。
适用场景
- 工作流编排
- 多智能体协作
- 企业内部 Copilot
- 邮件助手
- 任务自动化助手
- 项目管理助手
4. 推荐落地架构
4.1 总体架构
text
┌─────────────────────┐
│ 用户输入 / 工具事件 │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ 会话上下文管理器 │
│ Short-term Memory │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ 记忆抽取器 │
│ Memory Extractor │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ 记忆分类与审核 │
│ Fact / Preference │
│ Episode / Procedure │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ 多模态存储层 │
│ SQL / Vector / Graph │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ 记忆检索与重排序 │
│ Recall + Rerank │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ Prompt 组装器 │
│ Context Builder │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ LLM / Agent 执行 │
└─────────────────────┘4.2 记忆写入流程
text
1. 用户输入
2. 判断是否包含可记忆信息
3. 抽取候选记忆
4. 判断记忆类型
5. 判断是否敏感
6. 判断是否长期有效
7. 与已有记忆做冲突检测
8. 写入数据库
9. 记录来源和置信度
10. 必要时允许用户确认写入判断 Prompt 示例
text
请判断以下内容是否值得写入长期记忆。
判断标准：
1. 是否对未来对话有帮助
2. 是否是长期稳定事实
3. 是否是用户明确偏好
4. 是否涉及敏感信息
5. 是否可能短期过期
6. 是否与已有记忆冲突
输出 JSON：
{
"should_save": true/false,
"memory_type": "fact/preference/episode/procedure",
"content": "...",
"confidence": 0.0-1.0,
"reason": "..."
}4.3 记忆读取流程
text
1. 解析用户意图
2. 判断是否需要记忆
3. 根据任务类型选择检索策略
4. 从短期 / 中期 / 长期记忆中召回
5. 重排序
6. 去重
7. 冲突检测
8. 组装进 Prompt检索策略
| 用户问题类型 | 推荐召回方式 |
|---|---|
| 当前任务问题 | 短期上下文 |
| 用户偏好问题 | 结构化记忆 |
| 历史对话问题 | 向量检索 + 时间过滤 |
| 复杂关系问题 | 图谱检索 |
| 文档问答 | RAG |
| 工作流状态 | State Store |
| 多项目切换 | project_id + memory scope |
5. 存储设计建议
5.1 最小可行版本
适合 MVP：
text
Redis：短期上下文
PostgreSQL：结构化记忆
pgvector：向量检索
对象存储：原始对话和文件5.2 企业增强版本
适合企业 Agent 平台：
text
Redis：会话态
PostgreSQL：结构化记忆、权限、审计
Milvus / Qdrant：向量记忆
Neo4j / NebulaGraph：关系图谱
Elasticsearch：关键词检索
Kafka：事件流
对象存储：原始数据归档6. 记忆表设计
6.1 user_memory
sql
CREATE TABLE user_memory (
id BIGSERIAL PRIMARY KEY,
user_id VARCHAR(64) NOT NULL,
scope VARCHAR(32) NOT NULL,
memory_type VARCHAR(32) NOT NULL,
memory_key VARCHAR(128),
memory_value TEXT NOT NULL,
source_type VARCHAR(32),
source_id VARCHAR(128),
confidence NUMERIC(5,4),
importance_score NUMERIC(5,4),
status VARCHAR(16) DEFAULT 'active',
created_at TIMESTAMP DEFAULT now(),
updated_at TIMESTAMP DEFAULT now(),
expired_at TIMESTAMP
);6.2 memory_event
sql
CREATE TABLE memory_event (
id BIGSERIAL PRIMARY KEY,
memory_id BIGINT,
event_type VARCHAR(32),
old_value TEXT,
new_value TEXT,
operator VARCHAR(64),
reason TEXT,
created_at TIMESTAMP DEFAULT now()
);6.3 memory_embedding
sql
CREATE TABLE memory_embedding (
id BIGSERIAL PRIMARY KEY,
memory_id BIGINT,
chunk_text TEXT,
embedding VECTOR,
created_at TIMESTAMP DEFAULT now()
);7. 算法与策略
7.1 记忆重要性评分
可以用以下公式：
text
importance_score =
0.35 * relevance
+ 0.25 * stability
+ 0.20 * frequency
+ 0.10 * explicitness
+ 0.10 * recency解释：
| 因子 | 含义 |
|---|---|
| relevance | 对未来任务是否有用 |
| stability | 是否长期稳定 |
| frequency | 是否多次出现 |
| explicitness | 用户是否明确表达 |
| recency | 最近是否出现 |
只有超过阈值才写入长期记忆：
text
score >= 0.75：自动写入
0.5 <= score < 0.75：写入中期记忆或请求确认
score < 0.5：不写入7.2 记忆遗忘机制
长期记忆不是越多越好，需要遗忘。
遗忘策略：
text
1. TTL 过期
2. 用户主动删除
3. 新事实覆盖旧事实
4. 低频低价值记忆降权
5. 敏感信息定期清理
6. 冲突记忆进入待确认状态建议字段：
text
status: active / inactive / expired / deleted / conflicted
expired_at: 过期时间
last_used_at: 最近使用时间
use_count: 使用次数7.3 冲突检测
例如：
text
旧记忆：用户喜欢简短回答
新记忆：用户希望技术方案尽量详细处理方式：
text
1. 判断是否同一 memory_key
2. 判断时间先后
3. 判断适用场景
4. 新记忆覆盖旧记忆
5. 旧记忆标记为 inactive
6. 保留审计记录7.4 召回重排序
推荐组合：
text
final_score =
0.35 * semantic_similarity
+ 0.25 * importance_score
+ 0.15 * recency_score
+ 0.15 * scope_match
+ 0.10 * confidence其中：
| 因子 | 作用 |
|---|---|
| semantic_similarity | 语义相关性 |
| importance_score | 记忆重要性 |
| recency_score | 时间新鲜度 |
| scope_match | 是否匹配当前项目 / 场景 |
| confidence | 记忆置信度 |
8. 不同场景选型建议
| 场景 | 推荐方案 |
|---|---|
| 普通聊天助手 | 滑动窗口 + 摘要 |
| 企业知识库问答 | RAG + 向量库 + 关键词检索 |
| 个人长期助手 | 结构化记忆 + 向量记忆 |
| 工作流 Agent | LangGraph State + Memory Store |
| 自主 Agent | MemGPT / Letta 风格多层记忆 |
| 金融投研助手 | RAG + 结构化记忆 + 审计 |
| CRM / 销售助手 | 时间知识图谱 + 用户画像 |
| 多智能体协作 | 共享 Memory Bus + 权限隔离 |
| 本地客户端 | SQLite + 向量库 + 本地加密 |
| 企业级平台 | SQL + Vector DB + Graph DB + 审计治理 |
9. 本地客户端落地方案
如果要在本地客户端实现用户长短期记忆，推荐：
text
SQLite：结构化记忆
Chroma / LanceDB / sqlite-vec：本地向量检索
本地文件系统：原始记录归档
加密模块：敏感信息加密
Memory Controller：记忆写入和读取策略本地架构
text
客户端 UI
↓
Agent Runtime
↓
Memory Controller
↓
SQLite + Vector Store
↓
Context Builder
↓
LLM API / 本地模型本地客户端关键能力
- 用户可查看记忆
- 用户可删除记忆
- 用户可关闭记忆
- 敏感记忆默认不保存
- 支持导出和备份
- 支持项目级隔离
- 支持本地加密
10. 分阶段实施路线
第一阶段：MVP
目标：快速可用。
实现：
text
短期上下文
会话摘要
结构化用户偏好
简单向量检索
手动删除记忆周期：1 - 2 周。
第二阶段：可产品化
目标：稳定可靠。
实现：
text
记忆分类
重要性评分
冲突检测
TTL 过期
记忆审计
用户记忆管理页面
项目级 Scope周期：3 - 6 周。
第三阶段：企业级
目标：多业务、多用户、多智能体。
实现：
text
权限控制
图谱记忆
多源数据接入
审计与合规
记忆质量评估
多租户隔离
自动评测集周期：2 - 4 个月。
11. 推荐最终方案
对于大多数可落地的大模型应用，推荐采用混合记忆架构：
text
短期：上下文窗口 + Redis
中期：任务 State + 会话摘要
长期：结构化 Memory + 向量 Memory
高级：时间知识图谱
治理：记忆审核 + 冲突检测 + 用户可控最终形态：
text
Memory = State + Summary + RAG + Profile + Graph + Governance不要把记忆简单理解为"把历史聊天记录塞进向量库"。真正可落地的记忆系统，需要解决：
text
记什么
什么时候记
记到哪里
怎么召回
怎么更新
怎么遗忘
怎么解释
怎么让用户控制
怎么避免污染模型上下文12. 实施优先级建议
优先做：
- 短期上下文管理
- 会话摘要
- 用户偏好结构化记忆
- 记忆管理页面
- 向量召回
- 冲突检测
- TTL 与遗忘机制
暂缓做：
- 全量知识图谱
- 完全自主记忆写入
- 多智能体共享记忆
- 自动长期画像推理
- 复杂图谱推理
原因是这些能力工程复杂度高，且容易带来误记、隐私和不可解释问题。
相关文档
总结
大模型记忆系统的最佳实践不是单一算法，而是分层架构。
最推荐的落地路径是：
text
先做短期上下文和摘要
再做结构化长期记忆
再接入向量检索
最后根据业务复杂度引入图谱记忆对于你的智能体平台建设，建议优先采用：
text
LangGraph State 思路
+ 结构化 Memory Store
+ 向量检索
+ Memory Controller
+ 用户可控记忆管理如果未来要支持企业级客户、复杂项目管理、长期任务执行，再逐步引入 Zep / Graphiti 类似的时间知识图谱记忆模型。