第 2 章 智能体记忆核心概念

本章不碰复杂配置，只建立三个心智模型：为什么需要结构化记忆、memU 的三层架构、写入与读取如何分工。

2.1 大模型的「失忆症」

纯 LLM 对话存在天然缺陷：

工业界常见补救方案：

方案 A：全量塞入 System Prompt     → 窗口不够、成本爆炸
方案 B：向量 RAG                    → 片段化、缺乏主题结构
方案 C：外部 KV / 数据库            → 需人工建模「记什么」
方案 D：memU 结构化工作区           → 自动提取 + 分层 + 可追溯
​

memU 属于方案 D 的进化：不是简单存向量，而是编译成可浏览、可排序、可导出的记忆树。

2.2 「文件系统即记忆」

memU 的核心隐喻：记忆像文件系统一样组织。

这种设计带来三个工程优势：

1. 可浏览：LLM 可以先读 Category 摘要，再决定是否深入 Item
2. 可审计：每条 MemoryItem 都能追溯到 Resource 来源
3. 可导出：整棵记忆树可渲染为人类可读的 Markdown（见第 10 章）

2.3 三层记忆架构

memU 的数据自底向上分为三层（详见第 3 章）：

┌─────────────────────────────────────────┐
│  Layer 3: MemoryCategory（主题文件夹）    │  ← 宽泛查询、紧凑上下文
│  例：user_preferences, project_goals     │
├─────────────────────────────────────────┤
│  Layer 2: MemoryItem（原子记忆文件）      │  ← 精确事实、偏好、技能
│  类型：profile | event | knowledge |     │
│        behavior | skill | tool           │
├─────────────────────────────────────────┤
│  Layer 1: Resource（原始来源）           │  ← 溯源、重读原文
│  模态：conversation | document |       │
│        image | video | audio             │
└─────────────────────────────────────────┘
​

检索方向是自上而下：先匹配 Category → 再筛 Item → 必要时回到 Resource 读原文。这与传统 RAG「扁平向量 Top-K」形成对比。

2.4 六种记忆类型（memory_type）

LLM 在 memorize 阶段会把内容分类为以下类型：

类型化提取的价值：检索时可以按场景过滤——编码智能体多召回 tool / skill，客服助手多召回 profile / event。

2.5 两大运行时操作

WRITE：memorize()

把原始来源编译进记忆工作区，内部流水线（第 5 章详解）：

Ingest → Preprocess → Extract → Organize → Persist
  │          │           │          │          │
  存Resource  解析/描述   LLM提取    分类+向量   写数据库
​

READ：retrieve()

按查询召回相关上下文，内部流水线（第 6 章详解）：

Route → Category Recall → Sufficiency? → Item Recall → Resource Recall → Build Response
  │           │              │              │               │
 意图路由    主题层匹配      够了吗？        细项层          原文层
​

两种检索策略：

2.6 作用域（Scope）概念

memU 从设计之初支持多租户 / 多用户 / 多智能体隔离：

• 写入时通过 user={"user_id": "..."} 绑定作用域
• 检索时通过 where={"user_id": "..."} 过滤
• 作用域字段会传播到 Resource、Item、Category 各层

这意味着：同一套 MemoryService 实例可以服务多个用户，只要 where 正确即可。第 4 章会讲如何配置 UserConfig。

2.7 memU vs 传统 RAG（决策表）

结论：memU 不是要废弃向量检索，而是在其之上增加结构化中间层，让智能体「先知道主题，再找细节」。

2.8 Workflow 引擎（原理一瞥）

自托管版 memU 内部用 Workflow Pipeline 编排各步骤：

• 每个步骤声明：需要的输入键、产出的输出键、能力标签（llm / vector / db / io / vision）
• PipelineManager 在注册时校验依赖
• 支持运行时替换步骤（高级定制，见第 10 章）

对你而言，公开 API 仍是 memorize() 与 retrieve()；Workflow 是「盖在 API 下面的发动机」。

2.9 本章小结

• 智能体需要结构化、可追溯、可分层读取的记忆，而非扁平向量堆。
• memU 三层：Resource → MemoryItem → MemoryCategory。
• 两个核心操作：memorize() 编译写入，retrieve() 分层读取。
• 六种 memory_type 覆盖画像、事件、知识、行为、技能、工具。

动手实验

1. 画一张你自己的智能体架构图：在用户消息进入 LLM 之前，retrieve() 的返回应注入到哪里？（System Prompt？Tool 上下文？）
2. 列举你的应用场景需要哪几种 memory_type，各举一条真实例子。
3. 阅读附录 A 术语表中的「充分性检查」「Query Rewrite」，预习第 6 章。

下一章：第 3 章 — 数据模型详解。

参见：第 0 章架构图；第 5、6 章流水线细节。