TencentDB Agent Memory 开源，为AI Agent带来分层记忆引擎，解决“AI失忆”痛点。
核心内容：
1. 传统AI记忆方案（堆叠上下文）的三大弊端
2. TencentDB Agent Memory 的分层记忆与符号压缩核心解法
3. 项目的开源背景与实际价值

发现大部分用 Agent 做过项目的人，都经历过这种情况。

花了半天把项目背景给 Agent 交代清楚。比如技术栈用到 TypeScript、测试文件放在 __tests__ 目录，还有写好避坑指南、代码注释保持简短等等。

说完这些之后，一开始 Agent 配合得很好，任务也能很快完成。但当我们新打开一个会话时，便会发现，说过的内容全忘了，又得重新交代。

这种每次重新反复的交流，其实都是在浪费人机协作产生的经验价值。

那些踩过的坑、确认过的偏好、跑通过的流程，本可以沉淀下来，却因会话结束而凭空消失。

随着 Agent 在越来越多的真实项目中应用，AI 频繁出现失忆的情况，变成了实实在在的工时消耗。

这也是为什么，近两年大家都在一直激烈的讨论 Context Engineering（上下文工程）。

答案就是，给模型提供什么样的信息、结构，在这件事本身上，正变得和模型能力一样的重要。

另外 AI 的记忆层，也正在从可选插件，变成 Agent 架构里绕不过去的基础组件。

就在这背景下，腾讯云数据库团队开源了一套面向 AI Agent 的分层记忆引擎： TencentDB Agent Memory。

开源不久，便斩获了 4500+ Star。其核心目标只有一个：不是让 AI 存下所有东西，而是让人不必重复跟 AI 交代所有事情。

GitHub：https://github.com/Tencent/TencentDB-Agent-Memory/

下面带大家一起来看下，这个项目到底能帮我们解决什么问题，以及背后的技术原理是什么。

狂塞上下文，对话越来越乱以前面对 Agent 失忆的情况，大家最简单的做法，可能是把历史对话全部塞进上下文，让 Agent 每次都能看到完整的过去信息。

不得不说，这种解决方式对短对话确实管用。如果在长线复杂的任务里，就会暴露出三个问题：

1. 跨会话断裂：历史的对话不跨会话保留，就等于没有了记忆；

2. 事实与偏好混淆：比如「我喜欢用 TypeScript」 和 「帮我查一下天气」，两条信息的方向完全不同；

3. 上下文膨胀：任务越长，历史记录越多，Token 消耗成本越大，模型注意力也会持续衰减。

既然这种暴力堆历史内容的方式不行，于是就有人提出了长上下文压缩，然而再次被打脸。

传统的摘要压缩是有损的，压缩之后无法还原，出了问题找不到根因，同样也只能让 AI 去猜。

记忆分层，对话更清晰于是 TencentDB Agent Memory 提供的解法是：给长期记忆建立层级，给短期记忆引入符号压缩。

长期记忆：四层语义金字塔

以往大多数记忆方案会把对话切成片段，再扔进向量数据库，让所有信息平铺在同一层。

比如「你喜欢用 TypeScript」和「你昨天问了天气」这两句话，在向量数据库里地位是相同的。

在信息召回时，AI 只能靠相似度来碰运气，没有一个宏观结构的引导。

所以，这次 TencentDB Agent Memory 换了一个思路，采用 分层蒸馏，而不是平铺堆积。

简单来说，就是先让模型提取出有用的事实，再归纳成场景，最终浓缩成用户画像。

这四层结构从下往上依次是：

L0 全量保留原始对话；

L1 自动提取原子事实（代码偏好、踩坑记录、工作约定）；

L2 按场景聚类成记忆块；

L3 持续蒸馏出稳定的用户画像。

Agent 会先从 L3 画像获取方向，当需要更多细节时就会逐层往下钻。也就是说，上层给的是方向，下层留的是证据。

