4 个月 26,648★:腾讯把 Agent 记忆做成了"分层 + 资产"的工程

GitHub Explore trending 把它列在前面,GitHub 月榜解读把它放在"Agent 上下文层"那组的代表项目里,而仓库页右上角的 star 数告诉所有人——这不是又一轮"又有一个国产项目火一阵"的故事。

TencentCloud/TencentDB-Agent-Memory,截至 2026-09-14:26,648 ★、2,509 fork、TypeScript、Apache-2.0/MIT 双标(README 顶部徽章写的是 MIT,但仓库根目录的 LICENSE 文件是腾讯 2026 自有 license 文本,代码可商用、商标受限,详见后文"许可"一节)。5 月 14 日开源,4 个月前只有 4,600★,现在已经 26k+。

但和大多数"国产开源冲 star 走一波流"的项目不同,这个仓库靠的不是 README 喊口号,而是两个真正能落地的设计:把所有记忆分成 4 层(L0 对话 / L1 事实 / L2 场景 / L3 画像),把所有能用上的资产分成 4 类(Chat Memory / Skill / Wiki / CodeGraph),再用 Memory Hub 团队控制台统一管起来。

这一篇要回答你三个问题:它到底解决了什么(为什么不是又一个"摘要压缩")?它怎么用(对个人玩家和小团队,什么值得上、什么别碰)?它和我之前讲过的 DSH/Hermes 有什么关系?

一句话定位 + 为什么这个月又火了

TencentDB Agent Memory 是腾讯云数据库团队做的、本地优先(local-first)、零外部 API 依赖的 AI Agent 分层记忆引擎。一句话:

把 Agent 的记忆拆成 L0→L3 四层、把可复用资产拆成 Chat Memory / Skill / Wiki / CodeGraph 四类,跑在你自己机器或内网上,Claude Code / Codex / DSH / Hermes / OpenClaw 等 8 个主流客户端开箱即用。

为什么最近又火起来?三个时间点撞到一起:

  • 4 月底到 5 月 14 日:腾讯云数据库团队把短期记忆压缩能力做出来,5 月 14 日在 云+社区 正式发版开源,首日斩获 4,500+★(见 IT之家报道)
  • 6 月:开 v0.3.x 系列,加入 TCVDB 后端、BM25 混合检索、迁移工具;7 月发布 v2.0 beta;8 月 25 日发 v2.0.1 stable,引入 Memory Hub 团队控制台 + Proxy 统一接入层
  • 9 月 14 日(本文发稿日):star 数从 4.6k 一路涨到 26.6k,4 个月涨了 5.7 倍;GitHub Explore trending 当周把它放在第一屏,GitHub 月榜解读把它和 OpenViking、llmfit、omlx 并列 9 月"Agent 上下文层"代表项目

但数字只是结果。真正的驱动力是 Agent 玩家集体踩到的那个坑——用过 Agent 做过稍微长一点项目的人,都经历过"上下文爆掉"和"换个会话啥都忘"这两件事,而这个项目是少数同时正面回答了这两个问题的开源实现。

下面我把它的设计拆给你看。先看最厚的一节——4 层记忆到底怎么工作。

它解决了什么:不是"又一种摘要压缩"

在腾讯云官方介绍里,他们直接点名了当前主流 Agent 记忆方案的三个短板(云+社区官方文章):

  • 暴力堆上下文:把历史对话全塞进窗口,长任务里 Token 直接爆,模型注意力持续衰减
  • 传统向量数据库:只存不提炼,碎片化对话的精确召回率低,容易把"用户偏好"和"今天查的天气"混在一起同等对待
  • 摘要压缩:有损、不可逆,出问题找不到原始证据,只能让 AI 去猜

TencentDB Agent Memory 的解法是把记忆拆成 L0→L3 四层语义金字塔(完整说明见 README §Technical Implementation):

层级存什么主要用途举例
L0 Conversation原始对话全量回查原话、时间戳、来源“用户 2026-09-14 13:42 说:用 TypeScript,测试放 __tests__”
L1 Atom从对话里抽出的原子事实、偏好、约束、事件精确召回可执行信息{"fact": "user_likes_typescript", "confidence": 0.93, "source_ref": "L0-conv-7421"}
L2 Scenario按项目/场景组织的知识块(Markdown 格式,人可直接读)快速还原工作上下文“项目 X 的鉴权:旧 auth 模块别动,移动端还在用”
L3 Persona长期用户画像、团队稳定模式、宏观偏好Agent 快速进入用户/团队语境“团队偏好:TypeScript、Vitest、Conventional Commits、PR 前先跑 lint”

