夜雨聆风——EverMemOS 记忆系统完整搭建实录
大多数 AI 助手都有一个致命缺陷：它们没有记忆。
每次对话结束，它就把你忘得一干二净。你昨天告诉它你在做什么项目、用什么技术栈、遇到了什么问题，今天再开口，它完全不认识你。
这不是 AI 在假装健忘，而是架构层面的根本缺失。
今天，我想分享一个我亲手搭建并调试的系统：EverMemOS，一个让 AI 真正拥有长期记忆的操作系统。它不只是"存储对话历史"，而是像人类大脑一样，会主动遗忘无用信息、强化重要记忆、精准检索所需内容。
最终实现：
- 记忆 → 经验
- 经验 → 方法
- 方法 → skill
为什么普通的"记忆"不够用？
很多人的第一反应是：把历史对话全塞进 prompt 不就行了？
不行，原因有三：
-
上下文窗口有限
哪怕是最强的模型，塞入几万条历史记录也会撑爆窗口，还会严重拖慢响应速度。 -
噪声淹没信号
三个月前你随口说的一句话，和今天真正重要的技术决策，对 AI 来说权重是一样的。这是灾难性的。 -
没有结构，无法精准检索
"帮我找上次讨论过的关于 MongoDB 优化的内容"，如果记忆只是一堆原始文本，这个请求几乎无法精准命中。
EverMemOS 的解法是：把记忆当成操作系统来管理。
EverMemOS 的核心架构
EverMemOS 的记忆分三层，就像人类记忆的工作方式：
L1 短期记忆（Short-term）
↓ 对话结束后提取
L2 情节记忆 MemCell（MongoDB）
↓ 向量化后写入
L3 语义记忆 MemScene（Milvus 向量库）
每一条记忆进入系统时，都会被结构化成这样的格式：
{
"title": "EverMemOS GC 超时根因修复",
"summary": "修复 async cursor 冲突，GC 耗时从 120s 降至 0.6s",
"keywords": ["GC", "pymongo", "async_cursor", "model_validate", "MemCell"],
"linked_entities": {
"人物": [],
"项目": ["EverMemOS"],
"技术栈": ["MongoDB", "pymongo", "Milvus"]
}
}不是原始文本，是结构化知识单元。
最关键的设计：主动遗忘机制
这是整个系统最有意思的部分，也是我花时间最多的地方。
人类记忆有一个特性：不常用的记忆会淡化，经常回忆的会强化。EverMemOS 用一个数学公式模拟了这个过程：
Score = e^{-λ · t} + w · log(1 + access_count)其中：
- t = 距离上次访问的天数
- λ = 0.01 = 时间衰减系数
- w = 0.1 = 访问频率权重
- 阈值 = 0.2，低于则触发软删除
举几个直观的例子：
| 场景 | 得分 | 结果 |
|---|---|---|
| 200 天前写入，从未被访问 | 0.135 | 🗑️ 遗忘 |
| 200 天前写入，访问 30 次 | 0.482 | ✅ 保留 |
| 5 天前写入，从未被访问 | 0.951 | ✅ 保留 |
| 161 天前写入，从未访问 | 0.199 | 🗑️ 遗忘（刚过边界） |
| 160 天前写入，从未访问 | 0.202 | ✅ 保留（边界内） |
每天凌晨 04:00，系统自动扫描全量记忆，低分的进入软删除队列，30 天后彻底清除。整个过程 0.6 秒完成，8000 条记忆无感清理。
三层防护：记忆写入不丢失
记忆的写入依赖外部 LLM 做结构化提取。问题来了，如果 API 挂了怎么办？
我设计了三层防护：
第一层：Gemini 503 → 指数退避重试（2s → 4s → 8s）
↓ 三次全失败
第二层：切换本地模型 gemma4-local（Ollama 本地运行）
↓ 本地模型也忙
第三层：写入 pending 队列，每 30 分钟自动补写
实测效果：SSL EOF 触发重试 → Ollama 高负载切换 → pending 队列写入成功。一条记忆都不会丢。
混合检索：让"找记忆"变得精准
存得好还不够，还要找得准。
EverMemOS 用的是双引擎混合检索：
- Milvus 向量库：语义相似度检索，找"意思接近"的记忆
- Elasticsearch 倒排索引：关键词精准匹配，找"包含特定词"的记忆
今天我做了一个重要升级：把结构化提取的 keywords 和 linked_entities 注入 ES 层，并设置权重：
| 字段 | Boost 权重 |
|---|---|
| keywords | 5.0 |
| linked_entities | 4.0 |
| title | 3.0 |
| summary | 2.0 |
| 正文 | 1.0 |
搜索"MongoDB GC 优化"，命中 keywords 的结果排在最前面，而不是随机混在一堆正文里。
Agentic 三轮检索
当一次检索结果不够好时，系统会自动启动三轮检索机制：
Round 1：threshold=0.7，严格匹配
↓ 结果不足
Round 2：LLM 重写查询语句，重新检索
↓ 仍然不足
Round 3：threshold=0.5，放宽匹配
冷启动时，也就是记忆库还很少时，效果尤其明显。
今天跑通的完整链路
经过一整天的开发和调试，系统最终实现了：
用户对话
↓
conversation_hook（实时捕获）
↓
gemini-2.5-flash 结构化提取
（失败则 → gemma4-local → pending 队列）
↓
MemCell 写入 MongoDB（含 keywords/entities/summary）
↓
向量化 → Milvus 存储
+ 分词 → Elasticsearch 存储
↓
每日 04:00 GC 主动遗忘低价值记忆
全自动，无人值守，记忆持续自组织。
自生技能：灵感来源于HERMES
在记忆系统的最底层我设计了skill-growth
skill-growth 是怎么工作的
这是 EverMemOS 往上再长的一层。
它不只是“记住”，还要把重复经验提炼成skill 候选。
大致流程
EverMemOS 里积累 episodic memories
skill-growth 定时扫描这些记忆
聚类相似事件
提炼出稳定流程
产出 skill 候选或自动 skill 文件
所以它干的事是：
从“发生过什么”提升到“以后应该怎么做”
这就是：
- 记忆 → 经验
- 经验 → 方法
- 方法 → skill
这套系统背后的核心理念，其实来自认知科学：
遗忘不是记忆的失败，而是记忆的自我净化。
人类大脑每天睡眠时都在做同样的事，清理无用连接，强化重要回路。EverMemOS 只是把这个过程，用代码实现了一遍。
当你的 AI 助手开始"记得住事"，又"懂得忘事"，它才真正开始像一个长期协作的伙伴，而不是每次见面都需要重新介绍自己的陌生人。
