用户记忆和知识库

用户记忆不保存每一句对话。每次对话结束后，框架会额外调用一次 LLM，提取、压缩并审查将来用得上的事实。这和上下文学习不同，上下文学习只在当前窗口内有效。

好的提取要同时满足三条：有选择（丢掉短期细节）、有抽象（把这次的选择归纳成长期偏好）、有结构（按可检索的字段存）。

三层次评估框架

先定标尺，再谈设计。LoCoMo 基准构造了平均约 300 轮、最多 35 个会话的超长对话，考三类任务：问答（单跳、多跳、时间推理、开放域、对抗）、事件摘要和多模态对话生成。作者结合各类基准和商业产品，把记忆能力归纳为八项（这是作者自己的归纳口径），再合并成三个逐级递进的层次。

记忆设计可以拆成三个互相独立的问题。先看“放哪里”：轨迹是本次运行的完整记录（用户消息 + 模型回复 + 工具结果），按时间只追加、不修改；用户长期记忆跨会话、跨实例保存，通常是绑定用户 ID 的键值，Agent 通过工具调用显式读写。另外还有业务状态，即开发者定义的任务阶段，比如“需要澄清”“等待付款”。

轨迹是流水账，长期记忆是档案。流水账只追加；档案会被反复改写、合并、淘汰。每轮真正发给模型的上下文可以压缩或摘要，原始记录保留多少，取决于审计要求。

#1 user: 订下周五去东京，要靠窗
#2 tool: flight_search → 3 options
#3 agent: 推荐 ANA 直飞
#4 user: 用 MileagePlus 12345678

seat_pref: window
trip: Tokyo, ANA, 下周五
loyalty.united: 12345678

四种存储格式：简单性递减，表达力递增

实践中多用混合模式：关键且数量少的数据（偏好、关键人物关系）用 Advanced JSON Cards，保证能检索到；量大但不关键的对话事实用 Simple Notes，降低成本。

进阶：把用户写成可执行代码（User as Code）

前四种格式都是文本：召回单条事实很擅长，但聚合、冲突检测、约束检查都得交给 LLM “心算”。User as Code 把用户状态写成带类型的对象，规则写成普通函数，表示和推理用同一种可验证的介质。机制借鉴“预写日志 + 检查点”：会话结束后先把事实追加到只增日志，再定期从完整日志重建带类型的状态。

state = {
  passport: PassportInfo(number="AB1234567",
    country="US", expiry_date=date(2025,2,18)),
  trips: [Trip(destination="Tokyo",
    departure_date=date(2025,1,15),
    is_international=true), ...],
}
# 聚合：2025 年国际行程数
count(trip for trip in state.trips
  if trip.is_international
  and year(trip.departure_date)==2025)  # => 2

存什么：认知科学的三类长期记忆

工作记忆对应上下文窗口（核心是轨迹，也可能包括从长期记忆加载进来的内容）。长期记忆分三类：

Mem0 的演进是一个很好的系统设计案例。2025 年论文（arXiv:2504.19413）和 v2 在写入时消除冲突；2026 年 4 月发布的 v3 改成只追加写入，冲突留到检索时靠相关性和时间来判断。

v3 不删旧事实：既不会因为一次错误的 UPDATE/DELETE 丢掉历史，LLM 调用也更少。

Memobase：画像槽位 + 事件时间线 + 缓冲批处理

Memobase（memodb-io/memobase）不做通用流水线，只做“用户画像”。画像（Profile）是开发者可配置的两级槽位（主题 → 子主题），存稳定属性；事件记忆按时间线记录经历，回答“上次讨论预算是什么时候”这类问题。对话先进缓冲区，积累到一定规模或时限才统一提取一次，摊薄 LLM 成本，查询侧只读整理好的数据，延迟低。

图 3-4 · 多类型记忆协同的参考架构

只往里加的记忆库会“爆炸”：占存储，还会降低检索准确率。可以分三层压缩：

日志脱敏：用本地小模型找出 PII

