TencentDB Agent Memory 的 clone 地址：两套组织名只有一套能用

2026-08-16

跑通一个开源项目的第一条命令通常是 git clone。TencentDB Agent Memory 这个仓库的麻烦就出在这第一条命令上：文档里的 clone 地址有两套 GitHub 组织名，而且不是「中文文档一套、英文文档一套」这种好识别的分法——同一个 README_CN.md 文件内部就同时出现了两种写法。

下面的内容基于我们在 2026-08-16 取的快照 97f9465，分支 feat/server_team（这个仓库的默认分支就是它，不是 main 也不是 master）。全部结论来自静态阅读仓库文件，我们没有部署、也没有运行过该项目的任何一个模块。

一、两套写法分别出现在哪里

按仓库内相对路径与行号列出来（分支均为 feat/server_team）：

组织名写法	出现位置
`Tencent/TencentDB-Agent-Memory`	`README_CN.md:37`、`README.md:36`、`CHANGELOG.md:110`、`CHANGELOG.md:204`、`CONTRIBUTING_CN.md:49`
`TencentCloud/TencentDB-Agent-Memory`	`INSTALL_CN.md:19`、`ROADMAP_CN.md:8`、`ROADMAP_CN.md:94`、`ROADMAP_CN.md:103`、`README_CN.md:337-342`（贡献者与 issue 徽章）

注意最后一行：README_CN.md 第 37 行的 git clone 用的是 Tencent/，而同一个文件第 337 到 342 行的两个徽章链接指向的是 TencentCloud/。两处相隔三百行，都在同一份 README 里。

再看两份入门文档的差异。README 中文版第 36 到 42 行给的是四行上手命令：

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

INSTALL_CN.md 第 17 到 33 行是同一套流程，但 clone 地址写的是 TencentCloud/，并且在 ./start-all.sh 之前多一步 ./verify.sh。也就是说，你从 README 进和从 INSTALL 进，拿到的第一条命令是不一样的。

我们只陈述这个差异，不推断哪一处是笔误、也不去猜为什么两处没有对齐。

二、能核到的硬事实只有一条

标题那句「只有一套能 clone 到」需要先打个折扣，说清楚我们的依据边界：

我们能核到的硬事实是——2026-08-16 通过 GitHub API 实取到的仓库全名是 TencentCloud/TencentDB-Agent-Memory，本批采用的本地快照 97f9465 也是按这个全名、指定 -b feat/server_team 取下来的。至于另一套写法在你的网络环境下会不会 clone 失败，我们没有逐个验证过，本批禁止联网，也就不去替你下这个结论。

所以实用的判断规则只有一句：以 GitHub API 返回的仓库全名为准，两套写法不一致时，选 TencentCloud/ 这一套是有实读依据的，另一套没有。

顺带把这个仓库的身份口径也交代清楚，免得你按别的名字去搜：GitHub 未能自动识别其协议（API 返回 NOASSERTION），而仓库 LICENSE 文件正文第 5 行明确写的是「TencentDB Agent Memory is licensed under the MIT.」，以官方 LICENSE 原文为准。另外 README.docker.md 第 264 到 266 行的 License 小节写的是 Proprietary — Tencent Cloud，与前两处不同。

三、clone 之后要额外确认的三件事

地址对了不代表你落到了对的地方。按这个顺序确认：

第一，确认落在哪个分支上。 这个仓库的默认分支是 feat/server_team——一个 feat/ 开头的功能分支。我们在快照里执行 git branch -a 看到的是 remotes/origin/HEAD -> origin/feat/server_team。这一点的直接后果是：任何写着「main 分支上的某文件」的表述、任何按 main 拼出来的 raw 链接，在这个仓库上都对不上。用 git remote -v 与 git branch -a 各看一眼即可（这是通用 git 用法，不是该项目文档内容）。

顺便说一句，仓库里关于分支的口径同样有三套：.github/workflows/pr-ci.yml 第 4 到 5 行只在 pull_request: branches: [main] 时触发，第 155 到 157 行的 BASE_REF 兜底也是 origin/main；CONTRIBUTING_CN.md 第 61、71 到 72 行说从 master 或最新的 develop_* 切分支、PR 发到 develop_server_team 或 master；而快照的默认分支是 feat/server_team。三处互不相同，同样只陈述、不延伸。

第二，确认仓库根目录的名字。 README 的第二行命令是 cd TencentDB-Agent-Memory/deploy/global-images，仓库实际名字确实是 TencentDB-Agent-Memory。但仓库文档里对「仓库根」还有另外两种写法：CONTRIBUTING_CN.md 第 18 行把根目录写作 tdai-memory-openclaw-plugin/，deploy/panel-knowledge-combined/README.md 第 264 行写作 memory-tencentdb/。所以别照着文档里的目录名去 cd，照着你 clone 下来的实际目录名走。

