记忆生命周期管理
在 MemOS 中，记忆并不是静态存放的，而是会随着时间和使用情况不断演化。
1. 能力介绍
一条记忆从被生成开始，可能会逐步沉淀为稳定的长期偏好，也可能因过时或无效而被清理。
提示
这套演化过程称为 记忆生命周期管理，它的目标是保持记忆库“干净而有序”
这套演化过程称为 记忆生命周期管理，它的目标是保持记忆库“干净而有序”
- 近期有用的条目保持活跃，方便随时调用；
- 长期稳定的事实被沉淀，减少重复和噪音；
- 过时或冲突的信息会被归档或删除，保证一致性和合规性。
需要注意的是，生命周期管理关注的是记忆条目在存储层面的演化；而具体一次推理里“是否调用某条记忆”，仍由调度机制决定。
生命周期阶段简介
| 阶段 | 说明 | 系统行为 |
|---|---|---|
| Generated 生成 | 新产生的记忆对象，带有来源、时间戳、置信度等元信息 | 初始存入存储层，等待后续使用 |
| Activated 激活 | 在推理或任务中被引用，进入高频活跃状态 | 更容易被调度机制选中 |
| Merged 合并 | 与历史记忆存在语义重叠或用户补充数据，系统将其整合为新版本 | 多条记录被压缩合并，形成更新后的稳定条目 |
| Archived 归档 | 长期未被访问，自动降级为冷存储状态 | 仅在特殊检索或回溯时启用 |
| Expired 过期，可选 | 归档后进一步超时或被策略判定为无效 | 被清理出索引，不再参与推理，仅留最小日志 |
| Frozen 冻结，特殊状态 | 关键或合规性记忆被锁定，不允许修改 | 保留完整历史版本，支持审计与合规追踪 |
2. 案例：在线教育助手的记忆生命周期
假设你正在用 MemOS 构建一个 在线教育助手，帮助学生解答数学题。
生成（Generated）
- 学生第一次使用时说：“我总是把二次函数和一次函数搞混。”
- 系统抽取出记忆：
{"fact": "学生常混淆二次函数与一次函数", "confidence": 0.8, "timestamp": "2025-09-11"}
- 状态：Generated
- 行为：被存储进记忆库，等待后续使用。
激活（Activated）
- 在接下来的多次答题中，系统频繁调用这条记忆来辅助解题。
- 状态：Activated
- 行为：被调度机制优先缓存进 MemoryCube，提高检索速度。
合并（Merged）
- 随着更多交互，系统发现学生不仅混淆一次函数和二次函数，还对指数函数也容易混淆。
- 系统将多条相似记忆合并为：
{"fact": "该学生在函数知识点上存在混淆，尤其是一元一次、二次和指数函数", "confidence": 0.95}
- 状态：Merged
- 行为：旧条目被压缩，形成新版本，减少冗余。
归档（Archived）
- 三个月后，学生已掌握函数相关知识点，系统很久没有再调度到这条记忆。
- 状态：Archived
- 行为：被迁移至 MemVault（冷存储），默认不参与推理，但可在“学习轨迹回溯”中被调用。
过期（Expired）
- 又过了一年，该学生升级到新的学段，旧的“初中函数混淆”记忆被策略判定为无效。
- 状态：Expired
- 行为：从索引中彻底清理，仅保留最小审计信息：
{"deleted_fact_id": "12345", "deleted_at": "2026-09-11"}
冻结（Frozen，特殊状态）
- 与此同时，该学生的“期末成绩评估报告”属于合规性文件，不允许修改。
- 状态：Frozen
- 行为：被锁定，禁止更新，仅保留完整修改历史，便于审计与合规检查。
3. 进阶：如果你想做深度定制
| 可扩展点 | 描述 | 示例 |
|---|---|---|
| 状态转换条件 | 控制各个状态触发条件 | “若 7 天未使用 → 归档” |
| 合并与压缩 | 定义相似记忆的处理方式 | 多条“喜欢科幻片”合并为一条置信度更高的事实 |
| 冲突解决 | 处理时间戳或来源矛盾的记忆 | 选择“最新覆盖旧条目”或“并列保留” |
| 清理机制 | 设置删除条件，控制索引规模 | 删除低置信度或用户撤回的记忆 |
| 审计追踪 | 决定是否保留被删除条目的最小元信息 | 在合规要求下开启“溯源日志” |
4. 下一步行动
还有疑惑？去看看 FAQs能不能为您解答~
5. 联系我们
