TencentDB Agent Memory 是什么：团队级 Agent 记忆中枢怎么读

2026-08-16

克隆这个仓库时，第一个需要留意的不是它的功能，而是分支。截至 2026-08-16，GitHub API 返回 TencentCloud/TencentDB-Agent-Memory 的默认分支是 feat/server_team——不是 main，也不是 master。这意味着你在网上看到的任何一条指向该仓库 main 分支的 raw 链接、任何一句「main 分支上的某文件」的描述，路径都对不上。本文引用的所有文件路径，都在 feat/server_team 分支的快照 97f9465 上。

同一天取到的仓库元数据还有：star 22,233、fork 2,038、open issues 607，建仓时间 2026-04-07，最后一次 push 是 2026-08-15。这些数字随时在变，也说明不了质量，只作为你阅读本文时的时间坐标。

它自述要解决的问题

README_CN.md:79 的开篇设问原文是：「我们从一个很实际的问题出发：怎样减少使用 Agent 时的重复工作？」紧接着 :81 把这句话拆成三种具体的重复：「项目背景讲过了，不该换个 Session 再讲。文档读过了，不该每个 Agent 从第一页重读。一套做法已经跑通，不该下次再摸索一遍。」

于是它给自己划的边界写在 README_CN.md:83：「所以这里的 Memory 不只是”记住对话”。凡是能让下一个 Agent 少走弯路的信息，都应该被保存、组织并复用。」:85-87 给出的链路示意是：已有信息 → 可复用记忆资产 → 更少 Turns → 更少返工 → 更稳定的结果和更高的效率。

README.docker.md:3 另有一句更技术化的定位：「AI Agent 长期记忆服务，为任意 Agent 框架提供四层渐进式记忆能力（L0 对话 → L1 原子记忆 → L2 场景归纳 → L3 用户画像）」。

理解这个项目的关键，是它把「记忆」当作有归属、有版本、有状态、需要被分配的资产来管，而不是当作一个可检索的历史库。README_CN.md:194 把这层差别写得很直白：「RAG 解决”能查到什么”。Team Memory 还要解决”谁可以用、哪个版本有效、应该给哪个 Agent”。」同一小节还有一张三列对比表（聊天历史 / 普通 RAG / 本项目），那是项目方自述的对比，我们没有做任何验证。

四类资产：README 里的名字，与代码里的标识

README 反复出现的四个词是 Chat Memory、Skill、Wiki、CodeGraph。落到代码里，MemoryCore/src/metadata/types.ts:24 的类型定义是：

export type AssetType = "skill" | "llm_wiki" | "code_graph" | "chat_memory";

同样四个值的 Zod 枚举在 MemoryCore/src/metadata/router/v3-meta-schemas.ts:11。资产 ID 的前缀也各有出处：skl- 加 12 字符 base62（MemoryCore/src/core/skill/skill-core.ts:232-235）、wiki- 与 cg- 各加 8 位 base36（MemoryKnowledge/src/store/ids.ts:17-18），Chat Memory 则是拼出来的 chat_memory-{team_id}-{agent_id}（MemoryCore/src/metadata/utils/chat-memory-asset.ts:6）。

这里有一处值得先记下的差异：知识类资产在资产层写作 llm_wiki / code_graph（下划线），在知识层写作 wiki / code-graph（横杠，见 MemoryCore/src/core/store/types.ts:453 与 MemoryKnowledge/src/routes/tools.ts:191），而 README 正文统一写 Wiki 与 CodeGraph（README_CN.md:119、:123）。三处拼写不同，以你实际调用的那一层为准。

另外，由 kubb 生成的网关契约 MemoryCore/src/gateway/generated/types.ts:98-102 的 assetTypeEnum 只有 skill / llm_wiki / code_graph 三个值，没有 chat_memory；schemas.ts:46 同为三值。两处枚举一个四值一个三值，我们只陈述这个差异，不推断哪边覆盖哪边。

L0 到 L3 的分层落在哪里

README_CN.md:99-101 给的链路是「L0 Conversation → L1 Atom → L2 Scenario → L3 Persona，从原始对话逐层沉淀」。这套编号在源码里不是概念口号，能一层层找到落点：

