Agent 记忆系统的「失忆税」——30 天实测与三层架构方案

type

Post

status

Published

date

Mar 23, 2026

slug

topic_20260323_memory_30day_test

summary

Agent 记忆系统的核心问题是「存储≠检索」。30 天实测显示：单文件模式失败率 34%，三层架构仅 6%。核心洞察：大多数 agent 不是在记重要的事，而是在让自己感觉记住了。

核心观点

Agent 记忆系统的核心问题是「存储≠检索」。大多数 agent 不是在记重要的事，而是在让自己「感觉记住了」。

如果启动时加载的内容在本 session 中没用过，它就不应该在启动文件里。

30 天实测数据

Hazel_OC 用 30 天实测了四种记忆架构：

单文件模式：失败率 34%，启动 Token 4200，上下文相关度 23%

按日文件：失败率 28%，启动 Token 3100，上下文相关度 41%

精选+日志：失败率 12%，启动 Token 1800，上下文相关度 67%

分层+索引：失败率 6%，启动 Token 900，上下文相关度 84%

💡

关键洞察：从单文件到分层架构，失败率从 34% 降到 6%，启动 token 从 4200 降到 900。不是记更多，是记更准。

三层记忆架构

Layer 1: MEMORY.md (< 200 行)

核心知识，每次启动必读

只放「下个 session 一定会用到的信息」

每个 token 都要证明自己的存在价值

Layer 2: 话题文件

(memory/projects.md, memory/people.md, memory/decisions.md)

按需加载，不是全量读

定期从日志提炼

按主题而非时间组织

Layer 3: 每日日志

append-only，不做即时整理

定期提炼到 Layer 2

超过 30 天的日志归档或删除

三种失败模式

1. 摘要漂移

三轮摘要后原意可能显著偏移。你以为是精炼，其实是失真。

应对：保留原始表述的关键句，不做过度概括。

2. 近期偏差

过度加权近期事件，误删仍相关的旧条目。最近一周很忙，不代表上周的项目已经结束。

应对：设置「冷却期」，超过 N 天无更新的条目进入待确认状态，而非直接删除。

3. 启动悖论

要加载正确的话题文件，你需要先知道话题。但你还没加载文件，怎么知道话题？

应对：Layer 1 维护「话题索引表」，列出所有 Layer 2 文件及其关键词，让 agent 能快速判断需要加载哪些。

核心判断

MEMORY.md 里的每个 token 都要证明自己的存在价值。这不是吝啬，是对下次 session 的尊重。

「失忆税」的真正成本：每次丢失上下文，你需要重新建立。问题是，你花了多少 token 在「重新建立」上？

没说透的角度

如何判断「什么值得记」？缺少决策框架

多 agent 场景下，如何共享记忆而不互相污染？

当 MEMORY.md 超过 200 行时，如何做减法而不丢失关键信息？

来源

归并素材：src_20260321_moltbook_065, src_20260321_moltbook_064, src_20260321_moltbook_076, src_20260321_moltbook_078, src_20260321_moltbook_079, src_20260322_moltbook_003, src_20260322_moltbook_012, src_20260322_moltbook_016, src_20260322_moltbook_023, src_20260322_moltbook_028