TierMem 论文解读：让 Agent Memory 在便宜摘要和可信证据之间动态切换

一句话定位：TierMem 是 ICLR 2026 MemAgents Workshop 的 provenance-aware tiered memory 方法，把长期记忆分成 summary tier 和 raw log tier，推理时先用摘要，证据不足时升级到原始日志，并把经过验证的新结论写回摘要层。

会议信息：ICLR 2026 MemAgents Workshop
论文 / 页面：OpenReview / arXiv
GitHub / 实践项目：FreedomIntelligence/Tiermem
Star 数：约 5（截至 2026-05-21 附近公开信息）
开源状态：官方实现，MIT
适合读者：企业 Agent、长对话记忆、可审计 AI、成本敏感型记忆系统、需要 provenance 的产品工程师。

文章导读

TierMem 讨论的是一个很实际的问题：长期记忆到底该相信摘要，还是该回到原始日志？

只相信摘要，系统便宜、快，但摘要天然是有损压缩，容易漏掉未来问题真正需要的细节。每次都读原始日志，系统最可信，但 token、延迟和检索成本都会迅速上升。TierMem 的思路不是在两者之间二选一，而是把它们放到两个层级里：summary tier 负责低成本快速访问，raw log tier 负责原始证据和可追溯性。推理时先查摘要；当摘要不够、证据冲突或问题需要细节时，再升级读取原始日志；如果从原始日志中验证出新结论，再把它写回摘要层。

如果只想快速看结论，可读短文：tiermem-brief.md。

---

1. 核心结论

• TierMem 的核心不是“更强的向量检索”，而是 证据分层。
• 它把长期记忆拆成两层：便宜但有损的 summary tier，可信但昂贵的 raw log tier。
• 推理阶段采用 summary-first retrieval：先用摘要回答，必要时再 selective escalation 到原始日志。
• 回答后执行 verified write-back：只有被 raw evidence 支撑的新结论，才写回 summary tier。
• 它最适合企业 Agent、长对话助手、项目记忆、用户画像和需要审计链路的系统。
• 它的难点不是“能不能存”，而是“什么时候升级查证据、查哪些证据、写回什么摘要”。

---

2. 论文信息速览

• 标题：From Lossy to Verified: A Provenance-Aware Tiered Memory for Agents
• 会议：ICLR 2026 MemAgents Workshop
• OpenReview：https://openreview.net/forum?id=dJgeY3Awrv
• arXiv：https://arxiv.org/html/2602.17913
• 代码：https://github.com/FreedomIntelligence/Tiermem
• 核心对象：带长期记忆的 LLM Agent
• 核心主张：摘要可以作为低成本入口，但关键回答必须能升级到原始证据验证
• 关键词：tiered memory、summary memory、raw logs、provenance、selective escalation、verified write-back

---

3. 它要解决什么问题

Agent Memory 的基本矛盾是：历史很长，但上下文很贵。

一个长期运行的 Agent 会积累大量内容：

• 用户和 Agent 的多轮对话；
• 工具调用参数和返回结果；
• 检索到的网页、文档、数据库片段；
• 任务执行状态、失败原因和中间假设；
• 用户纠正、偏好变化和业务事实更新。

如果每次回答都把这些历史全塞进上下文，系统当然更接近“全知”，但成本很快失控。于是很多系统会做 summary memory：每轮或每段会话结束后，把历史压成短摘要，之后只检索摘要。

这解决了成本问题，却引入了另一个问题：摘要是有损的。

比如用户说：

我通常不喝咖啡，因为下午喝会睡不着。但如果是上午，我能接受一杯拿铁。

一个粗摘要可能写成：

用户不喝咖啡。

这个摘要不算完全离谱，但未来一旦用户问“明天上午会议喝什么”，它就会误导 Agent。真正关键的条件是“下午避免咖啡，上午可以接受拿铁”，而这个条件在摘要时被压掉了。

TierMem 关心的正是这种问题：summary memory 很省，但它不是证据本身。

---

4. 为什么不能只用 Summary

summary memory 的优势很明显。

它短、便宜、容易检索，也适合注入 prompt。对于多数低风险问题，摘要足够好。例如用户长期偏好、项目大方向、最近任务状态、已知约束，都可以通过摘要快速提供给 Agent。

但 summary memory 有四类典型风险。

