记忆系统：Agent 怎么记住昨天的自己

Agent 每次 session 醒来都是一张白纸。如果你想让它记住昨天做的决定，你必须把记忆写成文件。

问题#

Agent 没有持久记忆。每次 session 开始时，它只知道系统提示词和当前对话。昨天做了什么决定、踩了什么坑、建立了什么规则——全部归零。

这在单次对话场景下不是问题。但在多 agent 团队连续运作的场景下，这是致命的：

昨天刚建立的”一人一活”规则，今天的 session 不知道
上周踩过的”并行有依赖的任务”坑，这周又踩一次
上个月做的组织架构决策，新 session 完全不了解背景

演化过程#

V1：一个大文件（3.27–4.9）#

最初只有一个 MEMORY.md，所有记忆往里追加。

优点：简单。问题：文件膨胀。到 4 月 9 日，MEMORY.md 已经超过 400 行，包含了从组织设计到 PR 跟进规则到 RCA 报告的所有内容。每次 session 启动都要加载整个文件，严重浪费上下文窗口。

V2：日志 + 长期记忆分离（4.9–4.10）#

参考 OC Wiki 的 Alaya 记忆系统（三层：沉淀/联想/唤醒，冷热分层），我们做了第一次分层：

MEMORY.md — 长期有效的规则和决策
memory/YYYY-MM-DD.md — 每天的原始日志

问题：MEMORY.md 仍然只增不减，越来越臃肿。

V3：精简 + 归档（4.10，Hermes 启发）#

Hermes Agent 的核心启发是：记忆应该精简，不是无限追加。

具体落地：

将超大 MEMORY.md 全量备份到 memory/MEMORY-ARCHIVE-2026-04-10.md
重写 MEMORY.md，只保留当前仍生效的规则和决策
历史细节、旧规则、具体案例放到 daily logs 或归档文件

结果：MEMORY.md 从 436 行精简到 265 行，且每一行都是当前有效的。

当前架构#

1
workspace/
2
├── MEMORY.md                              # 当前生效的规则（精简版）
3
├── memory/
4
│   ├── 2026-03-27.md                     # 第一天日志
5
│   ├── 2026-03-29.md                     # ...
6
│   ├── ...
7
│   ├── 2026-04-14.md                     # 最近日志
8
│   ├── MEMORY-ARCHIVE-2026-04-10.md      # 历史归档
9
│   └── oc-wiki-updates.md                # OC Wiki 增量分析日志
10
└── reports/
11
    └── workflow-runs/                     # 工作流复盘报告

三层职责#

层	文件	内容	加载时机
热层	MEMORY.md	当前生效的规则、组织设计、关键能力	每次主 session 启动
温层	memory/YYYY-MM-DD.md	当天 + 前一天日志	每次 session 启动
冷层	MEMORY-ARCHIVE / 旧日志	历史决策、旧规则、具体案例	按需搜索

写入规则#

事情发生时写日志：决策、事件、教训写入 memory/YYYY-MM-DD.md
规则沉淀时写 MEMORY.md：日志中值得长期保留的规则，提炼后写入 MEMORY.md
定期精简：MEMORY.md 定期审查，过时的规则移到归档
搜索优先：做决策前先 memory_search，避免重复犯错

安全规则#

MEMORY.md 只在主 session（和 Coraline 的直接对话）中加载
群聊、共享 session、和其他人的对话中不加载 MEMORY.md
原因：MEMORY.md 包含组织内部信息，不应泄露给外部

数据#

指标	值
日志文件数	22
MEMORY.md 行数（V1 峰值）	400+
MEMORY.md 行数（V3 精简后）	265
归档文件	1（400+ 行）
总记忆文件大小	492KB

关键教训#

“记住这个”不等于”写下来了”。Agent 的”心理笔记”不存在——如果没写进文件，下次 session 就忘了。
记忆不是越多越好。把所有历史都塞进上下文窗口，会导致重要规则被稀释。精简比堆砌更有价值。
分层是必须的。热数据（当前规则）和冷数据（历史案例）的加载策略不同。每次都加载全量历史是浪费。
搜索比记忆更可靠。与其期望 agent “记住”三周前的决策，不如建立搜索机制让它随时检索。