第8章：在长期运行的智能体系统中，记忆数据库可能会积累大量数据。请设计一个"记忆归档"机制：将长期不用但可能有价值的记忆转移到冷存储，需要时再恢复。这个机制应该如何与现有的四种记忆类型集成？

[LiuYuPeng1101]

建立“热/温/冷”分层：热层继续使用现有高性能存储；冷层使用便宜的大对象存储（OSS）+ 压缩向量集合；温层可选地放置最近被访问的归档条目，避免频繁抖动。
需要扩展更多的元数据：last_accessed, access_count, importance, user_pin（用户手动标记的）, archive_status（hot、archived、restoring）, archive_pointer（冷层中的内容的引用，具体是什么需要看设计）
hot_score：代表是否能留在热层的分数。计算：hot_score = f(recency, frequency, importance, user_pin)，得分越高，留在热层
value_score ：代表热度低，是否值得放入冷层。计算：value_score = g(user_feedback, LLM评估, size)，这里的user_feedback就是代表用户的显示评分或者业务日志，要映射到0-1区间，如果分高代表不常用但值得保存，size就表示存储的成本。
当hot_score和value_score都低的时候，直接清理
归档流程：
1.后台线程分类拉取未钉住且热层容量/阈值触发的条目，给每条记忆计算 hot_score = f(recency, frequency, importance, pin)；若低于 θ_hot 再计算 value_score = g(user_feedback, LLM评估, size)。

hot_score 低 → 说明近期不常用。
value_score 高 → 说明仍值得留存。
满足“热度低 + 价值高”的条目会进入归档队列；热度低且价值低的直接按原 TTL/淘汰策略删除。
2.归档写入：生成摘要，保留关键信息，更新 archive_status='archived'，在热层插入“代理记录”供检索命中
3.检索：常规检索先命中热层。若召回不足或命中代理记录，异步根据 archive_pointer 将原文/向量取回（需要时重建向量、图关系），完成“按需回迁”。
4.回迁：某条冷数据短期内频繁被访问，热分会重新升高。调度器检测到后执行逆流程：从冷层拉回全量数据，写回热层存储，恢复 archive_status='hot'