AI 记忆、RAG 与上下文管理是什么关系？

学习助手知道 Python 生成器的定义，却不知道你上次看到哪里；它能找到你说过“主要写 Java”，却把一周前的计划当成今天的任务。两种失败表面上都像缺少上下文，实际发生在不同环节。设计之前，先问这次回答需要什么信息、信息从哪里来，以及它在什么时候仍然有效。

本文是 AI 记忆工程专题的第一篇。我们用同一个学习助手拆开几个容易混用的概念，再把它们放回一次请求的完整链路。以下职责划分是本专题的工程设计，不是要求所有框架采用相同名称。

从四种信息开始划分

Alice 说“我主要写 Java”，表达的是个人背景；“我最近在学习 Python”表达阶段性目标；“我学到 Python 生成器”表达学习进度；“生成器通过什么机制暂停执行”则需要语言知识。这四项信息可能同时帮助回答，但来源、更新频率和作用范围都不同。

划分的价值是让变更有落点。如果用户不再学习 Python，应该更新目标，不应删除 Python 文档；如果流程执行失败，应该恢复任务状态，不应凭一句历史摘要猜测哪个工具已经成功。来源相同也不意味着必须进入同一个存储：一段对话可以同时生成工作流事件和候选记忆。

上下文窗口与上下文管理

模型每次推理只能使用实际传入的信息。上下文管理负责选择和装配这次输入，包括当前问题、会话片段、检索证据、工具结果和必要约束。即使底层保存了十年的历史，这次没有送入模型的内容也不会因为“曾经存过”而自动生效。

因此，扩展窗口容量与构建长期记忆解决的是不同问题。窗口更大，可以容纳更多原始材料；记忆系统仍需处理身份、有效期、更新与撤回。把旧计划、模型猜测、重复记录全部塞进去，未必比少量明确证据更有帮助。是否有帮助需要实验验证，不能仅从容量推断。

本专题的 Java 示例把上下文装配作为独立方法：先获得符合用户范围和时间条件的候选，再按分数排序，最后在预算内按整条事实加入。它使用字符数模拟容量约束，明确不声称等于模型 Token 数。真实服务应使用目标模型对应的计数方式，并给问题、工具和输出预留空间。

RAG 在链路中承担什么

RAG 通常通过外部检索为生成提供材料。检索对象可以是知识文档，也可以是记忆、工单、代码或其他业务记录。长期记忆可以使用 RAG 的方式被消费，但记忆的形成、纠正与删除仍是另外一组职责。两者更适合被理解为能够组合的机制。

例如，用户问“结合我的 Java 背景解释 Python 生成器”。知识检索返回生成器相关文档，记忆检索返回主要语言，当前消息给出解释目标。上下文装配把三者连接起来，生成模块形成回答。若文档错误，要修正文档或检索；若背景已经变成 Kotlin，要修正记忆有效性；若两者都正确却回答跑题，要检查装配或生成。

不要把“用了向量数据库”当成具有长期记忆的充分条件。向量库能保存和检索表示，但何时写入、同一事件如何去重、事实是否失效、哪个用户有权访问，都需要上层定义。相反，一个简单的结构化偏好表也可能有效支持跨会话个性化，不必先引入复杂检索栈。

短期与长期不是保存天数

一个持续三个月的会话仍可能只有会话范围的状态；一条刚刚写入的表达偏好却可能立即被另一个会话使用。区分短期与长期时，访问范围往往比保存时长更有价值。框架命名各不相同，设计文档应把“谁能读取、跨不跨会话”写清楚。

LangChain 的官方说明将会话内状态与跨会话记忆分开，并讨论事实、经历和规则等不同记忆类型。这提供了组织信息的视角，但具体如何提取、持久化和治理，仍需要应用实现。参考文档

在学习助手里，“我偏好简洁解释”可能影响多个学习会话；“这道题先不要给答案”只约束当前练习。若把后者自动提升为长期偏好，几天后用户要求答案时系统可能仍然拒绝。提升范围是一项业务决策，应有明确证据或产品规则，而不是由存储位置偶然决定。

用户画像、情景记录与任务状态

用户画像适合回答“当前知道这个人什么”，通常需要紧凑且可更新的结构。情景记录更适合回答“某次发生了什么”，需要保留发生时间、参与主体与来源。两者可以互相引用：画像里的学习阶段来自具体学习事件，用户质疑时能够回到证据解释。

任务状态则应该准确驱动系统行为。假设助手为用户生成练习、提交评分、记录进度，状态中需要明确哪些步骤已成功、哪些请求可以重试。自然语言记忆可以帮助解释任务，但不应代替事务结果。不能因为摘要写着“已完成评分”，就跳过实际上失败的写入操作。

程序性经验也需要边界。助手可以记录“上次用类比解释生成器更容易理解”，作为下一次教学策略的候选；但它不能把一段外部文档中的命令提升为系统级指令。事实证据、经验建议和执行权限应分开表达，避免检索内容直接获得工具调用权。

一次请求的建议数据流

可信身份与当前问题
  → 会话状态：正在讨论什么
  → 任务状态：哪些步骤已经完成
  → 知识检索：问题需要什么领域资料
  → 记忆检索：哪些个人信息当前有效
  → 上下文装配：过滤、排序、限额、标明来源
  → 生成或工具执行
  → 反馈事件与候选记忆提取

这里的箭头表达职责关系，不要求所有步骤串行执行。知识与记忆检索可以在权限范围确定后并发进行；写入可以在后台处理。但任何并发设计都要回答一致性问题：本轮新增的学习目标在下一轮何时可见？写入失败时是否提示？如何避免重复投递产生重复记忆？

对 Java 服务，可以先定义三个独立边界：交互事件入口、记忆读写服务、上下文装配器。业务数据库负责可靠存储，检索索引负责候选召回，应用侧再次确认当前版本和权限。这个分层不强制微服务部署，在一个进程内也可以通过清晰接口实现。

几个可以直接使用的判断题

如果去掉用户标识后答案仍然完全相同，优先考虑知识检索；如果需要知道用户过往选择，考虑记忆；如果必须知道流程是否执行成功，查询任务状态；如果信息已经存在但输入过长或互相干扰，检查上下文管理。这些是排查起点，不是互斥分类。

再看“上次学到哪里”：它可能需要检索最新学习进度，也可能需要读取课程系统的权威记录。如果已有业务系统准确记录学习位置，优先把它作为事实来源，避免让模型从多段聊天中重新猜测。记忆可以补充用户的困难与偏好，不能无条件覆盖权威业务状态。

最后，考虑“不要参考我以前的偏好”。这是一条当前请求约束。系统应在检索或装配阶段停止引入相应个人记忆，而不是把旧偏好一起传给模型，再期待模型自行忽略。把边界变成可测试的工程行为，后续选型才有明确依据。

下一步与参考

下一篇进入记忆写入：同一段交互如何产生候选，如何判断来源与主体，如何在重试时保持幂等。可以先下载离线实现，观察 Candidate、Evidence、Memory 与 Store 如何分别承担不同职责。

进一步阅读可参考 RAG 原始论文与长期记忆生命周期。前者提供检索与生成结合的研究背景；本文的身份隔离、状态划分和服务分层属于面向案例的工程建议，不是论文实验结论。