Agent 记忆系统也需要 GC：拆解 Cowork 的 consolidate-memory

我们每天都在给手里的 agent「立规矩」：别用 2.35:1 当封面、副作用命令跑过一次别再重跑、提交前先跑一遍测试。这些规矩被 agent 写进了一个叫memory/的目录，下次开会话直接背着进来——非常省心。但很少有人想过一个问题：这个目录开了三个月之后，会变成什么样？

打开当前这个仓库的记忆目录，可以看到一份很有意思的实物：

~/.claude/projects/<project>/memory/ ├── MEMORY.md # 索引，每条一行 ├── feedback_cover_ratio.md # 封面比例规范 └── feedback_no_rerun_side_effects.md

feedback_cover_ratio.md里赫然写着一句：

上一版规则错误：“2.35:1 已废弃”

也就是说，关于"封面比例"这个主题，曾经存在过另一份完全不同的结论——它被覆盖了，但覆盖痕迹留在了文件里。如果没人主动整理，旧版本和新版本会同时驻留在记忆库；agent 每次开会话都把这堆混杂的事实加载进来，prompt 越长，判断越糊。

Cowork 的解法不是让在线 agent 边写边整理，而是把"整理"切出来做成一个独立的 skill：anthropic-skills:consolidate-memory。它的任务描述只有一行：

Reflective pass over your memory files — merge duplicates, fix stale facts, prune the index.

注意"reflective"和"pass"这两个词——离线、批处理、专门做反思。这一切分本身就是设计点。

一个反直觉的类比：记忆系统是 WAL log，不是真相之书

很多人对 agent 记忆系统的直觉是「越多越准」——存得越细，下次越聪明。这个直觉错了。

更准的类比是 PostgreSQL 的 WAL log：写入很便宜，每次 INSERT/UPDATE 都先追加到日志，绝不停顿；但 WAL 必须配CHECKPOINT和VACUUM，定期把无效行清掉、把碎片合起来，否则磁盘会被废数据撑爆，查询计划也会越来越偏。

记忆系统也是同一对结构：

让在线 agent 边聊天边判断"这条要不要和上次的合并"，等于边写代码边重构整个仓库——不可能不分心。所以 Cowork 做了和 Postgres 一样的选择：写入路径只管 append，整理留给独立工序。

拆开看：consolidate-memory 到底做哪三件事

如机制图所示，consolidate-memory 的工作可以严格切成三种操作。每一种都对应记忆库随时间衰退的一种典型病灶。

① 合并重复（merge duplicates）

同一主题在多次会话里被反复提起，会产生多份高度相似的 feedback 文件。比如连续三轮对话告诉 agent「封面别用 2.35:1」，会留下feedback_cover_v1.md、feedback_cover_v2.md、feedback_cover_ratio.md三个文件。consolidate 的合并动作不是简单 diff——它要保留最新结论、合并所有Why论据、统一How to apply段落，最后只留一份权威版。判断"权威"的依据是文件 mtime 加内容里的版本痕迹（比如"上一版规则错误"这种话）。

② 修正过时事实（fix stale facts）

记忆里说的事实，世界可能已经变了。典型例子就是用户当前那条feedback_cover_ratio.md：里面留着"旧 SKILL 里 2.35:1 硬规范的来源是公众号头条提示语，但那是头条单图位置的限制"——这是对已经废弃的规则的考古备注。consolidate 的修正动作要做两层判断：

• 这条事实和当前SKILL.md/ 代码 / 配置一致吗？不一致就重写或删除。
• 这条事实是不是给"曾经的错误"立了块墓碑？如果新版本已经稳定，墓碑可以拆。

注意它做不到的事：识别不出"用户当时就告诉错了"——它只能识别"和当前世界不一致"。事实溯源问题超纲了。

③ 清理索引（prune the index）

MEMORY.md是整个记忆系统的唯一入口。系统 prompt 里写得很死：

MEMORY.md总是被加载进上下文——200 行后会被截断，所以索引必须保持简洁

实际索引会朝着相反方向漂移：指向已删文件的链接、措辞冗长的描述、重复主题的多条占位。consolidate 的清理动作把这些都修掉——孤儿链接删掉、措辞压回 ~150 字符、合并重复主题。这一步是 user-visible 收益最直接的一步，因为它直接决定每次新会话开局加载多少废话进来。

它不解决什么：边界比能力更重要

consolidate-memory的"不做"清单和"做"清单一样长：

• 不创建新记忆——这是在线 agent 的活。看见用户说"以后都用 16:9"才写入，是在线判断；写好之后能不能存活下来，是离线整理的事。
• 不初始化记忆体系——memory/目录、MEMORY.md模板、frontmatter 的 schema 都是setup-cowork在用户第一次跑 Cowork 时建的。consolidate 假设这套结构已经存在，它只整理不创建。
• 不替我们判断"这条值不值得存"——如果在线写入的判断本身就糟（什么都往里塞），consolidate 只能让脏库稍微整齐，根治不了。这是 GIGO 问题，不是 GC 能解决的。
• 不是后台 daemon——它是用户/agent 显式触发的 skill，跑一次结束。多久跑一次完全看库的体量：30 条以内不用管，100+ 条就该跑。

把"创建/写入/整理/初始化"这四件事拆给四个不同入口——setup-cowork管初始化，在线 agent 管写入，consolidate-memory管整理，索引由所有人共同维护——这种把单一动作切成多 skill 的做法，正是 Anthropic 一贯的设计哲学：每个 skill 的边界画干净，每个 prompt 的责任聚焦。一个无所不能的「memory manager」prompt 听起来更通用，实际跑起来必然在写入快和整理深之间和稀泥。

记忆系统不是真相之书，是一份永远在涨的 WAL log。consolidate-memory不让 agent 变得更聪明，它让 agent 在三个月后不变得更糊涂——而这恰恰是真正长期能用的记忆系统的及格线。