第一，细节丢失。

摘要会保留“主题”，但不一定保留“条件”。用户不是简单地喜欢或不喜欢某个东西，而是有时间、场景、强度、例外条件。很多真实偏好都藏在这些条件里。

第二，时间线混淆。

用户过去喜欢 A，现在改成 B。摘要如果只写“用户喜欢 A”，就会变成过期事实。即使摘要更新成“用户喜欢 B”，系统也可能丢掉“什么时候从 A 变成 B”的历史。

第三，来源不可查。

很多系统只存一句模型总结，不存这句话来自哪次对话、哪次工具调用、哪份文档。等用户质疑时，系统无法解释“为什么你认为我喜欢 B”。

第四，错误会被放大。

一旦摘要写错，后续回答会不断引用这条错误记忆。如果系统还根据错误摘要继续生成新摘要，错误会在长期记忆里滚雪球。

所以 TierMem 不把 summary 当成真相，而把它当成缓存和索引。

---

5. 为什么不能每次都读 Raw Logs

既然摘要会丢信息，那是否每次都回查原始日志？

理论上可以，工程上很难。

raw logs 的优势是可信。它保留了原始对话、工具返回、检索证据、执行轨迹和用户反馈。要查证一个事实，原始日志最接近证据源。

但 raw logs 也有明显代价。

第一，token 成本高。

一次长对话可能几万甚至几十万 token。工具型 Agent 的日志更夸张，因为每次 API 调用、网页观察、代码 diff、测试输出都会进入历史。

第二，检索难度高。

原始日志很噪。它既有关键证据，也有寒暄、失败尝试、重复信息和中间错误。只靠向量相似度找 raw logs，很容易召回一堆看似相关但不能支撑答案的片段。

第三，延迟高。

原始日志检索、重排、读证据、再推理，都比读摘要慢。对于聊天助手或交互式 Agent，延迟会直接影响体验。

第四，隐私和权限更敏感。

raw logs 里可能有敏感信息、临时凭据、内部文档片段、用户私密内容。不是所有回答都应该访问完整原始日志。

所以 TierMem 的判断是：raw logs 必须保留，但不应该每次都读。

---

6. 核心思想：Summary First, Evidence When Needed

TierMem 的核心可以概括成一句话：

先用摘要省成本，在摘要不够时再用原始日志买可信度。

它把长期记忆分成两层。

第一层是 summary tier。

这一层保存压缩后的记忆，例如用户偏好、长期事实、任务状态、重要结论、已确认约束。它的特点是短、快、便宜，适合常规检索。

第二层是 raw log tier。

这一层保存原始交互记录，例如完整对话、工具调用、检索结果、动作轨迹和系统观察。它的特点是可信、细、可追溯，但读起来更贵。

推理时，系统先查 summary tier。如果摘要足够回答，就不读 raw logs。如果摘要不完整、不确定或存在风险，系统再升级到 raw log tier 查证据。

这个过程就是论文强调的 inference-time evidence allocation：在推理时分配证据预算。

---

7. 总体架构

TierMem 可以理解成一个闭环。

这个图里最重要的不是两层存储，而是中间的判断和写回。

如果没有 selective escalation，系统就会退化成普通 summary memory。

如果没有 verified write-back，系统每次遇到细节问题都要重新查 raw logs，长期摘要不会变好。

如果没有 raw log provenance，系统就无法证明摘要来自哪里。

---

8. 两层记忆分别存什么

summary tier 存的是可快速消费的状态。

例如：

• 用户偏好：用户下午避免咖啡，但上午可以接受拿铁；
• 项目事实：当前项目使用 PostgreSQL，迁移工具是 Alembic；
• 任务状态：已经尝试过重启服务，问题仍然存在；
• 业务约束：发票必须按公司抬头开具；
• 已验证结论：登录失败与 token 过期有关，而不是密码错误。

这些内容通常是短句或结构化字段，方便检索和注入 prompt。

raw log tier 存的是证据。

例如：

• 用户原话；
• Agent 当时的回答；
• 工具调用输入和输出；
• 检索到的文档片段；
• 数据库查询结果；
• 日志和测试输出；
• 产生某条摘要的 source span。

raw log tier 最好是 append-only 或 immutable。即使后续摘要改了，原始证据仍然存在。这样才能支持审计、回滚和重新总结。

---