路由层：MemoryCore/src/gateway/v2-router.ts:6-9 的文件头注释直接列出四层与动词；同文件 :153-172 的 V3_ALLOWED_SUBPATHS 是 18 条（conversation 5 / atomic 5 / scenario 5 / core 3）。
存储类型层：L0 是 L0Record（core/store/types.ts:141），L1 有一整组 L1* 类型（:56 起），而 L2 与 L3 在存储层是同一个类型 ProfileRecord（:266），靠 type: "l2" | "l3" 区分（:269）。
文件落盘层：core/storage/types.ts:250-282 的 StoragePaths 把 L3 落成 persona.md、L2 落成 scene_blocks/ 下的单文件、L0 与 L1 各自落成按日期切的 .jsonl。

在 2026-08-16 的这份快照上，我们按正则 \bL[0-3]\b 统计过 MemoryCore/src 下的 272 个 TypeScript 文件，其中 115 个文件出现该词元，出现次数 L0 331、L1 806、L2 431、L3 365。这个分层不是文档里的装饰。

顺带一提，MemoryCore/src/core/prompts/persona-generation.ts:69 里还写了另一套「四层深度扫描」（Layer 1 基础锚点 / Layer 2 兴趣图谱 / Layer 3 交互协议 / Layer 4 认知内核），编号也是 1 到 4。这套 Layer 与 README 的 L0-L3 是两套不同的编号，读代码时别混。

「Loadout」这个词只在文档里

README 用「Agent Loadout」描述给不同 Agent 配装不同记忆（README_CN.md:212、:259-263）。我们全仓不区分大小写检索 loadout，命中的只有 4 个 Markdown 文件、共 11 处（README.md 4 处、README_CN.md 3 处、ROADMAP.md 2 处、CHANGELOG.md 2 处），源码里 0 处。

代码侧对应的命名是 agent-fixed-asset：表叫 meta_agent_fixed_assets（MemoryCore/src/metadata/store/sqlite-adapter.ts:252-261），列含 injection_mode（默认 'summary'）与 priority（默认 50），路由是 /v3/meta/agent-fixed-asset/set / /list / /list-with-detail / /summary-by-agents 四条（v3-meta-router.ts:264-273）。搜文档词去翻源码是搜不到的，这一点先记住能省不少时间。

权限模型：README 的表比代码少一格

这是本仓库里最容易踩的一类差异，两处都在权限上：

可见性：README_CN.md:230-235 的表列了 4 个值——private / team / restricted / agent；MemoryCore/src/metadata/types.ts:25 的 AssetVisibility 是 5 个，多一个 task，且 permission-checker.ts:102-107 有专门分支。CHANGELOG.md:82-83 的说法同样没有 task。
团队角色：README_CN.md:136 写「分为 Admin 和 Member」两种；types.ts:18 的 TeamRole 是 "admin" | "member" | "reviewer" 三种。而默认权限是硬编码的两档（permission-checker.ts:37-38）：ADMIN_ACTIONS = ["read", "write", "assign", "share"]、MEMBER_ACTIONS = ["read"]，判定处写的是 membership.role === "admin" ? ADMIN_ACTIONS : MEMBER_ACTIONS（:117），即只分 admin 与非 admin。Permission 枚举本身有 6 个值，delete 与 use 不在任何一档默认权限里。

还有一处并列陈述、不做解释的差异：README :233 说 restricted 是「通过 User / Role / Agent ACL 精确授权」，而 permission-checker.ts:166-169 的 canBindAsset 对 task 与 restricted 一律返回 false。一个讲读权限，一个讲能否固定绑定到 Agent，两处口径就摆在这里。

版本号有四处写法

出处	写的版本
`CHANGELOG.md:12` 最新条目	`2.0.1-beta.1` — 2026-08-13
`ROADMAP_CN.md:5`	当前版本 v2.0.1-beta.1
`README_CN.md:299`	当前版本 v2.0.0
`MemoryCore/package.json`	`2.0.0-beta.1`

同仓另外三个模块的 package.json 版本都还是 0.1.0：MemoryKnowledge（包名 @tencentdb-agent-memory/knowledge-service）、MemoryPanel（包名 team-memory-control）、MemoryProxy（包名 context-proxy）。注意目录名不等于包名，写安装命令时别把 MemoryPanel 当包名。

