TencentDB Agent Memory 的 MemoryProxy 版本：0.1.0 还是 0.2.0

如果你要接一个自托管服务，第一件想确认的事往往是”我现在跑的到底是哪个版本”。惯常做法有两个：读包清单，或者打健康检查接口。在 TencentDB Agent Memory 的 MemoryProxy 模块上，这两个做法会给你两个不同的答案。

先把前提说清楚。我们看的是 TencentCloud/TencentDB-Agent-Memory 这个仓库，截至 2026-08-16 它的默认分支是 feat/server_team——不是 main，也不是 master。本文所有文件路径都在这个分支上，对应快照 97f9465。整个项目的主模块处于 beta 阶段，MemoryProxy 自身的版本号还是 0.1.0，接口与配置随版本变动，下面写到的每一行都可能被后续提交改掉。

三处版本号，两个值

第一处：包清单。 MemoryProxy/package.json 第 2、3 行：

{
  "name": "context-proxy",
  "version": "0.1.0",

顺带一提，这里就藏着这个仓库的另一个惯常绊子：目录名叫 MemoryProxy，包名是 context-proxy。同仓的 MemoryPanel 目录，包名是 team-memory-control。目录名和包名不是一回事，写命令的时候别拿目录名去当包名用。

第二处：健康检查接口的返回体。 路由注册在 MemoryProxy/src/server.ts 的 createApp(config) 里（src/server.ts:19-331），GET /health 这一段构造响应对象时，version 字段给的是一个硬编码的字面量字符串 "0.2.0"（src/server.ts:90）。它不是从 package.json 读来的，也不是从配置或环境变量里注入的——就是源码里的一个常量。

第三处：README 的示例响应。 MemoryProxy/README.md:128 给出的 /health 样例 JSON 里，"version": "0.2.0"，中文版 README_CN.md 的同一位置也是这个值。也就是说，文档这一侧和接口这一侧是对得上的，跟包清单对不上的是这两者共同的那个值。

按本站的写法纪律，这里只陈述差异：MemoryProxy/package.json:3 写的是 0.1.0，MemoryProxy/src/server.ts:90 与 MemoryProxy/README.md:128 写的是 0.2.0，三处不一致；以我们实读的仓库状态为准。我们不推断哪个”才对”，也不去猜为什么两边没同步。

你自己怎么在半分钟内核到这三处

不用装环境，clone 下来读三行文件就行——这也是我们能给出上面结论的全部依据，我们没有部署、也没有启动过这个模块。

拿到 feat/server_team 分支的代码后，在 MemoryProxy/ 目录下：

• 看 package.json 的第 3 行，那是包清单版本；
• 在 src/server.ts 里找 app.get("/health"，往下第几行就是 version: 那一行；
• 在 README.md 里找 "version"，落点是第 128 行的示例响应块。

如果你那边已经有一个在运行的实例，还可以直接打它自己的健康检查地址。这个地址不用猜——MemoryProxy/Dockerfile:100-101 的 HEALTHCHECK 指令原样写的就是：

HEALTHCHECK --interval=30s --timeout=5s --retries=3 --start-period=15s \
    CMD curl -fsS http://127.0.0.1:8096/health || exit 1

端口 8096 与 Dockerfile:96 的 EXPOSE 8096、config.example.yaml:26 的 port: 8096 一致。以上命令抄自仓库中的 Dockerfile，我们没有执行过它，实际行为以你自己环境里的运行结果为准。

要注意的是：打这个接口拿到的 version 永远是 0.2.0，因为它是常量。它不能用来区分你部署的是哪一次提交，也不能用来判断某个补丁有没有生效。

/health 除了版本号还返回什么

既然要拿它当探针，就得知道它到底暴露了哪些字段。按 src/server.ts:84-104，返回体包含 status、version、upstream、opik、costGuard、rateLimit，以及一个 storage 对象，里面是 enabled、requested、effective、degraded，出错时再多一个 lastError。

这里有一条比版本号更值得留意的行为：当 storage.enabled 为真、requested === "cos"、而 effective !== requested 时，status 会变成 "degraded"，并且 HTTP 状态码返回 503（src/server.ts:86-87、:103）。源码里那段注释写明了这样做的目的，是让 k8s 的负载均衡把该 pod 摘掉。

而 README 的端点表（MemoryProxy/README.md:198）对这条只写了「runtime health check (includes storage.effective)」，示例响应给的是 degraded: false 的 200 情形，没有提 503。这是另一处文档与代码的口径差异——同样只陈述，不延伸。

对接监控的时候这一点是有实际后果的：如果你按”200 即健康”配探针，degraded 状态下这个接口会返 503，节点会被判为不健康；如果你按”能返回 JSON 即健康”配，又会漏掉降级信号。该怎么配取决于你自己的部署形态，项目没有给出通用建议。

那该拿什么当版本锚点

在 version 字段是常量的前提下，仓库里还能拿到的、跟”你手上这份代码是什么”直接相关的信息，只有这么几样，我们只列能核到的：

来源	位置	值（2026-08-16 快照）
包清单版本	MemoryProxy/package.json:3	0.1.0
/health 返回	MemoryProxy/src/server.ts:90	硬编码 "0.2.0"
README 示例	MemoryProxy/README.md:128	"0.2.0"
仓库快照	git commit	97f9465（分支 feat/server_team）

实际能唯一标定一份代码的，是最后一行的 commit。这一点对这个模块尤其成立，原因写在它的启动方式里：package.json 的 start 脚本是 node --import tsx/esm src/index.ts，Dockerfile 的 ENTRYPOINT 也是 ["/usr/bin/tini","--","node","--import","tsx/esm","src/index.ts"]（Dockerfile:105）——运行期不做编译，直接用 tsx 跑 TypeScript 源码。进程加载的就是你 checkout 的那一棵源码树本身，没有中间产物可以对照。

顺带说一句版本口径在这个仓库里的分层情况，免得你只盯着 proxy 一个模块。截至 2026-08-16，四个模块的 package.json 是这样的：MemoryCore 是 @tencentdb-agent-memory/memory-tencentdb-v2，版本 2.0.0-beta.1；MemoryKnowledge 是 @tencentdb-agent-memory/knowledge-service，0.1.0；MemoryPanel 是 team-memory-control，0.1.0；MemoryProxy 是 context-proxy，0.1.0。而仓库 CHANGELOG.md 的最新条目标的是 [2.0.1-beta.1] — 2026-08-13，与 MemoryCore/package.json 里的 2.0.0-beta.1 不一致。也就是说，“这个项目是几点几版”这个问题在这个仓库里本来就没有单一答案，得先说清你问的是哪个模块、看的是哪个文件。

什么情况说明你碰到的不是这件事

这一条容易被跳过，但它才是排查的分界线。

• 你拿到的 version 不是 0.2.0。 那说明你跑的不是这份快照的代码，上游已经改过 src/server.ts 的那一行，或者你面前的服务根本不是 MemoryProxy。这时候本文的行号全部作废，回去读你自己那份源码。
• /health 返回 503。 那是存储降级路径（src/server.ts:86-87），跟版本号没有关系，去看返回体里的 storage.requested 与 storage.effective 差在哪里。
• 进程压根起不来、直接退出。 先看 Node 版本。src/index.ts:3-10 在进程第一行做检查，判据是 if (!process.version.startsWith("v22."))，不满足就打印错误并 process.exit(1)。这个判断只比对前缀，没有 minor 版本比较；而 README.md:76 写的是「Node.js v22.x（checked strictly at startup；>= 22.16.0 recommended）」。这也是两处口径的差异，同样只作记录。
• 你在找 MemoryProxy/config.yaml 却找不到。 这个文件被 .gitignore 排除了（MemoryProxy/.gitignore 里有 config.yaml 一行），仓库里只有 config.example.yaml。因此仓库里能读到的”默认值”只有两个来源：src/config.ts 的 DEFAULT_CONFIG，以及 config.example.yaml 的示例值——线上真实生效的值不在仓库里。

收束

这类差异在这个仓库里不止一处：README 的目录结构列了 gateway/ 和 docs/ 两个目录，快照里都不存在；src/ 里有 73 处引用指向不存在的 docs/ 下的文件；README 说各子模块下有 __tests__/，而快照里 *.test.ts 一个也没有。这些我们另有篇目专门讲，此处不展开。

对使用者来说，可操作的结论只有一条：在这个模块上，别把 /health 的 version 当版本依据用，它是 src/server.ts:90 的一个常量。要标定代码，用 commit；要判断某处行为，回去读那一行源码。这个项目还在快速变动之中，主模块 beta、其余模块 0.1.0、默认分支是一个 feat/ 分支，接口和默认值随时可能变——本文写下的每个行号，都请你在自己那份 checkout 上再对一次。

延伸阅读

• 从头读起：TencentDB Agent Memory 是什么：团队级 Agent 记忆中枢怎么读
• 本专题共 40 篇，完整分组目录见专题页
• TencentDB Agent Memory 的四级降级：源码里有一档直接 FATAL
• TencentDB Agent Memory 被引用的 cost-guard 目录并不存在

---

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