跳到主要内容

记忆系统不是越多越好，先分清短期和长期

· 阅读需 5 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-03 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

“给 AI 加记忆”这件事，从概念上特别诱人。因为只要系统记住更多，它看起来就会更像一个长期协作者。

但我这两年越做越明确的一件事是：很多记忆系统不是死于“不够多”，而是死于“什么都想记”。

用户偏好想记，最近对话想记，历史任务想记，工具执行结果想记，失败原因也想记。最后系统确实拥有了很多“记忆”，但它不知道哪些该短暂保留，哪些该长期沉淀，哪些根本不该写进去。

所以我现在做记忆系统，第一步不是选向量库，也不是先做召回，而是先把短期记忆和长期记忆的边界画出来。

两类记忆解决的不是同一个问题​

短期记忆解决的是“当前任务别丢线”​

它通常服务于一个会话、一个工单、一次执行流程。
重点是让系统记住当前目标、当前约束、刚刚发生过什么。

例如：

  • 本轮会话已经确认的需求
  • 当前任务进行到第几步
  • 最近一次工具调用结果
  • 这次生成失败的原因

这类信息通常有明显的生命周期，任务结束后价值会迅速下降。

长期记忆解决的是“以后还值得复用什么”​

它服务的不是一次请求，而是跨会话、跨任务的持续协作。
重点不在完整，而在稳定。

例如：

  • 用户长期偏好的表达风格
  • 经人工确认过的业务规则
  • 经常复用的知识片段
  • 被验证过的历史结论

这类信息一旦写错，后面会持续污染很多次交互，所以更新门槛应该更高。

真正容易踩坑的是“把它们塞进同一个桶”​

很多系统最开始会做成一个大而全的 memory store：

  • 所有对话都进向量库
  • 所有摘要都长期保留
  • 所有用户行为都尝试抽取偏好
  • 所有工具结果都可被未来检索

短期看起来信息越来越全，长期会马上出现三种副作用：

1. 召回越来越脏​

系统每次都能“记起很多东西”，但不代表记起的是该用的东西。

2. 偏好和状态混在一起​

“用户今天想写短一点”和“用户长期偏好短句风格”不是一回事。
如果混写，系统会把一次性的要求误当成长期人格。

3. 更新策略会失控​

到底什么信息可以自动写入，什么需要人工确认，什么应该带 TTL，这些规则会越来越难解释。

我现在更喜欢三层结构​

第一层：运行态记忆​

只服务当前任务，带明显过期时间。

{
  "scope": "run_state",
  "ttl": "6h",
  "content": {
    "goal": "完成内容发布前检查",
    "currentStep": "policy_review",
    "lastToolResult": "risk=medium"
  }
}

这层通常放在 Redis、任务表或者工作流状态里，不要求长期可检索，只要求恢复快。

第二层：任务级沉淀​

沉淀这次任务里真正有复用价值的结论，但不直接等于长期用户记忆。

例如：

  • 这类文章审核时最常出错的是引用来源
  • 某个工作流在第 3 步最容易超时
  • 某类 bug 的排查路径已被验证

它更像“经验摘要”，不是“个性画像”。

第三层：长期记忆​

只写入那些跨任务稳定成立、并且最好经过确认的信息。

例如：

  • 用户明确说过偏好怎样的写作语气
  • 某个项目固定使用哪套输出格式
  • 某个团队长期遵守的发布规则

这层写得越克制，后面越稳。

写入策略比检索策略更重要​

很多人一上来先聊召回算法，我现在反而会先问：什么信息允许进入记忆？

我会给每类记忆加三个约束：

  1. 写入条件
  2. 生存周期
  3. 覆盖规则

例如：

短期状态：自动写入，任务结束自动失效
任务总结：模型生成后人工抽样确认
长期偏好：只有用户明确表达或人工确认后才能写入

只要这三条没定清楚，记忆越多，污染越快。

一个我现在很少再犯的错误​

以前我也做过一种很“全能”的设计：每次对话结束都自动总结，再把总结写回长期记忆。
后面很快发现，系统会把很多一次性的上下文误记成长期事实。

比如：

  • 用户今天临时要严肃一点
  • 某次任务里临时禁用了一个工具
  • 某个异常只是当天环境波动

这些都不应该变成长期记忆。
所以我后来改成了“短期自动写，长期谨慎写，长期覆盖必须有证据”。

什么时候你根本不需要长期记忆​

不是每个 AI 产品都需要长期记忆。
如果你的场景是：

  • 一次性问答
  • 明确表单生成
  • 低频工具调用
  • 单任务执行后即结束

那很多时候短期上下文就够了。
强行上长期记忆，只会增加隐私、治理和召回噪音。

总结​

记忆系统不是越多越好，真正重要的是先分清短期和长期。

短期记忆要服务当前任务的连续性，长期记忆要服务未来协作的稳定性。两者一旦混在一起，系统得到的不会是更聪明的记忆，而是更难治理的噪音。对大多数团队来说，先把写入规则和生命周期设计清楚，比先堆一座“大记忆库”更关键。