这样做还有一个好处，当出了问题，可以沿着 L3→L2→L1→L0 这条链路追溯。

短期记忆：Mermaid 符号画布

此外 Agent 在执行长任务，调用工具产生的中间输出，比如搜索结果、代码日志、报错信息等内容。

这种信息叠加起来动辄几万 Token，如果全部堆在对话上下文，很快就会撑爆上下文长度。

为了解决这个问题，TencentDB Agent Memory 采用了 Mermaid 做符号压缩。

这种方式，既能让 LLM 精确解析，也能给人阅读。而不像 JSON 结构那样，读起来很费劲，若是纯文本摘要，又容易丢失结构。

TencentDB Agent Memory 具体做法是，把工具调用的详细输出保存到外部文件refs/*.md。

对于上下文只保留一张 Mermaid 任务状态图，每个节点有 node_id，需要细节时可以根据节点 ID 从文件中直接定位读取。

这样做的好处就是：既能保证原文不丢，结构可查，也能阻止 Token 的线性增长。

真正价值，不止于节省 Token在我看来，以上给出的解法得到的价值还远远不够，先跟大家说三个开发者值得关注的地方。

从项目结构上看，所有记忆中间产物都以可读文件存在本地 ~/.openclaw/memory-tdai/，L3 是 persona.md，L2 是 Markdown，L1 是原始事实列表内容。

以前大部分记忆系统出了问题，只从查看向量分数来猜测原因，而用 TencentDB Agent Memory 可以沿 L3→L0 一路追溯，对生产环境意味着有非常强的可维护性。

试想下，当打开 persona.md 文件，就能直接查看到 Agent 把你记成了什么样的人。

对于这个项目而言，代码本身也是一份非常值得学习的设计文档。

分层记忆、符号压缩、异构存储都有清晰、完整的架构，对想自建类似系统的开发者来说，可以快速上手读源码学习研究。

另外数据默认存放在本地 SQLite，不依赖任何外部 API，对企业用户或数据隐私敏感场景也非常友好。

在数据测试方面，以连续长任务会话为例，在 SWE-bench 上每个会话连续跑 50 个任务。

WideSearch 显示 Token 消耗降低 61.38%，成功率提升 51.52%；PersonaMem 长期记忆准确率从 48% 升到 76%。

不仅 Token 消耗大幅降低了，而且长期记忆的准确率也得到了明显的提升。

接入很简单，不只限于龙虾接下来，再说下如何使用，项目提供了三种接入方式，接入非常简单。

如果我们正使用 OpenClaw，可作为OpenClaw 插件安装，只需两行命令，无需配置，直接开箱即用：

openclaw plugins install @tencentdb-agent-memory/memory-tencentdbopenclaw gateway restart

对于 Hermes Agent，可使用 Docker  快速部署，支持任何兼容 OpenAI 接口的模型。

另外，最新开源版本 1.0.0-beta.1 还提供独立服务模式，可从嵌入式插件，升级为独立可部署的 Memory 服务。

并且提供完整 HTTP v2 RESTful API，直接用 TypeScript SDK 或 Python SDK 即可快速开始。

有了这些接入方式，不管我们用什么 Agent 框架，只要可以发送 HTTP 请求，都能快速接入，让模型的长期记忆层变成通用基础设施。

写在最后Agent 失忆不只是使用体验上的的问题，还在不断浪费每一次人机协作所产生的经验价值。

近半年，模型能力的增长已在逐步放缓，下一个真正的差异化，将不在模型参数量，而在经验的积累。

当我们和 Agent 协作的时间越长，它就越懂我们的代码风格、踩过的坑，以及惯用的解决方案。

在我看来，这些完全都是属于我们自己的数字资产，不会因为更换或升级了模型而消失。

现在腾讯云数据库团队，将记忆层这套基础设施开源了，个人开发者也能轻松建立自己的经验壁垒。

更让人能从重复交代、重复踩坑的消耗里解放出来，把更多的精力真正放在判断和创造力上。