Agent记忆机制

目录

一、Agent 为什么需要记忆？

普通 LLM：

  • ❌ 无状态（stateless）
  • ❌ 每次请求都是“失忆”的

Agent：

  • ✅ 能持续执行任务
  • ✅ 能基于历史做决策
  • ✅ 能个性化响应

👉 本质问题：

如何跨多轮推理保存和利用信息？

二、Agent 记忆的核心分类

2.1 感知记忆（Sensory Memory）

本质：存储Agent从环境中感知到的原始信息

存什么

  • 用户输入文本
  • 图片内容（多模态）
  • 工具返回结果
  • 当前环境状态

特点

  • ✅ 原始数据（未抽象）
  • ✅ 时间敏感（很快过期）
  • ❌ 不结构化

2.2 短期记忆（Short-Term Memory）

本质：上下文窗口（Context Window）

  • 存储在 Prompt 中
  • 通常是最近几轮对话
  • 直接参与当前推理

特点

  • ✅ 访问速度快
  • ❌ 容量有限（token 限制）
  • ❌ 会被截断

示例

1
2
3
User: 帮我写一个Java接口
Agent: ...
User: 再加一个异常处理

👉 第二句话依赖第一句话 → 短期记忆

2.3 长期记忆（Long-Term Memory）

本质：外部存储 + 检索机制（RAG）

常见实现：

  1. 向量数据库（最主流）
  • 存储：embedding
  • 检索：相似度搜索

常见组件：

  • FAISS
  • Milvus
  • Pinecone
  1. 结构化存储
  • Redis / MySQL
  • Key-Value 形式

特点

  • ✅ 可扩展
  • ✅ 持久化
  • ❌ 需要检索步骤（有延迟）

长期记忆还可以细分为：

  • 情节记忆：存的是具体的事件经历
  • 语义记忆：存的是从多次经历中提炼出来的通用知识和规律
  • 程序记忆：存的是怎么做某件事的操作流程

2.4 实体记忆（Entity Memory）

本质：从感知信息中抽取出的对象及其属性

存什么
例如：

1
2
3
4
5
6
7
8
9
10
{
  "user": {
    "name": "张三",
    "city": "北京"
  },
  "weather": {
    "location": "北京",
    "temperature": "25°C"
  }
}

特点

  • ✅ 结构化（JSON/Graph）
  • ✅ 可长期保存
  • ✅ 可更新
  • ✅ 可推理

2.5 四种记忆对比

类型 载体 容量 生命周期 访问方式
感知记忆 当次输入 极小 单次调用 即时访问
短期记忆 context window 受token限制 当前对话 直接访问
长期记忆 向量/关系数据库 无限 持久 语义检索
实体记忆 结构化数据 无限 持久 精确查询

三、Agent 记忆的核心流程（重点）

标准流程：

3.1 写入（Write）

  • 用户输入
  • Agent 输出
  • 关键信息抽取

3.2 存储（Store）

  • 向量化（embedding）
  • 存入 DB

3.3 检索（Retrieve）

  • 当前 query → embedding
  • 相似度匹配历史信息

3.4 注入（Inject）

  • 拼接到 prompt 中

3.5 推理（Reason）

  • LLM 基于“记忆 + 当前输入”生成结果

👉 可以总结为一句话：

Memory = 存 + 找 + 用

四、不同 Agent 范式中的记忆作用

4.1 ReAct

  • 记忆内容：

    • Thought / Action / Observation

  • 用途：

    • 形成推理链（chain of thought）

👉 更像“工作记忆”

4.2 Plan-and-Execute

  • 记忆内容：

    • 任务计划（Plan）
    • 子任务状态

👉 类似“任务状态机”

4.3 Reflection / Reflexion

  • 记忆内容：

    • 错误记录
    • 自我反馈

👉 关键能力：

从失败中学习

五、工程实现常见方案

5.1 LangChain Memory（经典）

  • ConversationBufferMemory
  • ConversationSummaryMemory
  • VectorStoreRetrieverMemory

5.2 RAG + Memory 融合

结构：

1
2
3
4
5
6
7
8
9
User Query
   ↓
