AI Agent 记忆为什么要区分短期上下文和长期存储

AI Agent 的“记忆”不是把历次聊天无限追加到提示词里。更稳妥的做法是把当前线程要用的短期上下文，与跨会话复用的长期存储分开：前者保存正在进行的任务，后者只保存经过筛选、带范围和生命周期的事实。这样既能避免上下文越来越长，也能减少旧信息、错误信息跨会话污染答案。

短期上下文回答“这次任务进行到哪里了”，长期存储回答“以后哪些已确认信息值得再次使用”。两者的所有者、保存时间、读取方式和权限边界都不同，不能用一个大聊天记录代替。

资料入口：https://redis.io/docs/latest/develop/use-cases/agent-memory/

AI Agent 记忆先按会话边界拆开

短期上下文通常属于一个 thread 或 conversation，包含消息历史、工具调用结果、当前目标和中间草稿；长期存储则跨越多个 thread，适合保存用户偏好、已经确认的业务事实或可复用的解决经验。事件日志是另一种有用的记录：它保留按时间排列的动作与观察，便于审计或异步整理，但不应原样塞进每次提示词。

可以先用下面的表做边界设计。它描述的是职责，不是强制要求某一种数据库。

短期上下文只服务当前任务

短期记忆的目标是让 Agent 能恢复当前工作，而不是永久保存所有细节。消息过长时，可以保留系统约束、当前目标和最近几轮交互，把更早内容压缩成摘要；工具返回的大段日志也应提取结论后再放回上下文。LangChain 的短期记忆文档把这类状态绑定到 thread，并提供检查点、裁剪、删除和摘要等思路。

如果用框架实现，关键不是类名，而是 thread_id 的来源和隔离规则。下面的伪代码展示最小数据结构，示例没有连接真实模型或数据库：

# 短期状态只跟随当前 thread，不把临时草稿写进长期记忆
short_term = {
    "thread_id": "thread-42",  # 同一任务恢复时使用稳定的线程标识
    "goal": "整理客户反馈",  # 当前任务目标，任务结束后可被摘要替换
    "messages": recent_messages,  # 只保留能支撑当前回答的消息
    "tool_state": {"page": 2, "pending": True},  # 工具调用的中间状态
}

# 接近上下文预算时先压缩旧消息，避免把全部历史重复发送给模型
if token_count(short_term["messages"]) > context_budget:
    short_term["messages"] = summarize_old_messages(short_term["messages"])

检查点应能让同一个 thread 在进程重启或换工作进程后继续；但新 thread 默认不应继承旧 thread 的临时草稿。这个边界能直接挡住“上个客户的未完成任务出现在下个客户对话里”的问题。

长期存储只接收可复用记忆

长期记忆不是聊天记录的备份，而是可在未来任务中复用的数据。适合写入的内容通常具备三个条件：来源明确、未来可能复用、不会因一次临时对话就轻易改变。例如“用户明确偏好简短回答”比“用户刚才问了一个问题”更像长期事实。

写入前建议经过记忆提取器，把事件日志或对话中的候选事实单独列出，再做去重、冲突判断和敏感信息过滤。对于同一用户，namespace 可以像目录一样组织数据；检索时必须同时带上用户、组织或业务空间的过滤条件。LangGraph 的长期存储就是按 namespace 和 key 保存 JSON 文档，并支持在指定范围内搜索。

如果系统只需要精确读取，键值或文档存储就够用；只有当用户不会复述原句、需要按含义找回经验时，才考虑向量索引。不要因为“用了 Agent”就默认所有内容都要向量化。

把写入、检索、过期和权限连成闭环

一套可维护的长期记忆至少要回答四个问题：谁能写，谁能读，什么时候失效，发生冲突时保留谁。TTL 适合处理会自然过期的工作偏好或阶段性项目状态；稳定的用户事实可以采用更长保留期，但仍要支持修改和删除。事件日志则可用限长或归档策略，不应把日志保留规则误当成事实保留规则。

读取时不要只按相似度取前几条。先按租户和用户做授权过滤，再按任务相关性、来源可信度和新鲜度排序；召回结果还要标出来源，方便模型和业务代码判断它是事实、经验还是未经确认的候选。

Redis 的 Agent memory 文档把工作记忆、长期语义召回和有序事件日志分成不同数据职责；这是一种实现参考，不是唯一架构。无论底层选择 Redis、PostgreSQL 还是其他存储，都建议保留类似字段：

{
  "memory_id": "m-001",
  "namespace": "tenant-a/user-42",
  "kind": "semantic",
  "content": "用户偏好简短的中文回答",
  "source": "thread-42",
  "status": "confirmed",
  "expires_at": null
}

上面的 JSON 必须保持有效格式；字段含义紧跟在正文中解释。生产环境还应记录写入时间、更新时间、版本或冲突原因，并把记忆读取和写入纳入审计。

常见误区与记忆边界速查

• 把全部历史直接拼进 prompt：短期能工作，长期会增加上下文成本，并让无关或矛盾信息干扰当前任务。
• 让模型直接写长期事实：模型输出应先进入候选区，经过来源、敏感信息、重复和冲突判断，再决定是否晋升。
• 只建一个全局 namespace：这会让多用户、多组织或多 Agent 共享边界变得模糊；命名空间不是授权本身，仍需服务端校验。
• 只做向量检索不做保留：相似度高不代表信息仍然正确，TTL、删除、版本和人工修正同样重要。

最后可以用一条简单规则复盘设计：临时状态留在短期上下文，稳定事实进入长期存储，过程动作进入事件记录；任何跨会话召回都必须同时通过范围、相关性和生命周期判断。

相关问题

短期上下文是不是一定不能落库？

不是。为了断点恢复，短期状态可以持久化到检查点；关键是它仍按 thread 隔离，并设置清理或过期策略，不要因为落库就把它当成跨用户共享的长期事实。

长期记忆一定要使用向量数据库吗？

不一定。用户 ID、配置项和明确键值适合结构化读取；只有需要按语义召回历史经验时才增加 embedding 和向量索引，先解决范围与生命周期，再选择检索技术。