本期回答一个根本问题：既然记忆就是一堆事实，为什么不直接存成一个列表？
最近一直在阅读TencenDB-Agent-Memory，想整理下TDAM的实现思路，加深对于agent memory功能的理解。
一、问题的起点
OpenClaw出现之后，出现了Hermes Agent，最重要的功能就是关于记忆的能力，让agent能够记住用户输入的内容，不需要反复的向用户提及一些固定的内容。那么memory功能又是如何实现的呢？
我们从项目官方 README 的一个问题出发：
我们从一个很实际的问题出发：怎样减少使用 Agent 时的重复工作？
项目背景讲过了，不该换个 Session 再讲。文档读过了，不该每个 Agent 从第一页重读。一套做法已经跑通，不该下次再摸索一遍。
所以这里的 Memory 不只是"记住对话"。凡是能让下一个 Agent 少走弯路的信息，都应该被保存、组织并复用。
这句话拆开看，包含三个诉求：保存（留证据）、组织（找得到）、复用（用得上）。
而记忆天然有个矛盾：你想要证据完整，就得把原话一字不改地存下来；你想省 Token，就得把它们压缩成精简摘要。同一份数据没法既是原文又是摘要。
于是官方给出的解法是——分层：从底到顶越来越精简，官方把四层结构称为记忆金字塔。
二、记忆金字塔：L0 → L3
官方 README 给出了一张非常凝练的分层表：
| 层级 | 保存什么 | 主要用途 |
|---|---|---|
| L0 Conversation | 原始对话与完整上下文 | 核对原话、时间和来源 |
| L1 Atom | 从对话提取的事实、偏好、约束与事件 | 精确召回可执行信息 |
| L2 Scenario | 围绕项目或场景组织的知识块 | 快速恢复一个工作场景 |
| L3 Core / Persona | 长期画像、稳定模式与高层认知 | 让 Agent 迅速进入用户和团队语境 |
——《README_CN.md · 技术实现 · 1. 记忆不是平铺记录，而是逐层生长》
一句话概括四层的分工：
- L0 留证据：流水账，每次对话结束把原话写进本地文件，一字不改、不做任何提炼。
- L1 保精度：记忆卡片，相当于"会议纪要"，每张卡片只记一件事，带类型与优先级。
- L2 保情境：场景档案，把同一情境下的卡片打包成一份文件，按情境组织、不按日期。
- L3 保效率：人格摘要，描述"这个用户是谁"，是四层里唯一每次新会话无条件注入的。
引用自官方社区解读（《拆解 TencentDB Agent Memory 源码》）：“L0 是流水账……L1 是记忆卡片……L2 是场景档案……L3 是人格摘要。”
三、为什么底层是数据库、高层是 Markdown？
这是官方实现里一个非常有意思的取舍，体现在存储方式上：
| 层 | 存储介质 | 谁在读 |
|---|---|---|
| L0 | l0_conversations 表 + JSONL 文件 | 程序检索（向量 / FTS） |
| L1 | l1_records 表 + vec0 向量表 + FTS5 | 程序检索 |
| L2 | scene_blocks/*.md 场景文件 + scene_index | 人可以直接读、直接改 |
| L3 | persona.md 全实例一份 | 人可以直接读、直接改 |
官方架构文档的原话是：
关键点：L2/L3 的"存储"是文件优先（md 文件是权威，store 里的 profiles 表是同步副本，供 TCVDB 等远端后端拉取）；L0/L1 的存储由 IMemoryStore 抽象接管。
这背后的逻辑很清晰：机器要的是可检索，人要的是可理解。 L0/L1 面向程序，天然进数据库和索引；L2/L3 面向人（用户和团队要审阅、修正记忆），所以是 Markdown 文件——你在面板上看到的每一份场景档案、每一份画像，本质上就是磁盘上的一个 .md。
四、四层还能串起来：下钻溯源
四层不是四座孤岛，而是一条证据链：
L3 人格摘要 ──下钻──▶ L2 场景档案 ──下钻──▶ L1 记忆卡片 ──下钻──▶ L0 原始对话
（是谁） （什么情境） （哪条事实） （原话 + 时间）
- L1 卡片带
source_message_ids，能一路追到 L0 的某条原始消息； - L2 场景文件由 L1 卡片（
scene_name字段）分组而来； - L3 画像由 L2 场景内容归纳而来。
官方 README 对分层召回策略的总结是：
生成和召回都分层：平时用 L2 / L3 快速进入语境，需要具体事实时通过 BM25、向量检索与 RRF 回到 L1 / L0。结果还会经过条数、字符预算和超时限制，避免记忆反过来占满上下文。
平时给你高密度摘要，纠错时给你完整证据链——这就是"分层"带来的核心价值。
五、与「聊天历史」「普通 RAG」的对比
官方用一张表说明了 TDAM 的定位差异：
| 聊天历史 | 普通 RAG | TencentDB Agent Memory | |
|---|---|---|---|
| 跨会话理解用户 | △ | △ | ✅ Chat Memory |
| 沉淀可执行经验 | — | — | ✅ Skill |
| 文档结构与关系 | — | △ 切片检索 | ✅ Wiki + Link Graph |
| 代码调用与影响范围 | — | △ 文本命中 | ✅ CodeGraph |
| Owner / 版本 / 状态 | — | — | ✅ |
| 团队分享与 Agent 配装 | — | — | ✅ |
| 私有 / 团队 / ACL | — | △ | ✅ |
RAG 解决"能查到什么"；Team Memory 还要解决"谁可以用、哪个版本有效、应该给哪个 Agent"。L0–L3 是这套资产体系在 Chat Memory 这一资产类型上的落地形态。
六、本期小结
记忆无法既是原文又是摘要 → 用四层金字塔拆解矛盾：L0 留证据、L1 保精度、L2 保情境、L3 保效率。
底层（L0/L1）进数据库、可全量检索；高层（L2/L3）写成 Markdown、人可直接读改。
四层串成证据链：平时自上而下取摘要，纠错时自下而上查原文。
参考来源：https://github.com/TencentCloud/tencentdb-agent-memory