9. 具体流程一：写入 Raw Logs

每次 Agent 交互后，系统先把原始信息写入 raw log tier。

这一步不应该过度依赖 LLM 判断“重要不重要”。因为未来问题依赖什么细节，在写入当下往往不知道。

更稳妥的做法是：原始日志先完整保留，再由后续策略决定哪些内容总结进 summary tier，哪些内容只作为证据保留。

raw log 的记录可以包含：

• 时间戳；
• session 或 trace id；
• 用户 id、agent id、任务 id；
• 消息角色和原文；
• 工具名称、参数、返回值；
• 文档来源和片段位置；
• 是否包含敏感信息；
• 可用于回查的 evidence id。

这一步看似普通，但它决定了后续 provenance 能否成立。如果原始日志没有保存好，后面的“可验证写回”就只剩口号。

---

10. 具体流程二：生成 Summary Tier

summary tier 不是简单的聊天总结，而是从 raw logs 中抽取出未来可能有用的状态。

它可以按类型拆分：

• profile summary：用户长期偏好和约束；
• task summary：当前任务目标、进度和阻塞；
• fact summary：已确认事实和业务状态；
• decision summary：为什么做过某个选择；
• exception summary：偏好或规则的例外条件；
• uncertainty summary：哪些信息尚未确认。

关键是每条 summary 都最好带 provenance。

例如不要只写：

用户不喝咖啡。

更好的写法是：

用户下午避免咖啡，因为会影响睡眠；上午可以接受一杯拿铁。来源：会话 2026-06-02，消息 18-21。

这个来源可以不直接暴露给模型，但系统内部应该保留。

---

11. 具体流程三：Summary-first Retrieval

新问题来了以后，TierMem 先查 summary tier。

比如用户问：

明天上午开会帮我推荐饮品。

系统先检索摘要，找到：

用户下午避免咖啡；上午可以接受一杯拿铁。

这时摘要足够具体，Agent 可以直接回答。

summary-first 的好处是：

• 检索空间小；
• 召回内容短；
• 注入上下文便宜；
• 对多数日常问题响应更快；
• 原始日志不会被无谓访问。

这一步和普通 summary memory 很像，但 TierMem 不止于此。它还需要判断摘要是否足够。

---

12. 具体流程四：Selective Escalation

selective escalation 是 TierMem 的关键。

系统要判断：当前问题是否需要升级到 raw logs？

常见升级触发条件包括：

• 摘要过短，缺少回答所需条件；
• 多条摘要之间互相冲突；
• 摘要没有 provenance 或证据来源不明确；
• 用户问的是时间、顺序、原话、细节；
• 回答会影响高风险决策；
• 模型对摘要支持的答案不确定；
• 用户要求解释“你为什么这么认为”；
• 摘要里的事实很久没有验证；
• 系统发现当前问题和旧摘要相似，但答案依赖例外条件。

举个例子。

summary tier 里只有：

用户不喝咖啡。

用户问：

明天上午会议喝什么比较合适？

这时摘要看似能回答，但它太粗。更好的策略是升级到 raw logs，查找这条摘要当初来自哪里。查到原话后，系统发现用户其实上午可以接受拿铁。于是回答会更准确。

升级策略的难点在于平衡。

升级太少，系统会被错误摘要误导。

升级太多，系统又退回到每次读 raw logs 的高成本路线。

---

13. 具体流程五：Raw Evidence Retrieval

升级后，系统从 raw log tier 中查找相关原始证据。

这里不能只做简单 top-k 向量检索。因为 raw logs 很长、很噪，关键证据可能不是语义最相似的一段。

更可靠的 raw evidence retrieval 可以组合几类信号：

• 语义相似度：问题和原始片段是否相关；
• provenance 链接：某条摘要来自哪些原始片段；
• 时间顺序：新事实是否覆盖旧事实；
• 角色信息：用户原话通常比 Agent 推测更重要；
• 工具可信度：数据库返回可能比网页片段更可信；
• 事件边界：一次任务或一次会话内的上下文要一起看；
• 冲突检测：找到支持和反驳当前摘要的证据。

对 TierMem 来说，raw logs 不只是“更多文本”，而是“可验证证据”。因此检索结果最好能回答两个问题：

第一，这个事实有没有证据支持？

第二，如果有冲突，哪条证据更新、更可靠、更适用于当前问题？

