Agent 用得越多，越能感受到一个反直觉的痛点：会话一结束，它就把项目背景忘得干干净净。下一次你得重新解释"老鉴权模块别动，移动端还在用"；它得重新把整个仓库的目录翻一遍；好不容易跑通的工作流，下次又要从零摸索。真正贵的往往不是算力，而是已经付过的"学习成本"——上下文解释过一次、文档读过一遍、流程跑通过一次，这些信息理应被存下来、组织好、复用给下一个 Agent。

本文解读腾讯云开源的 TencentDB Agent Memory（v2.0.0，2026-08-03 发布），看它如何把对话、文档、代码沉淀成四种可治理的"记忆资产"，并用 L0–L3 分层与混合检索按需注入上下文。所有数据均来自项目 README、CHANGELOG 与 GitHub API（查询日期 2026-08-06），可追溯；其中性能基准为项目自述，非本文独立复现，文中会明确标注。

它要解决的问题：Agent 的"失忆"与重复学习

项目给自己定的出发点很具体：如何减少使用 Agent 时的重复劳动。如果项目上下文已经讲过，就不该在新会话里重讲；如果文档已经读过，每个 Agent 就不必再从第一页开始；如果某条工作流已经跑通，下次就不该重新发现。它对"记忆"的定义也比"记住对话"更宽——任何能帮下一个 Agent 少走弯路的信息，都应被保存、组织、复用。

项目的核心抽象是 Memory Hub：一个面向 Agent 团队的记忆中枢，把"工作产出资产 → 资产在团队中流通 → 新成员直接读档"这一闭环串起来。定位上它强调三点：自动从对话/任务中提取资产、与 Agent 框架解耦可跨框架迁移、对冷启动友好（可导入既有文档/代码库/会话）。

先放一张可核实的事实表，便于读者判断项目状态：

维度	取值	来源
仓库	TencentCloud/TencentDB-Agent-Memory	GitHub API
最新版本	v2.0.0（2026-08-03，commit 0aff21a）	GitHub 提交历史
首次公开版本	v2.0.0-beta.1（2026-07-21）	CHANGELOG.md
仓库创建	2026-04-07	GitHub API
Star / Fork	10,367 / 993（2026-08-06 查询）	GitHub API
主语言	TypeScript	GitHub API
协议	README 标注 MIT	README 徽章
默认分支	feat/server_team	GitHub API

需要说明的一点：GitHub API 把 license 字段识别为 other（NOASSERTION），与 README 徽章标注的 MIT 不一致，这在 LICENSE 文件未被 licensee 确切解析时常见。本文采用更保守的表述"README 标注 MIT"，读者若要商用请以仓库 LICENSE 文件为准。

四种记忆资产：把经验变成可治理的对象

项目把记忆拆成四类资产，每类解决一种"重复学习"：

• Chat Memory：保留偏好、事实、决策与交互历史。每个 Agent 创建时自动拥有自己的记忆，下次不必重新自我介绍。原始对话按 L0 → L1 → L2 → L3 逐层蒸馏。
• Skill：从跑通的任务里提炼可复用 SOP。它不是一段提示词，而是带版本、资源文件、触发边界、执行步骤与验证规则的对象；个人 Skill 默认私有，审核后可共享给团队并装配给其他 Agent。
• Wiki：把产品文档、设计稿、运维手册变成带链接图谱的结构化页面（灵感来自 Karpathy 的 LLM 知识库实践）。
• CodeGraph：索引代码的符号、文件、调用关系与影响路径。Agent 改代码前能先做 impact analysis——不仅知道"代码在哪"，还知道"改这里会影响哪些地方"。

图 1：TencentDB Agent Memory 架构示意（本文依据 README 描述绘制，非官方运行时截图）。四种资产统一注册为 Memory Asset，经 Memory Hub 做 Owner/版本/状态/可见性管理，再按 Agent 负载装配。

项目用一张对比表把自身与"聊天历史"和"标准 RAG"区分开，本文转述其要点：标准 RAG 回答"能找到什么"，而 Team Memory 还要回答"谁能用、哪个版本有效、该发给哪个 Agent"。前者只做检索，后者在检索之上叠加了所有权、版本、状态与团队共享/装配。

能力	聊天历史	标准 RAG	TencentDB Agent Memory
跨会话用户理解	△	△	✅ Chat Memory
可执行的提炼经验	—	—	✅ Skill
文档结构与关系	—	△ 分块检索	✅ Wiki + 链接图谱
代码调用图与影响范围	—	△ 文本匹配	✅ CodeGraph
所有权/版本/状态	—	—	✅
团队共享与 Agent 装配	—	—	✅
私有/团队/ACL	—	△	✅

L0–L3 分层：记忆不是平铺记录，而是逐层蒸馏

记忆不做"全量平铺"，而是先以 L0 保存原始对话，再由异步流水线蒸馏成多粒度层级：

层级	存储内容	主要用途
L0 Conversation	带完整上下文的原始对话	核对原话、时间戳与来源
L1 Atom	从对话中抽取的事实、偏好、约束、事件	精确召回可执行信息
L2 Scenario	围绕项目/场景组织的知识块	快速恢复工作上下文
L3 Core / Persona	长期画像、稳定模式、高层认知	让 Agent 快速进入用户与团队语境

生成与检索都是分层的：常态下 L2/L3 提供快速上下文引导；需要具体事实时，再用 BM25 + 向量检索 + RRF 回落到 L1/L0。结果还会按条数、字符预算与超时上限截断，避免记忆撑爆上下文窗口。这个设计要点在于"按需取用"——文档与代码并不整块塞进 prompt，而是先通过 /v3/tools/list 发现能力，再用 /v3/tools/call 按需读取相关页面、源码或影响路径。

