第 20 章 Memory 的读取机制¶

写入只是 Memory 的一半。真正决定系统效果的，往往是“该不该取出来”和“取出来以后怎么用”。如果读取机制过于激进，系统会频繁把旧信息带回当前任务，造成偏见和干扰；如果读取机制过于保守，Memory 又失去意义。

20.1 基于任务读取¶

最稳妥的做法，是让记忆读取围绕当前任务发生，而不是围绕“用户的全部历史”发生。系统应先判断当前任务需要什么长期信息，再按需召回，而不是每轮都塞进所有可用记忆。

对偏好类和背景类信息，可以按用户维度召回，但仍应有适用范围。例如“偏好简洁回答”可能广泛适用，而“本周正在处理某个项目”则未必适合所有任务。

如果一个用户已经积累了多条长期信息，系统还需要判断哪条更相关、哪条更新、哪条更可信。没有排序机制的读取，往往会让过时或低价值信息抢占上下文。

Memory 取回之后也不一定原样进入模型。很多时候更合理的做法是把它们转换成简短状态说明或约束提示，而不是回灌长文本原记录。

flowchart LR
    A["当前任务"] --> B["判断是否需要记忆"]
    B --> C["按用户 / 任务召回候选记忆"]
    C --> D["相关性排序"]
    D --> E["压缩为状态或约束提示"]
    E --> F["注入本轮上下文"]

Memory 的读取核心是相关性控制。记忆只有在正确的任务、正确的时机、以正确的形式被取回时，才会真正提高系统质量。下一章会继续讨论 Memory 最难处理的一面：写错、冲突、过期和污染。