TencentDB Agent Memory 源码解读
feat/server_team，不是 main；
主模块处于 beta、另外三个模块版本号还是 0.1.0，路线图上仍有大量未完成项，
所以文中的路径、字段与默认值都带时效。
第三，这个项目会采集并存储团队的对话、文档与代码，属于敏感数据，
是否使用请结合自身合规要求评估。
另外它的协议口径有两层：GitHub 未能自动识别（显示 NOASSERTION），仓库 LICENSE 正文自述为 MIT，
以官方 LICENSE 原文为准。核对日 2026-08-16，对应仓库快照 97f9465。
本专题共 40 篇。内容依据
官方仓库 feat/server_team 分支上的 README、INSTALL、CHANGELOG、ROADMAP
与四个模块的源码整理。文中出现的阈值与默认值均为源码中的默认配置，
不构成对实际运行结果的保证。
TencentDB Agent Memory 是什么：团队级 Agent 记忆中枢怎么读
TencentDB Agent Memory 的默认分支不是 main 而是 feat/server_team。本文按 2026-08-16 的仓库快照，梳理它自述要解决的问题、四类记忆资产在代码里的确切标识、L0 到 L3 分层的落点，以及版本号、可见性枚举与开源协议表述在文档和源码之间对不上的几处地方，帮你在动手之前先看清这个仓库当下的状态。
认识、协议与部署
这个仓库的默认分支是 feat/server_team，贴 raw 链接前先看清这一点。协议在三处各说一套：LICENSE 正文写 MIT、Docker 文档写 Proprietary、GitHub 显示 NOASSERTION。这一组还包括文档里两套 clone 组织名、同一个服务在模块内与部署目录下的两个端口号，以及六个文档引用了却不在快照里的部署文件。
TencentDB Agent Memory 是什么协议：三处口径各写一套
TencentDB Agent Memory 的协议表述有四处：LICENSE 第 5 行写 MIT，README 徽章与页脚也写 MIT，README.docker.md 写 Proprietary，GitHub 侧显示 NOASSERTION。本文逐处标出文件与行号，给出自行核对的三个动作，只陈述差异不推断原因。
TencentDB Agent Memory 的 clone 地址：两套组织名只有一套能用
TencentDB Agent Memory 的文档里，git clone 用的组织名有 Tencent 和 TencentCloud 两套写法，同一个 README_CN.md 内就同时出现两者。本文列出两套写法各在哪一行，给出 GitHub API 实取的仓库全名，并说明 clone 之后还要确认哪几件事。
TencentDB Agent Memory 有几种装法：单机、Docker 与合并镜像
TencentDB Agent Memory 仓库里并存七条安装与部署路径，从一键三件套脚本到单模块源码启动、合并镜像自建、插件与 SDK 安装，各自的容器数、端口与外部依赖都不一样。本文按仓库快照逐条摆开，标出目录名与包名的差别、端口在两套形态下的取值差异，以及文档与脚本口径对不上的几处。
TencentDB Agent Memory 端口对不上：模块写 8421，部署写 8424
TencentDB Agent Memory 的知识服务有两个端口数字：MemoryKnowledge 模块内写 8421，仓库根 INSTALL.md 与 deploy 部署路径写 8424。本文列清两组数字各自出现在哪些文件、怎么判定你走的是哪条部署路径，以及端口一改必须跟着改的两处。
TencentDB Agent Memory 的镜像用户：Dockerfile 里没有 USER 指令
TencentDB Agent Memory 的 README.docker.md 写镜像运行用户是 tdai (uid 10001)，而 MemoryCore/Dockerfile 里没有 USER 指令。本文给出核对这处差异的动作、仓库里唯一带 USER 的 Dockerfile 在哪，以及什么情况说明不是这一处。
TencentDB Agent Memory 文档引用的部署文件：六处在快照里对不上
TencentDB Agent Memory 的部署文档引用了若干配置模板、compose 与 K8s 清单，我们在 feat/server_team 分支的 97f9465 快照里逐个判定，发现这些路径不在仓库中。本文给出六条引用的出处与仓库实况、照文档做会卡在哪一步、可执行的自查命令，以及哪些故障并非文件缺失引起。
四类记忆资产与分层模型
Chat Memory、Skill、LLM-Wiki、Code-Graph 各自是什么，L0 到 L3 在代码里对应什么。这一组最值钱的一条是：README 通篇在讲的 Loadout 在源码里 0 处命中，实现叫 agent-fixed-asset；同类还有资产类型枚举的三套拼写、可见性与角色比文档多出来的取值，以及三处 JSDoc 注释与代码实际默认值全对不上。
TencentDB Agent Memory 的四类记忆资产各是什么
TencentDB Agent Memory 把「记忆」拆成四类资产。本文顺着仓库 feat/server_team 分支上的枚举定义、ID 前缀、绑定表与只读工具清单，逐类说清它在 README 里怎么写、在代码里叫什么名字、创建时被写死了哪些字段，以及四类资产在文档与源码之间对不上的几处拼写差异。
TencentDB Agent Memory 的 L0 到 L3：分层记忆在代码里对应什么
TencentDB Agent Memory 的 README 用一张四行表讲 L0 到 L3 分层记忆，但这四层在源码里并不对称。本文沿 feat/server_team 分支的路由层、存储类型层、落盘层与调度层各走一遍，把概念名对到具体文件、类型与默认值，并照实列出文档与代码对不上的几处。
TencentDB Agent Memory 的 Loadout：源码里它叫 agent-fixed-asset
TencentDB Agent Memory 的 README 里有「Agent Loadout」这个说法，但全仓 grep 这个词，源码一处都不命中。本文在 feat/server_team 分支上把它对应到 meta_agent_fixed_assets 表与四条 agent-fixed-asset 路由。
TencentDB Agent Memory 的资产类型枚举：源码四值、契约三值
在 TencentDB Agent Memory 的 feat/server_team 分支上，「资产类型」这个看似只有一个答案的字段，实际存在三套不同的字面量：metadata 层四值含 chat_memory，网关生成契约三值，知识层则用横杠写法。本文逐处标出它们各自的文件位置与取值，并给出自己动手核对的方法。
TencentDB Agent Memory 的权限：README 4 种可见性，代码有 5 种
TencentDB Agent Memory 的 README 用一张表列了四种资产可见性、团队角色写两种，而 feat/server_team 分支的源码枚举里可见性是五个、角色是三个。本文标出这两处差异的确切文件与行号，多出来的 task 与 reviewer 各落在哪条判定分支上，以及你自己去仓库核对的五个步骤。
TencentDB Agent Memory 的 config.ts：三处注释默认值与代码不符
TencentDB Agent Memory 的 MemoryCore/src/config.ts 同一个文件里，接口定义上的 JSDoc 注释写了一组默认值，下方读取配置的代码用 ?? 兜底又写了另一组。本文逐条给出这三处差异的字段名、两个数值与各自行号，说明怎样自己在仓库里核一遍，以及哪些字段其实是对得上的。
TencentDB Agent Memory 的 Benchmark 自述：能引用到什么程度
TencentDB Agent Memory 的 README 里只有一张 Benchmark 表、一行数据。这篇把原表照抄出来，说明它写了什么、没写什么，并把仓库里其它「自述数字」分成可核与不可核两类做对照，最后给出引用这类数字时该带上的四层限定。核对日 2026-08-16。
MemoryCore：全仓最大的模块
对外形态到底是什么——全模块搜不到一处 mcp，只有 HTTP 网关、插件 API 与 CLI。这一组拆网关路由的 v1/v2/v3 分层、两份 gateway 配置的逐字段差异、三份 SKILL 文档，以及一处值得留意的落差：文档说非回环绑定必须配 API Key，代码只打了一条 warn 就放行。
TencentDB Agent Memory 怎么接入：没有 MCP，只有 HTTP 网关与 CLI
TencentDB Agent Memory 的 MemoryCore 里检索 mcp 命中 0 条。本文沿 feat/server_team 分支摊开它对外的三种形态：8420 端口的 HTTP Gateway 路由表、插件 API 的三个工具两个钩子、描述写三条只实现一条的 CLI，并记录几处文档与代码差异。
TencentDB Agent Memory 的网关路由全景：v1 / v2 / v3 各管什么
MemoryCore 网关同时挂着 v1、v2、v3 三套前缀，路由表还分散在四五个文件里。本文按 feat/server_team 分支上的源码逐段摊开：v1 的七条扁平端点、v2 与 v3 共用的十八条数据面子路径、五十五条元数据接口，以及两代鉴权头与隔离三元组的差别，并照实记下源码注释与实际条数对不上的几处。
TencentDB Agent Memory 的两份 gateway 配置逐字段对照
TencentDB Agent Memory 的 MemoryCore 目录里并排放着两份 Gateway 配置模板，一份 165 行、一份 97 行。本文把它们逐字段摆在一起，说清哪些字段完全相同、哪几段只存在于其中一份、以及默认值在 yaml 与 schema 之间对不上的那一处，帮你改配置前分清手里拿的是哪份。
TencentDB Agent Memory 非回环绑定：文档要求配 key，代码只 warn
TencentDB Agent Memory 的 README 把 TDAI_GATEWAY_API_KEY 标成非回环绑定必填，但 feat/server_team 分支的源码里只有一条启动告警，没有拒绝启动的分支。本文按行号摆出文档、yaml、插件 schema 与代码四层口径，并给出可在仓库副本里执行的核对步骤。
TencentDB Agent Memory 的三份 SKILL 文档，与那个不存在的脚本
TencentDB Agent Memory 的 MemoryCore 下并排放着三份 SKILL 文档，分管安装验收、旧包迁移与诊断导出。本文按 feat/server_team 分支 97f9465 快照逐份摘出其门槛值与规则，并记录诊断文档要执行的导出脚本在仓库里找不到，以及包名、数据目录与默认值多处不一致。
TencentDB Agent Memory 插件侧：3 个 tool、2 个 hook 与注册入口
MemoryCore 也以插件形式装进 OpenClaw 宿主。本文沿 feat/server_team 分支上的 index.ts 核对它注册了什么：三处 registerTool、两处 api.on、registerCli 与 registerContextEngine，以及同仓第二套插件的 id 差异。
TencentDB Agent Memory 的测试现状：npm test 没有任何目标
在 TencentDB Agent Memory 的 feat/server_team 分支快照上，MemoryCore、MemoryPanel 与 sdk 三处的 test 脚本与 vitest include 模式都在，匹配到的测试文件却是零。本文给出三处行号、可自行复核的判定动作，以及真正存在的 E2E 脚本。
MemoryProxy：请求经过它时发生了什么
它拦下请求、注入内容再转发。要注意 README 说注入的标签与代码实际产出的标签不是同一个，调的接口也不是同一个；「四级自动降级」的说法与源码里对某一档直接 FATAL 也对不上。这一组还包括 package.json 与 /health 返回的两个版本号，以及一个被 tsconfig 和六个源文件引用、目录却不存在的包。
TencentDB Agent Memory 的 MemoryProxy：一条请求经过它发生了什么
顺着 TencentDB Agent Memory 仓库 feat/server_team 分支的 MemoryProxy 源码，看一条 LLM 请求从 8096 端口到上游都经过什么：两道 marker 门控、路径归一化五步、14 条白名单、比 README 多出的五个阶段、九个注入点与三类超时口径。
TencentDB Agent Memory 注入的标签：README 与代码产出的不是同一个
TencentDB Agent Memory 的 MemoryProxy 里，README 写注入块叫 <cloud_skills>，injector 源码自述的是 <available_skills>；配置注释写 GET /v3/skill/search，实现用 POST。本文给出两处差异的文件行号及真正产出的标签。
TencentDB Agent Memory 的四级降级：源码里有一档直接 FATAL
TencentDB Agent Memory 的 MemoryProxy 里，README 与示例配置都写存储后端有一条四档自动降级链，源码却在 cos 这一档装配失败时打 FATAL 日志并直接抛错，同一份示例配置前后两处说法也不同。本文标出差异落在哪个文件的哪几行，给出回仓库自查的顺序与可验证的健康检查字段。
TencentDB Agent Memory 的 MemoryProxy 版本：0.1.0 还是 0.2.0
TencentDB Agent Memory 的 MemoryProxy 模块里，版本号三处给出两个值：包清单写 0.1.0，健康检查接口返回写死的 0.2.0，README 示例响应也是 0.2.0。本文按仓库快照标出这三处位置，讲清 /health 还返回了什么，以及该拿什么当版本锚点。
TencentDB Agent Memory 被引用的 cost-guard 目录并不存在
TencentDB Agent Memory 的 MemoryProxy 里，tsconfig 与 vitest 都配了 packages/cost-guard 别名，源码也把它当模块名，而 feat/server_team 快照里没有这个目录。本文摊开涉及的文件、代码自带的缺失处置，及其与 cos 后端的关系。
TencentDB Agent Memory 的 MemoryProxy 配置：哪些字段真的会读
对照 TencentDB Agent Memory 的 MemoryProxy 模块在 feat/server_team 分支上的示例配置与代码内建默认值，逐段梳理配置的三层优先级、两层取值不一致的字段、只被代码读取却没有写进示例的隐藏配置段，以及示例里明确标注为当前不生效的死字段，并给出三个可自己动手核对的检索动作。
MemoryKnowledge：知识服务与数据层
仓库挂着 vector-search 标签，但这个模块里 embed 与 vector 命中 0 处——真正的检索是 SQLite FTS5 加 bm25 权重再做 wikilink 图扩展。这一组还包括 OpenAPI 自称 28 个端点而代码注册了 37 条、三处都写「4 张表」而实际建了 5 张，以及同一张表在 schema 与建表 SQL 里的两套定义。
TencentDB Agent Memory 有向量检索吗：embed 与 vector 命中 0 处
TencentDB Agent Memory 的 topics 挂着 embedding 与 vector-search，但 MemoryKnowledge 模块里搜这两个词命中为 0。本文标明差异的两处位置，并沿源码走一遍该模块在用的检索路径：FTS5 加 BM25 排序与 wikilink 图扩展。
TencentDB Agent Memory 的检索实现：FTS5 加 bm25 再做图扩展
TencentDB Agent Memory 的 topics 标着 vector-search，但 MemoryKnowledge 里搜 embed、vector 命中 0 处。本文沿 wiki 检索路径走一遍：index.db 三张表分工、bm25 两个权重取值多少、wikilink 多跳扩展的默认值写在哪一行。
TencentDB Agent Memory 的 OpenAPI：自称 28 个端点，代码 37 条
TencentDB Agent Memory 的 MemoryKnowledge 模块里，openapi.yaml 描述原文写着「Provides 28 endpoints」，paths 下也确实是 28 条；而代码在 /v3 前缀下注册了 37 条。本文列清两处位置、差在哪九条，并给出自己复核的可执行动作。
TencentDB Agent Memory 三处都写 4 张表，实际建了 5 张
TencentDB Agent Memory 的 MemoryKnowledge 模块有三处写着「4 张表」，而 schema 定义与运行时建表 SQL 都是 5 张。本文按 feat/server_team 分支快照标出三处位置，说清第五张 llm_binding 存什么、字段在两层有何差异，以及怎么自己核一遍。
TencentDB Agent Memory 的 llm_binding 表：schema 与建表 SQL 两套
TencentDB Agent Memory 的 MemoryKnowledge 里，llm_binding 有两处定义：Drizzle schema 没有 model 列，运行时建表 SQL 里却有。本文按 feat/server_team 分支快照标出这两处位置与差异，并梳理同链路上另外几处两层口径。
TencentDB Agent Memory 的构建产物名：三处写法不一致
TencentDB Agent Memory 的 MemoryKnowledge 模块，启动入口指向的构建产物文件名在多处写法不同：包描述与 bin 脚本写 dist/server.js，容器入口脚本写 dist/server.mjs，合并镜像脚本两种都试。本文逐处标出文件与行号，并给出自己去核对的动作。
面板、治理与 SDK
面板能做哪些操作、隐私边界落在哪一行代码上。这一组会看到几处仍在演进的痕迹：代码自述「schema 还没落真字段，演示阶段先塞进 metadata」、同一份前端里 admin 权限有两组相反的注释、定义好的两个路由守卫在八条路由上一处都没接线，以及面板、SDK 与 OpenAPI 三边对不上的操作条数。
TencentDB Agent Memory 的接口条数：面板 55、SDK 54、OpenAPI 54
TencentDB Agent Memory 的 meta action 条数三处对不上：MemoryPanel 的 META_ACTIONS 是 55 条，两侧 SDK 写 54 条，OpenAPI 契约 55 条 path 里 54 条 POST。本文交代三个数各出自哪个文件、怎么数的，差的那条是什么。
TencentDB Agent Memory 的两个 SDK 与路线图上的五项
TencentDB Agent Memory 的两个 SDK，元数据里的包名比自家 README 的安装命令多一个 -v2 后缀。本文按仓库快照逐行核对 Python 与 TypeScript 两侧的包名、版本、依赖与文档覆盖面，并摊开 ROADMAP_CN.md 里那五项计划中的条目，只陈述差异并标明每一处出处。
TencentDB Agent Memory 的两个路由守卫：八条路由一处没接线
TencentDB Agent Memory 的 MemoryPanel 定义了 ResourceGuard 与 MemberManageGuard 两个路由守卫，但 routes/index.tsx 的八条子路由一条都没包上。本文摆出两者的定义位置、唯一生效的菜单角色过滤与几处不一致注释，并给出复核动作。
TencentDB Agent Memory 的数据模型：代码自述还在演示阶段
TencentDB Agent Memory 的 MemoryPanel 里，Agent「借入记忆」的关系没有独立数据库字段，代码注释自述后端 schema 还没落 chat_memory_rel 真字段，演示阶段先塞进 Agent.metadata_json。本文沿这段注释把同类临时落点逐个列出，并给出核对动作。
TencentDB Agent Memory 的隐私边界：那个三选一的读取授权判定
TencentDB Agent Memory 讲「共享经验，不共享隐私」，落到代码上是 MemoryPanel 的 authorizeChatMemoryRead。本文沿 feat/server_team 分支读这个三选一读判定、两个复用点、写删为何只认 Owner，以及可见性枚举在代码与 README 间的差异。
TencentDB Agent Memory 面板：admin 权限有两组完全相反的注释
TencentDB Agent Memory 的 MemoryPanel 前端里，关于「全局 admin 有没有特权」有两组相反的注释：一组写 admin 拥有所有权限，另一组写 admin 不再有全局特权。本文列出两组注释的文件与行号，对照 canManageAsset 等实现代码，并给出自己去仓库核对的动作。
TencentDB Agent Memory 面板能做哪些操作：从路由与菜单反推
MemoryPanel 到底能做哪些操作？本文按前端路由表、菜单常量、前端 API 调用面、后端端点注册四层，对照 TencentDB Agent Memory 仓库 feat/server_team 分支的源码，把「文档宣称的」与「代码里真注册了的」分开摆，并标出明写演示阶段、暂未开放、尚未稳定支持的位置。
想让 Agent 真正记住团队的经验？
从记忆、上下文到多智能体协作，站内有成体系的 Agent 工程学习路线。