TencentDB Agent Memory · 第 3 章 记忆资产统一模型

TencentDB Agent Memory · 第 3 章 记忆资产统一模型

章节摘要:Agent Memory 最容易被忽视、却是最关键的设计,是它把四类形态迥异的内容——对话里抽出的人 和事、做完工作提炼的做法、整理过的文档、索引过的代码——统统登记为同一种东西:记忆资产(Memory Asset)。正因为统一,它们才能用同一套规则被治理:有 Owner 归属、有版本号、有状态机、有可见性、有使用计数、有 Agent 绑定。本章把这个统一模型拆开:先讲资产如何被登记与附带哪些元数据,再讲 Owner / 版本 / 状态构成的资产生命周期,接着是四级可见性(private / team / restricted / agent)如何兼顾共享与隐私,最后落到 Fixed Binding + ACL 这套「先过滤权限范围、再召回内容」的装配机制。读完本章你会理解为什么「团队可以共享经验,却不必共享全部隐私」在工程上是如何成立的。

学习目标

阅读完本章,你应当能够:

1. 说出 Memory Asset 这个统一抽象带来了哪些治理红利
2. 列出资产生命周期里的关键字段(Owner / 版本 / 状态)并解释它们的协作
3. 用四级可见性模型描述一条资产在不同范围内的可读性
4. 解释 Fixed Binding + ACL 的「先过滤后召回」流程,并指出它与传统全局 Prompt 的根本差异

核心概念速览

一句话金句:统一登记是治理的前提——只有当四类内容长得一样(都有 Owner、版本、可见性),它们才能被同一套「谁可以用、哪个版本有效、应该给谁」的规则管理。

子章节导航

01 Memory Asset 登记与元数据

讲清一条资产被登记时附带的元数据契约:Owner、版本、状态、可见性、使用次数、Agent 绑定,以及这套元数据如何让四类异构内容共享同一套治理 API。

02 Owner / 版本 / 状态的资产生命周期

拆解资产从「新建 → 审核 → 分享 → 配装 → 归档」的状态流转,讲清 Owner 自动获得管理权限、版本号支撑回滚、状态字段控制可用性。

03 可见性模型:private / team / restricted / agent

逐级讲清四种可见性的语义边界,强调「新记忆默认私有、分享是明确动作」,并用表格对比四者在「谁能读 / 谁能管 / 典型场景」上的差异。

04 Fixed Binding + ACL:从权限范围到召回

讲清装配的核心机制——先按 Team / User / Agent / 可见性缩小候选集,再对缩小后的集合做检索,从而实现「换 Agent 只需重新装配,不必重新训练」。

子章节之间的逻辑关系

本章四节是「登记 → 生命周期 → 可见性 → 装配」的层层递进,前三节讲「资产本身长什么样」,第四节讲「资产如何到达 Agent」:

┌────────────┐    ┌────────────┐    ┌────────────┐    ┌────────────┐
│ 01 登记模型 │──▶│ 02 生命周期 │──▶│ 03 可见性   │──▶│ 04 装配机制 │
│ 统一元数据  │    │ 归谁/几版/可用│    │ 谁能读      │    │ 怎么到Agent │
└────────────┘    └────────────┘    └────────────┘    └────────────┘
                                                          │
                                                          ▼
                                                 (第 5 章操作台)
​

铺垫说明:第 3 章只讲「资产模型的规则」,不展开「人在哪里操作这些规则」——那是第 5 章 Memory Hub 的事;也不展开「资产内部的内容如何分层」——那是第 4 章四层记忆的事。本章是治理逻辑的骨架,第 4、5 章是它的血肉与表皮。

前置知识与后续延伸

前置知识:

• 第 2 章的四类资产总览与四组件拓扑
• 对「权限」「角色」有基本概念(用过任何带权限系统的产品即可)

本章为后续章节奠定的基础:

• 装配机制是第 5 章 Agent Loadout(装备背包)的底层规则
• 可见性模型是第 8 章代理层 sessionInit(确定 team/agent/task)生效的依据
• 「先过滤后召回」是第 6 章召回引擎执行检索前的隐含前提