奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

TencentDB Agent Memory 的 Loadout：源码里它叫 agent-fixed-asset

2026-08-16

读一个项目的 README，最容易留下印象的往往是那几个造得好的词。TencentDB Agent Memory 的 README 里，「Loadout」就是这样一个词——「不同角色，不同 Loadout。少给噪音，多给它完成工作真正需要的记忆。」（README_CN.md:188）。看完这句话，很自然的下一步是去代码里找一个叫 loadout 的模块、接口或者字段。

找不到。截至 2026-08-16 我们采集的快照 97f9465（分支 feat/server_team，这个仓库的默认分支就是它，不是 main 也不是 master），全仓不区分大小写 grep loadout，命中的只有 4 个 Markdown 文件、共 11 处：README.md 4 处（:187、:202、:211、:257）、README_CN.md 3 处（:188、:212、:259）、ROADMAP.md 2 处（:16、:26）、CHANGELOG.md 2 处（:84、:181）。源码 0 处。

这不是什么毛病，但它是一个具体的阅读障碍：如果你打算照着 README 的概念去读实现，得先知道这个词在代码里换了个名字。这类「文档一套词、代码另一套词」的情况，在这个仓库里不止一处——比如目录叫 MemoryPanel，它 package.json 里的包名却是 team-memory-control；目录叫 MemoryProxy，包名是 context-proxy。所以读这个项目时，最好一开始就准备一张自己的对照表，别指望 README 的用词能直接当搜索关键词用。

文档这边说了什么

README_CN.md:212 的 Memory Hub 玩法表里有一行：「Agent Loadout ｜ 给不同 Agent 绑定不同记忆，调整优先级与使用方式」。技术实现 §2 的小标题（README_CN.md:259）是「记忆不是全局 Prompt，而是 Agent 的 Loadout」，正文写：「Chat Memory、Skill、Wiki 和 CodeGraph 都被统一登记为 Memory Asset。Memory Hub 通过 Fixed Binding + ACL 决定某个 Agent 能带走哪些资产：先按 Team、User、Agent 和可见性缩小权限范围，再按当前问题召回。」

注意这段里已经给了一半线索：Fixed Binding。代码那边对应的命名就是 fixed asset。

代码这边叫什么

先看落到存储上的那张表。MemoryCore/src/metadata/store/sqlite-adapter.ts:252-261：

CREATE TABLE IF NOT EXISTS meta_agent_fixed_assets (
  id TEXT PRIMARY KEY,
  agent_id TEXT NOT NULL,
  asset_id TEXT NOT NULL,
  asset_type TEXT NOT NULL,
  injection_mode TEXT NOT NULL DEFAULT 'summary',
  priority INTEGER NOT NULL DEFAULT 50,
  created_by TEXT NOT NULL,
  created_at TEXT NOT NULL,
  UNIQUE(agent_id, asset_id)
);

README 那句「调整优先级与使用方式」，在这张表里就是两列：priority 与 injection_mode，默认值分别是 50 和 'summary'。同文件 :287 还建了一个索引 idx_meta_fixed_agent_prio_created ON meta_agent_fixed_assets(agent_id, priority DESC, created_at DESC)——按 agent、优先级倒序、创建时间倒序取，这与「一个 Agent 的背包按优先级排」的读法是对得上的。UNIQUE(agent_id, asset_id) 则决定了同一个资产在同一个 Agent 上不会被绑两次。

TypeScript 侧的实体类型是 FixedAssetBindingEntity（MemoryCore/src/metadata/types.ts:194-203）。还有一个按类型聚合的计数类型 FixedAssetTypeCounts（:206-211），它的四个字段正好就是四类记忆资产：skill / code_graph / llm_wiki / chat_memory——和 AssetType 枚举（types.ts:24）一致。

