据腾讯 GitHub 仓库显示,腾讯近期开源了一款 AI Agent 记忆引擎 TencentDB Agent Memory,主打"短期符号化 + 长期分层"双轨架构,采用 MIT 许可证,完全本地部署,零外部 API 依赖。该项目最新一轮 release 与 OpenClaw、Hermes 两大主流 Agent 框架的官方插件同步上线,目前活跃 commit 节奏在 5 天内,处于早期高频迭代阶段。
一、TencentDB Agent Memory 是什么:不是又一个 Mem0 复刻
当前 AI Agent 记忆赛道已经有 Mem0、Zep/Graphiti、Letta(原 MemGPT)、LangMem 等多家方案,基本路线是"切片 + 向量入库 + 召回"。TencentDB Agent Memory 给出的是一条结构不同的路径,其官方架构定义为两大支柱:
符号化短期记忆(Symbolic Short-Term Memory):把 Agent 在长任务中产生的工具调用日志、搜索结果、错误堆栈这些大体积中间产物从主上下文中"卸载"出去,只在上下文中保留一张极简的 Mermaid 任务画布。Agent 平时只读这张画布,出错时再沿着 node_id 下钻到底层。底层是原始 refs/*.md,中层是 jsonl 步骤摘要,上层是 Mermaid 符号——三层之间双向可追溯。
分层长期记忆(Layered Long-Term Memory):打破传统记忆系统的"扁平向量堆",建立四层语义金字塔——
- L1 Atom:结构化原子事实(用户偏好、工作流约定、术语定义等)
- L2 Scenario:场景块(以 Markdown 形式存放,人类与 Agent 都可读)
- L3 Persona:用户画像(集中存放在 persona.md)
平时 Agent 调用 L3 Persona 把握用户整体偏好,需要考证细节时再下钻到 L1 Atom 或 L0 Conversation。每一层都不是不可逆的暴力摘要——这是它与多数现有记忆系统的关键架构分歧。
二、性能数据:OpenClaw 集成下的三项硬指标
GitHub README 公开的 benchmark 数据,均基于与 OpenClaw 集成 + SWE-bench 连续 50 任务/会话的测试场景:
- Pass rate(任务成功率)相对提升 51.52%
- PersonaMem 准确率从 48% 提升至 76%
需要注意,这些数字的测试条件是"连续长任务、模拟真实世界长时程 Agent 的上下文累积压力",不是单轮对话或孤立任务的数据。Token 压缩的主要贡献来自符号化短期记忆——把冗长的工具日志压成 Mermaid 节点,这一项在长任务中本身就是 token 大头。
三、技术细节:依赖、部署与可追溯性
从 package.json 与脚本目录可见的工程实现细节:
- 向量层用 sqlite-vec(0.1.7-alpha.2),不依赖外部向量数据库
- Embedding 接口走 @ai-sdk/openai 兼容协议,可对接任意 OpenAI 兼容端点
- 默认数据根目录 ~/.memory-tencentdb/,可通过 MEMORY_TENCENTDB_ROOT 环境变量覆盖
- 安装方式:npm install @tencentdb-agent-memory/memory-tencentdb,装完跑 memory-tencentdb-ctl.sh 初始化
可追溯性是该项目刻意强调的设计点。多数向量记忆系统调试时只能看到一串相似度分数,无法判断召回错在哪。TencentDB Agent Memory 把所有中间产物存为可读文件:L2 Scenario 是 Markdown、L3 Persona 是 persona.md、短期任务画布是 Mermaid——调试链路明确为 Persona → Scenario → Atom → Conversation,人类与 Agent 都能逐层定位。
四、与 Mem0 / Zep / Letta 的差异对比
把它放进 Agent 记忆赛道的同行序列里:
Mem0:主流向量记忆方案,扁平存储,优势是接入简单、社区活跃。TencentDB Agent Memory 的差异在于强制分层 + 符号化短期压缩,牺牲了一定接入便捷性,换来 token 效率和可调试性。
Zep / Graphiti:走"时序知识图谱"路线,把记忆建成图。TencentDB Agent Memory 走金字塔不走图,可读性更强(Markdown/Mermaid 直接打开),但表达关系网络的能力弱一些。
Letta(原 MemGPT):经典的"OS-style memory hierarchy",理念最接近。区别在 Letta 把记忆作为框架内核的一部分,TencentDB Agent Memory 是插件形态,可挂载到 OpenClaw 与 Hermes 等宿主框架上。
LangMem:LangChain 系记忆方案,绑定 LangGraph 生态。TencentDB Agent Memory 通过 HostAdapter / LLMRunner 抽象层做到宿主无关,适配器模式更宽松。
简而言之,TencentDB Agent Memory 在四个常见技术权衡上明确选了一边:结构化 > 扁平、符号 > 纯向量、可读 > 黑盒、插件 > 内核。
五、上手:OpenClaw 与 Hermes 集成路径
OpenClaw 用户安装最直接,有专门的 OpenClaw 插件 tdai-memory-openclaw-plugin,默认目录 ~/.memory-tencentdb/tdai-memory-openclaw-plugin。该插件需要 OpenClaw v2026.4.7 及以上版本,旧版本通过 extraSystemPrompt 兼容回退。 Hermes 用户走 Gateway 模式,通过 memory_tencentdb Hermes Plugin 独立运行,Gateway 零配置自动发现——也就是 Hermes Agent 启动后,Memory Gateway 会被自动识别接入,无需手动指定地址端口。release 中提到的 Dockerfile.hermes 把 Hermes Agent + memory_tencentdb 插件 + TDAI Memory Gateway 打包成单容器镜像,统一通过 MODEL_* 环境变量驱动,适合追求"开箱即用"的场景。 六、局限与待观察
第一,benchmark 单一。目前公开的所有数据都基于 OpenClaw + SWE-bench 场景,在其他 Agent 框架(LangGraph、CrewAI、AutoGen)与其他任务类型(客服对话、写作助手、数据分析)下的提升幅度,需要社区独立复现。
第二,Node.js 单语言绑定。engines.node >=22.16.0 意味着 Python 系 Agent 项目(占当前开源 Agent 项目主流)需要通过 Gateway HTTP 方式接入,不如同语言原生集成方便。Python SDK 暂未在仓库中出现。
第三,长期记忆抽取依赖 LLM 调用。L1 Atom 的提取需要大模型完成结构化抽取,这部分调用频率、成本与延迟,在大规模部署时是真实开销,README 未公开抽取链路的 token 消耗数据。
第四,中文分词依赖固定方案。@node-rs/jieba 是合理选择,但对方言、行业术语、混合中英文场景的召回准确率仍需测试。
第五,早期版本仍在快速迭代。release 记录显示项目处于 0.4.x 阶段,5 天内有多次 schema 兼容性 patch(如 OpenClaw 2026.4.23 Zod schema 修复)。生产环境部署需要做好跟随升级的准备。
第六,benchmark 复现门槛。PersonaMem 48%→76% 的提升幅度可观,但要让外部团队复现这个数字,需要明确的测试集划分、prompt、Agent 框架配置——README 目前给出的复现说明粒度还有提升空间。
七、给谁用,什么场景值得试
适合的场景:
- 跑长任务的 Agent(代码助手、深度研究、SWE-bench 类多步任务)——核心收益在 token 压缩与上下文不溢出
- 已经用 OpenClaw 或 Hermes 的开发者——有官方插件,接入成本最低
- 对调试可追溯性要求高的团队——Markdown / Mermaid 可读产物的价值会显著
- 数据敏感场景——完全本地部署、零外部 API 依赖、MIT 许可
不太适合的场景:
- 短轮对话为主的 Chatbot——分层金字塔的收益不明显
- Python-only 技术栈且不想引入 Node 运行时
- 已经深度绑定 LangGraph + LangMem 的项目——迁移成本高于收益
仓库地址:https://github.com/Tencent/TencentDB-Agent-Memory,英文 README、中文 README、CONTRIBUTING 三份文档齐全,issue 区已开放贡献。