TencentDB Agent Memory 的四类记忆资产各是什么

2026-08-16

读 TencentDB Agent Memory 这个仓库，最省事的入口不是 README 的那几张示意图，而是一行类型声明。MemoryCore/src/metadata/types.ts:24（分支 feat/server_team，下同）写着：

export type AssetType = "skill" | "llm_wiki" | "code_graph" | "chat_memory";

四个字符串，就是这个项目对「记忆」的全部切法。同样的四值 Zod 枚举出现在 MemoryCore/src/metadata/router/v3-meta-schemas.ts:11。README 里那些「资产背包」「Agent Loadout」的说法，最终都要落到这四个值上。

先把一件事说在前面：这个仓库的默认分支就是 feat/server_team，不是 main 也不是 master。本文提到的所有文件路径都在这个分支的快照 97f9465（我们于 2026-08-16 采集）上。另外主模块 MemoryCore/package.json 的 version 是 2.0.0-beta.1，MemoryKnowledge / MemoryPanel / MemoryProxy 三个模块的 package.json 版本都还是 0.1.0——下面出现的枚举、字段名与接口路径都可能随版本变动，以仓库最新内容为准。

一、四类资产各自的 ID 前缀，是最快的辨认方式

四类资产在库里靠 ID 前缀区分，出处分散在三个文件：

资产类型	枚举值	ID 形态	出处
Skill	`skill`	`skl-` + 12 字符 base62	`MemoryCore/src/core/skill/skill-core.ts:232-235`
LLM-Wiki	`llm_wiki`	`wiki-` + 8 位 base36	`MemoryKnowledge/src/store/ids.ts:17-18`
Code-Graph	`code_graph`	`cg-` + 8 位 base36	同上
Chat Memory	`chat_memory`	`chat_memory-{team_id}-{agent_id}`	`MemoryCore/src/metadata/utils/chat-memory-asset.ts:6`

前三个前缀在 MemoryCore/src/gateway/generated/schemas.ts:49 的描述文本里也一并列出过（skl- / wiki- / cg-）。ids.ts 的文件头注释（:4-8）还写了一句选型说明：8 位 base36 约等于 36^8 ≈ 2.8e12 的空间。

值得注意的是 Chat Memory 的 ID 不是随机串，而是 chat_memory-{team_id}-{agent_id} 这样拼出来的确定值，拼接函数 buildChatMemoryAssetId 在同文件 :22-24，前缀常量 CHAT_MEMORY_ASSET_PREFIX = "chat_memory-" 在 :19。也就是说，给定 team 与 agent，这个资产 ID 是可以按规则拼出来的。MemoryCore/src/metadata/service/metadata-service.ts:1236-1250 的方法注释写的是：「幂等确保 (team, agent) 对应的 chat_memory 资产存在并已绑定到 agent」。

二、Chat Memory：创建时有四个字段是写死的

README_CN 在 :97 起的小节里给 Chat Memory 下的定义是三句话（:99-101）：「Chat Memory 保留偏好、事实、决策和交互历史」「每个 Agent 创建时自动获得独立记忆，下次对话不必从自我介绍开始」「L0 Conversation → L1 Atom → L2 Scenario → L3 Persona，从原始对话逐层沉淀」。小节末尾还配了一句引语（:105）：「“别重构旧鉴权模块，移动端还在用。“——这种代价很高的上下文，不应该靠人每次提醒。」

分层那条线索另有专篇可讲，这里只看资产层面。上面那句「自动获得独立记忆」在代码里的具体表现，是创建时四个字段被硬写：visibility: "private"、source_type: "auto"、injection_mode: "summary"、priority: 50（metadata-service.ts:1293-1322）。这四个值不是配置项默认值，是这段创建逻辑里的字面量。

private 在这个项目里的语义比一般理解要严格。MemoryCore/src/metadata/service/permission-checker.ts:73-81 的注释写得很明白：「private = 个人隐私资产，团队里没人能看到（包括管理员）」「permission-checker.check 对 admin 访问他人 private 也返回 DENY」，并给了一条出路——「若管理员确实需要看，让 owner 主动切到 team 或通过 acl/grant 授权」。

三、Skill：一行一个不可变快照，结构靠 prompt 建议而不是字段约束

README_CN :109-111 说 Skill「不只是一段 Prompt：它有版本、资源文件、触发边界、执行步骤和验证规则」，并强调「个人 Skill 默认私有；审核后可分享给团队，再配装给其他 Agent」。

