TencentDB Agent Memory 的测试现状：npm test 没有任何目标

2026-08-16

翻一个陌生仓库时，我习惯先看两个地方：package.json 的 scripts.test，和测试运行器的 include 模式。这两处对上了，基本就知道该往哪儿看别人是怎么验证自己代码的。

在 TencentCloud/TencentDB-Agent-Memory 上，这两处都读得到，但把它们连起来跑一遍匹配，落到的文件数是零。

先说清楚前提：这个仓库的默认分支不是 main 也不是 master，而是 feat/server_team。我们下面所有路径都是这个分支上的，快照 97f9465，核对日 2026-08-16。仓库主模块 MemoryCore 的 package.json 版本是 2.0.0-beta.1，MemoryPanel 的是 0.1.0，都处在会继续变的阶段，参数和文件随时可能和你看到的不一样。我们没有部署、没有 npm install、没有跑过任何一条命令，下面全部是静态读文件数出来的。

一、三处配置，三套 include，零个匹配

MemoryCore

MemoryCore/package.json:32 里 test 的值是 vitest run。

同目录的 vitest.config.ts 一共 26 行，关键字段在 :4-24：environment: "node"、pool: "forks"、include: ["src/**/*.test.ts", "__tests__/**/*.test.ts"]、exclude: ["dist/**", "node_modules/**", "**/*.e2e.test.ts"]、testTimeout 与 hookTimeout 都是 120_000、coverage.provider: "v8"。

这是一份写得很完整的配置。问题在于它指向的两个位置：截至 2026-08-16，我们在 MemoryCore/ 全目录里筛 .test.ts 与 .spec.ts，命中 0 个文件；include 的第二段所指的 __tests__/ 目录本身不存在。

作为对照，同一个 MemoryCore/ 目录下我们数出 300 个 .ts 文件、95,923 行（按 os.walk 逐文件计行，同时把 .tsx/.mts/.cts 一起算进去结果不变，因为这三种后缀在这个目录下一个都没有）。

顺带一提，package.json:78-80 的 files 字段里还写着三条排除规则："!src/**/*.test.ts"、"!src/**/*.spec.ts"、"!src/**/__tests__/"。

MemoryPanel

MemoryPanel/package.json:15 同样是 "test": "vitest run"。它的 vitest.config.ts:5 里 include 写的是 ['tests/**/*.test.ts'] —— 注意和 MemoryCore 的两段模式不是同一套约定，这里只认 tests/ 这一层。

而 MemoryPanel/tests/ 目录在快照里不存在。find 和 git ls-files 我们都试过，找不到该目录，也找不到任何 .test.ts。git ls-files MemoryPanel | grep -i test 唯一返回的一行就是 MemoryPanel/vitest.config.ts 本身。

这个模块的体量：git ls-files MemoryPanel 是 220 个文件，其中 .ts/.tsx 共 160 个、30,537 行。

sdk/

sdk/memory-core/typescript/ 下有一份 10 行的 vitest.config.ts。git ls-files sdk | grep -i test 的唯一命中也是它自己。sdk/ 目录 git 跟踪的文件一共 44 个。

三处放在一起，形态是一致的：运行器配置在、include 模式在、被匹配的文件不在。我们只陈述这个状态，不推断它为什么是这样，也不由此评价这个项目。

顺便交代一下本文的边界：仓库根下并列着 MemoryCore/、MemoryKnowledge/、MemoryPanel/、MemoryProxy/ 四个模块目录，而我们这次逐条核过测试配置的只有 MemoryCore、MemoryPanel 和 sdk/ 三处。MemoryProxy 与 MemoryKnowledge 不在我们本次核对的范围内，它们的测试情况本文不做任何描述。

二、你怎么自己确认一遍

这类结论最怕的是转述失真，所以判定动作要能自己跑。在你 clone 下来的目录里：

find . -name "*.test.ts" -not -path "*/node_modules/*"
git ls-files MemoryPanel | grep -i test
git ls-files sdk | grep -i test

Windows 用户如果不想装 git-bash 里的 find，可以直接用 Python 走一遍 os.walk，口径更明确：

import os
n = 0
for r, d, fs in os.walk('MemoryCore'):
    d[:] = [x for x in d if x not in ('node_modules', '.git', 'dist')]
    for f in fs:
        if f.endswith('.test.ts'):
            n += 1
print(n)

要点是排除目录要显式写清楚。node_modules 里当然会有一大堆别人的 .test.ts，不排掉就会数出一个毫无意义的数字。另外一条：如果你是 git clone --depth 1 拿的浅快照，那么你看到的就是某一个 commit 的状态，不代表历史上任何时刻的状态，也不代表你 clone 那天的最新状态。

三、`scripts` 里还挂着别的测试入口，它们指向什么

MemoryCore/package.json 的 scripts 段里，除了 test 之外还有好几条带测试语义的命令。我们对它们指向的路径逐一做了 [ -e ] 存在性判定（2026-08-16）：