挑战在于：既要用用户信息做个性化，又不能让敏感数据暴露在 LLM 上下文和系统日志里。实验 3-3 的 log-sanitization 项目通过 Ollama 调用本地 Qwen3 0.6B（CPU 和消费级设备能跑，也可换成 qwen3:1.7b、qwen3:4b）。之所以不用云端 API，是因为日志本身就可能含敏感信息，送到云端脱敏违背了初衷。

{ "type": "身份证号 | 银行卡号 | 地址 | 密码 …",
  "position": [起, 止],
  "confidence": … }   // JSON Schema 结构化输出

表示和管理解决的是“怎么存”。记忆增长到成千上万条以后，还要能快速找到相关的那几条，这就是 RAG 的任务。它服务于共享知识库，本章末尾也会反过来用于用户记忆。

RAG 把 LLM 的推理和生成能力，与外部知识库的广度和时效结合起来。模型的训练数据有截止日期，知识库可以随时更新。检索器负责找出相关片段，生成器（通常是 LLM）把片段当上下文来作答。

query = "退款流程"
results = retriever.search(query, top_k=2)
# ["退款政策：订单签收后7天内可申请全额退款，需提供订单号。退款将在3-5个工作日内...",
#  "退款操作步骤：1. 进入'我的订单' 2. 选择需退款的订单 3. 点击'申请退款'..."]
answer = llm.generate(system="你是客服助手。", context=results, question=query)

文档分块：能检索之前的离线工序

分块有两个理由：嵌入模型有输入长度限制，而且整篇文档压成一个向量，几个主题混在一起，哪个都表达不准（和 Enhanced Notes 的问题同源）；另外，检索只该把相关的部分放进上下文，块太大会带进无关内容。

块太小，语义不完整（“该公司收入增长了 3%”，哪家公司？哪个季度？）；块太大，主题被稀释。常见起点是每块 256–1024 token、相邻块重叠 10%–20%，再按实测调。

嵌入把文本变成一串数字（向量），语义相近的文本，向量也相近。“稠密”是指每个维度都有值，稀疏向量则大部分维度为零。衡量远近通常用余弦相似度：cos θ = A·B / (|A|·|B|)。

比较的是夹角，不是长度。内容相同、长度不同的两篇文档，向量长度不同但方向一致，余弦相似度能认出它们语义相同。

稀疏向量维度极高，只有文档里出现的词那几维非零。理论基础是词袋模型：只看哪些词出现、出现几次，不管词序，“猫追狗”和“狗追猫”一样。TF-IDF 的直觉是：一个词在本文档出现越多、在整个语料里越少见，就越重要。

稀疏检索在技术代码、人名这类查询上表现极好，但不懂同义词：查一个词只能找到字面相同的文档。项目还展示了倒排索引：从“词”反查“包含它的文档”，就像书后的术语索引页（查 TCP → 第 45、112、203 页）。

两种方法各有盲区：稠密检索搜“HTTP-403”可能返回“服务器错误”的泛泛讨论；稀疏检索搜“kitty”找不到只写了“cat”的文档。两个引擎都跑一遍再合并，难点是两组分数尺度完全不同：余弦通常在 0–1，BM25 可以是 0 到几十。

RRF 不看原始分数，只看排名：得分 = Σ 1/(k + rank)，k 常取 60。它简单稳健，但丢掉了分数里的相关性信息。重排序本来就值得加，不是为了弥补 RRF 的损失：它换用了更强的匹配方式。

实验 3-6 的结论：没有哪种单一检索策略在所有场景都可靠。retrieval-pipeline 的测试案例覆盖语义相似、精确名称、多语言、技术代码四类，它会展示每个文档在稠密、稀疏两路里的原始排名和重排序后的变化，被单一方法低估的相关文档会被提到顶端。

混合检索解决的是“给定一堆块，找出最相关的几个”。更根本的问题是这些块本身该怎么组织。把文档切成互不相关的扁平块，就丢掉了知识原有的层次和跨文档关联，就像靠翻字典里的随机词条去读懂一部小说。

未经提炼和结构化的知识，模型用不可靠：不管是放进向量库、检索后注入，还是直接塞进长上下文。必须在索引阶段多花算力，主动做提炼、抽象和结构化。