对到代码上，MemoryCore/src/core/skill/types.ts:264-286 的 Skill 行结构含 skill_id、version（number）、is_head、content、content_hash、manifest、storage_dir、status。:258 的注释一句话交代了版本模型：「每行 = (skill_id, version) 一个不可变快照」。SkillStatus 只有两个值 "active" | "archived"（:227）。资源文件条目类型 SkillManifestEntry 在 :230-236，字段是 path / size_bytes / mime_type / is_executable，其中 path 的注释写明「相对 files/ 的路径，UNIX 风格，禁 .. / 绝对路径」（:231）。

那句「触发边界、执行步骤和验证规则」在代码里不是三个独立字段。它们出现在 MemoryCore/src/core/skill/prompts/skill-review-prompt.ts:119-160 列出的 SKILL.md 推荐小节里：## When to use、## When not to use (optional)、## Required inputs、## Workflow、## Background / Context、## Decision rules (optional)、## Output format (optional)、## Validation (optional)、## Pitfalls (optional)、## Supporting files (optional)。同一个 prompt 明写这套结构是「recommended, not enforced」（:119），硬性最低要求只有一条：frontmatter 里的 name 与 description，加上至少一个有内容的正文小节（:159）。

也就是说，Skill 的「结构」在写入时是靠 review prompt 引导的，不是靠 schema 卡住的。你要判断一个 Skill 合不合规范，得去看这份 prompt 的清单，而不是去找字段定义。

四、LLM-Wiki 与 Code-Graph：暴露给 Agent 的只有只读工具

这两类在 README_CN 里合在同一个小节（:117 起）：「Wiki 把产品文档、设计方案和运维手册生成结构化页面与链接图谱。(灵感来源于 Karpathy 的 LLM 知识库)」（:119）、「CodeGraph 索引代码符号、文件、调用关系和影响路径」（:123），并补了一句用法（:127）：「Agent 可以搜索、阅读、查 callers / callees，也可以在改代码前先做 impact analysis。」致谢小节 :308 写明「我们的 CodeGraph 资产模块复用了该项目的代码」，指向 colbymchenry/codegraph。

真正能被 Agent 调到的东西，全在 MemoryKnowledge/src/routes/tools.ts 的两份白名单里：

Wiki（源码注释写「Wiki tools (7)」，:48）：get_info / search / list_pages / read_page / get_graph / list_raw / read_raw
Code-Graph（注释写「Code-Graph tools (9)」，:90）：get_info / search / explore / callers / callees / impact / node / status / files

我们按 name: 字段数了一遍，实际条数与注释自称的 7 与 9 一致。这个文件头 :8-9 还有一句边界声明：「Management operations (create/delete/ingest/sync) are NOT exposed — only read-only query tools.」——建库、删库、导入、同步这些动作不在 Agent 手上。

几个默认值可以顺手记住：impact 的默认 depth 是 2（:142），描述原文是「列出修改会影响到的符号。重构前先用它评估影响面。」（:139）；callers / callees 的默认 limit 都是 20（:127、:135）；explore 被标为「【首选工具】」，默认 maxFiles 12（:114-121）。这些是代码里的默认值，不代表你用起来会得到什么结果。

Agent 侧的发现与调用走 /list 与 /call 两条路由（tools.ts:194、:246）。路由本身定义时不带前缀，文件头 :11 注明「prefix applied at server.ts mount level」；挂载在 api.route("/tools", ...)（MemoryKnowledge/src/server.ts:77-83），前缀取 env("API_PREFIX", "/v3")（MemoryKnowledge/src/config.ts:154）。默认拼出来确实是 README_CN :265-269 那一节写的 /v3/tools/list 与 /v3/tools/call，但这个前缀可以由 API_PREFIX 环境变量改掉。

五、四类资产共用的那层外壳

四类资产之所以能被统一管理，靠的是同一张绑定表 meta_agent_fixed_assets（MemoryCore/src/metadata/store/sqlite-adapter.ts:252-261），列有 id / agent_id / asset_id / asset_type / injection_mode（DEFAULT 'summary'）/ priority（DEFAULT 50）/ created_by / created_at，并带 UNIQUE(agent_id, asset_id)。按类型聚合的计数类型 FixedAssetTypeCounts（MemoryCore/src/metadata/types.ts:206-211）字段正好是那四类：skill / code_graph / llm_wiki / chat_memory。

