Agent 记忆的类型：短期记忆、长期记忆、工作记忆
难度：基础 分类：Memory & State
简短回答
LLM Agent 的记忆系统借鉴认知科学，分为三种核心类型：
短期记忆（Short-Term Memory）——当前会话的对话历史，存在于 LLM 的上下文窗口中，会话结束即丢失；
长期记忆（Long-Term Memory）——持久化存储在外部系统（向量数据库、关系数据库）中的知识，跨会话保留，需要检索才能使用；
工作记忆（Working Memory）——Agent 在当前任务中主动维护的关键信息子集，本质上就是上下文窗口中当前可用的信息。
关键理解：LLM 本身是无状态的，所有"记忆"都是工程层面的外部实现。
详细解析
LLM 的记忆本质
代码块
Plain Text
核心事实：LLM 本身是无状态的
每次 API 调用都是独立的——模型不会"记住"之前的调用。
产品层面的"记忆"（如 ChatGPT 记住你的名字）是在 LLM 之上
工程化实现的记忆层，不是模型的固有能力。
构建 Agent 时，你需要自己实现这个记忆层。
短期记忆（Short-Term Memory / STM）
代码块
Python
# 短期记忆 = 上下文窗口中的对话历史
conversation_history = [
{"role": "user", "content": "帮我查一下订单 #12345"},
{"role": "assistant", "content": "订单 #12345 已发货，预计明天到达"},
{"role": "user", "content": "物流单号是多少？"},
# Agent 可以回答，因为"订单 #12345"在短期记忆中
]
# LLM 调用时，完整对话历史作为输入
response = llm.invoke(messages=conversation_history)
特点：
•
存储位置：LLM 的上下文窗口（Context Window）
•
生命周期：当前会话
•
容量限制：受上下文窗口大小限制（4K-200K tokens）
•
访问方式：直接可用，无需检索
•
丢失时机：会话结束、上下文窗口溢出
长期记忆（Long-Term Memory / LTM）
代码块
Python
# 长期记忆 = 外部存储 + 检索
class LongTermMemory:
def __init__(self, vector_db, relational_db):
self.vector_db = vector_db # 语义检索
self.relational_db = relational_db # 结构化查询
def store(self, memory: dict):
"""存储记忆到外部系统"""
# 向量化存储（用于语义检索）
embedding = embed(memory["content"])
self.vector_db.upsert(
id=memory["id"],
vector=embedding,
metadata=memory["metadata"]
)
# 结构化存储（用于精确查询）
长期记忆的三个认知子类型（LangMem 框架）：
代码块
JSON
memory_subtypes = {
"语义记忆 (Semantic)": {
"定义": "事实和知识——Agent 知道的东西",
"示例": "用户偏好、产品知识、规则",
"存储": "向量数据库 Collection 或结构化 Profile",
"检索": "按语义相似度搜索",
},
"情景记忆 (Episodic)": {
"定义": "经历和事件——Agent 做过的事",
工作记忆（Working Memory）
代码块
Python
# 工作记忆 = 当前上下文窗口中的所有信息
# 包括：System Prompt + 对话历史 + 检索到的长期记忆 + 工具结果
working_memory = {
类比操作系统：
代码块
Plain Text
上下文窗口（工作记忆）≈ RAM（当前运行的程序可直接访问，容量有限）
长期记忆（外部存储）≈ 硬盘（大容量但需要读取操作）
MemGPT 正是基于这个类比，实现了类似操作系统虚拟内存的机制——自动在"内存"（上下文窗口）和"磁盘"（外部存储）之间移动数据。
工作记忆 = 上下文窗口（RAM），长期记忆 = 外部存储（硬盘），"记忆"全靠工程层在两级之间搬运。
记忆管理策略
代码块
Python
class MemoryManager:
最新研究：AgeMem（统一记忆管理）
2026 年 1 月提出的 AgeMem 框架将记忆操作暴露为工具调用，让 Agent 自主决定何时存储、检索、更新、摘要或丢弃信息：
代码块
Python
# AgeMem：记忆操作即工具
memory_tools = [
{"name": "memory_store", "description": "存储重要信息到长期记忆"},
{"name": "memory_retrieve", "description": "从长期记忆中检索相关信息"},
{"name": "memory_update", "description": "更新已有的记忆条目"},
{"name": "memory_summarize", "description": "将多条记忆合并为摘要"},
{"name": "memory_forget", "description": "删除不再需要的记忆"},
]
# Agent 在任务执行中自主调用这些工具管理记忆
官方原语：Anthropic Memory Tool（memory_20250818，2025-08）
Anthropic 在 2025-08 通过 Claude Developer Platform 推出 Memory Tool，把"记忆"做成 client/server 模式的官方工具原语——服务端只暴露文件接口（list/read/create/update/delete），由客户端持久化到任意存储后端（本地 FS、S3、SQLite、Redis 等），Claude 在 agentic loop 中按需调用：
代码块
SQL
import anthropic
client = anthropic.Anthropic()
# 1) 声明 Memory Tool（type 字段是 server-managed 标识，与 web_search 同范式）
memory_tool = {
"type": "memory_20250818",
"name": "memory", # 工具固定名
}
# 2) 调用 Claude，启用 context-management beta 与 memory beta
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=2048,
关键特性：
•
客户端持有数据所有权：服务器不存任何记忆内容，便于满足 GDPR/合规
•
与 context editing 协同：旧的 tool_result 会被服务端策略性清理，但 memory 文件保留
•
跨会话共享：把同一份 memory 文件挂到多个 Claude 会话/Agent，实现团队级或个人长期画像
•
比向量数据库更简单：路径 + 文本读写，模型自己决定存什么，不依赖额外的 embedding 服务
这是目前 LLM 厂商提供的最完整的"官方记忆原语"，与 Anthropic Skills、Structured Outputs 一起构成 2025-2026 Claude Platform 的三大新原语。
三种记忆的关系
常见误区 / 面试追问
误区："上下文窗口越大，就不需要长期记忆了" — 即使 200K token 的窗口，也无法存储数月的用户交互历史。更重要的是，窗口越大成本越高，且 LLM 在超长上下文中的注意力会分散（"lost in the middle" 问题）。
误区："短期记忆和工作记忆是一回事" — 短期记忆是对话历史的累积；工作记忆是当前步骤可用的全部信息（包括从长期记忆检索的内容）。工作记忆 = 短期记忆 + 检索的长期记忆 + System Prompt + 工具结果。
追问："如何决定什么信息值得存入长期记忆？" — 用重要性评分：(1) 用户明确要求记住的信息（高优先级）；(2) 影响未来决策的事实（如用户偏好）；(3) 成功解决问题的范例（情景记忆）。避免存储临时性信息和中间推理步骤。
追问："MemGPT 的核心思想是什么？" — 将上下文窗口视为有限的"内存"资源，实现类似操作系统虚拟内存的层级管理。Agent 可以在核心记忆（RAM/上下文窗口）和归档记忆（磁盘/外部存储）之间主动移动数据，创造"无限记忆"的体验。
追问："'LLM 无状态'这个前提会一直成立吗？" — 不一定。它描述的是当前主流架构，不是理论必然。Metis 这类记忆基础模型把记忆状态放进模型内部，通过 memory attention 访问历史压缩信息，更新只需一次前向传播、不需要梯度，推理时权重冻结而记忆状态自主演化——这时"无状态"就不再成立了。面试时的稳妥答法：说清楚这是当前工程现实和它成立的原因（每次 API 调用独立、KV cache 不跨请求保留），再指出已有把记忆内化进底座的研究方向。