TencentDB Agent Memory 怎么接入：没有 MCP，只有 HTTP 网关与 CLI

2026-08-16

翻一个 2026 年新做的 Agent 记忆项目，我下意识会先找它的 MCP server 在哪——毕竟现在客户端接外部能力，第一反应就是问一句「有 MCP 吗」。

TencentCloud/TencentDB-Agent-Memory 这个仓库里，MemoryCore/ 目录给出的答案是：没有。

先说检索口径，这样你能自己复现

截至 2026-08-16，我们取的是该仓 feat/server_team 分支（这也是它的默认分支，不是 main 也不是 master）的快照 97f9465。在 MemoryCore/ 全目录内对 \bmcp\b 做大小写不敏感检索，覆盖 .ts、.json、.md、.yaml 四类文件，命中 0 条。也就是说，这个目录里既没有 MCP server 的实现，也没有任何一份文档提到过它。

需要先把范围说清楚：标题里的「全模块」指的是 MemoryCore/ 这一个模块目录。该仓另有 MemoryKnowledge/、MemoryPanel/、MemoryProxy/ 三个模块目录，不在这次核对范围内，我们没有对它们做同样的检索，所以不要把结论扩大到整仓。

顺带交代一下这个目录的体量，好让你知道 0 条命中是在多大范围里数出来的：截至 2026-08-16，我们按 os.walk 逐文件统计，MemoryCore/ 下共 347 个文件、69 个目录，其中 .ts 文件 300 个、95,923 行。这不是一个几千行的小模块。

那它对外到底长什么样

三种形态，一个一个看。

一、HTTP Gateway：主要形态

README.md:29 的架构图里写的是 MemoryCore Gateway :8420，README.md:44 写 Listens on 127.0.0.1:8420 by default。代码侧 src/gateway/server.ts:13 的注释原文是「Built with Node.js native http module — no Express/Fastify dependency.」——连 Web 框架都没引。

路由分了好几段，散在不同文件的路由表里：

路由段	条数	定义位置
v1（`/health` `/recall` `/capture` 等）	7	`src/gateway/server.ts:1046`、`1055-1069`
v2/v3 数据面	18	`src/gateway/v2-router.ts:414-431`
`@deprecated` 的 v2 实体路由	16	`src/gateway/v2-router.ts:451-466`
`/v3/skill/*`	17	`src/gateway/skill-handlers.ts:1138-1157`
`/v3/meta/*`	55	`src/metadata/router/v3-meta-router.ts:84-315`
`/v3/memory-prompt/*`	7	`src/gateway/memory-prompt-handlers.ts:290-296`
`/v3/knowledge/*`	5	`src/gateway/knowledge-handlers.ts:149-153`
`/v2/offload/*`	3	`src/offload_server/router.ts:57`/`66`/`77`

数据面那 18 条是 DATAPLANE_HANDLERS 里的子路径：/conversation/{add,query,search,delete,count}、/atomic/{update,query,search,delete,count}、/scenario/{ls,read,write,rm,count}、/core/{read,write,count}。挂载规则写在 v2-router.ts:436-441：以 /count 结尾的只挂 /v3，其余同时挂 /v2 与 /v3。方法上也有约束（v2-router.ts:498-505）：默认只接受 POST，只有 5 个 memory-prompt / memory-generation-log 的读接口允许 GET。

表外还散着几条零碎路由，接入时最容易漏：/v3/memory-generation-log/{list,get} 两条（src/gateway/memory-generation-log-handlers.ts:72-73）、/v3/chat-memory/clear 一条（src/gateway/chat-memory-handlers.ts:472）、/v2/pipeline/status（v2-router.ts:468），以及实例销毁的 /v2/instance/destroy 与 /v3/instance/destroy（server.ts:848、:859）。

