先记住这个答案
短期记忆通常服务于当前会话或任务线程，包含消息、工具结果、计划进度和待确认操作等执行状态；长期记忆用于跨会话复用相对稳定的事实、偏好或经验。短期状态也可以通过检查点持久化，所以“写进数据库就是长期记忆”并不成立。长期保存的数据也不应全部塞入提示词，应按权限、相关性和时效性选择，再送入模型当前上下文。
- 会话或线程状态也可以持久化保存
- 长期记忆关注跨任务复用及后续维护
- 存储、检索和上下文装配是不同步骤
短期记忆并不是进程里的临时变量
假设一个 Agent 正在整理采购清单，已经查到部分商品但仍等待用户确认预算。当前清单、查询结果和待确认事项属于这次任务的工作状态。如果服务进程重启后还需要继续，应用可以把这些状态做检查点保存；它们依然是线程范围的短期记忆，不会因此自动成为全局知识。
同样，长期记忆也不是必须永不删除的历史归档。用户的默认收货地区、语言偏好或已确认的项目约束可以跨会话使用，但都应有来源、更新和失效机制。用“短期等于内存、长期等于向量库”的划分会混淆逻辑范围与实际存储设施。
用户跨会话回访时如何装配信息
假设用户今天询问某份采购任务的进度，应用应先定位其有权访问的线程状态，恢复已完成步骤与尚未确认的动作。若还需要默认币种等偏好，再从用户范围的长期记忆中读取。两个来源可能进入同一次模型调用，但读取入口、授权条件和更新方式不必相同。
装配上下文时还应筛选内容。上次查询得到的一大段网页原文可能已经过期，没有必要每次完整送入；可以保留引用、摘要或重新获取的条件。长期记忆检索也要检查用户边界和事实有效期，不能因为相似度较高就把别人的信息或陈旧偏好放进当前任务。
什么时候把一次对话内容转为长期事实
用户明确表达持续偏好，例如以后优先使用某种语言，可能值得提取为长期记忆；一次临时指令，例如这次出差寄到酒店，则不能直接覆盖默认地址。写入前要区分原话、模型推断和任务临时条件，并根据业务必要性决定是否保存。
设计验证用例时应覆盖新线程不应继承旧任务的待执行操作、同一用户应能读取允许复用的偏好，以及删除或修改长期事实后不应继续检索旧值。对于并发线程，还应规定冲突处理与版本检查，避免稍后结束的旧任务重新写回已经被用户纠正的信息。
容易答错的地方
- 把所有聊天记录都当作高质量长期记忆
- 原始对话包含临时要求、工具噪声和已过期结论，不经筛选直接检索会放大错误。长期记忆需要明确用途、事实抽取与纠正方式，而不是仅增加一个更大的历史表。
- 以为模型上下文窗口等同于记忆系统
- 上下文窗口只是某次调用能接收的信息范围。应用还需负责保存、索引、授权、筛选和删除；把状态持久化与本次是否送入模型是两个独立步骤。
面试官还会怎么问？
会话摘要应该放短期还是长期？
取决于用途。为缩短当前线程上下文而生成的摘要通常仍属于该线程状态；若从中提取跨会话偏好，则应另行检查来源与保存依据，再写入长期记忆。
短期记忆一定要保存完整工具输出吗？
不一定。需要考虑恢复执行的必要信息、输出大小和时效性，可以保存结构化结果、外部引用与重取条件。省略内容时必须确保后续步骤不会误以为已经掌握了被丢弃的细节。
长期记忆能完全替代业务数据库吗？
不能。订单状态、账户权限等权威业务数据应从相应系统读取，记忆可以保存辅助上下文或检索线索。不能用模型总结出来的旧事实替代必须实时核验的业务记录。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。