TencentDB Agent Memory 的 config.ts：三处注释默认值与代码不符
翻别人家仓库的配置项，多数人第一反应是去看类型定义上的注释——接口字段旁边挂着一行 JSDoc，写着 default: 30，比翻文档快，也比翻实现快。
在 TencentDB Agent Memory 这个仓库里，这个习惯会踩坑。MemoryCore/src/config.ts 这一个文件内部，接口定义上的 JSDoc 注释写了一组默认值，文件下方真正构造配置对象的那段代码用 ?? 兜底又写了另一组，其中三个字段两边对不上。下面把这三处逐条摆出来，并说明怎么自己核一遍。
先交代口径：本文全部内容来自我们在 2026-08-16 拉取的仓库快照，分支是该仓库的默认分支 feat/server_team（不是 main，也不是 master），下文所有文件路径都指这个分支上的文件。该项目主模块 MemoryCore/package.json 的 version 是 2.0.0-beta.1，处于 beta 阶段，同仓另外三个模块的版本号还是 0.1.0；配置字段与默认值随版本变动，看到本文时对不对得上，以你手上仓库的当前内容为准。
三处对不上的字段
| 字段 | 所在接口 | JSDoc 注释写的默认值 | 代码 ?? 后的实际默认值 |
|---|---|---|---|
l1IdleTimeoutSeconds | PipelineTriggerConfig（注释在 :73） | 30（default: 30） | 600（:565） |
l2DelayAfterL1Seconds | PipelineTriggerConfig（注释在 :75） | 90（default: 90） | 10（:566） |
maxScenes | PersonaConfig（注释在 :55） | 20（Max scene blocks (default: 20)） | 15（:556） |
行号都是 MemoryCore/src/config.ts 这一个文件里的行号。两组数值的落差方向还不一致：l1IdleTimeoutSeconds 是注释小、代码大（30 与 600），l2DelayAfterL1Seconds 是注释大、代码小（90 与 10），maxScenes 也是注释大、代码小（20 与 15）。
按本站一贯的写法，这里只并列陈述两处文本的差异，标明各自位置，不去推断哪一个才是「作者想要的」，也不去猜为什么没同步，更不拿它评价项目质量。以我们实读到的仓库状态为准：运行时最终取到哪个值，取决于代码那一侧的 ?? 兜底，而不是注释。
这三个字段在链路上管什么
只看数值容易失焦，简单交代一下它们所处的位置——同样只引用文件里能读到的注释原文。
PipelineTriggerConfig 这个接口的顶头注释（MemoryCore/src/config.ts:66）写的是 Pipeline trigger settings (L1→L2→L3 scheduling)。README 里那套分层记忆模型——README_CN.md 技术实现小节的原表把它写成 L0 Conversation / L1 Atom / L2 Scenario / L3 Core（Persona），「对话首先作为 L0 保存，再由异步 Pipeline 提炼为不同粒度的记忆」——从 L1 往上跑的调度节奏，就落在这个接口的字段上。
l1IdleTimeoutSeconds（:73）与l2DelayAfterL1Seconds（:75）这两个字段名本身已经把语义写在标识符里了：一个是以秒计的 L1 空闲超时，一个是 L1 之后到 L2 之间以秒计的延迟。它们都归在这个「L1→L2→L3 调度」的接口下。- 同一接口里另外几个字段——
everyNConversations、enableWarmup、l2MinIntervalSeconds、l2MaxIntervalSeconds、sessionActiveWindowHours——注释与代码是对得上的，下面会列。
PersonaConfig 的顶头注释（:50）写的是这个接口 controls scene extraction (L2) and user profile generation (L3)。maxScenes 的注释原文是 Max scene blocks (default: 20)，对应 L2 那层的 scene block 上限；scene block 在落盘层的位置也能对上，MemoryCore/src/core/storage/types.ts:254 的 StoragePaths 里有 sceneBlocksDir: "scene_blocks/"，单个文件是 scene_blocks/${name}.md（:273）。
再强调一句：以上都是配置里的默认值，不是「你用起来会怎样」的保证。l1IdleTimeoutSeconds 是 30 还是 600，只说明这一行代码写了什么数字，不能据此推算任何触发频率下的资源占用、延迟、成本或稳定性——那需要真实部署与测量，而我们没有部署、也没有运行过这个项目的任何一个模块。
怎么自己确认是这个问题
这类坑的典型现象是：你照着注释把预期建立起来了，实际行为对不上，然后开始怀疑自己的配置文件写错了。判定动作其实很短：
第一步，打开 MemoryCore/src/config.ts，找到接口定义那一段（PersonaConfig 从 :50 开始，PipelineTriggerConfig 从 :66 开始），记下字段旁边 JSDoc 里的数字。
第二步，在同一个文件里往下翻到构造配置对象的那一段（persona 分组在 :555 一带，pipeline 分组在 :563 一带，recall 分组在 :571 一带），看同名字段 ?? 右边的字面量。写法是统一的「先读用户配置，读不到就用 ?? 右边这个数」——例如 maxScenes 那一行的 ?? 15、l1IdleTimeoutSeconds 那一行的 ?? 600。
第三步，两个数字并排比。对不上的就以 ?? 右边那个为准，因为那是真正参与取值的表达式；注释不参与运行。
处置上没有什么玄机：如果你在意这个值，就在自己的配置里把它显式写出来，不要依赖任何一侧的默认值。按 ?? 的语义，左边读到了值，右边的兜底就不会参与，注释与代码那两个数字怎么写都影响不到你。至于该写成多少，仓库没有给出通用建议值，README 与 ROADMAP 里也没有这三个字段的调参指引，取值取决于你的用法，我们不替你给数。
什么情况说明不是这个原因？如果你观察到的偏差涉及的是 everyNConversations、enableWarmup、l2MinIntervalSeconds、l2MaxIntervalSeconds、sessionActiveWindowHours，或者 PersonaConfig 里的 triggerEveryN、backupCount、sceneBackupCount，那就跟这篇没关系了——这几个字段的注释与代码是一致的：
| 字段 | JSDoc | 代码 ?? |
|---|---|---|
everyNConversations | 5 | 5（:563） |
enableWarmup | true | true（:564） |
l2MinIntervalSeconds | 900（=15 min） | 900（:567） |
l2MaxIntervalSeconds | 3600（=60 min） | 3600（:568） |
sessionActiveWindowHours | 24 | 24（:569） |
triggerEveryN | 50 | 50（:555） |
backupCount | 3 | 3（:557） |
sceneBackupCount | 10 | 10（:558） |
也就是说，这不是「整个文件的注释都不可信」，而是同一个文件里三个具体字段对不上。上表这几个字段，注释与代码给的是同一个数。
一个容易被误判成第四处的地方
同文件的 RecallConfig（接口在 :84-100，取值在 :571-578）里，maxCharsPerMemory 与 maxTotalRecallChars 的实际默认值都是 0。乍一看像是「注释没写默认值、代码给了个 0」，但翻回注释会发现两边是自洽的：这两个字段的 JSDoc（:90-93）分别写 0 disables the per-memory limit 与 0 disables the total limit，即 0 本身就是「不设限」这个语义，不是漏填。
RecallConfig 里其余几个字段的实际默认值是 maxResults 5、scoreThreshold 0.3、strategy "hybrid"、timeoutMs 5000，同样在 :571-578 这一段里。我们在这个文件里核到的注释与代码对不上的地方，就是前面那三处，RecallConfig 不在其中，所以别把它算进「对不上」的清单。
同一个仓库里的同类差异
如果你打算把「注释与代码并排看一遍」变成读这个仓库的固定动作，那么值得知道它不止 config.ts 这一处。同样是只陈述差异、标明位置：
- 版本号在四个地方写法不同：
README_CN.md:299写「当前版本 v2.0.0」，ROADMAP_CN.md:5写「当前版本：v2.0.1-beta.1」，MemoryCore/package.json的version是2.0.0-beta.1，CHANGELOG.md:13最新条目是[2.0.1-beta.1]。 MemoryCore/src/gateway/v2-router.ts的文件头注释（:6-9）按 L0/L1/L2/L3 列出四层动词共 14 个动作，而实际的V3_ALLOWED_SUBPATHS（:153-172）与 handler 映射各是 18 条，每层都多一个count。- 资产可见性：
README_CN.md:230-235的表列了private/team/restricted/agent四个取值，MemoryCore/src/metadata/types.ts:25的AssetVisibility是五个，多一个task。 - 团队角色：
README_CN.md:136写 Admin 与 Member 两种，MemoryCore/src/metadata/types.ts:18的TeamRole是"admin" | "member" | "reviewer"三种。
这些放在一起看，结论只有一条操作性的：这个仓库里凡是「某个值是多少」的问题，最终答案都要回到参与运行的那一行代码上，注释、README、CHANGELOG 都只能当线索。 这不是这个项目独有的现象，只是它正处在快速迭代阶段，同一件事在不同层留下不同快照的机会更多一些——ROADMAP 自己也写着「路线图列出的是团队正在推进的工作，不是承诺，范围与时间可能调整」。
最后提醒一件与配置相关的事：这套 Pipeline 调度的对象是团队真实的对话内容——L0 那层保存的是原始对话与完整上下文，L1 往上是从中提炼出来的事实、偏好与场景。调这几个数字时，你调的是「这些内容多久被提炼一次、留几份」，不是纯粹的性能旋钮。是否使用、怎么存、存在哪，需要按你自己的合规要求评估。
延伸阅读
- 从头读起：TencentDB Agent Memory 是什么：团队级 Agent 记忆中枢怎么读
- 本专题共 40 篇，完整分组目录见专题页
- TencentDB Agent Memory 的权限：README 4 种可见性，代码有 5 种
- TencentDB Agent Memory 的 Benchmark 自述：能引用到什么程度
本文依据 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，参数与接口随版本变动，请以仓库最新内容为准。
该项目会采集并存储团队的对话、文档与代码，属于敏感数据，是否使用请结合自身合规要求评估。
安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。