表里的 asset_id 那一列会装进什么，也可以对着代码核。四类资产的 ID 前缀分别是：Skill 用 skl- 加 12 字符 base62（MemoryCore/src/core/skill/skill-core.ts:232-235），LLM-Wiki 用 wiki-、Code-Graph 用 cg-，各加 8 位 base36（MemoryKnowledge/src/store/ids.ts:17-18，文件头注释 :4-8 写明「8-char base36 ≈ 36^8 ≈ 2.8e12 space」），Chat Memory 则不是随机串，而是拼出来的 chat_memory-{team_id}-{agent_id}（MemoryCore/src/metadata/utils/chat-memory-asset.ts:6，前缀常量在 :19，拼接函数 buildChatMemoryAssetId 在 :22-24）。也就是说，光看一条绑定记录的 asset_id，你就能判断它是哪类资产。

asset_type 这一列还有一处值得先知道的差异：MemoryCore/src/metadata/types.ts:24 与 v3-meta-schemas.ts:11 都是四值（含 chat_memory），而由 kubb 生成的网关契约 MemoryCore/src/gateway/generated/types.ts:98-102 的 assetTypeEnum 只有 skill / llm_wiki / code_graph 三值，gateway/generated/schemas.ts:46 的 assetTypeSchema 同样是三值。两处枚举不一致，我们只标出位置，不推断原因。

对外的接口是四条，都在 MemoryCore/src/metadata/router/v3-meta-router.ts:264-273，schema 映射在 MemoryCore/src/metadata/router/v3-meta-schemas.ts:433-436：

路径语义（按路由名与参数读）
/v3/meta/agent-fixed-asset/set为某个 agent 设置绑定
/v3/meta/agent-fixed-asset/list列出某个 agent 的绑定
/v3/meta/agent-fixed-asset/list-with-detail带资产详情的列表
/v3/meta/agent-fixed-asset/summary-by-agents按多个 agent 汇总

路径里的 /v3/meta 来自同文件的 V3_PREFIX = "/v3/meta"。这四条只是元数据面 v3 接口的一小部分：v3-meta-schemas.ts:2 的注释自称有「55 公开接口」，我们分别在 schema 映射与 router 映射里各数出 55 条，两处与注释自称的数字一致。另外，绑定之外还有一条与之相关的过滤规则：列表接口用的常量 FILTERED_STATUSES: AssetStatus[] = ["archived", "deprecated", "failed"]（metadata-service.ts:220），而 AssetStatus 一共 6 个取值（metadata/types.ts:26-32）。所以，如果你要在这个仓库里找「Loadout 功能」，搜索关键词应该是 agent-fixed-asset（路由与文件名风格）、FixedAsset（类型名风格）、meta_agent_fixed_assets（表名）这三个，而不是 loadout。

「使用方式」这一列：枚举四个，写入点三个

injection_mode 的类型定义在 MemoryCore/src/metadata/types.ts:34：

export type InjectionMode = "direct" | "summary" | "tool" | "reference";

四个取值。但我们在仓库里读到的实际写入点只有三种：

  • summary：chat_memory 资产创建时写死（MemoryCore/src/metadata/service/metadata-service.ts:1320），另外两个 adapter 也把它作为缺省兜底（sqlite-adapter.ts:1398、mongodb-adapter.ts:1104）。
  • reference：skill 绑定时用（metadata-service.ts:1431，方法注释在 :1349）。
  • tool：knowledge 分配时用（MemoryPanel/src/panel/http/routes/knowledge/allocate-routes.ts:103），该文件头注释 :8 写「injection_mode = ‘tool’（knowledge 是工具型注入，Proxy 渲染 <knowledge_tools>）」。

direct 我们没有找到写入点。在 MemoryProxy/ 里，injection_mode 只作为 DTO 字段出现过一次（MemoryProxy/src/meta/client.ts:91，类型是 injection_mode?: string），我们也没有在 MemoryProxy 中找到按这个字段分支的实现。这里只陈述我们读到的情况：枚举里有四个值，我们核到三个值的写入位置，第四个没核到。至于它是预留、还是在别处、还是我们漏了，我们不做推断。