脚本名（行号）	命令	指向的路径是否存在
`test`（:32）	`vitest run`	配置在，匹配到 0 个文件
`test:oss`（:33）	`vitest run -c vitest.oss.config.ts`	`vitest.oss.config.ts` 不存在
`test:standalone:memory`（:34）	`bash __tests__/standalone/e2e.sh`	不存在（`__tests__/` 目录本身也不存在）
`test:standalone:all`（:37）	`bash scripts/e2e-standalone.sh`	不存在
`smoke:skill:*` 六条（:39-44）	`tsx scripts/smoke-skill/smoke-skill-*.ts`	`scripts/smoke-skill/` 整个目录不存在
`lint:skill-isolation`	`bash scripts/ci/check-skill-queue-isolation.sh`	存在

这张表要这么读：最后一行是存在的，说明这不是「scripts 里写的东西一概不在」，而是逐条各有各的状态。同样地，我们只做存在性判定，不推断执行结果 —— 比如 postinstall（:48）指向的 scripts/openclaw-after-tool-call-messages.patch.sh 也不在快照里，但那条命令源码里带着 2>/dev/null || true，会发生什么我们没跑过，不猜。

MemoryPanel 侧是同样的读法：package.json:16-18 有三条脚本指向 tests/ 下的文件，其中点得出名字的是 tests/panel/e2e-panel-meta.sh 和 tests/knowledge/e2e-knowledge-chain.ts；MemoryPanel/.env.example:50 也写着「Panel E2E：./tests/panel/e2e-panel-meta.sh」；MemoryPanel/README.md:41 的目录树里同样有一行「tests/ 单元测试与 E2E 测试」。这四处说的是同一个目录，而该目录在快照里找不到。这是 README 与仓库实况的差异，我们把两处位置都标出来，到此为止。

还有一处很小但值得记：MemoryPanel/scripts/secret-scan.sh:31 的默认扫描目标 TARGETS 是 src web/src tests config docker README.md package.json，里面同样含着不存在的 tests。该脚本 :49 有一行 [[ -e "$t" ]] || continue 的存在性跳过。

四、仓库里真正存在的验证脚本长什么样

不是没有验证手段，只是形态不同。MemoryPanel/scripts/ 下确实有两个能读到的 E2E shell 脚本，而它们的头注释直接写明了前置条件：

e2e-knowledge-authz.sh:3 —— 需要 Panel 跑在 :8123、Kernel 跑在 :8420、Knowledge Service 跑在 :8421；
e2e-skill-authz.sh:3 —— 需要 team-memory-control 后端跑在 127.0.0.1:8123。

也就是说，这两个脚本不是 vitest 那种进程内单测，而是要先把几个服务拉起来才谈得上执行的联调脚本。我们没有运行过它们，也没有起过任何一个服务，所以它们跑起来是什么结果、覆盖到哪些分支，本文一个字都不写。

同目录下另有一个 mock-memory-server.ts，文件头注释写的是「Mock memory 服务（本地端到端联调用）」，默认端口取 MOCK_KERNEL_PORT ?? 9090（:67）。它的存在说明联调这条路上有配套件，至于配套到什么程度，我们没有读完它的实现，不做延伸。

五、这件事对你意味着什么

如果你正打算把这个仓库 clone 下来看，有三点是可以直接带走的。

第一，别把 npm test 当成入口。 从 include 模式匹配不到文件这个静态事实出发，你至少知道不该指望靠它来了解各模块的行为边界。真要摸清楚一个模块干了什么，还是得读源码和它自带的注释 —— 比如 MemoryCore 的 tdai-gateway.yaml 里就有几段标着哪些字段是「预留字段、暂无消费者」、哪些是「未接线字段，已从活跃配置移除」，这类字段状态是仓库自己写下的原文，比任何转述都更接近你要核的那一处。

第二，如果你想给它补测试，先确认你在哪个模块。 三处 include 模式是三套：MemoryCore 认 src/**/*.test.ts 和 __tests__/**/*.test.ts，MemoryPanel 只认 tests/**/*.test.ts，sdk/memory-core/typescript/ 另有自己的一份配置。文件放错层级，运行器不会报错，只会安静地匹配不到。

第三，把版本阶段一起记住。 主模块是 2.0.0-beta.1，MemoryPanel 和另外两个模块目录的 package.json 版本还停在 0.1.0，默认分支是一个 feat/ 功能分支，ROADMAP_CN.md:7 自己也写着「路线图列出的是团队正在推进的工作，不是承诺，范围与时间可能调整」。本文的全部结论都只针对快照 97f9465 这一个 commit，你今天核出来的清单和下周的未必一样 —— 所以上面每一条我都写了行号和文件路径，你可以自己重跑一遍判定。

最后交代没核到的部分，免得读者以为这篇给出了全貌：npm registry 与 PyPI 上这些包是否已发布、发布出去的产物里是否带测试文件，本批禁止联网，我们没有核实；仓库之外是否另有一套 CI 流程在跑测试，我们也核不出来；MemoryProxy 与 MemoryKnowledge 两个模块目录不在本文核对范围。这三块都请以官方仓库最新内容为准。

延伸阅读

从头读起：TencentDB Agent Memory 是什么：团队级 Agent 记忆中枢怎么读
本专题共 40 篇，完整分组目录见专题页
TencentDB Agent Memory 插件侧：3 个 tool、2 个 hook 与注册入口
TencentDB Agent Memory 怎么接入：没有 MCP，只有 HTTP 网关与 CLI

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