上下文工程那页讲了记忆的分层（放在哪：窗口内 / scratchpad / 外部存储），这页讲另一条正交的轴——类型（存的是什么）。认知科学的三分法搬到 Agent 上意外地合身，因为三种记忆的写入时机和取回方式完全不同👇
三种类型对应三套基建：情景记忆要日志存储 + 时间索引，语义记忆要蒸馏管线 + 向量检索，程序记忆只要一个会被自动加载的文件。把"用户的包管理器偏好"塞进会话日志里，或者给 CLAUDE.md 配向量库，都是类型错配——存得进去，取不出来。
新手做记忆系统的第一反应是"把对话全存了"——存储确实便宜，但检索时每一条垃圾都在稀释信号。成熟的写入管线是一个漏斗：原始对话 → 蒸馏候选 → 查重处理冲突 → 入库。点击"下一步"，看一段对话怎么被消化成两条记忆👇
显式：用户说"记住我用 pnpm"——立刻写，且置信度最高；隐式：会话结束或压缩前，让模型自问"这次有什么值得下次记住的"。隐式写入要更保守：置信度不够的宁可不记，记错一条的代价（每个未来会话开局就被污染）远大于漏记一条。
读端就是 RAG。入门篇一句话带过的"检索最相关的几块"，拆开是一条五站管线，每一站都有自己的翻车方式。先看准备工作，再逐站跑一个真实问题👇
① 切块（chunking）：把文档切成段。太碎——"最多结转 5 天"被切离了"年假"主语，检索回来没法用；太大——整章进上下文，95% 是噪音。常用策略：按标题/段落等语义边界切，几百 token 一块，相邻块留重叠。
② 向量化（embedding）入库：每块算一个向量存进向量库。这一步离线做一次，之后增量更新——文档改了块没重算，是线上答案过时的常见原因。
检索质量（该找到的块找到了吗）和生成质量（找到了之后答得对吗）要分开测——答案错了先看是哪一半的锅。检索不行调切块/embedding/重排，生成不行调提示词。混在一起测就只能玄学调参。
上面的管线是固定的：每个问题检索一次、用就用了。Agentic RAG 换一个思路——把检索做成一个工具，让模型自己决定查不查、查什么、查几次。同一个问题，两种做法对比👇
Agentic 检索每多跳一次就是一轮完整的模型调用，延迟和成本随跳数线性涨；而且"再查一次"和"原地打转"只有一线之隔——架构模式那页 ReAct 的防打转三件套（步数预算、重复检测、失败清单）在这里原样适用。简单问答用固定管线，开放调研才值得上 Agentic。
上下文工程那页讲过窗口内的四种失效，长期记忆有自己的四种慢性病——而且更隐蔽：它们跨会话潜伏，每个新会话开局就发作。点击查看病例和处方👇
记忆系统是替用户保管信息，不是悄悄给用户建档案。用户应该能看到系统记住了什么、能修改、能一键忘掉——这既是合规要求，也是发现记忆污染的最后一道防线（用户比任何 eval 都更快发现"它把我记成谁了"）。
5 道题。答错没关系，解析比答案重要。