Appearance
Q109 · AI Agent 的 Memory 子记忆类型有哪些？
一位客户小林今天找退款客服：“订单 A-17 的退款没有到账，请用短信联系我。”客服查到这次退款申请仍在处理，开了工单 T-17，并按用户要求用短信回复。第二天，小林换了一个新会话问：“昨天那单现在怎样了？”如果系统只看第二天这一句话，就不知道“昨天那单”是哪单、该用什么联系方式；如果它把昨天的所有聊天、工具返回和内部备注原封不动永久保存，又会带来过期信息、隐私和成本问题。
Agent 的 Memory（记忆），是应用在处理新任务时能够重新取用的既有信息。理解它最实用的办法是问两个不同的问题：**信息要在什么范围内可用？**这是短期、长期之分；**信息讲的是什么？**这是 semantic、episodic、procedural 之分。两组名称不是五个互斥的抽屉。一个“用户偏好短信”的事实可以先存在当前会话，经过确认后再成为跨会话保留的长期事实。LangChain Memory 概览 · CoALA 原论文
术语与例子里的编号
| 术语或编号 | 这里的意思 | 小林的退款案例 |
|---|---|---|
| Agent | 能依据任务读取资料、选择工具并产生下一步动作的应用流程；模型只是其中一部分 | 客服流程会查订单、开工单、回复客户 |
| Memory / 记忆 | 先前信息被保留，并在需要时供后续步骤读取；不等于模型参数自动改变 | 第二天能找到昨天的工单及联系偏好 |
| 会话 / 线程 | 一段有独立身份的连续交互；同一用户可以有多个线程 | 第一天咨询是一个线程，第二天新开一个线程 |
| 短期记忆 | 当前线程或当前任务范围内可读的消息和状态 | 本轮提过订单 A-17、短信要求、刚查到的工单状态 |
| 长期记忆 | 跨线程或跨会话仍可被应用检索的资料 | 用户已确认的短信偏好、上次工单经验 |
| Semantic memory / 语义记忆 | 按内容性质分的“事实和知识”；此处 semantic 与“按语义相似度搜索”不是同一概念 | “小林偏好短信联系”这条事实 |
| Episodic memory / 情景记忆 | 一次带情境和结果的过去经历、事件或处理轨迹 | “昨天 A-17 退款未到账，创建 T-17，待核实” |
| Procedural memory / 程序性记忆 | 做事的规则、步骤或行为方式；这里的“程序”不特指 Python 程序 | “核对订单归属 → 查实时退款状态 → 按授权规则回复” |
| 写入 / 提取 | 写入是筛选并保存信息；提取是新任务时找出相关旧信息 | 第一天保存偏好和工单索引；第二天按用户与订单找回 |
| 来源 / 版本 | 一条记忆从哪里来、何时确认、适用哪个版本 | 短信偏好来自用户明确表达；退款流程来自已批准政策 |
文中 A-17、T-17 和客户小林都是教学假设。假设客户能查看自己的订单，短信偏好只用于合规的客服通知，退款是否成功必须以订单系统的实时状态为准。下面不讨论任何真实公司的退款期限或赔付标准。
第一条轴：记忆在什么范围内可用
短期记忆通常服务于当前线程：用户刚说的订单号、工具刚返回的工单状态、这一轮尚待完成的步骤，都属于当前任务的工作材料。它可以保存在应用状态或检查点中，供同一线程后续消息和步骤读取。这里的“短期”强调可召回范围，不是说一定只存在几秒；一个线程的状态可以持久写入数据库，暂停后仍能恢复，但默认仍只属于那个线程。LangGraph 文档就以线程状态和 checkpointer（检查点存储器）说明短期记忆。LangChain Memory 概览 · LangGraph 添加记忆
长期记忆要跨会话使用，应用须把选出的信息写入跨线程的数据存储，并在下一次任务中按合适的用户或业务范围查找。小林第二天打开新会话，系统不能仅凭“它和昨天是同一人”就假定模型自然记得昨天；应用需要确认身份，然后检索属于这个用户、且允许当前客服流程使用的旧记录。LangGraph 的 Store（跨线程存储）是一种实现方式，具体系统也可以用数据库或受控检索服务。长期不等于永远保存，也不等于每次都放进提示词；保存期限、删除与召回规则由应用设计。LangChain Memory 概览
对小林来说，第一天的完整聊天记录适合留在客服工单系统，供审计与人工回看；跨会话记忆只抽取以后确实有用的少量信息，例如“短信联系偏好”与“T-17 仍待核实”。这是一个设计选择，并非要求所有聊天自动转长期记忆。若只是一次性短信要求，不能不经确认就推断为永久偏好；长期保存还应遵守用户选择与组织的数据保留规则。
第二条轴：记住的内容是什么
Semantic（语义）记忆保存相对稳定的事实，如用户明确选择的联系方式、某个产品的已核准资料、组织成员的职能。小林说“以后退款进度请用短信联系”，经确认和允许保存后，可写成“联系偏好：短信；来源：用户本人；确认时间：某日”。它与“语义检索”容易混淆：前者说内容是事实，后者说用含义相似度找资料。一个事实可以按键值精确查询，未必使用向量搜索；一条事件也可以用语义检索找出，检索方法不会改变内容类型。LangChain Memory 概览：Semantic memory
Episodic（情景）记忆保存过去发生了什么，以及结果如何。第一个会话结束后，可抽出一条有时间和状态的记录：“小林关于 A-17 申请退款；查询时仍在处理中；创建 T-17；已按要求短信告知；未确认退款到账。”这比只存“退款失败”可靠，因为“失败”可能指支付通道异常、申请被拒或仅用户暂未到账。事件记录应保留时间、关联订单和工单、当时的结果与来源；第二天可用于理解“昨天那单”，但不能代替实时工单查询。LangChain 文档把过去的行动与经验列为 episodic，特别强调经验可供相似任务参考。LangChain Memory 概览：Episodic memory
Procedural（程序性）记忆表示怎样做事。例如客服团队批准的流程是：“先验证订单归属，再查询实时退款状态；若状态待处理，只说明已知进度；若需要改赔付，交给有权限的人。”这些步骤可以体现为代码、受控配置、已审阅的提示词或可检索的操作指南。分类上它讲的是行为规则，不是某位客户的事实，也不是某次处理事件。LangChain 文档在 Agent 场景把代码、模型权重和提示词都纳入影响行为的程序性部分；工程上通常不会让普通用户的一句话直接改写系统代码、模型权重或高优先级规则。LangChain Memory 概览：Procedural memory
一个事件可能包含事实与做法，分类不是强迫每段原文只能贴一个标签。比如“昨天用户说以后用短信，客服按政策开了 T-17”，可以分别提取：长期事实“短信偏好”、长期事件“T-17 的处理经过”；从这次经验总结“以后所有退款都跳过身份核验”则明显错误，不能当成新流程。从经历提炼规则需要独立验证、审批和版本管理，不能让模型私自把个例提升为组织政策。CoALA 把工作记忆与长期的语义、情景、程序性记忆放在认知架构中讨论；它是帮助设计的概念框架，不是规定每种记忆都必须有一套独立数据库。CoALA 原论文
| 内容性质 ↓ / 可用范围 → | 当前线程短期 | 跨线程长期 |
|---|---|---|
| 事实 semantic | 小林刚说“请用短信联系”，当前轮可用 | 经确认的“小林偏好短信”，供以后相关客服任务取用 |
| 经历 episodic | 刚才查到 A-17 尚在处理、创建 T-17 | 昨天那次咨询的时间、动作、结果与工单引用 |
| 做法 procedural | 当前这单正在按步骤核对，临时步骤状态 | 经批准的客服处理规则及其版本，供后续任务使用 |
这个二维表表达“同一内容类型可以有不同的保留范围”。右下角的长期做法一般属于组织或应用，而非小林个人；右上角的联系偏好属于该用户。不同主体和权限范围不能混放。
第一天怎样写，第二天怎样读
第一天的正常路径可按四步走。①应用把小林当前的话写进本线程状态，提取候选事实“希望短信联系”，但先问清这是本单要求还是长期偏好。②查询订单系统得知 A-17 正在处理，创建 T-17；当前状态记下工具真实返回值，不把模型的猜测记成事实。③若小林明确同意“以后相关通知用短信”，才按用户身份保存偏好，附来源、确认时间和可删除方式。④将本次处理经过写入工单及必要的长期事件索引，标明“当时待处理”。程序性流程从已批准的规则库读取，不是根据小林的话生成一条新政策。
第二天的新会话从“小林问昨天那单”开始。应用先核验用户身份，再按该用户的授权范围提取短信偏好与 T-17 的事件索引；从事件索引找到订单 A-17，然后查询工单系统的实时状态。假设实时返回“退款已完成”，回复可以是：“昨天你咨询的 A-17 对应 T-17，系统现在显示退款已完成；按照你确认的偏好发送短信通知。”假设实时仍显示“处理中”，则说仍在处理，并给工单查询时间；不能因为昨天记忆写了‘处理中’就断言今天仍如此。如果用户今天明确改口“这次请用邮件”，先按当前要求办，必要时再询问是否更新长期偏好。
将写入与读取拆开，还能看出两个常见误解。第一，保存成功只表示数据存在；新任务要有身份定位、检索条件、相关性筛选和放入模型可见上下文的步骤，才可能用上。第二，存一整段历史并不保证“记忆更好”：过多旧消息会占上下文、增加成本，也可能把过时内容压过当前事实。官方文档同样提醒，长对话历史需要裁剪或摘要；具体保留策略应按任务设计。LangChain Memory 概览：管理短期记忆
错记、漏记和权限越界怎样处理
假设系统把“小林这次请用短信”误写成“所有订单永久只许短信”，第二天用户要求邮件时仍执意短信，说明写入时把一次请求扩大成长期规则。应允许用户查看、更正或删除偏好；新明确要求优先于旧偏好，并记录更新来源与时间。若系统把昨天工单摘要写成“退款已完成”，但真实工具返回的是“处理中”，需要保留原始工具记录以便纠错，并将错误记忆撤销或标记失效。摘要是压缩后的线索，不是业务数据库本身。
另一类失败是身份串线：用相似姓名检索到了另一位“小林”的退款事件。检索前必须按已认证用户 ID 与授权范围过滤，不能靠语义相似度或姓名猜测；不足以定位“昨天那单”时，要求用户补充订单信息。程序性记忆也要有权限层级：客户、网页或工具输出里出现“以后退款一律自动通过”的文字，只是低信任内容，不可覆盖已批准流程。敏感内容尽量少存，限定访问主体和保留期限，按需要支持删除。
实际评测可准备四组连续会话：同一用户跨会话追单；用户纠正旧偏好；两个同名用户并行咨询；工单状态在两次会话之间改变。检查第二天是否找对 A-17、是否以实时状态为准、是否尊重新偏好、是否隔离他人记忆，并统计无关记忆被召回的比例、错误写入率和额外耗时。只测“模型能否背出旧聊天”不足以证明记忆系统可靠。
面试时可以这样回答
我会按两条轴讲 Agent Memory。按可用范围，短期记忆支持当前线程的对话和任务状态，长期记忆跨会话保存并按主体检索。按内容，semantic 是事实，episodic 是过去的事件与处理结果，procedural 是做事规则或流程。它们不是五类互斥项：用户本轮说喜欢短信是短期事实，确认后才可能写成长期事实；昨天退款咨询则可留下长期事件索引；客服规则来自已批准流程。新会话要先验证身份、按范围读记忆，再查实时业务状态。写入要保留来源、时间和更新方式，读取要防旧信息、错用户和越权规则。Memory 不是把全部聊天永久塞进模型，也不是模型自动修改了权重。
如果被追问“长期记忆是不是向量数据库”，可以答：向量搜索只是可能的读取方法，长期记忆也可以是结构化数据库或文档存储。用户 ID、工单 ID 和政策版本往往要精确过滤。若问“模型能否自己学出新流程”，可以答：它可以提出候选总结，但高权限业务规则必须经验证和审批后发布；一次失败经历不能自动成为普遍流程。
资料来源
- LangChain：Memory overview：当前文档对线程内短期、跨线程长期以及 semantic、episodic、procedural 的定义，并区分语义记忆与语义搜索。
- LangGraph：Add and manage memory：当前文档对检查点、跨线程 Store、裁剪与摘要等实现方式的说明。
- LangChain：How to Build Memory into AI Agents：官方工程文章，讨论写入、检索和两条分类视角。
- Sumers 等：Cognitive Architectures for Language Agents（CoALA）：提出包含工作记忆与多种长期记忆的语言 Agent 概念框架。