记忆系统的写入读取策略
1. 为什么 Agent 需要记忆
Agent（智能体）需要记忆，是因为上下文窗口是有限的，而用户的需求是连续且累积的。
1.1 上下文窗口 vs 记忆系统的本质区别
| 维度 | 上下文窗口（Context Window） | 记忆系统（Memory System） |
|---|---|---|
| 存储位置 | LLM 输入 token 序列 | 外部存储（向量数据库、KV 存储等） |
| 容量限制 | 受限于模型输入上限（如 128k tokens） | 仅受存储介质限制，理论上无限 |
| 访问方式 | 全部涌入 prompt，无差别对待 | 按需检索，只取相关内容 |
| 适用场景 | 当前会话的即时上下文 | 跨会话、跨任务的信息复用 |
| 成本 | 每个请求都要付费，越长越贵 | 检索成本远低于重复编码整个上下文 |
| 衰减 | 会话结束即消失 | 持久化，可跨会话保留 |
核心结论：上下文窗口是”工作内存”，记忆系统是”外部存储”。上下文窗口解决”当前计算”的问题，记忆系统解决”历史信息复用”的问题。
1.2 记忆系统解决的三个核心问题
- 信息跨会话保留：用户上周说过的偏好，今天无需重复提醒
- 上下文窗口的高效利用：不是把所有历史都塞进 prompt，而是精确检索所需内容
- 系统状态的持久化：任务执行到一半被打断，能从断点恢复
2. 记忆的分类体系
记忆不是铁板一块，按用途和时效可划分为五类：
2.1 短期记忆（Short-Term Memory）
也称为工作记忆，存在于单次请求的生命周期内。
- 内容：当前对话的最近几轮、当前任务的中间状态
- 时效：毫秒到秒级，随请求结束而消亡
- 容量：上下文窗口的一部分
- 典型实现：直接放在 prompt 的 system/user/assistant 消息序列中
输入: "帮我把报告发给张总"
短期记忆: {当前任务: 发送报告, 附件: report.pdf, 收件人: 张总}
2.2 中期会话记忆（Session Memory）
跨越单次请求，但仅存在于当前会话（浏览器 tab 打开期间）。
- 内容：当前会话中用户提到的关键事实、已确认的任务目标
- 时效：会话期间（可能是几分钟到几小时）
- 容量：中等（通常 50-200 条记忆条目）
- 典型实现：Redis、会话级向量存储
2.3 长期事实记忆（Long-Term Factual Memory）
持久化存储，跨会话存在。
- 内容：用户提供的个人资料、项目背景、已验证的事实
- 时效：长期（需要显式更新或过期策略）
- 容量：大（向量数据库可存储百万级条目）
- 典型实现：向量数据库（Milvus、Pinecone）+ 结构化 KV 存储
2.4 偏好记忆（Preference Memory）
专门存储用户的行为偏好和操作习惯。
- 内容：沟通风格偏好、常用工具、拒绝的行为模式
- 时效：长期（偏好相对稳定）
- 特点：写入需谨慎，一旦错误写入会持续影响体验
- 典型实现：结构化存储 + 向量混合检索
2.5 任务状态记忆（Task State Memory）
记录多步骤任务或异步任务的执行进度。
- 内容：任务当前进行到哪一步、已收集的信息、待确认事项
- 时效：任务生命周期内，任务完成后可清除或归档
- 典型实现：状态机 + KV 存储
2.6 分类对比总览
| 类型 | 时效 | 容量 | 写入频率 | 读取频率 | 典型场景 |
|---|---|---|---|---|---|
| 短期记忆 | 请求级 | 极小 | 每轮 | 每轮 | 当前对话上下文 |
| 中期会话记忆 | 会话级 | 中等 | 数次/会话 | 数次/会话 | 会话中的关键信息 |
| 长期事实记忆 | 永久/长时 | 大 | 极少 | 频繁 | 背景信息、已验证事实 |
| 偏好记忆 | 长期 | 小 | 极谨慎 | 频繁 | 用户风格偏好 |
| 任务状态记忆 | 任务级 | 中等 | 按任务进度 | 按任务进度 | 多步骤任务断点恢复 |
3. 记忆的数学抽象
3.1 记忆作为外部状态
将记忆系统抽象为外部状态机：
：状态空间，所有可能记忆条目的集合 ：动作空间，写入、读取、更新、删除操作 ：状态转移函数 ：检索函数，从记忆中获取相关条目的机制
记忆系统的运作流程：
用户输入 → 检索记忆 → 与输入融合 → LLM 推理 → 决定是否写入新记忆 → 更新外部状态
3.2 记忆检索的数学形式
给定查询
其中
：语义相似度（向量检索） ：时效性得分（新近写入的记忆权重更高） ：重要性权重（经显式评估的记忆质量）
3.3 写入策略与读取策略的数学影响
写入策略决定记忆的质量分布。设写入函数为
- 宽松写入：
大，记忆容量快速增长，但噪声增多，检索召回率提高但精确率下降 - 严格写入：
小，记忆精炼，但可能遗漏重要信息，精确率提高但召回率下降
读取策略决定记忆的利用效率。设读取函数为
- 宽松读取：
大，返回更多候选，但融合成本高，LLM 需要更强的判别能力 - 严格读取：
小，上下文更干净，但可能遗漏相关记忆
读写策略共同决定系统性能上界。设系统整体性能为
写入和读取不是独立的——好的写入策略降低读取难度，好的读取策略减少对写入质量的依赖。
4. 写入策略：写什么、何时写、怎么写
4.1 记忆写入的触发条件
应该写入记忆的场景：
-
用户显式提供的事实
- “我叫张伟”，“我们公司在望京”
- 判断标准：用户用了陈述句且包含可验证的个人/业务事实
-
跨会话仍然有效的推断
- 用户连续三次选择了方案 A → 可能存在方案 A 偏好
- 判断标准：该推断在当前会话结束后仍然有价值
-
任务执行的关键里程碑
- “已完成第一步：数据清洗”
- 判断标准：若任务中断，需要从该状态恢复
-
用户明确要求记住的内容
- “把这个记住，以后别再问我”
- 判断标准：用户使用”记住""别忘了”等显式指令
不应该写入记忆的场景：
-
情绪性表达
- “我今天心情很差” → 这是会话内的上下文，不需要持久化
- 除非情绪状态对后续任务有实质影响（如”我今天很忙，只能聊 5 分钟”）
-
模糊或未确认的信息
- “可能是周二开会吧” → 不确定，不写入
- 除非明确标注置信度，且后续可验证
-
可从知识库直接获取的公共信息
- “北京是中国的首都” → 不需要记忆，检索知识库即可
-
纯粹的一次性闲聊
- “今天天气不错” → 无信息价值，写入是浪费
4.2 记忆条目的字段设计
每条记忆条目应包含以下字段：
{
"id": "mem_20240517_001",
"type": "fact|preference|task_state|session",
"content": "用户偏好使用简洁的语言回复",
"embedding": [0.123, -0.456, ...],
"created_at": "2024-05-17T10:30:00Z",
"updated_at": "2024-05-17T10:30:00Z",
"importance": 0.85,
"confidence": 0.9,
"source": "explicit_user_statement|inference|tool_result",
"expires_at": null,
"tags": ["偏好", "沟通风格"],
"metadata": {
"session_id": "sess_abc123",
"related_entities": ["用户_001"]
}
}字段说明：
| 字段 | 用途 | 备注 |
|---|---|---|
| id | 唯一标识 | 用于更新和去重 |
| type | 记忆类型 | 影响检索权重和过期策略 |
| content | 记忆文本 | 原始可读内容 |
| embedding | 向量表示 | 用于语义检索 |
| created_at | 创建时间 | 用于时效性排序 |
| updated_at | 更新时间 | 用于判断是否陈旧 |
| importance | 重要性 | 0-1 之间，影响检索排序 |
| confidence | 置信度 | 该记忆的可靠程度 |
| source | 来源 | 区分显式提供和推断 |
| expires_at | 过期时间 | null 表示永不过期 |
| tags | 标签 | 用于分类检索 |
| metadata | 元数据 | 业务相关的附加信息 |
4.3 写入流程
用户输入/系统事件
│
▼
┌─────────────────┐
│ 判断是否需要写入 │ ──否──→ 丢弃，不写入
└────────┬────────┘
│是
▼
┌─────────────────┐
│ 判断记忆类型 │
└────────┬────────┘
│
┌────┴────┬──────────┬──────────┐
▼ ▼ ▼ ▼
fact preference task_state session
│ │ │ │
▼ ▼ ▼ ▼
提取实体 提取偏好 更新状态 存储会话摘要
│ │ │ │
└────┬────┘ │ │
▼ ▼ ▼
生成 embedding 写入状态 写入会话存储
│ │ │
▼ │ │
检查冲突/去重 │ │
│ │ │
└───────┬───────┘ │
▼ ▼
写入主存储 写入会话存储
5. 读取策略：何时读、读多少、怎么读
5.1 记忆读取的触发条件
应该读取记忆的场景：
-
用户提问涉及个人/业务背景
- “上次那个项目进展如何” → 需读取项目状态记忆
- “我的年假还剩几天” → 需读取用户信息记忆
-
系统需要复用历史决策依据
- 用户重复提出类似问题 → 读取之前的回答摘要
- 避免重复询问同一信息
-
任务恢复
- 用户说”继续上次的工作” → 读取任务状态记忆
读取策略的选择：
| 场景 | 推荐读取策略 |
|---|---|
| 用户问事实性问题 | 读取长期事实记忆，精确检索 |
| 用户表达不满 | 读取偏好记忆，排查是否违反已知偏好 |
| 开始多步骤任务 | 读取相关任务状态记忆，了解进度 |
| 用户首次对话 | 读取偏好记忆（若有），判断沟通风格 |
5.2 读取的排序策略
记忆检索返回的条目需要排序，综合考虑多个因素：
各因子计算方式：
- 语义相似度
：查询与记忆内容的向量余弦相似度 - 时效性
：距离上次更新越近，得分越高 - 重要性
：写入时设定的固定权重 - 类型匹配
：记忆类型与查询场景的匹配度
权重调优建议：初始设置可参考
5.3 读取容量的控制
读取不是越多越好，需要设置上限：
| 记忆类型 | 建议读取上限 | 原因 |
|---|---|---|
| 长期事实记忆 | top-10 | 相关事实通常不多 |
| 偏好记忆 | top-5 | 偏好是稳定的，少量即可 |
| 任务状态记忆 | top-3 | 只需当前任务最新状态 |
| 会话记忆 | top-20 | 需要回顾会话上下文 |
超出上限的处理：
- 精确截断：直接取 top-k
- 摘要压缩：将多条记忆合并为摘要
- 分层检索：先粗召回再细筛选
6. 记忆质量维护
6.1 记忆污染的治理
记忆污染指记忆系统中存在错误、过时或有害的内容，持续影响系统行为。
污染来源：
- 推断错误：模型推断出错误的事实并写入
- 用户恶意输入：故意注入错误信息期望系统记住
- 级联错误：一条错误记忆导致后续推断持续错误
治理策略：
预防：
- 低置信推断不写入（confidence < 0.7 的推断标记为"待确认"）
- 重要事实多源交叉验证
检测：
- 定期用知识库验证记忆准确性
- 用户反馈触发记忆复核
- 检测记忆条目之间的逻辑冲突
修复：
- 冲突时以置信度高的为准
- 显式冲突触发用户确认流程
- 错误记忆标记为"已撤销"而非直接删除
6.2 陈旧记忆的处理
记忆会过时，需要定期清理或更新。
识别陈旧记忆的策略：
- 基于时间：设置过期时间（如偏好记忆 6 个月无更新则降权）
- 基于事件：特定事件触发记忆失效（如用户换工作，相关项目记忆降权）
- 基于验证：定期用查询验证记忆准确性，不一致则触发更新
处理方式：
| 策略 | 适用场景 | 实现方式 |
|---|---|---|
| 直接删除 | 明确过时的信息 | expires_at 到期后删除 |
| 降权 | 不确定是否过时 | importance 衰减，但不删除 |
| 更新 | 有新版本可用 | 原地更新 updated_at |
| 归档 | 有存档价值 | 移出主存储，保留在归档库 |
6.3 冲突记忆的合并
同一事实可能出现多条相互矛盾的记录。
冲突检测：
- 实体级别：相同实体的属性值不一致
- 语义级别：相似内容的核心主张矛盾
解决机制：
冲突检测 → 评估各条置信度 → 高置信度记忆覆盖低置信度 → 若置信度相近则触发用户确认
示例：
- 记忆 A：“用户公司是字节跳动”，confidence=0.95
- 记忆 B：“用户公司是美团”，confidence=0.6
- 结果：保留 A，B 降权或标记为冲突待确认
6.4 去重策略
重复写入会导致存储浪费和检索噪声。
去重维度：
- 精确去重：基于 content hash 或 id 完全匹配
- 语义去重：embedding 相似度 > 0.95 的条目认为是重复
- 实体去重：相同实体的多条属性记录合并
去重操作：
- 写入前检查：写入新记忆时检查是否与已有记忆重复
- 定期合并：周期性运行去重任务，合并相似记忆
7. 用户偏好的提取与稳定保存
7.1 偏好提取的触发条件
偏好不是凭空产生的，从用户行为中推断：
显式偏好：
- 用户直接说明：“我喜欢用表格形式展示数据”
- 判断标准高，可直接写入，置信度也高
隐式偏好：
- 从行为模式推断：用户三次都要求”简洁点” → 偏好简洁风格
- 需要累积多次信号才可写入，置信度较低
偏好提取的置信度阈值：
| 信号来源 | 写入置信度阈值 | 备注 |
|---|---|---|
| 用户直接说明 | 0.9 | 可直接写入 |
| 多次行为验证 | 0.8 | 需 2-3 次一致行为 |
| 单次行为推断 | 0.6 | 标记为”候选偏好”，待验证 |
7.2 偏好的稳定性保障
偏好一旦写入错误，代价很高（会持续影响每次交互）。
稳定性保障机制：
新偏好写入 → 设置"候选"状态
↓
用户确认 或 多次隐式验证 → 升级为"已确认"状态
↓
已确认偏好才能影响系统行为
偏好更新的双轨制：
- 重大偏好变更：需用户显式确认（如”你之前说喜欢简洁风格，现在还这样吗？”）
- 微小偏好漂移：自动更新，但保留回滚能力
7.3 偏好的分类存储
不同类型的偏好使用不同的存储策略：
| 偏好类型 | 存储方式 | 更新频率 | 读取优先级 |
|---|---|---|---|
| 沟通风格（正式/随和） | 结构化存储 | 月级 | 高 |
| 输出格式（表格/列表/段落） | 结构化存储 | 周级 | 高 |
| 时间偏好（上午/下午） | 结构化存储 | 月级 | 中 |
| 拒绝的行为模式 | 结构化存储 | 极低 | 极高 |
8. 任务状态记忆的落盘与恢复
8.1 状态落盘的触发点
任务执行过程中，关键状态点需要持久化：
任务开始 → 记录任务ID、目标、初始参数
↓
关键步骤完成 → 记录步骤ID、完成时间、产出物
↓
步骤失败 → 记录错误类型、已尝试的解决方案
↓
任务完成/中止 → 记录最终状态、产出物、耗时
状态落盘的判断标准：
- 步骤不可逆（下一步依赖上一步结果）
- 执行时间超过 5 分钟
- 用户可能中断交互
8.2 任务状态的结构设计
{
"task_id": "task_20240517_001",
"task_type": "report_generation",
"goal": "生成月度销售报告",
"created_at": "2024-05-17T09:00:00Z",
"status": "in_progress|completed|failed|paused",
"current_step": 3,
"total_steps": 5,
"steps": [
{
"step_id": 1,
"name": "数据采集",
"status": "completed",
"completed_at": "2024-05-17T09:15:00Z",
"outputs": ["sales_data_0424.xlsx"]
},
{
"step_id": 2,
"name": "数据清洗",
"status": "completed",
"completed_at": "2024-05-17T09:30:00Z",
"outputs": ["cleaned_data.csv"]
},
{
"step_id": 3,
"name": "生成图表",
"status": "in_progress",
"started_at": "2024-05-17T09:30:00Z"
}
],
"resume_point": "从步骤3继续，已完成图表制作，待添加文字分析"
}8.3 任务恢复流程
用户："继续上次的任务"
↓
读取 task_id → 获取任务状态
↓
定位 resume_point → 定位继续执行的位置
↓
加载相关产物 → 读取已完成步骤的输出
↓
执行恢复 → 从断点继续任务
9. Agent 对话记忆 vs 知识库记忆
9.1 核心区别
| 维度 | Agent 对话记忆 | 知识库记忆 |
|---|---|---|
| 内容来源 | Agent 与用户的交互历史 | 外部文档、数据库、网页 |
| 所有权 | 用户私有 | 可共享（多人共用同一知识库） |
| 更新方式 | 动态写入（从对话中学习） | 批量导入或定时同步 |
| 一致性要求 | 可接受暂时不一致 | 通常要求高度准确 |
| 典型技术 | 向量存储 + 写入策略 | 全文检索 + 结构化索引 |
| 用途 | 个性化服务 | 事实性知识支撑 |
9.2 两者的协同
Agent 对话记忆和知识库记忆不是替代关系，而是互补关系：
用户提问
│
├──→ 检索对话记忆（个性化背景、偏好）
│
└──→ 检索知识库（公共知识、领域知识）
│
↓
融合两部分结果
│
↓
生成回答
典型场景：
- 用户问”我的项目进度怎么样了” → 对话记忆
- 用户问”如何配置 Nginx” → 知识库记忆
- 用户问”上次那个bug修好了吗” → 对话记忆
9.3 记忆优先级的动态调整
不同场景下两类记忆的权重不同：
| 用户意图 | 对话记忆权重 | 知识库权重 |
|---|---|---|
| 问个人事项（进度、计划、偏好） | 高 | 低 |
| 问领域知识（技术、概念、流程） | 低 | 高 |
| 需要综合判断 | 中 | 中 |
10. 记忆系统设计原则
10.1 核心设计准则
1. 记忆不是无限存储，而是带策略的状态管理
无限存储带来的是检索噪音和成本膨胀。每一比特存储都应该有明确的用途和过期策略。
2. 写入和读取是两个独立的决策问题
- 写入决策：判断”这条信息值得记住吗”
- 读取决策：判断”这个场景需要哪些记忆”
- 两者可以独立优化，但必须联合调参
3. 置信度是记忆系统的第一公民
每条记忆都应该携带置信度，没有置信度的记忆不如没有。
4. 记忆的可见性需要可审计
写入来源、更新历史、复核记录都应当可查。不可审计的记忆系统是不可信的。
5. 遗忘和写入同样重要
没有清理机制的存储系统会逐渐退化成一个充满噪音的数据沼泽。
10.2 设计检查清单
新记忆系统设计时，逐项检查：
□ 是否区分了记忆类型（事实/偏好/状态/会话）？
□ 每种类型的写入触发条件是否明确？
□ 每种类型的读取容量是否受限？
□ 置信度是否是必填字段？
□ 是否有冲突检测和解决机制？
□ 是否有陈旧记忆的清理机制？
□ 是否有去重机制？
□ 记忆的来源和更新历史是否可审计？
□ 写入和读取的性能是否可监控？
□ 是否有用户反馈触发的记忆复核机制？
11. 记忆写入与读取流程图
11.1 写入流程详图
┌──────────────────────────────────────────────────────────────┐
│ 记忆写入流程 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 用户输入 / 系统事件 │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 触发条件判断 │ │
│ └────────┬────────┘ │
│ │ │
│ ┌─────┴─────┐ │
│ ▼ ▼ │
│ 通过 拒绝 ──────────────────────────────────────┐ │
│ │ │ │
│ ▼ │ │
│ ┌─────────────────┐ │ │
│ │ 判断记忆类型 │ │ │
│ └────────┬────────┘ │ │
│ │ │ │
│ ┌─────┼─────┬────────────┐ │ │
│ ▼ ▼ ▼ ▼ │ │
│ 事实 偏好 任务状态 会话 │ │
│ │ │ │ │ │ │
│ └─────┴───────┼────────────┘ │ │
│ ▼ │ │
│ ┌─────────────────┐ │ │
│ │ 提取信息 + 生成 embedding │ │ │
│ └────────┬────────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌─────────────────┐ │ │
│ │ 冲突检测与去重 │ │ │
│ └────────┬────────┘ │ │
│ │ │ │
│ ┌───────┴───────┐ │ │
│ ▼ ▼ │ │
│ 发现冲突 无冲突 │ │
│ │ │ │ │
│ ▼ ▼ │ │
│ ┌──────────┐ ┌──────────────┐ │ │
│ │ 置信度 │ │ 写入存储 │ │ │
│ │ 裁决 │ │ 设置过期 │ │ │
│ └────┬─────┘ └──────┬───────┘ │ │
│ │ │ │ │
│ └────────┬────────┘ │ │
│ ▼ │ │
│ 写入主存储 │ │
│ │ │ │
│ ▼ │ │
│ 触发记忆复核（可选） │ │
│ │
└──────────────────────────────────────────────────────────────┘
11.2 读取流程详图
┌──────────────────────────────────────────────────────────────┐
│ 记忆读取流程 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 用户查询 / 系统需要读取 │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 判断读取场景 │ │
│ └────────┬────────┘ │
│ │ │
│ ┌─────┴─────┐ │
│ ▼ ▼ │
│ 需要记忆 不需要记忆 │
│ │ │ │
│ │ ◄─────────────────────────────┐ │
│ ▼ │ │
│ ┌─────────────────┐ │ │
│ │ 确定读取优先级 │ │ │
│ └────────┬────────┘ │ │
│ │ │ │
│ ┌─────┴─────┬─────────────┐ │ │
│ ▼ ▼ ▼ │ │
│ 偏好 事实/状态 会话记忆 │ │
│ │ │ │ │ │
│ └─────┬─────┴──────┬─────┘ │ │
│ ▼ ▼ │ │
│ ┌─────────────┐ ┌─────────────┐ │ │
│ │ 向量检索 │ │ 标签/过滤 │ │ │
│ │ (语义相似度) │ │ (结构化查询)│ │ │
│ └──────┬──────┘ └──────┬──────┘ │ │
│ └───────┬────────┘ │ │
│ ▼ │ │
│ ┌─────────────────┐ │ │
│ │ 综合排序与过滤 │ │ │
│ │ sim+recency │ │ │
│ │ +importance │ │ │
│ └────────┬────────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌─────────────────┐ │ │
│ │ 容量控制 top-k │ │ │
│ └────────┬────────┘ │ │
│ │ │ │
│ ┌───────┴───────┐ │ │
│ ▼ ▼ │ │
│ 压缩摘要 直接返回 │ │
│ │ │ │ │
│ └───────┬───────┘ │ │
│ ▼ │ │
│ 注入 prompt │ │
│ │ │ │
│ ▼ │ │
│ LLM 推理 │ │
│ │
└──────────────────────────────────────────────────────────────┘
12. 常见记忆系统失败案例
12.1 案例一：记忆雪崩
现象：系统上线后性能逐渐下降，响应变慢，最终崩溃。
根因：
- 写入策略过于宽松，几乎所有用户输入都写入记忆
- 检索库膨胀到千万级条目
- 向量检索性能线性衰减
教训：
- 写入策略必须有过滤，不能”凡说必记”
- 容量监控和限流是必备的
12.2 案例二：偏好错学
现象：用户 A 的偏好被错误地记住，影响了用户 B 的体验。
根因：
- 偏好记忆写入时未正确绑定 user_id
- 多用户共享同一记忆条目
教训：
- 记忆的归属权必须明确
- 跨用户记忆共享需要显式设计
12.3 案例三：状态记忆丢失
现象：用户正在填写长表单，突然刷新页面，所有进度丢失。
根因：
- 状态记忆只存在内存中，未及时落盘
- 只在步骤完成时写入，步骤进行中的状态未保存
教训：
- 关键状态点必须落盘，不能等到完成才保存
- 增量状态也需要定期持久化
12.4 案例四：记忆污染扩散
现象：一条错误记忆导致系统持续给出错误回答，用户纠正多次无效。
根因：
- 错误记忆的置信度被错误设置为高
- 没有冲突检测机制
- 错误记忆持续影响新记忆的生成
教训：
- 置信度评估必须保守，初始写入应该是低置信度
- 用户反馈是纠正记忆污染的最重要信号
12.5 案例五：知识库与对话记忆割裂
现象：Agent 记住了用户的错误说法当成事实，后续查询与知识库冲突。
根因：
- 对话记忆的置信度高于知识库
- 没有建立记忆与知识库的一致性校验
教训：
- 事实类记忆应该定期与知识库对齐
- 知识库是事实的记忆来源，不应该被对话记忆覆盖
12.6 失败案例总结
| 失败模式 | 核心原因 | 预防措施 |
|---|---|---|
| 记忆雪崩 | 写入无过滤 | 严格写入触发条件 |
| 偏好错学 | 归属不明 | user_id 必填，去重校验 |
| 状态丢失 | 落盘不及时 | 分段持久化，增量保存 |
| 污染扩散 | 置信度过高无校验 | 置信度保守，用户反馈闭环 |
| 知识库冲突 | 两套系统无对齐 | 记忆与知识库定期校验 |
附录 A：记忆系统模块依赖关系
┌─────────────────────┐
│ 记忆管理平台 │
│ (Memory Manager) │
└──────────┬──────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 写入策略模块 │ │ 读取策略模块 │ │ 质量维护模块 │
│ (WritePolicy) │ │ (ReadPolicy) │ │ (QualityCtrl) │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
└───────────────────┼───────────────────┘
│
▼
┌─────────────────────┐
│ 存储层 │
│ (Vector + KV) │
└─────────────────────┘
附录 B：关键配置参数参考
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 最大记忆条目数（会话级） | 200 | 超过后触发清理 |
| 最大记忆条目数（长期） | 10000 | 超过后触发归档 |
| 相似度阈值（写入去重） | 0.95 | 超过认为是重复 |
| 相似度阈值（读取召回） | 0.70 | 低于该值不召回 |
| 偏好记忆过期时间 | 180 天 | 过期后降权 |
| 任务状态记忆过期时间 | 7 天 | 任务相关记忆保留时长 |
| 读取 top-k（长期事实） | 10 | 单次查询最多召回条数 |
| 读取 top-k（偏好） | 5 | 单次查询最多召回条数 |
| 置信度写入阈值 | 0.7 | 低于该值不写入 |