灵犀Claw实战：从零搭建一个会自我进化的AI Agent（四）记忆整理

问题起源：自动沉淀的"最后一公里"

上一篇聊了Dreaming——一套每天凌晨自动运行的记忆沉淀系统。它从对话日志中提炼碎片，经时间验证后自动写入长期记忆文件。运行两周，效果很好：183条碎片中有84条已晋升为confirmed并沉淀，包括偏好、事实、规则等各类信息。

但自动化有三个解决不了的盲区：

盲区一：碎片只进不出。confirmed碎片一旦写入MEMORY.md就永久驻留。30天后被归档淘汰的碎片，其内容可能还残留在MEMORY.md中。没有"反向清理"机制，文件只会越来越大。

盲区二：偏好固化缺失。Dreaming能检测到"反复出现的操作模式"（Phase 3.5标记skill候选），但候选列表本身不会自动处理——需要一个"判断者"来决定：这个模式值得固化到MEMORY.md，还是应该创建成独立的自动化skill，还是暂时跳过。这种价值判断超出了自动化的能力边界。

盲区三：去重不完美。Dreaming的memory_writer用前50字模糊匹配防重复插入，但长期运行后会出现"语义相同但表述不同"的重复条目。比如同一个事件在不同日期被分别记录为"灵犀修复"和"sandbox版本问题修复"，自动去重拦截不住。

Layer 3的三把手术刀

Memory Consolidation每周一凌晨4点执行（比Dreaming晚1小时，确保当天Dreaming先跑完）。它有三大职责，按优先级排列：

第一刀：去重检测（全自动，最高优先级）

这是每次执行的第一步，在其他任何操作之前完成。去重分两个维度：

编年史日期去重。MEMORY.md末尾有一张编年史表格，记录每天的重要事件。Dreaming每天自动往里插入条目，但可能出现同一天被插入两次的情况（比如断线恢复后重复处理）。检测方法：正则匹配表格中所有日期行，找出重复日期，自动合并——保留信息最丰富的版本，并将其他版本中的独有事件追加进去。

全文逐section去重。扫描MEMORY.md的每个章节，提取条目行（以短横线开头或表格数据行），做标准化处理（去掉日期后缀、括号标注），然后按前40字生成指纹分组。同指纹组内的条目再做前30字精确比对，确认重复后标记。这部分不能自动删除，需要Agent人工判断哪条该保留。

第二刀：Skill候选审阅（半自动）

Dreaming Phase 3.5每天自动检测反复出现的操作模式，标记为skill候选，写入一个候选列表文件。但标记≠处理，候选列表会一直累积。

Layer 3每周读一次这个列表，AI Agent逐一审阅，三选一：

这里的核心设计理念是：机器能检测模式，但不能判断模式的价值。一个操作重复了5次，可能说明它很重要值得固化，也可能只是这周恰好频繁。这个判断需要Agent结合上下文来决定。

第三刀：Archived碎片清理（半自动）

Dreaming有淘汰机制——mention_count不超过1且30天未出现的candidate自动归档。但归档只改变了数据库状态，不会同步清理MEMORY.md中已写入的对应内容。

Layer 3读取所有归档超过30天的碎片，Agent逐条判断：这条碎片对应的内容是否还保留在MEMORY.md中？如果还在，是否应该移除？如果记忆已经过时或不再准确，就从MEMORY.md中清理掉。

去重引擎的技术细节

编年史去重算法

编年史是MEMORY.md末尾的一张Markdown表格，每行格式为"日期 | 事件描述"。去重算法分四步：

1. 范围定位：扫描文件找到包含"编年史"关键词的章节标题，确定表格的起止范围

2. 日期提取：用正则表达式从表格行中提取日期（YYYY-MM-DD格式），同一日期出现多次即为重复

3. 智能合并：保留最长版本（信息最丰富），从其他版本中按分号分割提取独有事件，追加到保留版本末尾

4. 安全删除：从后往前删除多余行，避免行号索引偏移导致删错

为什么要"从后往前删"？因为删除一行后，后面所有行的索引都会减1。如果从前往后删，第二个要删的行的实际位置已经变了。从后往前删则不会影响前面行的索引。

全文去重算法

全文去重要处理的问题更复杂，因为MEMORY.md各章节的结构不统一——有的是列表（短横线开头），有的是表格，有的混合使用。算法分三步：

1. 章节分组：按三级标题（###）将文件拆分为多个section，每个section独立检测

