TencentDB Agent Memory 是什么协议：三处口径各写一套

2026-08-16

判断一个仓库是什么协议，最省事的做法是瞄一眼 GitHub 仓库页侧栏那一行。TencentCloud/TencentDB-Agent-Memory 这个仓库上，那一行不太好用——截至 2026-08-16 我们通过 GitHub API 取到的 license 字段是 NOASSERTION，也就是没能被自动识别出来。

于是只能进仓库里翻。翻完发现，同一份快照里关于协议的表述不止一处，而且几处写的不是同一句话。这篇就把这几处摆出来，标明各自在哪个文件的哪一行，剩下的交给你自己判断。

本文对应的快照是 97f9465，分支 feat/server_team——这个仓库的默认分支就是 feat/server_team，不是 main 也不是 master。下面每一处引用的行号都以这个快照为准。

先摆结论：四处位置，三种说法

位置	写的是什么
`LICENSE` 第 5 行	`TencentDB Agent Memory is licensed under the MIT.`
`README_CN.md:11` 徽章 / `README_CN.md:373` 页脚 / `CONTRIBUTING_CN.md:145`	MIT
`README.docker.md:264-266` 的 `## License` 小节	`Proprietary — Tencent Cloud`
GitHub API 的 `license` 字段（2026-08-16 取）	`NOASSERTION`

四处放在一起看，前两行是一致的，第三行与前两行不一致，第四行是「未能识别」。这就是全部事实，下面逐层展开各自的原文长什么样。

第一层：`LICENSE` 文件正文

这是唯一一份把协议全文写出来的文件。我们逐行读过，结构是这样的：

第 1 行：Tencent is pleased to support the open source community by making TencentDB Agent Memory available.
第 3 行：Copyright (C) 2026 Tencent. All rights reserved.
第 5 行：TencentDB Agent Memory is licensed under the MIT.
第 8 行起：Terms of the MIT:，后面接标准 MIT 正文，一直到第 27 行

顺带记一个容易在统计上打架的细节：这个文件共 1341 字节，含 26 个换行符，末尾没有换行符。所以按 splitlines() 数是 27 行，按「换行符个数」数是 26 行。两种口径都不算错，只是数出来的数不一样——引用行数时最好说清用的是哪一种。核对命令是现成的：

python -c "d=open('LICENSE','rb').read(); print(len(d), d.count(b'\n'), len(d.decode('utf-8').splitlines()), d.endswith(b'\n'))"

输出是 1341 26 27 False。

第二层：README 的徽章、页脚与贡献指南

这一层有三处，彼此一致：

README_CN.md:11 挂的是 [![License: MIT]...](./LICENSE) 徽章，链接指向仓库内的 ./LICENSE
README_CN.md:373 页脚写 [MIT](./LICENSE) © TencentDB Agent Memory Team，英文版同位置在 README.md:371
CONTRIBUTING_CN.md:145 写「提交贡献即表示你同意你的代码将在 MIT License 下许可」

注意这一层的三处都是文档里的表述：徽章是 README_CN.md 第 11 行的一行 Markdown 标记，链接指向仓库内的 ./LICENSE；页脚与贡献指南那两处同样是文档正文里的一句话。所以它们和 LICENSE 正文一致，只能说明这几处写的是同一句话，不构成额外的证据。

第三层：`README.docker.md` 里的 `Proprietary — Tencent Cloud`

README.docker.md 是仓库根目录下的一份文档，共 266 行 / 9540 字节，第 3 行给的是这个项目的另一句独立定位：「AI Agent 长期记忆服务，为任意 Agent 框架提供四层渐进式记忆能力（L0 对话 → L1 原子记忆 → L2 场景归纳 → L3 用户画像）」。

这份文档的末尾也有一个 ## License 小节，位置在第 264 到 266 行，小节正文只有一行：

Proprietary — Tencent Cloud

到这里就停。这两处不一致是客观存在的差异，我们只陈述差异、标明位置，不去推断哪一处「才是对的」、也不推断为什么会这样。 需要给出结论的场合，请以官方 LICENSE 原文为准，或者直接向项目方求证。

第四层：GitHub 侧的 `NOASSERTION`

GitHub 对仓库协议的识别是自动做的，识别不出来时 API 就返回 NOASSERTION。我们 2026-08-16 取到的就是这个值。同一天取到的其它元数据里，star / fork / open issues 是 22,233 / 2,038 / 607，建仓时间是 2026-04-07，最后 push 是 2026-08-15。这类数字变动很快，请以仓库当前显示为准；它们带着时间锚点才有意义，而且和协议是不是被识别出来是两件互不相干的事，不要互相解释。