这张表读起来最该注意的是它的形状：/v3/meta/* 一段就有 55 条，是数据面的三倍，管的是 user / user-key / team / team-member / agent / task / asset / acl 这些实体。换句话说，你要用它，绕不开先把「谁在什么团队里、用哪个 agent、访问哪些资产」这套元数据建起来。

二、OpenClaw 插件 API：进程内那条路

MemoryCore/index.ts（1,034 行）里对宿主 API 的调用点很好数：api.registerTool(...) 三处（index.ts:379、466、619）、api.on("before_prompt_build", ...)（:681）、api.on("agent_end", ...)（:808）、api.registerCli(...)（:160 与 :1017）。另外 src/offload-client/index.ts:66 还调了 api.registerContextEngine("memory-tencentdb", () => engine)。

三个工具的名字在 openclaw.plugin.json:10 的 contracts.tools 里声明：tdai_memory_search、tdai_conversation_search、tdai_read_cos。

注意这条通路和 HTTP 那条不是一回事：它是在宿主进程里注册工具和 hook，靠的是宿主自己的插件协议。package.json:139-152 的 openclaw 段把门槛写得很死——compat.pluginApi: >=2026.3.13、compat.minGatewayVersion: >=2026.3.13，peerDependencies 里 openclaw >=2026.3.7（标了 optional: true）。也就是说这条路只对特定宿主开放。

三、CLI：描述里写了三条，实现了一条

index.ts:164 注册的子命令空间描述原文是 memory-tdai plugin commands (seed, query, stats)。但 src/cli/index.ts:54-60 里只调了 registerSeedCommand(program, ctx)，紧跟着 :58-59 是两行注释：// Future: registerQueryCommand(program, ctx); 和 // Future: registerStatsCommand(program, ctx);；src/cli/commands/ 下也确实只有 seed.ts 一个文件。描述与实现之间的这处差异，我只陈述位置，不推断原因。

唯一实现了的 seed 参数写在 src/cli/README.md:21-27：--input（必填）、--output-dir、--session-key、--config、--strict-round-role、--yes；:143-153 还列了输出目录的形状——conversations/、records/、scene_blocks/、vectors.db，外加 .metadata/manifest.json、.metadata/checkpoint.json 与 .backup/。不过 src/cli/commands/seed.ts:123 有一行注释写着 Checkpoint exists → resume scenario → P0 not implemented，:125 给用户看的报错文案是「Resume from checkpoint is not implemented in P0 yet.」——断点续跑这条路在本快照里是明写没实现的。

另一条 CLI 通路是 bin/ 下的薄启动器。package.json:8-11 的 bin 字段登记了三个：migrate-sqlite-to-tcvdb、export-tencent-vdb、read-local-memory；而 bin/ 目录里实际有 4 个 .mjs，多出来的 bin/seed-v2.mjs 没登记在 bin 字段里。

至于 SDK，README.md:161-164 指向的是仓库内 ../sdk/memory-core/typescript/ 与 ../sdk/memory-core/python/——这两个目录在 MemoryCore/ 之外，本文没有核对它们的内容。

两个适配层，都没有引入第四种协议

MemoryCore/ 下还躺着两个插件目录，值得一并看，因为它们恰好说明了这个模块被别的宿主接进去时走的还是上面那三条路。

openclaw-plugin/（15 个文件）的定位写在它自己的 README.md:5：它是 Memory Gateway /v3/* 的客户端适配层，原文明写「does not run extraction, indexing, scene generation, or persona generation」，README.md:13 的表格里 Not included 一栏写的是 Offload / Context Engine。它的插件 id 是 memory-tencentdb-client（openclaw-plugin/openclaw.plugin.json:2），和 MemoryCore/openclaw.plugin.json:2 的 memory-tencentdb 不是同一个 id。挂钩方式见 openclaw-plugin/docs/architecture.md:39-40：agent_end 钩子调 client.addConversation()，before_prompt_build 钩子并行调 client.searchAtomic()、client.readCore()、client.listScenarios()——插件 API 在上层，HTTP 在下层。

hermes-plugin/ 那份 Python 插件（plugin.yaml 声明 hooks: [on_memory_write, on_session_end]）也是同样的结构。它 README 里的生命周期映射表（hermes-plugin/memory/memory_tencentdb/README.md:33-38）把三个宿主回调一一对到 v1 的 HTTP 端点上：prefetch(query) → POST /recall，sync_turn(user, assistant) → POST /capture，shutdown() / on_session_end → POST /session/end；同表里 get_tool_schemas() 一行明写没有对应端点。

再往配置层看一眼也是同一个口径：openclaw.plugin.json:16-21 的 mode 是个五值枚举 ["local","function","client","gateway","remote"]，默认 local；:28-36 的 server 段默认值是 url: http://127.0.0.1:8420、apiKey: local、instanceId: default。紧挨着的 storeBackend（:22-27）是 ["sqlite","tcvdb"] 二选一、默认 sqlite，它的描述里注明「仅 local/function 模式生效」，是该文件中少数把 mode 取值与别的字段挂上钩的说明之一。至于这五个值各自的完整语义、分别走哪条通路，我们没有回代码逐个核实，这里只记录枚举与默认值本身。

接入之前，先看这几处

鉴权是分层的，且 v1 与 v2/v3 口径不同。 v2/v3 侧要求 Authorization: Bearer <key> 加 x-tdai-service-id（v2-router.ts:12 注释与 parseV2Auth，:350-360）：缺 Bearer 返 401「Missing or invalid Authorization header」，缺 service id 返 401「Missing x-tdai-service-id header」。/v3 还要求 team_id / agent_id / user_id 三元组齐全（collectV3Missing，v2-router.ts:130-150），可以从 body 或对应的 x-tdai-* 头里取，session_id 不强制。而 v1 侧的 verifyAuth（server.ts:1116-1129）在 server.apiKey 未配置时直接 return "ok"，注释写的是 auth disabled — default behaviour。

这里有一处文档与代码的差异值得单独标出来。 README.md:204 的环境变量表原文写 TDAI_GATEWAY_API_KEY | Unset | HTTP Bearer authentication; required for non-loopback binding；代码侧 server.ts:739-746 在「非回环绑定且鉴权未开」时打的是一条 logger.warn，文案为「Bind to 127.0.0.1, or set TDAI_GATEWAY_API_KEY, before continuing.」。我们没有在仓库里找到「未设 API Key 且绑非回环则拒绝启动」的实现。同时 Dockerfile:146 默认把 TDAI_GATEWAY_HOST 设成了 0.0.0.0。两处位置都摆在这里，怎么处置由你自己判断。

注释里的条数和路由表对不上。 v2-router.ts:520 的注释写「/v3 暴露 L0–L3 数据面 14 条（V3_ALLOWED_SUBPATHS）」，而 V3_ALLOWED_SUBPATHS（v2-router.ts:153-172）我们逐行数下来是 18 条（conversation 5 + atomic 5 + scenario 5 + core 3）。同文件 :444 注释说的「16 条」废弃实体路由，与 :451-466 的 16 行是对得上的。只陈述差异，以实读的路由表为准。

那 16 条 @deprecated 别当新接口用。 v2-router.ts:444-449 的注释原文写「仅为兼容现网保留、行为不变」「计划在确认无外部调用方后整体删除」，路径形如 /v2/{team,user,agent,task}/{create,get,update,delete}。新接入按注释的说法应走 v3。

自己核一遍的动作

想验证「没有 MCP」这个结论，不必读代码：把仓库按 feat/server_team 分支 clone 下来，在 MemoryCore/ 目录里对 mcp 做一次大小写不敏感的全文检索（记得覆盖 .md 和 .yaml，别只搜 .ts），看命中数。要确认对外接口，直接打开 src/gateway/v2-router.ts 的 414-431 行看 DATAPLANE_HANDLERS、src/gateway/skill-handlers.ts 的 1138-1157 行看 makeSkillRouteTable()，这两处是路由的定义源头，比 README 的表格全——两份 README 的 API 表都没有列 POST /session/end、POST /seed、/v2/pipeline/status 这几条。

最后一句限定必须写在正文里而不是文末：截至 2026-08-16，MemoryCore/package.json:3 的版本是 2.0.0-beta.1（根 CHANGELOG.md 最新条目写的是 [2.0.1-beta.1]，两处不一致，只陈述），同仓另外三个模块的 package.json 版本都还是 0.1.0，默认分支是一个 feat/ 分支，ROADMAP_CN.md:7 自己写着「路线图列出的是团队正在推进的工作，不是承诺」。上面所有路由、行号、字段名都是这个快照下的状态，下次再看很可能就变了。

延伸阅读

从头读起：TencentDB Agent Memory 是什么：团队级 Agent 记忆中枢怎么读
本专题共 40 篇，完整分组目录见专题页
TencentDB Agent Memory 的网关路由全景：v1 / v2 / v3 各管什么
TencentDB Agent Memory 的两份 gateway 配置逐字段对照

本文依据 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，参数与接口随版本变动，请以仓库最新内容为准。该项目会采集并存储团队的对话、文档与代码，属于敏感数据，是否使用请结合自身合规要求评估。安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。