记忆蒸馏：让 Agent 自动记住该记住的事

记忆不是”全都记下来”。记忆是”知道该忘掉什么”。

问题#

我们在之前的文章里介绍过多 agent 团队的三层记忆设计：日志 → 长期记忆 → 归档。这个架构解决了”记忆往哪写”的问题，但没有解决另一个问题：

谁来决定什么值得从日志升级到长期记忆？

答案一直是”协调层手动整理”。每隔几天，在心跳轮询的间隙，翻一翻最近的日志，把有价值的内容手动搬到长期记忆文件里。

这个方法有三个致命缺陷：

解决这个问题的灵感来自一个开源项目。它的核心思路是：

记忆不应该靠用户主动”存”，而应该从对话中自动提取。

它把记忆提取定义为一个独立模块——每次对话结束后，自动扫描对话内容，提取结构化事实，与已有记忆去重合并，然后写入持久化存储。

关键洞察：记忆提取应该是一个后台流程，而不是主流程的一部分。 在对话进行中，agent 应该专注于当前任务；记忆整理是事后的事。

我们把”什么值得记住”拆解成了 6 种事实类型：

类型	含义	示例
preference	用户偏好和行为习惯	”表述偏好用正向信号，少用否定句”
decision	明确做出的决策和规则	”所有代码改动必须走 ACP harness”
fact	客观事实和配置信息	”团队有 12 个 agent，协调层负责拆任务”
lesson	从错误或经验中总结的教训	”gateway restart 会断开所有 subagent”
relationship	人或实体之间的关系	”全栈工程师负责代码，架构师负责拆任务”
todo	待办事项和跟进项	”搜索 fallback 功能等待 API key”

这个分类不是凭空设计的，而是回顾了团队运行以来数十天的日志后，归纳出来的六种最常出现的”值得记住的东西”。

整个蒸馏流程分三步：

触发时机有三个：

扫描对象是日志文件（memory/YYYY-MM-DD.md），而不是原始对话记录。日志本身已经是第一层过滤——只有协调层认为值得记录的事件才会出现在日志里。

对每条候选事实，判断它属于哪种类型，并输出结构化格式：

1
- type: decision
2
  content: "故障重试策略：provider 级只告知，模型级告知并切模型重试"
3
  source: "2026-04-28"
4
  confidence: high

这是最关键的一步。新提取的事实必须和长期记忆中已有的内容对比：

去重逻辑不能只靠文本匹配。两条描述同一件事但措辞不同的记忆，需要语义级别的判断。在实践中，我们发现最可靠的方式是让 agent 自己判断”这条新事实和已有的哪条是在说同一件事”。

以近期 11 天的日志（4/17 - 4/28）为例，记录了以下内容：

手动蒸馏的话，需要逐天打开日志、筛选、归类、去重、写入长期记忆。大约 20-30 分钟。

自动蒸馏的理想状态：心跳触发 → 扫描最近未处理的日志 → 提取 → 去重 → 写入。协调层只需要在长期记忆文件更新时做一次快速审查。

当前系统只有”增加记忆”的机制，没有”主动遗忘”的机制。长期记忆文件只增不减，最终还是会膨胀。

理想的遗忘机制应该是：定期检查每条长期记忆的”最后引用时间”，如果很久没有被实际使用过，降级到归档层。但”最后引用时间”的追踪本身就是一个工程问题——你需要知道”哪些记忆在哪些 session 中被实际读取并影响了行为”。

当前记忆系统是协调层独占的。每个 agent 被派工时，协调层把相关上下文塞到 task prompt 里。agent 自己没有记忆。

但实际运行中发现，有些记忆应该是特定 agent 独有的——比如测试工程师积累的”这个模块的常见 bug 模式”，或者设计师积累的”这个项目的视觉规范细节”。这些信息放在协调层的全局记忆里不太对，但目前没有给单个 agent 建独立记忆的机制。

一条事实在 3 天前是对的，30 天后可能已经过时了。比如”当前使用的默认模型是 X”这种配置类事实，变化频率很高。但当前系统对所有记忆一视同仁，没有时效性权重。

记忆蒸馏 skill 已经写好并部署，定义了完整的提取协议和输出格式。目前在灰度验证阶段——先让它在心跳周期中实际运行几轮，观察提取质量和去重准确率，再决定是否调整分类体系或提取阈值。

从手动到自动，不是一步到位的事。但方向是确定的：记忆管理不应该是人的负担，它应该是系统的责任。