第三，确认模块目录确实存在。 CONTRIBUTING_CN.md 第 20 行的结构图里列了一个 MemoryHub/ 目录；快照里 git ls-files 的顶层分布中，模块目录只有 MemoryCore、MemoryKnowledge、MemoryPanel、MemoryProxy 四个，没有 MemoryHub/。如果你按结构图去找目录找不到，不是 clone 出了问题。

第四，确认你的操作系统在文档覆盖范围内。 这一条对本站读者尤其重要。deploy/global-images/README.md 第 20 到 24 行写的环境要求是 macOS 或 Linux、Docker（Docker Desktop、colima、OrbStack 任一）、bash 4 以上，并额外注明「macOS 自带 3.2 也能跑」——这份文档没有提 Windows。三件套脚本共用的 _lib.sh 第 54 到 76 行里，find_docker() 是依次在 PATH、/opt/homebrew/Cellar/docker、/usr/local/Cellar/docker、/opt/homebrew/bin/docker、/usr/local/bin/docker 这几处找 docker 可执行文件，全都找不到就直接终止。这几个路径的形态本身也说明脚本是按哪类环境写的。我们没有在任何系统上运行过这套脚本，上面两句都是文档与脚本的原文口径，Windows 下具体会怎样，本文不下结论。

四、什么情况说明问题不出在 clone 地址上

这一步比前面几步更值钱——排除法能省下大量瞎折腾的时间：

./start-all.sh 报某个变量缺失。 三件套脚本 deploy/global-images/start-all.sh 第 21 到 27 行的 require_vars 会校验 15 个必填项，判定规则写在 _lib.sh 第 34 到 49 行：值为空或等于字面量 REPLACE_ME 即算缺失。而 .env.example 里 MEMORY_LLM_BASE_URL 等六个变量的默认值本来就是 REPLACE_ME。这是 .env 没填，与 clone 地址无关。
按 README.docker.md 的路径找不到文件。 该文档多次引用 MemoryCore/tdai-gateway.service.yaml（第 33、42、161、257 行）、MemoryCore/tdai-gateway.real.yaml（第 75、258 行）等文件，我们在快照里逐个判定，这几个路径都不存在；存在的是 MemoryCore/tdai-gateway.standalone.yaml 与 MemoryCore/tdai-gateway.yaml。这属于文档引用与快照实况的差异，不是你 clone 错了仓库。
按 npm 徽章的包名装不上。 README_CN.md 第 10 行的徽章查询的包名是 @tencentdb-agent-memory/memory-tencentdb，而 MemoryCore/package.json 的 name 是 @tencentdb-agent-memory/memory-tencentdb-v2，差一个 -v2 后缀。CHANGELOG.md 第 154 到 155 行记录了这次带 -v2 的包名迁移。同理，目录名也不等于包名：MemoryPanel 的包名是 team-memory-control，MemoryProxy 的包名是 context-proxy，写安装命令时别把目录名当包名用。

把这几条串起来看，「同一个东西在文档里有多个名字」在这个仓库里不是孤例，clone 地址只是你会撞上的第一个。遇到名字对不上时，一律回到你实际 clone 下来的仓库里去核，而不是照着某一份文档抄。

五、动手之前还要知道的两件事

一是版本口径。这个仓库的版本号有四处写法：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。另外三个模块 MemoryKnowledge、MemoryPanel、MemoryProxy 的 package.json 版本都还是 0.1.0。主模块处于 beta 阶段，参数、接口、命令随版本变动，本文写下的每一行路径与行号都以你当时拉到的快照为准。

二是数据面。这套系统会采集并存储团队的对话、文档与代码——README_CN.md 第 146 到 150 行写明 Wiki 从导入的文档生成、CodeGraph 索引导入的代码库、Chat Memory 与 Skill 从对话 Session 提取。另外 deploy/global-images/README.md 第 112 到 113 行原文提醒，三个默认凭据「只适合个人本地跑通流程」，在生产、联调或公网暴露前必须替换成随机长串。clone 只是第一步，这一层在动手前就该想清楚。

延伸阅读

从头读起：TencentDB Agent Memory 是什么：团队级 Agent 记忆中枢怎么读
本专题共 40 篇，完整分组目录见专题页
TencentDB Agent Memory 是什么协议：三处口径各写一套
TencentDB Agent Memory 有几种装法：单机、Docker 与合并镜像

本文依据 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 原文为准，本文不构成法律意见。安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。