Agent 怎样记住事情：上下文、状态、长期记忆与 RAG
聊过的内容、存下来的记录和本轮真正看到的信息，是三件不同的事。用一个读书助手，理解 Agent 怎样接续任务、选择证据，以及为什么“已经保存”仍不代表它每次都会记得。
Agent 入门 · 阅读路线
先带走这三个判断
- 上下文窗口是模型可处理信息的容量上限；本轮上下文是实际装配的输入，存储记录需要被选中才能进入判断。
- 会话状态承接当前任务，长期存储跨会话保留信息；RAG 是找回相关资料的方法。
- 记忆应有来源、作用范围和更新规则，重要事实使用前仍需核对。
文章目录
先从一个读书助手说起
假设我们设计一个读书助手。你告诉它“我想读懂 Agent，每次解释短一点”，第一天读 ReAct，第二天继续看计划与执行。它需要知道你正在学什么，也需要找到相关资料。这里用的是构造场景：它不是某款产品的行为承诺，更不意味着所有聊天应用都具备相同的记忆功能。
如果第二天它忘了“解释短一点”，可能从来没有保存这条偏好，也可能保存了却没取出来，还可能取出来后被其他输入淹没。只问“模型记忆好不好”无法定位问题。我们需要沿着保存、检索、装配和使用四个环节，查看信息到底走到了哪里。
把四种容易混淆的东西分开
上下文窗口是模型可处理信息的容量上限，本轮上下文是实际装配进去的信息；短期状态保存当前会话的消息、任务进度或待办；长期存储保存跨会话的信息；RAG通过检索相关资料再交给模型生成回答。最后一种是一条取资料的路径，不能直接等同于个人记忆。
LangChain 官方概念文档把短期记忆按会话组织，把长期记忆按自定义命名空间组织。具体是否持久保存，取决于应用选择的存储实现。参考 Memory overview。在这个例子里，“正在读第几章”属于任务状态，“喜欢短解释”可成为个人偏好，ReAct 论文则属于知识来源。
输入与输出额度怎样共同计入窗口，取决于模型及接口约定；准备输入时还要预留输出空间，不能把标称窗口全部当成可塞资料的容量。参考 Claude 官方 Context windows。本文不固定具体模型的容量数字。
每一轮，先决定桌上放什么
可以把本轮上下文想成书桌：桌面空间有限，书架上的资料不会自动全部摊开。读书助手解释一个术语时，桌上放当前问题、必要前文、一小段偏好和相关原文就足够；如果把所有历史问答都放上来，旧话题可能干扰新问题，阅读和生成也更费时。
Anthropic 的上下文工程文章讨论了按需加载资料、压缩历史以及保留结构化笔记的方式。它们帮助管理输入，并不承诺长任务永不失忆。参考 Effective context engineering。设计时可以先保留当前目标、用户最新修改和未完成动作，再摘要已经结束的讨论。
摘要本身也会漏掉信息。“用户想学 Agent”远不如“读过 ReAct，下一篇解释规划，例子不要涉及真实支付”有用。重要条件应明确列出，出处放在旁边；不能把一段摘要当成原始资料的完整替身。
长期记忆需要一张小档案
一句“以后记住”还不够明确。我们为偏好记录加上内容、来源、适用范围、写入时间和是否仍有效。例如“偏好中文短解释”来自用户明确表达，作用于这个读书助手；“本周想了解 MCP”则是阶段目标，不能自动变成永久兴趣标签。
存储可以是结构化档案，也可以是一组独立记录。档案便于整体查看，但覆盖时容易误删字段；记录便于逐条维护，却需要处理重复和冲突。选择方式应跟使用场景相连。少量稳定偏好可用档案，学习笔记可独立记录；两者都需要隔离不同用户，提供查看、更正和删除的入口。
这类应用记忆通常改变的是下次请求装配进去的内容，不是给模型重新训练一遍。把“我已记住”解释成模型权重已更新，会误判保存机制，也容易让用户期待它在任何产品、任何会话都能记得。
RAG 找的是资料，资料还要被读对
当你问“ReAct 和先列计划有什么区别”，检索可以找论文、课程笔记或之前的学习记录。知识库与个人记忆可以共用检索技术，但应区分来源和权限。偏好只影响解释方式，不能代替技术依据；旧笔记可以帮助定位问题，也不能凭相似度变成权威结论。
检索不到时，应区分没有记录、当前范围无命中、权限不足和服务不可用。找到了，也要保留版本与适用范围。读书助手可以说“根据这篇原文，ReAct 将推理与行动交替组织”，不能仅凭自己上周生成的总结证明原论文如此描述。证据如何装配，可以继续读召回与证据。
写入之后，也要允许更新与遗忘
假设你后来改成“今天详细一点”。这个临时要求应优先影响今天的解释，却不一定要覆盖长期偏好。只有“以后都详细一些”才更像持久修改。设计写入流程时，先判断信息是暂时要求、稳定偏好还是未经核实的推测，再选择保存策略。
出现矛盾时保留来源和时间，不能悄悄拼成一个新事实。对可变信息设置复核或失效规则；删除应同时处理检索入口与派生摘要，否则正文删了，旧摘要还可能把内容带回来。哪些信息允许保存，需要符合应用与用户之间的明确约定。
常见误区：保存不等于每次想起
第一种误区是“窗口够大就不用管理”。更大的窗口能放更多输入，仍然需要选择相关信息。第二种是“向量库就是记忆”。向量检索只是候选查找方法，不能处理全部更新、授权和真实性问题。第三种是“多写一点总没坏处”。无关或错误记录会让以后回答偏离目标。
还有一个容易忽略的边界：模型可以复述一条偏好，不代表它使用了持久存储。也许这条偏好正好仍在聊天历史里。要验证跨会话记忆，应在新会话检查保存记录、检索结果和本轮输入，不能仅凭一次看起来连贯的回复宣布机制有效。
小练习：给读书助手做一次记忆审计
- 写三条信息：“以后用中文解释”“今天只读十分钟”“资料版本是上个月”。分别标成稳定偏好、临时约束与需要复核的事实。
- 为准备保存的那条补上来源、用户范围和删除入口；让临时约束只进入当前任务状态。
- 模拟新会话，列出准备交给模型的输入，再检查稳定偏好是否出现，旧资料是否保留版本。
- 把偏好改成“以后详细一点”，检查旧记录和摘要如何更新；最后模拟检索失败，让助手解释不确定性。
这张审计表比一句“支持长期记忆”更能说明能力。进一步理解运行状态如何恢复，可以读架构先从对象与状态开始，或继续看Harness 怎样组织一次任务。
参考资料
概念依据来自以下一手资料；文中的读书助手、分工、指标与练习是解释性构造，不代表生产实现或验收结果。资料访问日期：2026-10-07。
图表为通用设计示意。实际产品的能力、持久化方式、执行权限与预算，应以运行配置和可核对结果为准。
存下来、找得到、用得对，是记忆的三道关。
仅保存在当前浏览器。