小节四：什么值得长期保存，什么不应该——记忆系统最大的风险不是“忘”，而是“记错”

到了这里，重点就从“怎么存”切到“该不该存”了。长期记忆最怕的并不是少记一点，而是把不该记的东西写进去，后面还一直当真。先看下面这张判断图，思路会清楚很多。

可以把它理解成一个很朴素的筛选顺序：先问它是不是真实，再看它稳不稳定，接着判断未来能不能复用，最后再决定是否写入。像临时任务状态、整段日志、全部对话历史、未经验证的猜测，这些内容看起来很多，但往往只会制造噪声，不适合直接进入长期记忆。

很多人做 Memory 最担心，“Agent 忘东西。”

但真实系统另一个更危险的问题是，Agent 记住了错误的东西。

比如：

第一次猜：
入口可能是 app.py

如果还没验证就写进：

project.md

第二天 Agent 就会把：

app.py

当成长期事实。

这比不记更糟。

什么应该写入 user.md？

适合：

长期稳定偏好
明确默认约束
跨项目或跨 Session 会继续生效的偏好

例如：

代码修改优先最小改动
默认先解释根因再修改
高风险操作需要先确认

不适合：

这次任务先看 app.py
今天暂时不要运行测试

因为它们是临时要求。

什么应该写入 project.md？

适合：

已验证的项目事实
稳定技术栈
关键目录
默认测试方式
部署环境

例如：

Python 3.9
入口 src/main.py
pytest
配置目录 config/

不适合：

刚刚怀疑 service.py 有 Bug

因为这还不是稳定事实。

什么应该写入 decisions.md？

需要三个条件。

第一：

确实发生了选择

第二：

未来会影响行为

第三：

最好有原因

例如：

决定：继续使用 SQLite
原因：当前数据量小，无并发写压力

这比只写：

SQLite

有价值很多。

什么应该写入 learnings.md？

适合：

经过验证的排障经验
项目特有的操作经验
未来重复任务可复用的模式

例如：

该项目依赖统一由 pyproject.toml 管理，不使用 requirements.txt。

这条经验未来很有用。

什么绝对不应该直接写？

至少以下几类要谨慎：

未验证猜测
临时错误
敏感信息
完整日志
完整代码
巨大 Tool Result
一次性任务细节
过期状态

长期记忆不是归档系统。

Trace 才更像归档。

加一个 Memory Candidate

为了让写入动作更稳，比较好的办法不是让模型“想到什么就写什么”，而是先提炼成候选项，再由 Harness 做二次判断。下面这张图就把这条链路拆开了。

这么做的好处很直接：你可以要求候选项同时带上 statement、source、confidence、file_target 这些关键信息。这样一来，系统不仅知道“想写什么”，也知道“这条信息从哪来、可信度大概怎样、准备写到哪类文件里”。后续遇到冲突时，也更方便回头追溯。

可以让 Agent 先产生候选：

{
  "memory_type": "project",
  "scope_id": "project_456",
  "key": "entrypoint",
  "content": "项目入口为 src/main.py",
  "reason": "已通过 README 与实际运行确认",
  "source": "README.md + run:run_004",
  "confidence": 0.95,
  "expires_at": null
}

然后 Harness 再决定：

是否写入

这会比让模型直接随意写文件更稳。

Memory 还要有来源

真实系统至少可以记录：

source_session_id
source_run_id
created_at
updated_at
scope_id
confidence
expires_at
version

例如：

- entrypoint: src/main.py
  - source: sess_xxx / run_004
  - verified: true

字段不用一开始堆得很复杂，但来源不能只写成模糊的“模型认为”。更有用的来源是用户确认、配置文件路径、数据库口径版本，或可回看的 Session / Run ID。这样发现记忆有问题时，我们能顺着证据回查，而不是只能猜它从哪里来。

冲突怎么办？

假设已有：

Python 3.9

新 Session 发现：

pyproject.toml 已改成 >=3.9

不能简单：

append 新版本信息

这会留下冲突。

应该：

update_memory

把旧事实更新掉。

并可以在 decisions.md 记录：

2026-09-07：
项目运行版本继续固定为 3.9。

这样：

project.md

保存当前事实。

decisions.md

保存历史选择。

这两个角色就很清楚。

还有一种更隐蔽的冲突：Session A 和 Session B 都读到 version=3，随后分别写入不同结果。如果更新接口只看 key，最后一次写入会静默覆盖前一次。让调用方携带 expected_version=3，第一次更新后版本变成 4，第二次更新便应报冲突并要求重新读取。这不是为了增加仪式感，而是为了避免 Agent 把新证据悄悄写没。