顺带一提，chat_memory 资产创建的那一段（metadata-service.ts:1293-1322）把四件事都写死了：visibility: "private"、source_type: "auto"、injection_mode: "summary"、priority: 50。README 说的「每个 Agent 创建时自动获得独立记忆」，在代码注释里的表述是「幂等确保 (team, agent) 对应的 chat_memory 资产存在并已绑定到 agent」（metadata-service.ts:1236-1250）。

哪些资产能被绑上去

README 技术实现 §2 说的「Fixed Binding + ACL」，前半截在代码里对应的判定函数是 canBindAsset（MemoryCore/src/metadata/service/permission-checker.ts:155-171）。它按可见性分支：team 与 agent 要求同一个 team；private 要求同 owner 且同 team；task 与 restricted 一律返回 false（:166-169）。

跟绑定挨着的还有权限那一层。默认权限是硬编码的两档（permission-checker.ts:37-38）：ADMIN_ACTIONS = ["read", "write", "assign", "share"]、MEMBER_ACTIONS = ["read"]，判定处写的是 membership.role === "admin" ? ADMIN_ACTIONS : MEMBER_ACTIONS（:117）。而 Permission 枚举一共 6 个取值（MemoryCore/src/metadata/types.ts:37-43）：read / write / delete / assign / share / use——也就是说 delete 与 use 不落在上面任何一档默认权限里。ACL 主体分三类 AclSubjectType = "user" | "team_role" | "agent"（types.ts:45），效果 AclEffect = "allow" | "deny"，但同文件注释写着「一期仅 allow，deny 预留」，匹配代码也只认 acl.effect === "allow"（permission-checker.ts:127）。

这里有一处需要并列陈述的差异：README_CN.md:233 对 restricted 的说明是「通过 User / Role / Agent ACL 精确授权」，而 permission-checker.ts:166-169 里 canBindAsset 对 restricted 直接返回 false。两处讲的不是同一件事——一处讲读权限，一处讲能否固定绑定到 Agent——我们只把两处位置摆出来，不推断哪个覆盖哪个。可见性枚举本身在 README 的表（README_CN.md:230-235）里是 4 个，而 MemoryCore/src/metadata/types.ts:25 里是 5 个，多一个 task。

一张给读源码的人用的对照表

把这篇里核到的映射整理一下，方便你从 README 的词直接跳到代码位置：

README 里的词代码里的东西位置（分支 feat/server_team）
Agent Loadoutmeta_agent_fixed_assets 表MemoryCore/src/metadata/store/sqlite-adapter.ts:252-261
Fixed BindingcanBindAssetMemoryCore/src/metadata/service/permission-checker.ts:155-171
优先级priority（默认 50）同表
使用方式injection_mode（默认 'summary'）同表；枚举在 metadata/types.ts:34
四类记忆资产AssetType 四值MemoryCore/src/metadata/types.ts:24

最后补两条限定，免得把静态阅读当成运行结论。第一，README 的「注意事项」第三条（README_CN.md:283）自己写着「Hub 已支持人工绑定资产；全自动记忆路由仍在迭代」——我们在仓库里也确实只定位到人工绑定这条链路（上面那 4 条路由），没有找到一个明确叫「自动路由」的模块或开关，这里照实记为未核实到对应实现。第二，MemoryCore/package.json 的 version 是 2.0.0-beta.1，同仓 MemoryKnowledge / MemoryPanel / MemoryProxy 三个模块的版本还都是 0.1.0，CHANGELOG.md:13 的最新条目则是 [2.0.1-beta.1]。项目处于 beta 阶段，上面这些表名、路由路径与默认值都可能随版本变动，真要动手时以你手上那份仓库为准。

延伸阅读

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

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员