Memory Asset 登记与元数据

文档摘要

Memory Asset 登记与元数据本节摘要:第 2 章我们看到四类资产被「统一登记」,本节打开这个统一抽象看个究竟。一条记忆资产被登记时,会附带一套统一的元数据契约:Owner(归谁)、版本(第几版)、状态(可用与否)、可见性(谁能读)、使用计数(被召回多少次)、Agent 绑定(配装给谁)。这套元数据让四类形态迥异的内容(Chat Memory/Skill/Wiki/CodeGraph)共享同一套治理 API——审核、分享、路由、收回,一套规则管四类。本节讲清这套元数据契约的字段与协作,为你理解后续的资产生命周期与装配机制打下基础。

Memory Asset 登记与元数据

本节摘要:第 2 章我们看到四类资产被「统一登记」,本节打开这个统一抽象看个究竟。一条记忆资产被登记时,会附带一套统一的元数据契约:Owner(归谁)、版本(第几版)、状态(可用与否)、可见性(谁能读)、使用计数(被召回多少次)、Agent 绑定(配装给谁)。这套元数据让四类形态迥异的内容(Chat Memory/Skill/Wiki/CodeGraph)共享同一套治理 API——审核、分享、路由、收回,一套规则管四类。本节讲清这套元数据契约的字段与协作,为你理解后续的资产生命周期与装配机制打下基础。

一、统一登记的元数据契约

一条 Memory Asset 登记时,至少带这些字段:

字段	含义	作用
Owner	资产归属者	决定管理权限(Owner 自动获得管理权)
版本	资产的版本号	支持回滚、区分新旧
状态	新建/审核中/可用/归档	控制资产是否参与召回
可见性	private/team/restricted/agent	控制谁能读
使用计数	被召回次数	评估资产价值、辅助排序
Agent 绑定	配装给哪些 Agent	决定哪些 Agent 能带上它


┌──────────────────────────────────────────────┐
│  Memory Asset(任一类:ChatMemory/Skill/Wiki/CG)│
├──────────────────────────────────────────────┤
│  Owner:     alice@team                       │
│  版本:       v3                               │
│  状态:       可用                              │
│  可见性:     team                             │
│  使用计数:   42                               │
│  绑定 Agent: [Builder, Reviewer]              │
└──────────────────────────────────────────────┘

关键概念:这套字段对所有四类资产都成立——一条 Chat Memory 和一条 Skill 在「治理」层面长得一模一样。这就是「统一」的含义:不是统一内容,而是统一治理规则。

二、为什么「统一元数据」是治理的前提

设想一个反面:如果四类资产各有各的字段、各有各的 API,会发生什么?


不统一的代价(反面设想)
  审核 Chat Memory → 用 A 接口、A 字段
  审核 Skill       → 用 B 接口、B 字段
  审核 Wiki        → 用 C 接口、C 字段
  审核 CodeGraph   → 用 D 接口、D 字段
  → 四套审核、四套分享、四套收回、四套路由……治理复杂度爆炸

统一之后:


统一的红利
  审核任何资产  → 同一个接口、同一套字段
  分享任何资产  → 同一套可见性规则
  收回任何资产  → 同一套状态流转
  → 一套治理规则,管四类资产

💡 技巧:这套「统一元数据」思路,本质上是把「治理」与「内容」解耦——内容各异,治理同构。这是一种典型的「公共抽象」设计:抓四类资产的共性(都要归属、版本、可见性),抽象成统一接口。第 5 章你会看到控制台如何在这个统一抽象上做操作。

三、元数据如何参与召回

这些元数据不只是给人看的标签,它们直接参与召回的「过滤」环节:


召回前的过滤(由元数据驱动)
  全部资产
    │
    ├─ 过滤:状态=可用        (归档的不召回)
    ├─ 过滤:可见性允许当前用户 (private 只 Owner,team 要成员……)
    ├─ 过滤:绑定含当前 Agent  (Loadout 装配)
    │
    ▼
  候选集(缩小后)
    │
    ▼
  按当前问题做检索(BM25+向量+RRF,第6章)

注意这个顺序:先用元数据缩小范围,再做检索。这就是「先过滤后召回」——它是整套装配机制的核心,第 4 小节会展开。「使用计数」则在检索后参与排序(常用者优先),让高频资产更容易被召回。

四、四类资产在元数据上的细微差异

虽然元数据契约统一,四类资产在某些字段上仍有「适合自己」的细微差异,这是合理的:

资产	元数据上的特点
Chat Memory	内部还有 L0-L3 分层,每层可能独立登记
Skill	「版本」特别重要(可执行流程要能回滚);多「触发边界」字段
Wiki	「状态」含 ready(异步构建完成才可用);多「来源文档」字段
CodeGraph	同样有 ready 状态;多「源仓库」与「同步时间」字段

⚠️ 注意:这些差异是「在统一契约上的扩展」,不是「另搞一套」。基础字段(Owner/版本/状态/可见性)四类都有且语义一致,差异只在额外字段。理解这一点,你就不会觉得四类资产是「四个系统」。

本节要点回顾

统一元数据契约:Owner/版本/状态/可见性/使用计数/Agent 绑定,四类资产共享。
统一的本质:统一治理规则(非统一内容)——审核/分享/收回/路由一套规则管四类。
元数据参与召回:状态/可见性/绑定先缩小候选集,再检索,使用计数参与排序。
差异是扩展非另起:四类在统一契约上有各自额外字段(如 Skill 的触发边界、Wiki 的 ready),基础字段一致。
解耦设计:治理与内容解耦,是典型的公共抽象——抓共性、抽象统一接口。

登记模型清楚了,下一节看这些资产如何随时间流转——Owner、版本、状态构成的资产生命周期。