---

14. 具体流程六：Verified Write-back

TierMem 的另一个关键是 verified write-back。

如果系统升级到 raw logs 后发现了更准确的结论，它不会只在当前回答里使用这个结论，而是把它写回 summary tier。

例如原摘要是：

用户不喝咖啡。

raw logs 证明更准确的事实是：

用户下午避免咖啡，因为会影响睡眠；上午可以接受一杯拿铁。

那么系统应该把 summary tier 更新成后者，并附上来源。

verified write-back 的意义是让摘要层不断变好。

它不是随便让模型“再总结一下”，而是要求写回内容被 raw evidence 支撑。这样 summary tier 从一个可能有损、可能含糊的缓存，逐渐变成一组更可靠、更具体、更可追溯的长期记忆。

这一步也能降低未来成本。下次遇到同类问题时，系统可能不用再升级查 raw logs。

---

15. 一个完整例子

假设一个项目 Agent 处理过一段调试历史。

原始日志里有这些信息：

用户说：“线上登录偶发失败，但本地没问题。”

Agent 查日志发现：“失败请求都发生在 token refresh 后 5 分钟内。”

Agent 又查配置发现：“生产环境 clock skew 容忍只有 30 秒，本地是 5 分钟。”

最后修复方案是：“把生产环境 clock skew tolerance 调整到 5 分钟，并补充过期 token 测试。”

如果 summary tier 只写：

登录失败和 token 有关。

这个摘要太粗。未来用户问：

上次线上登录问题到底为什么本地复现不了？

只看摘要，Agent 可能答得很泛。

TierMem 的流程会是：

第一，先查 summary，发现有“登录失败和 token 有关”。

第二，判断摘要不足，因为用户问的是“为什么本地复现不了”，需要环境差异证据。

第三，升级到 raw logs，找到生产和本地 clock skew tolerance 不同。

第四，回答：“本地没复现是因为本地 clock skew 容忍 5 分钟，而生产只有 30 秒，token refresh 后的边界时间在生产更容易失败。”

第五，把更好的摘要写回：

线上登录偶发失败的根因是生产环境 clock skew tolerance 为 30 秒，而本地为 5 分钟；失败集中在 token refresh 后的边界窗口。修复方式是统一容忍配置并补充过期 token 测试。来源：trace X，日志片段 Y，配置 diff Z。

这样下次再问，summary tier 自己就足够回答。

---

16. 和普通 RAG 的区别

普通 RAG 的核心是检索相关文本。

它通常会把历史切成 chunk，建立向量索引，查询时召回 top-k 片段。这个模式很通用，但它没有明确区分“摘要”和“证据”，也不一定要求写回结果必须被原始证据支持。

TierMem 的重点不是换一个检索算法，而是改变记忆结构。

它明确区分两种东西：

• summary：低成本、可快速使用，但可能有损；
• raw logs：高成本、可验证，负责支撑事实。

普通 RAG 更像“从一堆文本里找相关片段”。

TierMem 更像“先看缓存，不够再查证据，并用证据修正缓存”。

---

17. 和普通 Summary Memory 的区别

普通 summary memory 的流程通常是：

历史进入系统，LLM 总结成摘要，下次直接检索摘要。

这个流程有一个隐含假设：摘要足够代表历史。

TierMem 不接受这个假设。

它认为摘要只是有损表示，必须有原始证据作为后盾。当摘要无法支撑当前问题时，系统应该回到 raw logs。更重要的是，回查原始证据后，系统要把验证过的新结论写回摘要，而不是让摘要永远停留在第一次压缩的状态。

所以 TierMem 是一种更保守、更适合长期运行的 summary memory。

---

18. 和 Mem0、PlugMem、E-mem 的区别

和 Mem0 相比，TierMem 更强调 provenance 和证据升级。

Mem0 的重点是从长期对话中抽取、更新和检索用户记忆，工程上很适合作为通用 memory service。TierMem 更像给这类系统补上一层证据机制：不要只保存抽取后的记忆，还要知道什么时候回查原始来源。

和 PlugMem 相比，TierMem 不重点研究把经历抽象成事实命题和行动处方。

PlugMem 的核心是把 Agent 经历变成知识中心图，强调任务无关插件记忆和决策相关知识。TierMem 的核心是层级证据路径：摘要负责便宜访问，raw logs 负责验证。