2. 标准化指纹：提取每个条目的文本，去掉日期后缀（括号中的日期标注）和状态标注，转小写，取前40字作为指纹

3. 精确认定：同指纹组内的条目再做前30字精确比对，完全匹配才认定为重复

为什么不直接用全文相似度（比如余弦距离）？两个原因：一是计算量大且依赖分词库，在sandbox中零外部依赖的原则下不可用；二是去重场景下"精确重复"远多于"语义近似"，指纹匹配足够覆盖。那些表述不同但语义相同的重复（比如"灵犀修复"和"sandbox版本修复"），留给Agent人工判断更安全。

为什么不用LLM做去重？

去重本质上是结构化操作——判断两段文字是否"说的是同一件事"。规则匹配（指纹+精确比对）对精确重复的拦截率接近100%，且结果完全可预测、可调试。LLM的优势在于"理解语义"，但去重场景中语义理解反而可能误判——两段看似相似但实际记录不同事件的文本，LLM可能错误地合并。

设计原则：规则能做的绝不交给LLM。LLM用在真正需要"理解"的地方——碎片提炼、候选审阅。

实际运行数据与效果

截至2026年5月，三层闭环记忆系统已运行17天，积累的真实数据如下：

fact占比72%——用户大部分对话在分享生活事件。preference只有7%，因为"至少2次出现才归类为preference"的门槛有效过滤了"随口一说"。rule有19条（10%），积累了相当数量的行为规则和约定。

MEMORY.md容量分析

这个数据揭示了Layer 3存在的紧迫性：MEMORY.md已经非常接近12000 Token的硬上限（Dreaming写入时设置了上限，超过就拒绝写入）。每天Dreaming还会继续自动插入confirmed碎片，如果不做精简整理，很快就会触及上限导致新碎片无法沉淀。

Layer 3每周执行一次的去重和清理，就是防止触及上限的止损机制。实际操作中，Agent会审阅MEMORY.md全文，移除过时事件（比如已完成的临时工作记录）、合并重复条目、精简冗余描述，把token控制在安全水位。

与Self-Improving系统的协同

除了三层闭环，系统还运行一套Self-Improving经验学习机制。它和Layer 3解决的是不同维度的问题：

Self-Improving管"经验教训"（什么做错了、什么该记住），Layer 3管"记忆结构"（记忆文件是否健康）。两者共享同一个heartbeat定时任务（每天凌晨3点检查衰减），各自独立运行。

设计反思与经验总结

混合模式的取舍

Layer 3的执行流程中，三种操作模式并存：

• 全自动：去重检测、编年史合并、状态更新——规则明确，不需要判断

• 半自动：skill候选审阅、archived碎片清理——工具提供数据，Agent做判断

• 人工判断：MEMORY.md内容精简——需要理解上下文和价值权衡

能自动化的全部自动化。需要判断力的，不回避交给Agent，但提供充分的结构化信息（比如列出所有重复条目的行号和内容），让判断变成"选择题"而非"问答题"。

文件编辑的安全规则

MEMORY.md是整个记忆系统的核心文件，任何编辑操作都必须遵守安全规则：先读取全文，在内存中修改，最后整篇写入。禁止做部分行替换，因为行号在编辑过程中会变化，部分替换极易破坏文件结构。

Dreaming的memory_writer也遵循这个规则：读取全文→定位目标section→在内存中插入内容→写回全文。插入前还做了去重校验（前50字模糊匹配），防止重复写入。

宁可少沉淀也不要灌水

整套系统有一条兜底原则：如果不确定一条信息是否值得保留，就不保留。碎片可以在下次Dreaming时重新提炼，但错误写入MEMORY.md的内容会持续污染AI的上下文。宁可少记一条，也不要让记忆文件变成垃圾桶。

本文涉及的核心组件开源，MIT协议：

• Memory Consolidation（记忆整理）：https://github.com/NMTZ-z/memory-consolidation

三层闭环的完整图景

至此，整个V4三层闭环记忆系统的全貌已经完整呈现：

Layer 1/2是"生产者"——每天从对话中提炼新知识，沉淀到长期记忆。Layer 3是"质检+清理"——每周检查记忆文件的健康度，清理冗余，审阅候选，控制容量。三层协同运转，确保记忆系统既持续增长，又不会无限膨胀。

下一篇：Cherry Diary —— 一个每天深夜自动生成的智能日记系统，融合天气、训练数据、对话摘要和生活感悟，用AI的视角记录用户的每一天。