每一层都从下一层提炼,但L3 的一条结论可以一路回溯到 L0 那一行原话——证据链不断裂。腾讯云在评测里给出了一个具体数字(见 README §Benchmark):

  • PersonaMem:从 48% → 76%,相对提升 +59%
  • 作为 OpenClaw 插件接入后:WideSearch 任务成功率从 33% → 50%(+51.52%),Token 消耗从 221.31M → 85.64M(−61.38%);SWE-bench 成功率 58.4% → 64.2%(+9.93%),Token 减 33.09%;AA-LCR 成功率 44% → 47.5%(+7.95%),Token 减 30.98%
  • 数据 + 云+社区官方评测

观点:这套评测是腾讯云自营,不是第三方独立跑出来的。如果你打算拿这个数字做采购/上线决策,自己拿 SWE-bench 子集在 50 任务上复现一次,再决定要不要把生产流量接上去。但架构设计的回溯性(L0→L3 全链路可追)是值得肯定的设计,跟单纯的"摘要压缩 + 向量召回"是质的差别。

短期记忆这边用的是符号化压缩 + Mermaid 任务画布(Mermaid 是 GitHub/技术文档里通用的图描述语言,主流大模型天然能读写),不是把日志压成不可逆的摘要:

  • 工具返回/网页内容/日志这种冗长信息,完整写进 refs/*.md 外部文件,上下文里只留一行索引
  • 上下文里只剩一张 Mermaid 流程图,标着节点 ID、并行分支、前置依赖
  • Agent 真正需要展开时,按 node_id 一路找回原始证据

这是它和"传统 RAG + 摘要压缩"在哲学上的区别——它把"记忆"当成可导航的地图,而不是可丢弃的日志。

四类资产 + Memory Hub:把记忆从"私有杂物间"变成"团队装备库"

光有 4 层不够。腾讯云做了第二件事——把所有可复用的东西归到 4 类 Memory Asset,用 Memory Hub(http://localhost:8125 那个控制台)统一管理:

资产类型它是什么一句话价值
Chat Memory跨会话的用户偏好/事实/决策/历史下次开新会话,Agent 不用你再交底一遍
Skill可复用的"怎么干这件事"工作流(版本、资源、触发条件、校验规则)Troubleshooting、Code Review、发布检查表,全团队共用
Wiki产品文档/设计稿/运维手册 → 结构化页面 + 链接图灵感来源 Andrej Karpathy 的 LLM Wiki
CodeGraph代码符号/文件/调用关系/影响范围索引改一处之前能看清"这会影响谁",不用让 Agent 翻整仓

这 4 类在 README §Memory Assets, Not a Chat Log Warehouse 里和"聊天历史 / 标准 RAG"做了对比表,直接搬过来:

能力聊天历史标准 RAGTencentDB Agent Memory
跨会话理解用户△△✅ Chat Memory
提炼可执行经验——✅ Skill
文档结构与关系—△ Chunk 召回✅ Wiki + Link Graph
代码调用图与影响范围—△ 文本匹配✅ CodeGraph
所有权/版本/状态——✅
团队共享与 Agent 装备——✅
Private / Team / ACL—△✅

控制台能干这 5 件事(见 README §Memory Hub Is Not a Display Board):Team Up(建团队、加成员、定分享边界)、Asset Library(浏览/检索/审/管 4 类资产)、Agent Loadout(把不同资产装备给不同 Agent,设优先级和用法)、Knowledge Workshop(建 Wiki 和 CodeGraph,看处理状态和元数据)、Access Control(切 private / team / restricted 三档,撤权)。

权限分 3 档:private 只 Owner 能看(连 team admin 都不行)、team 团队成员可见 Owner/Admin 可管、restricted 走 User/Role/Agent 三层 ACL 精确授权(详见 README §One Agent Team: Shared Experience, Not Shared Privacy)。

注意:restricted 这层 ACL 设计是它和"开源圈里 90% 的 Agent 记忆项目"最大的差别——大部分项目都只到 local 和 team 两档,腾讯直接上了三层 ACL,这个对"多人小团队"和"对外接活的工作室"是实打实有用的。

怎么用起来:一条命令三件套,8 个客户端都接

实操路径是它的强项。一条 ./start-all.sh 把 memory-core + memory-hub + proxy 三个容器全起起来(完整步骤见 INSTALL.md,中文版 INSTALL_CN.md)。

部署路径(单机本地,3 个容器,4 个端口)

默认端口表(INSTALL.md 第 49 行):

服务端口干什么
Memory Core8420记忆读写、鉴权、Skill/RAG 数据面
Memory Panel UI8125团队记忆控制台(浏览器打开)
Knowledge Service8424Wiki / CodeGraph 服务
Proxy8096LLM 请求代理(同时支持 Anthropic 协议和 OpenAI 协议)

一键启动:

1
2
3
4
5
git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env       # 填两套 LLM 参数(memory 组 + proxy 组,允许复用)
./start-all.sh     # 一条命令启三件套

脚本是交互式的,会自动做这几件事(原话见 INSTALL.md 第 27-40 行):

  1. 把 .env.example 拷成 .env
  2. 让你填两套 LLM 参数(MEMORY_LLM_* 给记忆层内部用,PROXY_UPSTREAM_* 给代理转发的上游用,可以填同一套)
  3. 填完立刻探测连通性,失败会让你重填
  4. 三个容器跑起来
  5. 首次启动调 init-admin 生成 32 位 user_key 写到 ./.admin-key,并跑一次 POST /v3/meta/auth/verify 自检
  6. 自检通过后打印一段你可以直接粘到 Claude Code 用的环境变量:
1
2
3
export ANTHROPIC_BASE_URL=http://127.0.0.1:8096/claude-code/default
export ANTHROPIC_AUTH_TOKEN='sk-mem-<random 32 chars>'
claude --model <PROXY_UPSTREAM_MODEL 配的模型名>

资源提醒:3 个容器 + Proxy 转发 + Knowledge 服务,实机占内存预计 600-900 MB(参考 本站 1.6 GB 服务器实测,DSH web 110-125 MB、MongoDB 305 MB,这套起全栈会更重)。1.6 GB 的小机器别硬上,2 GB 起,4 GB 舒适。

客户端接入(8 个,INSTALL.md 表格 280-291 行)

Agent配置方法文档
Claude Code环境变量或 ~/.claude/settings.jsonagents/claude-code/
CodeBuddy~/.codebuddy/models.jsonagents/codebuddy/
WorkBuddy~/.workbuddy/models.jsonagents/workbuddy/
Codex~/.codex/config.toml(⚠️ 首轮要在 Plan mode)agents/codex/
DeepSeek Harness (DSH)~/.dsh/settings.yaml + .credentials.yamlagents/dsh/
OpenCode~/.config/opencode/opencode.jsonagents/opencode/
Hermes~/.hermes/config.yaml + header preselectagents/hermes/
OpenClaw~/.openclaw/openclaw.json + header preselectagents/openclaw/
其他通用 header 预选agents/README.md

DSH 和 Hermes 的接入路径详细说,和我们之前在 《DSH + Hermes 工作流》 和 《DSH 项目部署》 里写的本地链路是直接对得上的——这意味着如果你已经在用 DSH 做 Agent 编排,装这一套几乎只是改一个 ANTHROPIC_BASE_URL + ANTHROPIC_AUTH_TOKEN 的事。

Proxy 转发管线有 4 步:auth(验 user_key)→ sessionInit(交互式选 Team/Agent/Task)→ injection(把 L2/L3 记忆 + Skill + Knowledge 混进 system prompt)→ forward(转发给上游 LLM)。PROXY_FULL_STACK=0 可以只留转发、关掉记忆注入(见 INSTALL.md 293 行)。

第一次跑会发生什么(以 Claude Code 为例,INSTALL.md §Step 4)

每个新 CC 会话,Proxy 会用 Claude Code 原生的 AskUserQuestion 工具让你三连选:

┌─────────────────────────────────────────────────┐
│  1. Please pick the Team for this session:     │
│     ○ Team A                                    │
│     ○ Team B                                    │
│                                                 │
│  2. Please pick an Agent under Team A:         │
│     ○ bug-fix engineer                          │
│     ○ frontend reviewer                         │
│                                                 │
│  3. Optionally pick a Task:                     │
│     ○ Fix login XSS                             │
│     ○ [Skip task binding]                       │
└─────────────────────────────────────────────────┘

选完后,Proxy 把这次会话绑到那个 team/agent/task,后续每一轮自动注入 L2/L3 记忆 + Skill + Knowledge 进 system prompt;L0 原始对话进 SQLite;后台 worker 跑 L1→L2→L3 异步抽取。

注意:你每次开新 CC 会话都要走一次三连选;同一 claude 进程内的多轮不会重复问。这对"我只想随手开一个会话玩玩"是阻力,但对"团队里分工明确"是好事。

关键设计:不是"塞上下文",是"按需召回 + Agent 装备"

它和"普通 RAG 记忆"最不一样的地方,藏在 README §Technical Implementation 的 3 个原则里:

  1. 记忆不是平铺记录,是分层的:日常 L2/L3 撑起快速上下文,需要精确事实时 BM25 + 向量 + RRF 召回回退到 L1/L0,再用 item count / 字符预算 / 超时三重限制卡住,不让记忆"撑爆窗口"
  2. 记忆不是全局 prompt,是 Agent 的装备:Chat Memory/Skill/Wiki/CodeGraph 统一注册为 Memory Asset,Hub 用固定绑定 + ACL 决定哪些 Agent 能用哪些资产(先按 Team/User/Agent/visibility 卡权限,再按当前 query 召回)——换 Agent 或换框架只需要换装备,不需要重训
  3. 知识不是全量塞入,是按需调用:Wiki 是可检索页面 + 链接图,CodeGraph 是符号/文件/调用关系索引,Agent 通过 /v3/tools/list 发现能力,通过 /v3/tools/call 按需读页面/读源码/分析影响范围。文档和代码是"可调用的工具",不是"system prompt 里常驻的一段"

第三条是它和"另一种常见的’记忆项目’——直接把 RAG 文档当 system prompt 塞"——的根本差别。塞 system prompt 的方案在长任务里一定会把窗口吃光,按需调用的不会。

和同类的对比:它处在哪一档

GitHub 月榜解读里把它和 OpenViking、llmfit、omlx、MTPLX、MemoryBank 等并列为 9 月"Agent 上下文层"代表(见 博客园《2026 年 9 月 GitHub 月榜深度解读》)。我从个人玩家视角给个简化对比:

项目偏向部署难度上手成本适合谁
TencentDB Agent Memory(本文主角)团队记忆 + Wiki + CodeGraph + ACL中(Docker 三件套)中(要走三连选)1 人公司 / 工作室 / 小团队
OpenViking(火山引擎)个人 Agent 长期记忆,自带 4-5 倍压缩中中个人 Agent 玩家
MemoryBank(硅基智能)聊天记忆 + 主动遗忘机制低低个人聊天助手类
Letta / MemGPT经典学术派,内生记忆管理中高(要写代码)研究/重度定制
直接把 RAG 接进 system prompt任何 RAG 库都行低低短任务 / 一次性脚本

它和 OpenViking 关系最近(都做分层记忆,腾讯云官方评测里那个"输入 token 降 34-91%、记忆准确率从 24-57% 提到 80-83%“的数据指的就是 OpenViking 的对比;见月榜解读)。差别在于腾讯这套额外做了 Wiki + CodeGraph + Memory Hub 团队控制台 + 8 客户端适配,边界更宽、运维面更广。OpenViking 走"更轻、更个人"路线。

它和"塞 system prompt"那类方案是代差关系——前者按需召回,后者全量灌入,长任务里差距会指数级拉大。

我的判断:什么人现在就该上、什么人再等等、什么人别碰

按规则要给"具体到角色"的建议:

现在就该上的人

  • 1 人公司 / 3-5 人小工作室 / 接活的开发者:Memory Hub 的 Team/Agent/Task 三层结构 + Skill 资产库,就是给这种规模设计的。第 0 天让新 Agent 加载团队积累的 Skill,比让他读 100 份历史对话快 10 倍。
  • 已经在用 Claude Code / DSH / Hermes / OpenClaw 做长任务的人:接 Proxy 的成本是改 2 个环境变量,但回报是 WideSearch 类任务 +51% 成功率、−61% Token(官方评测,自己复测再下结论)。对靠 Token 计费的人,这 61% 是真金白银。
  • 想"用别人的经验"但不想"被别人的数据训练"的人:它完全本地优先(README description 第一句:fully local long-term memory via 4-tier progressive pipeline, with zero external API dependencies),云端功能是可选的,不是强绑。

再等等的人

  • 只用 Claude/GPT 网页聊天,没接 API 也没用 Claude Code 的人:这套是给"Agent 框架用户"做的,不是给"网页聊天用户"做的。等官方出更轻的"网页聊天旁挂记忆"方案再说。
  • 单机 1.6 GB 小服务器玩家:三件套起全栈预估 700-900 MB,会和你现有的 DSH/Ollama/Forgejo 抢内存(参考 《1.6 GB 服务器能跑什么》 实测数据)。2 GB 起,4 GB 舒适。
  • CodeGraph 想覆盖私有仓库的人:CodeGraph 目前优先公开 HTTPS 仓库,私有仓库和 SSH 凭证支持仍在迭代(见 README §Notes 第 2 条)。

别碰的人

  • 生产环境流量大的 SaaS 团队:它还不是 1.0 通用标准,Memory Hub 全自动记忆路由还在迭代(README §Notes 第 3 条),要先做"内部小流量试点"再考虑上生产
  • 需要 SOC2 / ISO27001 / GDPR 合规审计的人:开源版没有公开的安全审计报告(腾讯云商业版有 SLA,但那不是这个仓库),合规清单要先和法务过
  • 对腾讯系生态有强戒心的人:即使代码是 MIT/Apache-2.0(见下一节"许可"争议),Memory Hub 默认配置走腾讯自家 MEMORY_LLM_BASE_URL 默认值,介意数据出境/出云的自己改 .env 指到自己的模型

许可说明(容易踩的坑)

这是必须如实讲清楚的一节——项目自己前后矛盾,读者不要被 README 顶部的徽章带跑偏:

  • README 顶部徽章:[![License: MIT](https://img.shields.io/badge/License-MIT-green.svg)](./LICENSE),看着是 MIT
  • 仓库根目录 LICENSE 文件:开头是 Tencent is pleased to support the open source community by making TencentDB Agent Memory available. ... TencentDB Agent Memory is licensed under the MIT.(LICENSE 全文 这里)
  • GitHub API 返回:NOASSERTION(因 GitHub 没法自动识别这种"开头是声明,正文其实是 MIT"的格式)

实操结论:这是一个 MIT 协议的项目,商用、修改、闭源分发、再授权都可以。腾讯那种"声明 + MIT"是它多个开源仓库的固定格式,业内有共识属于 MIT 范畴(可对照 Tencent/TencentDB-Agent-Memory 主仓的 LICENSE)。

如果你要做法律合规,以 LICENSE 文件全文为准,不要只信徽章。如果你拿不准,直接问你的法务。

Roadmap 和接下来要看什么

ROADMAP.md(中文 ROADMAP_CN.md)和 README 提到的下一步:

  • v2.0.1(8 月 25 日已发,本文撰写时 GitHub latest release tag)——Memory Hub 团队控制台 + Proxy 统一接入 + Wiki/CodeGraph 异步构建稳定化
  • 下一站 v2.0.2 方向(ROADMAP 提到的):零配置冷启动(目前首次启动要填两套 LLM 参数)、Wiki 生成加速、用户/团队自定义 prompt、Skill 导出、Codex IDE Plan mode 支持

要持续盯的 3 个变化:

  1. CodeGraph 对私有仓库/SSH 凭证的支持(目前卡在这,直接决定它能不能进"企业代码库"场景)
  2. 全自动记忆路由(目前 Memory Hub 还是手动装备,全自动还在迭代)
  3. 第三方独立评测(腾讯云自营评测虽然数据漂亮,但要等 SWE-bench / DSEval 上有独立团队复现才能下"值不值"的硬结论)

一句话总结

4 个月从 4.6k 涨到 26.6k 颗星,不是因为营销,是因为它正面回答了 Agent 玩家集体踩到的两个最疼的问题——“上下文爆了"和"换个会话啥都忘”——而且把它做成了带 ACL 的团队装备,不是个人杂物间。

对个人玩家:用 DSH/Hermes/Claude Code 做长任务,接 Proxy 改 2 个环境变量,Token 立省 30-60%、成功率 +7%~52%。值。

对 1 人公司和小团队:Memory Hub 的 Team/Agent/Task + Skill 资产库 + Wiki + CodeGraph,就是给"3-5 个人也想有组织资产"的人做的。必看,先小流量试点。

对 1.6 GB 小服务器玩家:这玩意别上,内存会爆。等 2 GB 以上再考虑。


顺带一提:给 Agent 搭记忆库这类服务,自己一台小机器就能起步——1.6GB 服务器跑 Hugo + Caddy + DSH 实测清单是同款配置的实录。

本文由拾光札记编辑部整理,勘误请联系我们。

互链提示:同主题前文(本站 AI 与效率分类)可对照阅读: