当所有人都在做“向量数据库 + RAG”时，腾讯云数据库团队交出了一份不一样的答案。
为什么又一个记忆系统值得关注？
市面上的 AI Agent 记忆方案已经很多了：LangChain Memory、MemGPT、Zep、Mem0……大多数都在解决同一个问题：怎么让 Agent 记住历史对话？
但 TencentDB Agent Memory 问的是另一个问题：当前这轮任务怎么别炸上下文？
这个差异看似微妙，实则关键。
真正的痛点：不是“记不住”，而是“撑爆了”
想象你让 Claude 帮你做一个复杂任务：分析 10 个 PDF、生成报告、创建演示文稿。
每个工具调用都会返回结果：
- 读取 PDF → 返回 5000 tokens
- 搜索资料 → 返回 3000 tokens
- 生成图表 → 返回 2000 tokens
10 个步骤下来，上下文窗口就被工具输出塞满了。模型开始“失忆”，忘记最初的任务目标，或者干脆因为超出 token 限制而报错。
这就是长任务的“上下文退化”问题。
大多数记忆系统的做法是：把历史对话存到向量数据库，需要时检索回来。但这解决不了当前任务正在进行时的上下文爆炸。
腾讯的方案是：把短期上下文压缩正式纳入记忆系统的边界。
核心创新：三层回溯 + 动态压缩
TencentDB Agent Memory 的 Offload 机制设计了一个三层结构：
第一层：Mermaid 任务图
把长任务压缩成一张流程图，标注每个节点的状态（done/doing/todo）。模型看到的不是一堆工具输出，而是“任务走到哪一步了”。
这张图会随着任务推进动态更新，始终保持最新状态。
第二层：JSONL 索引
每个工具调用都会被记录成一条索引：工具名、参数、摘要、引用位置。就像一本书的目录，告诉你“哪里有什么内容”，但不占用太多空间。
第三层：原文引用
完整的工具输出被保存在独立文件中。需要时可以“回钻”查看原文，但默认不加载到上下文里。
三级压缩策略：从温和到紧急
系统会根据 token 使用情况自动选择压缩强度：
Mild（温和）：把工具结果替换成摘要，信息保留度最高
Aggressive（激进）：删除旧消息段，注入 Mermaid 图补偿方向感
Emergency（紧急）：硬兜底，迅速把 token 打到安全线以下
这不是简单的“删消息”，而是从压缩视图到原始证据有完整链路。
L1.5：被忽视的关键层
在短期压缩和长期记忆之间，腾讯加了一层“任务生命周期判断”：
- 当前任务是否结束？
- 这是不是长任务？
- 新诉求是不是旧任务延续？
- 是否需要挂载历史任务图？
没有这一层，Mermaid 图和 offload 结果会跨任务串味。
这是大多数记忆系统缺失的环节——它们不知道“任务边界”在哪里。
长期记忆：四层流水线
除了短期压缩，TencentDB Agent Memory 还有一套完整的长期记忆体系：
L0：原始对话捕获
不做判断，先保真。原子 checkpoint 防止并发脏写。
L1：结构化记忆提取
从对话中提取三类原子记忆：
- persona：用户偏好和习惯
- episodic：重要事件和决定
- instruction：行为规则
每条记忆都有类型、优先级、来源引用、时间元数据。
L2：场景叙事整合
把原子记忆整合成连贯的叙事文档，不是清单，不是日志。就像把零散的照片整理成相册。
L3: Persona 画像
增量演化用户画像，不是每轮全量重算。“四层深度扫描”：基础锚点 → 兴趣图谱 → 交互协议 → 认知内核。
关键设计：各层职责不混。
L0 保真 → L1 抽象 → L2 组织 → L3 上卷。比“全都 chunk + vector”更有治理感。
Recall 注入：稳定区 vs 动态区
当模型需要调用记忆时，系统会分两个区域注入：
稳定区（system prompt 尾部）：
- Persona 画像
- 场景导航
- 工具指南
这部分变化少，可以享受 prompt cache 加速。
动态区（user prompt 前缀）：
- 当轮相关的结构化记忆
每轮可能不同，但不影响缓存收益。
同时提供两个工具：
- tdai_memory_search：搜结构化记忆（抽象层）
- tdai_conversation_search：搜原始对话（证据层）
分离抽象层和证据层，这是提升记忆可靠性的关键。
工程意识：魔鬼在细节里
TencentDB Agent Memory 不是学术 demo，而是生产级系统。从代码里能看到大量工程细节：
- 原子 checkpoint：防并发脏写
- tiktoken 计量 + WeakMap 缓存：不拍脑袋压缩
- MMD 动态刷新：不是静态总结
- orphan ref 清理：防止垃圾文件堆积
- 场景文件上限：防止中层知识结构熵增
- warm-up 阈值：新 session 早期加工更积极
- global mutex persona：防并发覆盖
- JSONL sanitize/validate：防真实数据腐坏
这些细节决定了系统能不能在真实场景中稳定运行。
宿主无关：不绑死任何框架
核心逻辑在 TdaiCore（host-neutral facade），通过适配器对接不同框架：
- OpenClaw 用 OpenClawHostAdapter
- Hermes/Gateway 用 StandaloneHostAdapter
这意味着你可以把它接入任何 Agent 框架。
风险与局限
没有完美的系统。TencentDB Agent Memory 也有明显的权衡：
风险 1：系统链路长，调试复杂度高
从 capture 到 recall 经过多个环节。任何一层异常都表现为“记忆不对”，但很难定位问题出在哪。
风险 2：高度依赖 prompt 质量
L1 情境切分、L2 场景整合、L3 画像更新、L1.5 任务判断都是 prompt 驱动。模型一换，行为可能漂。
风险 3：L1 是成败关键
L1 抽错 → L2 在错误原子上建叙事 → L3 在错误叙事上建画像。Garbage in → hierarchy out.
风险 4：抽象偏差累积
Scene 和 Persona 容易出现“局部失真但长期自洽”的问题——用户更难发现。
风险 5：对宿主消息协议敏感
assistant tool_use / tool_result 对偶关系，删错容易 400。
最值得借鉴的 5 个设计
如果你在构建自己的 Agent 记忆系统，这 5 个点最值得参考（按 ROI 排序）：
- Tool result offload— 直接解决长任务上下文退化
- L1.5 任务延续判断— 提升跨轮任务连续性
- L0 证据层 / L1 抽象层分离— 提升记忆可靠性
- L2 scene blocks— 提升长期语义组织能力
- Recall stable/dynamic split— 提升 prompt 质量和缓存收益
不该照抄的
- 别整套 1:1 搬过来（太重、状态机复杂）
- 别让记忆系统承担当前 prompt 压缩职责（职责混乱）
- 别过度依赖 scene/persona 当唯一真相源（容易累积偏差）
结语：记忆系统的下一个阶段
TencentDB Agent Memory 的价值不在于“又一个记忆库”，而在于它提出了一个新的问题框架：
记忆系统不只是“存历史”，还要管理“当前上下文”。
当所有人都在做向量检索时，腾讯选择了一条更难但更完整的路：把短期压缩、中期组织、长期画像整合成一个运行时系统。
这是 AI Agent 记忆系统从“数据库”走向“运行时”的一个标志性尝试。
源码地址：Tencent/TencentDB-Agent-Memory（开源）
推荐阅读路径：
- Offload 部分：src/offload/index.ts → hooks/after-tool-call.ts → mmd-injector.ts
- 记忆流水线：src/core/tdai-core.ts → record/l1-extractor.ts → scene/scene-extractor.ts
如果你正在构建长任务 Agent，这个项目值得深入研究。
干货可以关注👇
