腾讯开源了什么？一个解决 AI Agent 记忆难题的运行时系统

当所有人都在做“向量数据库 + 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，这个项目值得深入研究。

干货可以关注👇