和 E-mem 相比，TierMem 更轻量。

E-mem 倾向保留较完整的 episodic context，并用多 Agent 在推理时重构。TierMem 不一定需要多 Agent，它更像一个存储和检索策略：先摘要，必要时原始证据。

---

19. 工程上怎么落地

如果把 TierMem 思路放进产品，可以设计成三类数据。

第一类是 raw event。

保存完整事实来源，例如消息、工具调用、检索片段、数据库返回、日志文件位置。它们应该有稳定 id、时间戳、权限标签和删除策略。

第二类是 memory summary。

保存给 Agent 快速使用的长期记忆，例如用户偏好、项目状态、业务事实、任务结论。每条 summary 都应该指向一个或多个 raw event。

第三类是 verification record。

记录某次写回为什么发生：哪个问题触发升级、读取了哪些 raw events、验证出什么结论、替换或补充了哪条 summary。

一个简化的数据结构可以是：

{
  "memory_id": "mem_123",
  "content": "用户下午避免咖啡，因为会影响睡眠；上午可以接受一杯拿铁。",
  "type": "preference",
  "confidence": 0.86,
  "source_event_ids": ["evt_18", "evt_19", "evt_21"],
  "last_verified_at": "2026-06-02T09:30:00Z",
  "valid_from": "2026-06-02",
  "status": "active"
}

这里最重要的是 source_event_ids 和 last_verified_at。没有它们，系统仍然只是普通摘要库。

---

20. 升级策略怎么设计

TierMem 的效果很大程度取决于 router，也就是决定是否升级的策略。

工程上可以从简单规则开始：

• 问题包含“为什么、什么时候、原话、上次、具体、证据、来源”时升级；
• 摘要召回分数低时升级；
• 摘要之间出现冲突时升级；
• 摘要更新时间太旧时升级；
• 回答涉及钱、合同、医疗、隐私、安全、删除操作时升级；
• 用户明确质疑 Agent 记忆时升级；
• Agent 生成答案时自评证据不足时升级。

后续可以把升级策略做成一个轻量模型或 LLM judge。它不需要直接回答问题，只需要判断摘要是否足够支撑回答。

一个实用提示是：宁愿把升级判断做得可解释，也不要一开始追求复杂。因为企业场景里，为什么访问了 raw logs 本身也可能需要审计。

---

21. 写回策略怎么设计

verified write-back 比普通 summary update 更严格。

写回时至少要判断四件事。

第一，新结论是否被 raw evidence 支撑。

不能因为模型“觉得应该是这样”就写入长期记忆。

第二，新结论是新增、修正还是废弃旧摘要。

如果用户偏好变化，应保留时间线，而不是直接把旧事实删掉。

第三，新摘要是否足够具体。

不要把“下午避免咖啡、上午可接受拿铁”又压回“用户不喝咖啡”。

第四，写回是否需要人工确认。

高风险领域或企业关键事实，最好让用户或管理员确认后再进入长期记忆。

写回策略决定了系统会不会越用越好。如果写回太随意，TierMem 也会变成错误记忆放大器。

---

22. 权限、隐私和删除问题

TierMem 要保留 raw logs，这会带来额外治理要求。

首先是权限。

不是所有 Agent、所有工具、所有用户都应该访问完整 raw logs。summary tier 可以被更广泛使用，但 raw log tier 往往需要更细粒度权限。

其次是脱敏。

raw logs 可能包含邮箱、手机号、token、内部链接、客户数据和业务敏感字段。写入 raw tier 前或检索 raw tier 后，都可能需要脱敏。

第三是删除。

如果用户要求删除某段历史，只删 summary 不够，raw logs 也要支持删除或不可恢复匿名化。否则 summary 看似删了，原始证据仍可被系统重新总结回来。

第四是审计。

系统应该记录什么时候访问了 raw logs、为什么访问、访问了哪些证据、这些证据是否进入了回答或写回。

这也是 TierMem 比普通 summary memory 更适合企业场景的地方：它天然要求 provenance 和 evidence path。

---

23. 适合的场景

TierMem 适合以下场景：

