短期状态和长期记忆：Agent 该记住什么，什么时候该忘？

今天先记住

Agent 的记忆不是“把聊天记录都存下来”。短期状态负责当前任务能不能跑完，长期记忆负责跨会话保持连续性。真正的工程问题是：哪条信息该进入下一步决策，哪条该沉到长期存储，哪条已经过期必须别再影响判断。

它在大地图里的位置

继续看这条主线：

用户目标
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

昨天讲了 context window，今天把它旁边的“记忆”拆开。上下文窗口是这一步工作台，短期状态是当前任务的运行状态，长期记忆是以后还可能用到的事实、偏好、经验和项目背景。

它到底是什么

短期状态（short-term state）通常只服务当前任务：用户目标、已读过哪些文件、刚才哪个命令失败、下一步准备做什么。任务结束后，它可以归档，也可以丢掉。

长期记忆（long-term memory）服务跨会话连续性：用户偏好、稳定约束、常用项目规则、上次已经确认过的决策。它不应该每次全量塞进 prompt，而应该按任务检索、筛选，再放入当前上下文。

一句话区分：短期状态回答“这件事现在做到哪了”，长期记忆回答“这个人、这个项目、这个系统以前确认过什么”。

为什么 Agent 里会用到它

多步 Agent 如果没有短期状态，会重复动作。比如构建已经失败过一次，它还继续提交；某个文件已经读过，它又从头搜索。

如果没有长期记忆，每次会话都像新用户。它会忘掉写作框架、发布规则、用户不想收到主动通知、某些命令不能跑。更麻烦的是，长期记忆如果不带时间和来源，也会变成“自信的旧信息”：用户偏好变了，系统还按旧习惯行动。

所以记忆层不是为了显得贴心，而是为了减少具体失败：漏步骤、重复失败动作、越过权限、沿用过期状态。

怎么判断它有没有用

如果信息只影响当前这次执行，比如“npm build 刚失败在某个链接”，放短期状态。

如果信息会跨天、跨项目或跨会话复用，比如“发布文档要先构建再推送”，放长期记忆。

如果信息会随时间变化，比如位置、排队、临时计划，要给时间戳和过期规则，不能永久当事实。

如果一条记忆无法说明来源、适用范围和是否仍有效，宁可先不注入上下文，避免它把下一步决策带偏。

最近冒出来的词

这几天可以记一个词：behavioral state decay（行为状态衰减）。

arXiv 2026-07-09 的论文《Remember When It Matters》把它描述为长任务里的失败模式：重要信息可能还在轨迹里，但不再影响 Agent 的下一步动作。论文提出用一个单独的 memory agent 维护结构化记忆，并只在需要时插入简短提醒。

它和今天主题很贴：记忆不是“存着就行”，关键是该在什么时候重新进入决策。

来源提示：arXiv，2026-07-09，2607.08716。

一个小例子

Input:
用户要求生成 2026-07-18 的每日课程，并且要求不要主动发微信通知。

Process:
短期状态：
- 今天的文件是否已创建
- 上一课主题是 Context Window
- docs:build 是否通过

长期记忆：
- AI Agent Daily 要发布到 /ai-agent/YYYY-MM-DD
- 标题不能只写日期
- 文档站走 Git 自动部署，不手动跑 vercel

Output:
系统选择“短期状态和长期记忆”作为下一课主题；
写入 2026-07-18.md；
构建通过后只提交课程文件并推送；
不会额外触发主动消息。

这个例子可以用来判断真实系统：它有没有把“当前进度”和“长期规则”分开管理？如果两者混在一起，系统要么忘步骤，要么拿旧事实乱管新任务。

常见误区

1. 以为长期记忆就是完整聊天记录。长期记忆应该是筛过的事实和规则，不是历史大包。
2. 以为短期状态不用设计。多步任务里，当前进度、失败原因和下一步候选都要显式保存。
3. 以为记住越多越好。无关记忆进入上下文，会挤掉真正影响决策的信息。
4. 以为记忆永远正确。偏好、位置、项目规则都会变化，记忆需要时间、来源和失效机制。

今天自测

1. “刚才构建失败的错误日志”应该放短期状态还是长期记忆？
2. 一条用户偏好进入长期记忆前，至少要记录哪些边界？
3. 如果 Agent 一直沿用旧状态，你会检查记忆层的哪三个问题？