Memory Retrieval
   ↓
RAG Retrieval
   ↓
Prompt 拼接
   ↓
LLM

5.3 Memory 压缩（很重要）

因为上下文有限，需要：

  • Summarization（摘要）
  • Sliding Window（滑动窗口）
  • 重要性筛选（importance scoring）

六、实际设计记忆模块的三个核心问题

6.1 记什么（What to store）——信息筛选问题

本质

不是所有信息都值得记

为什么是问题？

  • Token 和存储资源有限
  • 噪声会干扰推理
  • 无关信息降低检索质量

需要做的决策

  1. 哪些信息重要？
  • 用户偏好（长期）
  • 任务关键信息
  • 错误 / 反馈（Reflection）
  1. 哪些可以丢？
  • 闲聊
  • 重复信息
  • 无关上下文

常见策略

  • 规则过滤（Rule-based）
  • LLM 判断（importance scoring）
  • 摘要压缩（Summarization）

总结

值得存的有三种：用户偏好和习惯、任务执行中产生的关键结论和决策、以及外部知识

不值得存的：中间推理过程、工具返回的原始数据、闲聊内容

6.2 怎么存（How to store）——数据结构问题

本质

用什么结构存，决定了你能不能高效用

常见方案

  1. 向量存储（最主流）
  • embedding + 相似度检索
  • 适合语义匹配
  1. KV 存储
  • key: 用户ID / 任务ID
  • value: JSON

👉 适合：

  • 用户信息
  • 状态信息
  1. 图结构（高级玩法）
  • Knowledge Graph
  • Entity Memory

👉 适合：

  • 多实体关系
  • 复杂推理

设计权衡

方案 优点 缺点
向量 灵活 不精确
KV 精确 不智能
图 可推理 复杂

总结

需要语义检索的非结构化文本适合存进向量数据库；结构化的用户偏好和状态字段这些可以精确查询的内容适合用关系数据库或KV存储。整段文档或知识库适合存进向量数据库配合RAG流程做召回。

混合存储是主流做法：结构化信息用关系数据库，非结构化信息用向量数据库。

6.3 怎么用（How to retrieve & use）——检索与注入问题 ⭐

本质

存得再好，用不好也没意义

关键问题

  1. 什么时候检索？
  • 每轮都检索？
  • 还是按需触发？
  1. 检索多少？
  • Top-K？
  • 动态数量？
  1. 怎么注入？
  • 直接拼接？
  • 分块插入？
  • 结构化输入？

常见策略

  • Top-K 相似度检索
  • Re-ranking（重排序）
  • Prompt 模板控制

常见坑

  • ❌ 检索过多 → 上下文爆炸
  • ❌ 检索不准 → 干扰推理
  • ❌ 注入混乱 → 模型理解错误

总结

检索一般分为两种：
一种是主动检索，在任务开始前用当前任务的描述去检索相关记忆，把结果注入system prompt作为背景知识。
另一种是被动检索，Agent在推理过程中判断当前步骤需要某类特定知识时主动发起检索。

七、面试标准回答

👉 这段你可以直接用：

Agent 的记忆机制主要分为感知记忆、短期记忆、长期记忆和实体记忆四大类。感知记忆存储原始输入，短期记忆是上下文窗口，长期记忆通过外部数据库实现持久化，实体记忆则是结构化的对象信息。

在实际流程中，记忆机制包括写入、存储、检索和注入四个步骤，即先将交互信息结构化并存储，再在新任务中检索相关内容并拼接到 prompt 中，从而增强模型的上下文理解能力。

此外，在不同 Agent 范式中，记忆的作用也不同，比如 ReAct 中用于推理链记录，Plan-and-Execute 中用于任务状态管理，Reflection 中用于错误反馈和自我优化。

在设计 Agent 的记忆模块时，主要有三个核心问题：首先是记什么，即需要对输入信息进行筛选，保留对任务有价值的内容；其次是怎么存，需要选择合适的数据结构，比如向量数据库、KV 存储或知识图谱，以支持不同类型的信息；最后是怎么用，即在推理时如何高效检索相关记忆并注入到上下文中，这直接影响模型的输出质量。