Memory Hub：把记忆做成团队控制台

Hub 的定位是"控制台而非展板"。打开一个资产时，重要的不只是"写了什么"，还有"来自哪里、是哪个版本、装配给谁、最近是否被用过"。它提供几种玩法：建 Team 并加入人员与 Agent、在资产库浏览/搜索/审核四类资产、给不同 Agent 绑定不同资产并调整优先级、在知识工坊构建 Wiki 与 CodeGraph、按需切换 private/team/ACL 访问。

可见性模型是这套设计里值得注意的一环——共享是显式动作，而非默认泄露：

可见性	语义
private	仅 Owner 可读，团队管理员也不可见
team	团队成员可读，Owner/Admin 可管理
restricted	通过 User/Role/Agent ACL 精确授权
agent	同团队内对 Agent 定向装配

角色分两层：全局 System Admin 管理用户与团队；团队级有 Admin 与 Member，负责团队内资产协作与访问控制。资产所有权由 Owner 追踪，Owner 自动拥有其资产的管理权限。这样可以把"发布 Skill"装配给发布 Agent、把"架构 Wiki"装配给所有开发 Agent、把 CodeGraph 装配给 Coder 与 Reviewer，做到"不同角色不同负载，少给噪声"。

一键部署与 SDK 调用

v2.0.0 把三件套（memory-core + memory-hub + proxy）打成多架构镜像（linux/amd64 + linux/arm64），发布到 Docker Hub 的 agentmemory 组织，公开可拉取。一键启动的命令如下（来自 README 与 CHANGELOG，请在 Bash/WSL 环境执行）：

git clone https://github.com/Tencent/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env      # 填入两组 LLM 参数（memory 组 + proxy 组）
./start-all.sh    # 一键起三件套，完成后打印一行可直接粘进 Claude 的命令

启动后面板开在 http://localhost:8125。start-all.sh 首次启动会自动 init-admin、生成形如 sk-mem-... 的 admin 密钥并落盘到 .admin-key，自检 /v3/meta/auth/verify 后输出可复制的启动命令；stop-all.sh --purge 可彻底清 volume 与 admin key 以便重置。三个镜像与职责如下：

镜像	职责
memory-core	记忆内核，资产存储与检索
memory-hub	Panel + Knowledge Service，团队控制台
memory-proxy	Claude Code 等 coding agent 接入团队记忆的通道

proxy 值得一提：它同时支持 Anthropic 与 OpenAI 双协议（/claude-code/<spaceId>/v1/messages 和 /v1/chat/completions），首轮通过 AskUserQuestion 让用户选 team/agent/task 并记住绑定，每轮把该 Agent 的 L2/L3 记忆、匹配到的 Skill、Wiki/CodeGraph 拼进 system prompt 再转发上游；鉴权用 x-tdai-user-key 换 user_id，按用户维度控制资产可见性。

官方提供两套 SDK，调用时需注意 v3 严格隔离——teamId/agentId/userId 三项必填：

import { MemoryClient, SkillClient, MetadataClient } from "@tencentdb-agent-memory/memory-sdk-ts-v2";
const memory = new MemoryClient({
endpoint, apiKey, serviceId,
teamId, agentId, userId,    // v3 严格 isolation：三项必填
});

from tencentdb_agent_memory.v3 import MemoryClient, MetadataClient, SkillClient
# pip install tencentdb-agent-memory-sdk-python

一个自述基准：PersonaMem

README 给出了一个基准 PersonaMem，测试 Agent 在长交互后能否正确理解并应用用户信息。需要强调：这是项目自述结果，并非本文独立复现，列出供参考。

图 2：PersonaMem 基准对比（数据源：项目 README Benchmark 表；图表由本文用 matplotlib 生成）。未启用 48%、启用 76%，相对提升约 59%。

该图的数据另存为 JSON 源文件（data/personamem-benchmark.json），图中数值与正文、JSON 完全一致：未启用 48、启用 76、相对提升 (76-48)/48 ≈ 59%。单组基准不足以概括全部场景，读者应把它视作"项目方选择的一个代表性指标"，而非普适结论。

限制与适用边界

诚实列几条 README Notes 中明示的限制，避免误用：

• CodeGraph 暂以公网 HTTPS 仓库为主，私有仓库与 SSH 凭据支持仍在完善。
• Wiki 与 CodeGraph 异步构建，需要等待处理到 ready 状态后才可用。
• 资产绑定目前以手动为主，全自动记忆路由仍在迭代。
• 客户端范围有限：当前支持 OpenClaw、Hermes、Claude Code、CodeBuddy 与 SDK 集成，更广的跨框架迁移在路线图上。
• 上述基准为项目自述，未由本文独立复现；star/fork 数为 2026-08-06 查询快照，会随时间变化。

结论

TencentDB Agent Memory 把"Agent 失忆"当作一个工程问题来拆：用四种资产把经验对象化，用 L0–L3 分层把记忆从平铺记录变成可检索的多粒度结构，用 Memory Hub 把记忆从"个人记事本"升级为"团队控制台"，再用 private/team/restricted/agent 的可见性模型守住共享与隐私的边界。对想给 Agent 团队加一层长期记忆的团队，它提供了一个可一键部署、有 SDK、与既有 coding agent 解耦的起点；但 CodeGraph 的私仓支持、自动路由的成熟度、客户端覆盖范围，是落地前需要逐项评估的。