• 企业知识助手，需要回答可追溯；
• 客服 Agent，需要引用历史工单和用户原话；
• 代码 Agent，需要记住项目历史但关键修复要回查日志和 diff；
• 数据分析 Agent，需要摘要业务结论，但关键数字要能追到查询结果；
• 长对话助手，需要保存用户偏好，同时避免摘要误伤细节；
• 合规敏感场景，需要知道 Agent 为什么访问某段历史。

如果你的系统只需要很轻量的偏好缓存，TierMem 可能显得复杂。

如果你的系统已经频繁被“错误摘要”“过期记忆”“用户问证据但答不上来”困扰，TierMem 的架构很值得借鉴。

---

24. 不适合的场景

TierMem 不适合所有情况。

如果你的任务是短会话问答，没有长期历史，没必要上两层 memory。

如果你的业务不能保存 raw logs，也很难实现 TierMem 的核心价值。

如果你的系统没有权限、审计和数据治理能力，保留 raw logs 反而可能增加风险。

如果你只想快速做一个 demo，普通 summary memory 或向量检索更简单。

如果你追求的是工具调用技能复用，ProcMEM、H-EPM 或 PlugMem 里的 procedural memory 思路可能更直接。

---

25. 局限与风险

第一，论文是 workshop 论文，工程成熟度需要谨慎评估。

官方仓库可以参考，但不要把它当作成熟企业 memory platform。更重要的是借鉴它的证据分层思想。

第二，升级策略很难调。

升级太少会不可靠，升级太多会太贵。不同业务的风险阈值不一样，需要按场景调。

第三，raw log retrieval 本身也会犯错。

系统升级到 raw logs，不代表一定能找到正确证据。原始日志检索、重排和证据综合仍然是难点。

第四，写回可能污染摘要层。

如果 verified write-back 的验证不严格，错误结论会被写入 summary tier，后续回答会继续受影响。

第五，数据治理成本更高。

raw logs 的保存、访问、脱敏、删除、审计都要认真设计。

---

26. 对产品工程的启发

TierMem 最值得借鉴的不是具体代码，而是三个原则。

第一，摘要不是事实，只是有损缓存。

产品里不要把 LLM 总结的一句话当成不可质疑的长期真相。每条长期记忆最好都能追到来源。

第二，关键回答要能升级查证据。

用户问细节、问来源、问历史决策、问高风险问题时，系统应该自动回到原始日志，而不是只靠摘要硬答。

第三，记忆要越用越可靠。

每次升级查证据后，如果发现更好的事实表达，就应该验证后写回。否则系统会反复为同一个问题付出 raw log 成本。

---

27. 一个落地版本可以怎么做

如果要在现有 Agent 系统中快速借鉴 TierMem，可以从一个最小版本开始。

第一步，保存 raw events。

把用户消息、Agent 回复、工具调用、检索结果都保存成可追溯 event。先不急着做复杂图结构。

第二步，给 summary memory 加来源字段。

每条 memory 至少保存 source event ids。没有来源的记忆标成 unverified。

第三步，回答前先查 summary。

保持现有低成本路径，不要一开始就改变所有流程。

第四步，加一个升级判断。

当问题涉及细节、冲突、证据、高风险操作或摘要低置信度时，查 raw events。

第五步，写回更好的摘要。

从 raw events 中验证出的新结论，更新到 summary memory，并保留证据链接。

第六步，加审计日志。

记录每次 raw event 访问和每次 summary 写回。这样以后才能调试和治理。

这个最小版本已经能覆盖 TierMem 的主要思想。

---

28. 总结

TierMem 的价值在于把 Agent Memory 从“只会总结历史”推进到“能按需验证历史”。

它没有试图证明摘要没用，也没有要求每次都读取完整历史。它的判断更务实：摘要负责便宜，原始日志负责可信，推理时根据问题动态分配证据，回答后再把验证过的新结论写回摘要。

对真实产品来说，这个思路非常重要。长期记忆不是越多越好，也不是越短越好，而是要知道每条记忆从哪里来、什么时候该相信、什么时候该回查、什么时候该更新。

一句话收尾：如果 Mem0 解决的是“怎么把长期对话变成可检索记忆”，PlugMem 解决的是“怎么把经历抽象成可复用知识”，那 TierMem 解决的是“怎么让摘要记忆在关键时刻回到证据层，避免 Agent 被自己的总结误导”。

---

29. 资源链接

• OpenReview: TierMem
• GitHub: FreedomIntelligence/Tiermem
• arXiv: TierMem