injection_mode 的枚举定义在 types.ts:34，共四个值："direct" | "summary" | "tool" | "reference"。我们读到的实际写入点只有三种：chat_memory 写 summary（metadata-service.ts:1320），skill 写 reference（:1431），knowledge 写 tool（MemoryPanel/src/panel/http/routes/knowledge/allocate-routes.ts:103，该文件头 :8 注明「knowledge 是工具型注入，Proxy 渲染 <knowledge_tools>」）。direct 我们没有找到写入点，在 MemoryProxy/ 里 injection_mode 也只作为 DTO 字段出现一次（MemoryProxy/src/meta/client.ts:91，类型是 injection_mode?: string），我们没有找到按该字段分支的实现。

顺带一提，README 里反复出现的「Loadout」（如 README_CN.md:188「不同角色，不同 Loadout」）是个纯文档词汇。全仓不区分大小写 grep loadout 只命中 4 个 Markdown 文件共 11 处，源码里 0 处；代码侧对应的命名是 agent-fixed-asset / FixedAssetBinding。你照着 README 的词去搜代码是搜不到的。

六、几处需要知道的拼写与口径差异

以下三处只陈述差异并标明位置，不推断哪一处是对的：

知识类资产有两套拼写。 资产层是 llm_wiki / code_graph（下划线，MemoryCore/src/metadata/types.ts:24），知识层是 wiki / code-graph（横杠，MemoryCore/src/core/store/types.ts:453 与 MemoryKnowledge/src/routes/tools.ts:191），README 正文则统一写 Wiki 与 CodeGraph（README_CN.md:119、:123）。三处并存，搜索时三种都要试。
资产类型枚举一处四值、一处三值。 metadata/types.ts:24 与 v3-meta-schemas.ts:11 是四值（含 chat_memory）；由 kubb 生成的网关契约 MemoryCore/src/gateway/generated/types.ts:98-102 的 assetTypeEnum 与 schemas.ts:46 的 assetTypeSchema 都只有 skill / llm_wiki / code_graph 三值。
两处 createAsset 传的 status: "active" 不在 AssetStatus 枚举里。 枚举的 6 个取值是 draft / candidate / approved / deprecated / archived / failed（metadata/types.ts:26-32），而 metadata-service.ts:1301（chat_memory）与 :1415（skill）写的都是 status: "active"。我们没有运行过类型检查或构建，这里只记录读到的文本差异。

七、还没做完的部分，README 自己列了

README_CN :279-283 的注意事项三条，其中两条能在代码里对上：Wiki 和 CodeGraph 是异步构建、要等状态变成 ready（状态机 SyncStatus = "pending" | "processing" | "ready" | "failed" 在 MemoryKnowledge/src/store/types.ts:18）；CodeGraph「当前首先支持公开 HTTPS 仓库」，对应 MemoryKnowledge/src/source-fetcher/git-fetcher.ts:58-61 的注释与报错串「first version only supports public HTTPS repos; SSH/private repo support coming soon」。第三条「全自动记忆路由仍在迭代」，我们没能在仓库里定位到对应模块或开关，只找到人工绑定的那 4 条路由（/v3/meta/agent-fixed-asset/set / /list / /list-with-detail / /summary-by-agents，MemoryCore/src/metadata/router/v3-meta-router.ts:264-273）。

ROADMAP_CN.md:7 也有一句免责：「路线图列出的是团队正在推进的工作，不是承诺，范围与时间可能调整。」

所以，回到最初那行枚举：四类资产是同一套元数据外壳下的四种内容形态，共用同一张绑定表、同一套可见性枚举与同一个 injection_mode 字段，而各自的 ID 前缀、内容从哪来、以什么粒度存、暴露给 Agent 的是内容本身还是一组只读工具，都不一样。你要在这个仓库里找任何一类资产的实现，从 AssetType 那四个字符串往下 grep，比从 README 的名词往下找要快得多。

延伸阅读

从头读起：TencentDB Agent Memory 是什么：团队级 Agent 记忆中枢怎么读
本专题共 40 篇，完整分组目录见专题页
TencentDB Agent Memory 的 L0 到 L3：分层记忆在代码里对应什么
TencentDB Agent Memory 的 Loadout：源码里它叫 agent-fixed-asset

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