专栏第 9 篇：解决 Agent 项目中“记不住、记太多、记错了”的三大问题。
一、问题描述：为什么记忆系统总在“要么失忆，要么混乱”
随着 Agent 使用时长增加，典型问题会出现：
- 对话一长就丢上下文；
- 什么都往长期记忆写，污染严重；
- 检索命中很多，但真正有用的很少；
- 私密信息、临时信息、长期偏好混在一起。
本质问题：没有明确的“记忆分层”和“写入边界”。
二、先给结论：把记忆拆成三层，职责分离
建议采用三层模型：
短期上下文（Session Memory）
当前会话窗口内的即时语境，生命周期短。工作记忆（Working Memory）
当前任务阶段的中间状态、待办、临时结论，随任务结束衰减。长期记忆（Long-term Memory）
用户稳定偏好、长期决策、关键事实，需要可检索与可维护。
关键：不是“能记就记”，而是“该记才记”。
三、什么该写长期记忆，什么不该写
3.1 建议写入长期记忆
- 稳定偏好（写作平台偏好、输出格式偏好）
- 长周期项目约定（目录、命名规范、流程）
- 经确认的重要决策（例如“默认只落盘不提交”）
- 可复用的高价值知识（长期方法论）
3.2 不建议写入长期记忆
- 一次性临时指令（如“这次先跳过”）
- 未确认猜测
- 高频变动的状态数据
- 敏感信息原文（凭据、密钥）
四、上下文窗口治理：防止“越聊越慢、越聊越偏”
建议每轮推理输入只保留：
- 最近 N 轮对话（如 8~12 轮）
- 当前任务必要事实
- 检索召回的 top-k 记忆片段
配套策略：
- 超长对话定期摘要（summary checkpoint）
- 摘要写入 working memory，而非直接进长期记忆
- 每次检索后做去重与重排，避免信息轰炸
五、检索边界设计：命中相关，而不是命中最多
5.1 检索流程建议
- Query 改写（补全语义）
- 混合检索（向量 + 关键词）
- Top-k 初筛（如 k=8）
- 重排（rerank）
- 仅注入 top-3~5 到上下文
5.2 关键参数建议（起步）
maxResults: 8~12minScore: 0.45~0.6（按语料调）- 上下文注入上限：3~5 条高相关片段
六、记忆写入策略：事件驱动而非每轮都写
建议触发条件：
- 用户明确“记住这个”
- 项目约定被确认并长期生效
- 出现复用价值高的结论模板
- 故障复盘形成稳定规则
写入流程：
- 先判断是否长期有效
- 再去重（语义相似度 + 关键词）
- 最后结构化写入（标题 + 要点 + 来源时间）
七、伪代码：记忆路由与写入判定
defroute_memory(event):ifis_transient(event):return"session"ifis_task_intermediate(event):return"working"ifis_long_term_value(event)andis_confirmed(event):return"long_term"return"drop"defshould_persist_long_term(event):ifnotevent.confirmed:returnFalseifevent.sensitivity=="secret":returnFalseifevent.stability_score<0.7:returnFalseifis_duplicate(event):returnFalsereturnTrue八、治理机制：让长期记忆“可维护”
建议每周/每双周做一次记忆体检：
- 清理过期条目
- 合并重复条目
- 标注冲突条目（旧规则 vs 新规则）
- 归档低频且低价值内容
可以给每条长期记忆增加字段：
created_atlast_verified_atconfidencestatus（active/deprecated）
九、常见误区与排查
误区：每轮对话都写长期记忆
- 后果：记忆污染，检索质量下降
- 修正：改为事件触发写入
误区：检索结果全部塞进上下文
- 后果：上下文噪音高、成本上升
- 修正：重排后仅注入 top-3~5
误区：不做去重
- 后果：同义条目泛滥，召回重复
- 修正：写入前做语义去重
误区：长期记忆不复核
- 后果：过时规则持续误导
- 修正：定期维护 + 状态标记
十、本篇总结
记忆系统的核心不是“记得多”，而是“记得准、取得到、用得上”。
一句话：短期保上下文，工作记忆保过程，长期记忆保约定。