顺着说一句协议。仓库 LICENSE:5 原文是「TencentDB Agent Memory is licensed under the MIT.」，README 徽章与页脚也写 MIT；但 GitHub 侧未能自动识别，返回的是 NOASSERTION；而 README.docker.md:264-266 的 License 小节原文写的是 Proprietary — Tencent Cloud。同一仓库里这三处表述并存，我们只陈述这个事实。

它现在还没做到的部分

README_CN.md:25 顶部横幅原文是「最新： Team Memory Beta 版本正在快速迭代，简单安装就能玩」。配合 ROADMAP 与「注意事项」看，几处限制是写在文档里的：

ROADMAP_CN.md 列的下个版本 5 项——Agent 模版、mem: 指令扩展到 Task 维度、L1–L3 记忆可编辑、L0/L1 记忆搜索、Cursor 支持——均未实现，且 :7 明写「路线图列出的是团队正在推进的工作，不是承诺」。其中记忆可编辑一项原文承认现状是「目前面板只能查看和删除，无法修正」。
已发布的 mem: 指令只有三个：mem:sync / mem:create-skill [提示词] / mem:help。
CodeGraph 目前只支持公开 HTTPS 仓库，MemoryKnowledge/src/source-fetcher/git-fetcher.ts:58-61 的错误串原文是「first version only supports public HTTPS repos; SSH/private repo support coming soon」。
README :283 说「全自动记忆路由仍在迭代」——我们没有在仓库里定位到叫「自动路由」的开关或模块，只找到人工绑定那四条路由，这里照实记为未核实到对应实现。

至于 README 里那一行 Benchmark（PersonaMem：无本项目 48%、启用后 76%、相对提升 +59%，README_CN.md:271-275），需要一起写清楚的是：README 没有给评测脚本、模型、样本量与日期，我们在仓库里也没有找到任何 PersonaMem 相关的脚本或结果文件。这是项目方自述的评测结果，评测方法以官方说明为准，我们没有复现过。

动手之前先知道的两件事

第一，部署形态是容器化的三件套。deploy/global-images/README.md:9-11 给的组件是 memory-core（容器 tdai-memory-core，宿主机端口 8420）、memory-hub（tdai-memory-hub，8125 / 8424）、proxy（tdai-proxy，8096）。该文档自述的环境要求是 macOS / Linux 加 Docker 与 bash 4+（:20-24），文档里没有提 Windows——Windows 上要怎么走，仓库没给说法，得你自己评估。同一份文档 :112-113 还有一句提醒：三个默认凭据「只适合个人本地跑通流程。生产/联调/公网暴露前必须替换成随机长串，否则任何拿到端口的人都能拿到 system_admin 权限」。

第二，这套系统采集并存储的是团队的对话、文档与代码：Wiki 由导入的文档生成，CodeGraph 索引导入的代码库，Chat Memory 与 Skill 从对话 Session 提取（README_CN.md:146-150）；Proxy 的接入方式是把 coding agent 的 API base URL 指向它，由它转发到上游 LLM 并注入记忆（README_CN.md:56）。这些都属于敏感数据，是否引入需要结合你自己的合规要求判断。

最后提醒一句范围：上面所有版本号、端口、字段名与默认值，都取自 2026-08-16 的快照 97f9465。主模块仍标 beta、另外三个模块还在 0.1.0，接口与配置随版本变动，动手前请以仓库最新内容为准。

本专题全部 40 篇

下面这份目录与专题页一致，按主题分组；每篇都是独立的，可以只挑你现在要用的那几篇看。

认识、协议与部署

四类记忆资产与分层模型

MemoryCore：全仓最大的模块

MemoryProxy：请求经过它时发生了什么

MemoryKnowledge：知识服务与数据层

面板、治理与 SDK

本文依据 TencentDB Agent Memory 官方仓库（github.com/TencentCloud/TencentDB-Agent-Memory） feat/server_team 分支上的 README、INSTALL、CHANGELOG、ROADMAP 与四个模块的源码整理，核对日 2026-08-16，对应仓库快照 97f9465。该仓库的默认分支即为 feat/server_team。本文内容为仓库源码与文档口径，我们没有部署、也没有运行过该项目的任何一个模块，因此不涉及运行效果、检索质量与性能的任何描述。该项目主模块处于 beta 阶段、其余模块版本号仍为 0.1.0，参数与接口随版本变动，请以仓库最新内容为准。该项目会采集并存储团队的对话、文档与代码，属于敏感数据，是否使用请结合自身合规要求评估。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。