Semantic recall
Vector Store
把文本块编码为高维 embedding，利用语义相似度做长期召回，是 LLM agent 最常见的长期记忆底座。
Strengths
天然适合语义搜索，适合海量文本知识与历史经验的近似匹配检索。
Risks
精确字段更新、冲突消解、强结构关系查询较弱；检索质量高度依赖 chunking、embedding 模型与索引策略。
Best Fit
偏好、案例、文档、知识片段、历史经验等语义型长期记忆。
Plain Explanation
可以把长期记忆想成代理的资料库。短期记忆像桌面，长期记忆像档案室。桌面放不下的内容，就要存到档案室里；等需要时，再快速找回来。这个档案室不一定只有一种柜子: 有些信息更适合放进向量检索层，有些更适合放进关系库或状态表。向量数据库和嵌入最擅长处理的是“按意思找资料”，但它们不是长期记忆的全部。
When To Use
- 当知识量远超上下文窗口时，需要长期记忆而不是只扩上下文。
- 当用户会跨多次会话回来，或者任务需要回看过去经验时，长期记忆很关键。
- 当检索的不只是固定字段，而是语义相似的历史经验时，向量检索通常会成为主线。
- 当你要保存的是明确状态、用户资料或稳定字段时，关系型或 KV 结构往往比单纯向量化更合适。
Design Questions
- 要记的是语义片段、实体关系，还是稳定业务状态？
- 查询更重近似召回，还是精确命中？
- 同一条记忆是否需要多种表示同时存在？
Evaluation Metrics
真正相关的旧内容，top-k 里能不能经常找回来
embedding + ANN 检索平均要花多久
chunk 切大一点或小一点，结果会不会明显变差
结构化字段更新后，旧值和新值能不能处理干净
多用户、多项目时，记忆会不会互相串
Mainstream Mechanisms
先抓住这一页真正主流的机制主线
这一组不是“所有相关概念”，而是这个维度最核心、最值得先理解的主线。带下划线的机制可以直接点开，会弹出一个更细的解释窗。
Pipeline
把这些机制放回一条工作流里看
如果只看孤立卡片，机制之间的关系会很模糊。把它们放回 pipeline 中，就能看清每一步在系统里承担什么角色，以及问题通常出在什么位置。
1
Chunk
将长文档或经验切成可检索的语义块。
2
Embed
用 embedding 模型将块映射为高维向量。
3
Index
将向量、原文与元数据写入向量索引或混合存储层。
4
Search
对查询向量执行 ANN 搜索并取 top-k 邻近块。
5
Filter & Rerank
按元数据、上下文与相关性进一步筛选和重排。
6
Return
将最终文本块和元数据送回工作记忆层。
Mechanisms
扩展机制与细部取舍
Entity / relation
Graph Memory
以实体和关系为核心，将记忆显式组织成网络结构。
Precise state
Relational / KV
把记忆作为稳定字段和结构化状态管理。
Layered memory
Hybrid Storage
多种存储并存，让语义、关系和精确状态各回各位，向量数据库通常只承担其中一层。
Examples
把这一章放进真实场景里看
研究助手回看旧资料
用户今天问一个框架的架构设计，下周回来再问“上次提到的检索模块有什么风险？”。如果长期记忆能做语义检索，系统能把上次讨论中真正相关的资料重新召回。
Takeaway: 长期记忆的目标不是把所有旧内容塞回 prompt，而是把真正相关的旧资料找回来。
企业文档问答中的 chunking 问题
如果一份设计文档被切得过碎，检索时只能拿到零散句子；切得过大，又会把不相关内容一起带回来。
Takeaway: 长期记忆效果经常不是输在模型，而是输在 chunking 和检索流程。
Architecture Notes
从系统设计角度看这个维度
这一部分补充的是更偏 memory system design 的视角：不只看概念本身，而是看这些机制在真实系统里应该放在哪一层、如何被组织、如何被观测。
长期记忆通常不只是一个数据库，而是一整条链路；而且这条链路里也未必只有一种存储。
向量数据库最有价值的地方，是能对高维向量做高效 ANN 搜索，不只是“帮你把 embedding 存起来”。
如果系统里同时存在知识片段、profile、任务状态和关系结构，就应该接受它们落在不同层，而不是强行全塞进向量库。
如果用了 Hybrid storage，要先说清楚每类信息到底以哪一层为准，不然写着写着就会前后打架。
存储方式必须和后面的检索方式对得上，否则就会出现“明明存进去了，但就是不好找、找回来也不好用”的问题。
Misconceptions
这一章最容易被误解的地方
误解一：有向量数据库就等于已经有长期记忆系统。
误解二：embedding 只要换成更大的模型，检索质量自然会更好。
误解三：检索错了主要怪数据库，实际上 chunking、metadata 和 reranking 同样关键。
Deep Dive
展开理解这个维度
语义搜索为什么是长期记忆的基础
长期记忆里有一大类非常常见的内容，是自然语言知识、案例和历史经验。对这类内容来说，语义搜索比关键词匹配更实用，因为它能找“意思相近”的内容。这就是 embedding 最有用的地方。但这说的是长期记忆里的一个大类问题，不是说所有长期记忆都必须走这条路。
- embedding 会把文本映射为高维稠密向量，语义相近的内容在向量空间中更接近。
- 查询时，系统不是逐词匹配，而是比较查询向量与文档向量之间的相似度。
- 因此 agent 能检索到“表达不同但意思相近”的经验与知识块。
- 但如果你要存的是明确字段和稳定状态，未必需要先把它们向量化。
向量数据库解决的是长期记忆里的“语义检索层”，不是全部长期记忆
向量数据库的价值，不是替代所有长期记忆，而是把“按意思找资料”这件事做得可扩展。它负责的是长期记忆中的语义检索层: 当你有很多文本块、案例和历史经验，需要在海量向量里快速找出和当前问题最接近的那几条内容时，它就很有用。
- 真实系统不会线性扫描所有向量，而是依赖 HNSW、IVF 等 ANN 索引。
- ANN 用可接受的近似精度换取大幅速度提升，这对实时 agent 很关键。
- 数据库通常还要同时保存原始文本块与元数据，而不仅仅是向量本身。
- 但 user profile、权限、任务状态这些内容，往往仍然会放在关系型或 KV 层里。
长期记忆的索引与查询流程比“选哪家库”更重要
很多团队会纠结该选 Pinecone、Milvus 还是 Chroma，但真正更影响效果的，通常是 chunk 怎么切、embedding 怎么做、检索链路怎么走。
- 长文档先要切成合适的块，chunk 太大或太小都会影响召回质量。
- 查询时必须使用与建库时一致的 embedding 模型，否则语义空间会错位。
- 最终返回给 agent 的不是向量，而是对应的原始文本块和元数据。
如何理解长期记忆的真实权衡
长期记忆最难的地方，不是看能存多少，也不是默认选某一种存储，而是看系统能不能用合适的表示，把远处但真正有用的记忆带回当前推理。
- 语义召回能力越强，越依赖 embedding 质量与索引策略。
- 精确状态管理越重要，越需要结构化存储和明确更新逻辑。
- 索引越追求速度，越可能牺牲部分精确度，这是 ANN 的基本取舍。
- 长期记忆越大，越要依赖 metadata、filtering 与后续 reranking 来维持质量。
Failure Modes
常见失败模式
把向量数据库当成完整长期记忆系统，忽略长期记忆里还有状态层、关系层和治理问题
chunk 切分不合理，导致语义片段过碎或过大，检索质量下降
用单一向量库承接所有信息，导致 profile、状态、知识混杂
没有时间戳和来源，无法判断哪条长期记忆更新更可信
ANN 速度很快，但没有后续过滤或 reranking，导致结果近似却不够可用
Previous Chapter
1. Short-term Memory
短期记忆怎么管
看当前上下文怎么保留与压缩
Next Chapter
3. Working Memory
工作记忆怎么组装
看真正喂给模型的上下文如何编排