NOASSERTION 这个值本身只说明一件事：自动识别没有给出结论。它既不等于「没有开源协议」，也不等于「协议有问题」。所以引用这个仓库的协议时，正确的写法是两层一起写——GitHub 未能自动识别其协议，仓库 LICENSE 文件正文自述为 MIT，以官方 LICENSE 原文为准。只写「MIT 协议」是把第四层丢了，只写「没有开源协议」则是把第一层丢了。

想自己核一遍：三个动作

第一，读 LICENSE 文件本身，别停在徽章上。徽章只是 README 里的一行标记，LICENSE 才是把协议正文写出来的那份文件。README_CN.md:37 给的 clone 命令原文是：

git clone https://github.com/Tencent/TencentDB-Agent-Memory.git

clone 下来之后直接打开根目录的 LICENSE，看第 5 行和第 8 行往下的正文。

第二，把仓库里所有 ## License 小节都找出来，不要只看根 README。这个仓库的差异恰好就出现在一份子文档里。可以按文件名先扫一遍根目录的 .md：根目录下这几份文档的行数分别是 README_CN.md 373 行、README.md 371 行、INSTALL_CN.md 760 行、INSTALL.md 827 行、README.docker.md 266 行、README.deployment.md 607 行、CHANGELOG.md 237 行、ROADMAP_CN.md 108 行、ROADMAP.md 119 行、CONTRIBUTING_CN.md 150 行、CONTRIBUTING.md 153 行。量不大，逐份翻 License 小节是可行的。

第三，看 GitHub 侧的 license 字段，并把它和文件正文分开记。两者不一致时，如实记两层，而不是挑一层写。

顺带一个容易连带踩的坑：分支

上面 clone 命令里还藏着另一件事。README_CN.md:37、README.md:36、CHANGELOG.md:110,204、CONTRIBUTING_CN.md:49 写的组织名是 Tencent/TencentDB-Agent-Memory；而 INSTALL_CN.md:19、ROADMAP_CN.md:8,94,103 以及 README 的贡献者/issue 徽章（README_CN.md:337-342）写的是 TencentCloud/TencentDB-Agent-Memory。我们 2026-08-16 通过 GitHub API 实取到的仓库全名是后者。这同样只是「两处写法不同」的记录，不做进一步推断。

再一个：这个仓库的默认分支是 feat/server_team。这意味着你贴 raw 文件链接、或者写「main 分支上的某某文件」的时候，路径大概率是错的。本文所有行号引用都写明了分支，就是这个原因。

这不是孤例

同一份快照里，还有几处类似性质的「两处写法不同」：CHANGELOG.md:12 的最新条目是 2.0.1-beta.1，ROADMAP_CN.md:5 写当前版本 v2.0.1-beta.1，README_CN.md:299 写当前版本 v2.0.0，而 MemoryCore/package.json 里的 version 是 2.0.0-beta.1；README 的 npm 徽章查询的包名是 @tencentdb-agent-memory/memory-tencentdb，而 MemoryCore/package.json 的 name 带 -v2 后缀。这些各自另有专门篇目在讲，这里只说明一点：在这个仓库里，「文档写了什么」和「文件里是什么」需要分别核一遍，这是一个通用习惯，不是针对某一处的判断。

顺带交代该项目的版本状态：主模块 MemoryCore 的 package.json 版本是 2.0.0-beta.1，其余三个模块 MemoryKnowledge / MemoryPanel / MemoryProxy 的 package.json 版本都还是 0.1.0；README_CN.md:25 原文写「Team Memory Beta 版本正在快速迭代」。协议表述、路径、参数都可能随版本变动，本文的每一处引用都只对 97f9465 这个快照负责。

最后：我们对这类观察的纪律

写这种「不一致」的东西很容易滑向两个坑：一是替项目方解释「大概是忘了同步」，二是把差异当成质量判据。这两件我们都不做。能写的只有三件事：差异是什么、两处分别在哪个文件的哪一行、以及你自己怎么去核。

至于协议到底意味着什么、能不能商用、二次分发有什么条件——本文不解读，也不该由一篇第三方文章来解读。请以官方 LICENSE 原文为准，必要时找法务。

延伸阅读

从头读起：TencentDB Agent Memory 是什么：团队级 Agent 记忆中枢怎么读
本专题共 40 篇，完整分组目录见专题页
TencentDB Agent Memory 的 clone 地址：两套组织名只有一套能用
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 原文为准，本文不构成法律意见。