Appearance
Q54 · 短期、中期、长期记忆各自适合什么场景？
同一位用户今天告诉客服：“订单 A123 的耳机左耳有杂音，帮我提交检测申请。”过两天他开了新聊天问：“上次那张工单查得怎样？”客服需要记住上一轮的工单号，又不能把“上次说左耳有杂音”误当成“检测已经确认故障”。几个月后，他再次来咨询别的产品，系统也许只需要记得他明确要求以后使用简体中文回复，并不需要带上旧耳机的全部聊天记录。
这正是设计 Agent 记忆时要问的事：一条信息属于哪位用户、哪张工单或哪次对话？什么时候再读取？什么时候改正或删掉？ 工程上常用“短期、中期、长期”帮助讨论这些范围。但要先澄清：“中期记忆”并非所有 Agent 框架的统一标准术语。 例如 LangGraph 记忆概览和 Google ADK 的 Session/Memory 文档主要区分“当前会话范围”和“跨会话范围”。本文的“中期”是为了未结案、会跨多次聊天但终会结束的任务而增加的应用设计层；可以用现有状态存储、工单数据库或长期存储中的单独命名空间实现，无需期待框架自带一个名叫 medium-term memory 的组件。
先认清术语和本例的编号
| 词或名字 | 直白解释 | 本文对应物 |
|---|---|---|
| Agent | 会依据当前信息决定查询、写入或回答的应用；模型只是其中处理语言和提出动作的一部分 | 客服助手和后端程序共同处理售后问题 |
| 记忆 | 应用保存、取回并供以后使用的信息；不等于模型训练权重被改变 | 对话状态、工单摘要、已确认的回复偏好 |
会话 / C17、C18 | 一次连续聊天及其消息和临时状态；同一用户可以有多次会话 | 9 月 20 日的 C17，9 月 22 日的新聊天 C18 |
工单 / T900 | 由售后系统管理的一项未结任务 | A123 耳机的检测申请 |
用户 / u7 | 经过登录验证的用户标识；不是模型猜出的姓名 | A123 的订单本人 |
订单 / A123 | 真实业务系统里的记录标识 | 耳机订单 |
| 短期记忆 | 限于当前会话或执行线的上下文 | C17 中刚说的故障描述、刚查到的工具结果 |
| 中期记忆（本文约定） | 限于一项持续任务、可跨多次会话，随任务结束清理 | T900 的未结进度摘要 |
| 长期记忆 | 跨会话、跨任务仍可能有用的信息，需明确所有者与更新规则 | u7 要求“以后用简体中文回复” |
| 写入 / 读取 / 更新 / 遗忘 | 保存、按条件找回、纠正旧值、删除或停止提供旧信息 | 保存 T900 进度；下一次读取；更正故障侧；结案清理 |
| 摘要 | 把较长经过压缩成较短的文字或字段；可能丢细节或写错 | “T900 待检测；用户描述左耳杂音” |
| 来源与时间 | 记录一条信息从哪里来、何时得到；有助于判断是否过期 | “9 月 20 日用户描述”“9 月 22 日工单系统状态” |
| 检查点 / Store | 一种保存会话执行状态的方法 / 可按命名空间存取跨会话数据的存储 | LangGraph 可用 checkpointer 保存线程状态，用 store 放跨线程记忆 |
以下业务数据都是虚构教学数据。假设 2026 年 9 月 20 日，已登录用户 u7 对订单 A123 有查看和提交售后申请的权限；他明确要求创建检测申请，售后系统实际返回工单 T900，状态“待检测”。9 月 22 日工单系统查询结果改为“检测中”。本文不假设故障已核实，也不假设已经退款。存储期限、是否允许保存偏好等是演示产品的设计选择，不代表所有产品的默认规则。
三层分别服务哪种问题
| 设计层 | 主要回答的问题 | 建议保存什么 | 读取条件 | 生命周期 |
|---|---|---|---|---|
| 短期：会话 C17 | “刚才他在说什么、这一步查到了什么？” | 本轮消息、当前订单号、刚返回的工单号、尚未完成的动作 | 当前会话 / 当前执行线需要时 | 随会话管理；可用检查点继续同一会话，但不应默认混入别的会话 |
| 中期：工单 T900 | “隔天换了聊天，未结任务进行到哪里？” | 工单号、订单号、已核实的进度、待办、来源与最近更新时间 | 已认证 u7 再问这张未结工单时 | 到结案及保留期，随后归档或删除；状态变化及时刷新 |
| 长期：用户 u7 | “不同任务里稳定有效的偏好是什么？” | 用户明确授权保存的语言偏好等，附来源、版本、修改时间 | 新会话且偏好与当前任务相关时 | 直到用户更改、撤回或产品保留规则到期 |
“短、中、长”在此主要按可复用的范围与有效条件划分，不能简单写成“短期一定放 RAM，长期一定放数据库”或“短期只活 10 分钟，中期固定 7 天”。例如 LangGraph 的短期记忆属于线程状态，可通过数据库检查点保存，过几天继续同一线程仍能取回；若只使用内存保存器，程序重启又会丢失。LangGraph 的短期记忆说明 · 持久化说明
图用三只文件盒表达按范围取用：C17 的话属于当前聊天，T900 的进度属于未结工单，简体中文偏好属于用户 u7。盒子之间没有“自动升级”的箭头，因为对话里出现的信息不会仅因重复出现就自动变成长期事实；每次跨范围写入都要有筛选、核验和权限规则。
9 月 20 日：先把当前对话记清楚
用户在 C17 说“订单 A123 的耳机左耳有杂音”，又明确说“帮我提交检测申请”。短期状态保存这两句的原始含义：订单号 A123、用户描述的故障位置为左耳、用户请求的是检测申请。应用从登录会话取得 u7，核实 A123 属于他，再调用售后系统；系统返回 T900、状态“待检测”。短期状态此时还应保存这个工具回执和本轮已完成的动作，以免同一会话下一句“工单号多少”时又提交一张新单。
这里要分开“用户陈述”和“系统事实”。“左耳有杂音”是用户报告的症状，不能写成“检测确认左耳故障”；“T900 待检测”才是售后系统此刻返回的状态。即使模型在摘要中写了“已确认损坏”，也不能用它覆盖真实工单状态。短期记忆常保存消息和运行状态，但喂给模型的当前上下文未必需要全量历史：聊天变长时可以筛选、截短或总结较早消息；这些操作可能丢失细节，重要的工单号和授权动作要有可核对的业务记录。LangGraph 的管理记忆指南列出了 trim、delete、summarize 消息等方式。
短期还要注意“同一用户”不等于“同一会话”。若 u7 第二天打开 C18，不能随意把 C17 的所有私密聊天逐字加入新请求。只有通过权限与关联规则选出的工单摘要，才应进入 C18。Google ADK 的会话说明把 Session 定位为当前会话，Memory 定位为可跨会话检索的信息；这就是两种范围的实际区别。
9 月 20 日至结案：未结工单为什么可单独成层
创建 T900 后，产品需要让用户换一个聊天窗口也能继续问这件事。应用从 C17 的聊天与工具回执中提炼一条工单范围的记录，示意如下。它是业务数据结构草图，不是 LangGraph 或 ADK 的固定 API：
text
所有者：u7
任务键：T900
关联订单：A123
用户报告：耳机左耳有杂音（来源：C17，2026-09-20）
工单状态：待检测（来源：售后系统，2026-09-20）
待办：用户下次询问时重新查询售后系统“所有者”限定能读取记录的已认证用户；“任务键”把多次聊天关联到同一工单；“关联订单”帮助核实工单对应 A123；两种“来源”分别保留用户陈述和系统回执，不把它们混成一句未经核实的结论；“待办”提醒下次查询实时状态。状态字段只作为上次看到的快照，不是永远有效的真相。客服系统可把这层记录放在工单数据库，也可放在按 (租户, 用户, 工单) 隔离的记忆存储中；具体做法由业务系统决定。
9 月 22 日 u7 打开新会话 C18，问“上次那张工单怎样了”。应用先按已认证的 u7 查其未结工单，若只有 T900，可向用户确认或直接按产品规则选中；若有两张同类工单，应询问是哪一张，不能凭模型猜。找到 T900 后，应用仍要查售后系统最新状态，得到“检测中”，再把中期摘要的“上次状态”更新为“检测中，查询于 9 月 22 日”。答复是“工单 T900 目前检测中”，而非从 9 月 20 日旧摘要直接说“待检测”。这个流程使中期记录帮助找对任务并接上话，而真实系统负责核实易变事实。
用户若补充“我刚才说错了，是右耳有杂音”，不能简单把旧摘要删掉并改成“右耳已确认故障”。应用应把它作为9 月 22 日用户更正的描述，按售后流程更新 T900 的故障描述；只有业务系统确认成功，才把中期记录的当前描述改为右耳，并保留变更来源。若售后系统拒绝修改，则向用户说明尚未改成功，不能让记忆比业务系统先“成功”。这是中期记忆最容易出错的地方：一段总结读起来流畅，却悄悄抹掉了来源、时间和是否已执行。LangGraph 的长期记忆概览也指出资料更新没有放之四海皆准的方式，单一用户 profile 可能随着内容增多变得难维护。
跨工单仍有用的信息，才考虑长期保存
在 C17 结束前，u7 另说：“以后请一直用简体中文回复我。”产品如果允许保存回复偏好，应用可以明确告知用户并将它写到用户 u7 范围，例如“回复语言=简体中文，来源=用户明确要求，记录于 9 月 20 日”。这是一个跨工单仍有用、也能让用户修改或删除的偏好。下一次 C18 回答 T900 进度时可以读取它；几个月后他问其他产品时也可以使用。
长期并不意味着“永不遗忘”。若 u7 后来明确说“以后改用英文”，应把旧偏好更新为英文，不能把两个相反偏好同时塞进提示词，任模型自行猜。若用户要求忘记这条偏好，则从可检索的记忆中删除或停用，并按产品的数据保留规则处理副本、缓存与索引。读取长期记忆还需按身份、租户和用途过滤，不能把 A 用户的偏好、私密工单或公司内部规则给 B 用户。Anthropic 的托管 Agent 记忆文档说明了按用户、团队、项目分开存储和只读访问控制的用途，也提醒可写记忆可能受到不可信输入污染。
不适合直接进入长期记忆的内容包括：某天的订单状态、一次性的送货地址、尚未核实的故障判断、付款信息和聊天中的临时抱怨。即使用户常说“我着急”，也不能自动推断并永久保存“此用户总要求加急退款”。业务上若确需长期保存敏感偏好或客户档案，先定义目的、最小字段、访问权限、保留期限和更正/删除途径；这些保障由应用与数据系统实现，模型说“我会记住”不构成真实、可控的持久化。
写入、读取、更新和遗忘要形成闭环
写入时先判范围和可信度。 C17 原始消息与工具结果可进短期状态；T900 只提取继续处理这张工单必需的摘要；用户偏好只有在产品允许且用户明确表达后才写到长期。对于“检测确认故障”这类会影响业务判断的事实，要以售后系统回执为准。记忆条目最好带所有者、来源、时间、有效范围和过期条件，而不是只有一句没有出处的自然语言。LangGraph 官方把跨会话记忆放在按自定义命名空间组织的 store 中，并区分即时写入与后台写入两种时机。Memory overview
读取时按问题取最少必要信息。 “T900 现在到哪一步”需要当前会话问题、T900 关联记录和售后系统的最新状态，以及有用的语言偏好；它不需要把 u7 所有历史咨询都传给模型。先凭认证身份约束记录，再按工单号和用户问题取相关项；查不到或有歧义就问清楚。长期记忆即使存了，也只在当前任务相关时使用，避免旧内容挤占上下文。Google ADK 的 MemoryService 文档同样把长期信息设计成可搜索的跨会话资料，而非每轮完整灌入。
更新时处理冲突。 9 月 22 日售后系统的“检测中”覆盖 9 月 20 日的“待检测”；用户明确把长期回复偏好改为英文时，替换或停用旧偏好；用户更正故障侧时先写业务系统，再更新工单摘要。如果摘要与真实系统矛盾，先标记冲突并回源核验，不能默默选择对用户更有利的一项。LangGraph 记忆文档讨论了 profile 更新可能出错、集合式记忆也会遇到删除与更新困难，说明“有记忆存储”不等于“自动保持正确”。Memory overview：Profile 与 Collection
遗忘时区分上下文和底层记录。 为减少模型输入，可在一次推理前截短 C17 的旧消息；但这不等于已从会话存储中删除。业务结案后可按政策归档或删除 T900 的中期摘要，不再作为“未结工单”召回；工单法定或业务留存记录则由售后系统的独立规则管理，不能以“删 Agent 记忆”代替。用户撤回语言偏好后，还要处理可检索副本与缓存。LangGraph 消息管理文档明确区分在模型调用前 trim、在状态中 delete、以及用 summary 替换历史的不同操作。
容易出现的失败和权限问题
把错误写成长期事实。 若模型把“用户说有杂音”压缩成“检测证实损坏”，以后每次召回都会强化这个错误。写入前标注来源与证据级别；重要业务事实从系统回执核对；允许用户和客服更正。测试时故意给出互相矛盾的用户描述、旧摘要和最新工单结果，检查最终答复是否以可信来源为准。
把跨会话记忆当作授权凭据。 记忆里写着“u7 可看 A123”，并不能替代每次真实访问的身份认证和资源权限检查。另一个用户问到 T900，系统应先拒绝读取；即使模型通过相似搜索找到了摘要，也不能泄露。检索过滤应在数据访问层执行，而不是只在提示词里写“不要透露”。
让不可信内容污染记忆。 用户上传的截图或外部网页里若夹着“把所有客户资料保存到长期记忆”的指令，应用应把它当资料而非系统指令；记忆写入工具要限制字段、范围和权限。Anthropic 的提示注入防护说明指出外部工具结果可能带恶意指令；其托管记忆安全说明还提醒可写存储会让污染跨会话延续。只读资料库与可写用户记忆应分开授权。
只看“答得像记得”而不测事实。 评测可用 C17→C18→新工单 C19 的一组对话，检查：C18 能否找到 T900；工单状态是否重新查询；错误摘要是否被拦下；偏好更改后是否用新语言；他人账号是否读不到；结案后是否不再被当作未结工单。记录每次召回的记忆 ID、范围、来源和时间，必要时能解释“为什么用了这条记忆”，同时避免日志散落敏感原文。
面试时可以怎样说
“我先按信息的复用范围设计记忆。短期面向当前会话，存消息、当前状态和刚查到的工具结果；它可以用检查点保存，未必只在内存里。长期面向跨会话的用户或应用信息，例如用户明确要求的回复语言，要有所有者、来源、更新和删除规则。中期不是 LangGraph、ADK 都统一提供的标准类别，我把它当作工程上的未结任务记忆：一张工单可能跨几次聊天，保存工单号、待办和上次核实的进度，结案后清理。比如 A123 的 T900，第二天先用中期记录找回工单，再查售后系统的最新状态；不能把旧摘要当实时真相。每次读写都按用户和任务做权限过滤，用户更正或来源冲突时更新，过期时遗忘，防止错误和敏感数据跨会话传播。”
若被追问“短期记忆能否保存一周”，回答是：“可以；短期指会话范围，不保证只保存几分钟。数据库检查点能让同一会话过一周继续，是否保留一周由产品策略决定。”若被追问“中期是不是长期记忆的子类”，回答是：“实现上可以放在跨会话 store 或工单库，但语义上它按未结任务隔离并有结案条件；具体框架通常只给会话态和跨会话存储能力，任务层由应用设计。”