两条结构化路线：树（RAPTOR）和图（GraphRAG）

(我, 有计划, 海滩旅行)
(我, 有备选计划, 博物馆旅行)

火山引擎开源的 OpenViking 提出第三种思路：把记忆、资源、技能都映射成虚拟文件系统里的目录和文件，每个条目有唯一 URI。viking:// 不指向具体的物理位置，从内存、磁盘还是远程加载，由框架决定。

viking://
├── resources/        # 外部知识：文档、代码库、网页
├── user/memories/    # 用户记忆：偏好、习惯
└── agent/            # Agent 自身
    ├── skills/
    └── memories/
每个目录自动生成 .abstract (L0) 和 .overview (L1)

知识库上线以后会不断收到新信息。只做局部更新不整理，会越积越乱；只做定期重写，新信息又不能及时生效。所以需要两条路径：事件触发的增量更新，和周期触发的全量整理。

把知识库当代码库：Markdown 知识、用户记忆文件、规则文档都进 Git。任何模型都不能绕过审核直接改主分支或线上向量库。

PR 要记录证据标识、知识库版本、审核意见和最终决定，保证线上每条知识都能说清“来自哪条证据、谁在什么时候批准”。

定期整理：对应第九章的“睡眠学习”

整理产物同样走 Proposer → 异源 Reviewer；diff 大时按目录或主题拆成多个 PR，但共享同一份整理计划和覆盖清单。全部合入后，重建全量索引，并回放典型检索和问答用例。触发条件：按时间（每周或每月），或新增条目数、冲突数、检索质量下降超过阈值。

传统 RAG 是单向管道：查询直接检索，结果直接注入，模型直接作答，好比在图书馆只能搜一次就得交报告。智能体化 RAG 像研究员，可以反复查不同书架、调整搜索策略、交叉验证，材料够了再动笔。检索不再是自动执行的前置步骤，而是 Agent 用 ReAct（思考 → 行动 → 观察）循环随时调用的工具。

价值在于“解决问题”而不是“回答问题”：用一些响应速度换来复杂问题上的鲁棒性。简单问题（“正当防卫怎么规定？”）一次检索就够，传统 RAG 更快，质量差不多。

实验 3-9 · 把对话历史当作知识库

agentic-rag-for-user-memory 按固定窗口（如每 20 轮）给对话历史分块建索引，再给 Agent 一个 search_user_memory 工具。第一层问题（layer1/01_bank_account_setup.yaml：“我的支票账户号码是多少？”）搜一次就够。

这就是分块一节留下的伏笔。“该公司第二季度的收入增长了 3%”脱离原文后，答不出代词指的是谁、报告是什么时候发的、和哪条产品线有关。Anthropic 提出的 Contextual Retrieval 在建索引前，先让 LLM 给每个块生成一段简短的前缀，把前缀和原块拼起来再索引。

一个前缀同时帮到两路检索：BM25 多了能精确匹配的关键词（ACME、2025 年第二季度），向量也多了关键的语义背景。

实验 3-11 · 用在用户记忆上

孤立的“好的，就订这个吧”没有任何信息量，只有知道上文是“从上海到西雅图的 500 美元单程机票”才有意义。在实验 3-9 的框架上，索引前给每个对话块生成背景前缀。

{"passport": {"person": "Jessica",
  "expiry": "2025-02-18"},
 "trip": {"destination": "Tokyo",
  "month": "一月"}}

很多领域的知识藏在海量结构化案例里，而不在文档里。决定判决的“知识”不只写在法条中，更体现在成千上万份判例里法官如何权衡动机、伤害程度、自首、社会影响等因素，就像资深医生的“直觉”来自大量病例。这需要从“信息检索”跳到“知识发现”。

知识库不一定只是个静态仓库：Agent 可以先把数据读懂，提炼出结构化的决策逻辑，再按这套逻辑回答问题。

前沿：多模态记忆

一张脸、一个人的嗓音，很难用文字描述，前面的文本记忆机制存不下。

常见误区