Skip to content

AI Agent 记忆系统

如果说"上下文"是 AI 对话时的短期工作记忆,那"记忆系统"就是 AI Agent 的长期大脑——让 Agent 跨会话记住用户、跨任务积累经验。


为什么需要 Agent 记忆?

前面八章讲的都是"开发者如何给 AI 提供上下文"——本质上,你在扮演 AI 的备忘录。但当你开始构建真正的 AI Agent(自动执行任务的智能体)时,会发现一个问题:Agent 自己不会记住东西

看看没有记忆的 Agent 是什么样的:

会话 1:
用户:帮我配置开发环境,我用 React + TypeScript
Agent:好的,我记住了

会话 2(新对话):
用户:继续上次的配置
Agent:什么配置?你用什么技术栈?

每开始一个新会话,Agent 就像失忆了一样。这不是 bug,而是架构设计就是这样——大模型本身是无状态的,每次对话都是"重新开始"。

Agent 记忆和上下文的区别

上下文(Context):当前对话中的工作记忆
- 存的是:当前任务描述、对话历史、引用的文档
- 有效期:一次对话(通常几十分钟到几小时)
- 存储位置:模型上下文窗口里
- 谁来管理:开发者手动提供

记忆(Memory):跨会话的长期存储
- 存的是:用户偏好、已学技能、积累的知识
- 有效期:跨会话(天、周、月)
- 存储位置:外部数据库(向量/图数据库)
- 谁来管理:Agent 自己(或记忆系统自动管理)

简单说:上下文是短期工作记忆,记忆是长期持久存储

为什么 2026 年记忆系统成了关键组件?

2025-2026 年,AI Agent 记忆从"可有可无"变成了"核心架构组件"。原因有三:

  1. Agent 需要持续学习:不能每次会话都从零开始
  2. 个性化需求:用户期望 Agent 记住自己的偏好
  3. 多步骤任务:Agent 需要在长时间执行中保持状态

Mem0 在 2026 年发布的《State of AI Agent Memory》报告中定义了一个完整的评估基准(LOCOMO),让不同记忆架构可以在同一个测试集上对比。这标志着 Agent 记忆从经验主义走向了工程化


Agent 记忆的分类

从认知科学借鉴的分类

AI Agent 的记忆分类借鉴了认知科学的记忆模型。目前主流框架将 Agent 记忆分为三类:

┌─────────────────────────────────────────────────────┐
│                  AI Agent 记忆                        │
├─────────────┬──────────────┬────────────────────────┤
│  情景记忆   │   语义记忆    │     程序性记忆         │
│ (Episodic)  │  (Semantic)  │   (Procedural)         │
├─────────────┼──────────────┼────────────────────────┤
│ 发生过什么  │  知道什么    │   会做什么             │
│             │              │                        │
│ "用户上周说 │ "用户用      │ "用户团队的 PR         │
│  想迁移到   │  TypeScript" │  流程是先 lint        │
│  Zustand"   │              │  再测试"              │
└─────────────┴──────────────┴────────────────────────┘

1. 情景记忆(Episodic Memory)

记录"发生过什么"。Agent 经历过的每一次交互、每一个决策、每一次反馈。

markdown
情景记忆示例:
- 2026-04-20 15:30: 用户要求用 Zustand 替代 Redux
- 2026-04-21 09:15: 用户指出生成的组件缺少 loading 状态
- 2026-04-22 14:00: 用户在订单模块遇到了性能问题

情景记忆是其他两类记忆的"原材料"——Agent 从情景中提取语义知识和程序性技能。

2. 语义记忆(Semantic Memory)

记录"知道什么"。从交互中提取出的事实性知识,独立于具体的对话场景。

markdown
语义记忆示例:
- 用户偏好:偏好 TypeScript 严格模式
- 技术栈:项目使用 React 18 + Zustand + Vite
- 代码规范:组件名用 PascalCase,工具函数用 camelCase

语义记忆的价值在于"一次学习,到处应用"——用户说一次"我用 TypeScript",Agent 记下来,后续所有对话都按这个来。

3. 程序性记忆(Procedural Memory)

记录"怎么做的"。这是 2025-2026 年新引入的记忆类型(Mem0 v1.0.0 正式支持)。

markdown
程序性记忆示例:
- 用户团队的 PR 流程:创建分支 → 开发 → lint → 测试 → PR
- 项目部署流程:pnpm build → docker build → kubectl apply
- 测试模式:单元测试用 Vitest,E2E 用 Playwright

程序性记忆和语义记忆的区别:语义记"是什么",程序性记"怎么做"。这是隐性的技能知识,不是显性的事实。

按时效分类

除了按内容分类,还可以按时效分类:

类型期限存储位置示例
工作记忆几分钟上下文窗口当前对话内容
短期记忆几小时-几天向量数据库本次会话的决策过程
长期记忆周-月-永久向量/图数据库用户偏好、技能流程

Mem0 的 benchmark 显示:选择性记忆(只存关键信息)比全量上下文在延迟上快 14 倍(0.71s vs 9.87s),token 消耗低 14 倍(1,800 vs 26,000),准确率只下降 6 个百分点(66.9% vs 72.9%)。


记忆系统架构

核心流程:四阶段管道

一个完整的记忆系统通常包含四个阶段:

用户输入


┌─────────────────────┐
│ 1. 记忆提取         │ ← 从对话中提取关键信息
│    (Extraction)     │    实体、事实、偏好、工作流
└──────────┬──────────┘


┌─────────────────────┐
│ 2. 记忆存储         │ ← 选择存储后端
│    (Storage)        │    向量数据库 / 图数据库
└──────────┬──────────┘


┌─────────────────────┐
│ 3. 记忆检索         │ ← 查询时检索相关记忆
│    (Retrieval)      │    语义搜索 + 元数据过滤
└──────────┬──────────┘


┌─────────────────────┐
│ 4. 记忆注入         │ ← 将检索到的记忆
│    (Injection)      │    添加到上下文窗口
└─────────────────────┘


       LLM 生成回复

阶段 1:记忆提取

这个阶段决定"什么东西值得记住"。不是所有对话内容都值得存——只提取关键的:

python
# 伪代码:记忆提取逻辑
def extract_memories(conversation):
    memories = []

    # 提取事实性记忆
    facts = extract_facts(conversation)
    # "我用 TypeScript" → 语义记忆

    # 提取偏好性记忆
    preferences = extract_preferences(conversation)
    # "不要用 any" → 语义记忆

    # 提取流程性记忆
    procedures = extract_procedures(conversation)
    # "先跑 lint 再提交" → 程序性记忆

    # 去重和冲突检测
    memories = deduplicate(facts + preferences + procedures)

    return memories

关键设计决策:

  • 提取粒度:提取太粗(整段对话)→ 检索噪声大;提取太细→ 信息碎片化
  • 冲突处理:新信息与旧记忆矛盾怎么办?按时间戳覆盖,还是保留多个版本?
  • 过滤机制:敏感信息(密码、密钥)必须过滤掉

阶段 2:记忆存储

选择存储后端主要看三个维度:规模、延迟、查询模式。

存储类型适合典型方案延迟规模
向量数据库语义相似性检索Qdrant, Chroma, Pinecone4-12ms百万级
图数据库实体关系查询Neo4j, Kuzu5-20ms万级节点
键值存储简单事实查询Redis<1ms千万级

2026 年的趋势是混合存储

  • 向量数据库存语义记忆("用户喜欢什么")
  • 图数据库存实体关系("用户和哪些模块有关")
  • 两者互补,不是替代

Mem0g(图增强版)在 LOCOMO 测试中比纯向量版准确率高 1.5 个百分点(68.4% vs 66.9%),在多跳推理场景优势更明显。

阶段 3:记忆检索

检索要解决的问题是"从海量记忆中精确找到当前有用的"。几个关键技巧:

语义检索 + 元数据过滤

python
def retrieve_memories(query, user_id, session_id):
    # 语义搜索:找到内容相关的记忆
    candidate = vector_store.similarity_search(
        query,
        k=20  # 先召回过多的候选
    )

    # 元数据过滤:限定范围
    filtered = [
        m for m in candidate
        if m.user_id == user_id  # 只查当前用户的
        and m.session_id != session_id  # 排除当前会话的(避免重复)
    ]

    # 重排序:用更精细的模型重新排序
    reranked = reranker.rerank(query, filtered)

    return reranked[:5]  # 只取 top-5

重排序(Reranking)是 2026 年的标配。向量相似度搜索的结果排序不一定最优,加一层重排序能显著提升检索精度。Mem0 v1.0.0 正式内置了重排序器支持(Cohere、Hugging Face、LLM-based)。

阶段 4:记忆注入

把检索到的记忆注入到 LLM 的上下文窗口中。方式很直接:

markdown
系统提示词(注入记忆后):

以下是关于用户的记忆:

## 用户偏好
- 技术栈:React 18 + TypeScript + Zustand
- 命名规范:PascalCase 组件名
- 禁用项:严格禁止使用 any 类型

## 当前任务上下文
- 正在开发:购物车模块
- 上次讨论:确定了商品列表的数据结构
- 待解决:结算页的优惠券计算逻辑

请基于以上信息回答用户的问题。

注入策略的要点:

  • 数量控制:一般 3-5 条记忆最有效,太多反而稀释注意力
  • 优先级排序:最新的、最相关的、最具体的优先
  • 格式结构化:Markdown 标题 + 列表比纯文本更易让 AI 理解

多范围记忆模型

Mem0 在 2025 年提出的四范围记忆模型,已经成为事实上的行业标准:

记忆范围层次:

组织级(app_id / org_id)
  └── 共享上下文:公司规范、团队标准

       ├── 用户级(user_id)
       │   ├── 个人偏好:技术栈、命名习惯
       │   └── 个人历史:做过的项目、遇到的坑

       ├── Agent 级(agent_id)
       │   ├── Agent 技能:学会的流程
       │   └── Agent 状态:当前任务进度

       └── 会话级(run_id / session_id)
           ├── 当前对话:最近几轮的 context
           └── 临时状态:未完成的操作

范围组合规则

  • 用户级的记忆跨所有会话生效("用户用 TypeScript")
  • 会话级的记忆只在本会话有效("刚才的报错信息")
  • 查询时可以组合过滤:user_id + session_id 同时限定

实际应用场景

场景记忆范围说明
个人编码助手user_id记住个人技术栈偏好
多租户 AI 客服org_id + user_id不同公司的知识隔离
团队协作 Agentagent_id共享团队流程知识
一次性问答session_id单次对话上下文

基准测试与性能对比

LOCOMO 基准

LOCOMO(Long-term Conversational Memory)是 2025 年发布的标准化记忆评估数据集,包含多会话对话数据,测试不同难度级别的记忆召回能力。

评估框架使用四个维度:

  • BLEU Score:token 级别的响应与真实值相似度
  • F1 Score:响应 token 的精确率和召回率
  • LLM Score:LLM 评判的事实准确率(0 或 1)
  • Token 消耗:回答消耗的总 token 数
  • 延迟:搜索和生成的端到端时间

Mem0 基准测试结果(ECAI 2025 发表)

方法LLM Score (准确率)中位数延迟Token 消耗
全量上下文(所有历史)72.9%9.87s~26,000/对话
Mem0g(图增强)68.4%1.09s~1,800/对话
Mem0(向量)66.9%0.71s~1,800/对话
RAG(标准检索)61.0%0.70s-
OpenAI Memory52.9%--

关键发现

最重要的数字不是准确率那列,而是延迟那列。全量上下文虽然准确率最高(72.9%),但 p95 延迟达到 17.12 秒——生产环境完全不可用。

Mem0 的选择性管道在牺牲 6 个准确率百分点的代价下,换来了:

  • 91% 更低的 p95 延迟(1.44s vs 17.12s)
  • 90% 更少的 token 消耗(1,800 vs 26,000)

图增强版 Mem0g 把准确率差距缩小到了 5 个百分点以内(68.4%),同时保持低延迟(p95 2.59s)。

这个 benchmark 的核心启示:在记忆系统中,延迟和成本比绝对准确率更重要。一个 17 秒才回复的 Agent,再准也没人用。


图谱记忆:向量检索做不到的事

向量 vs 图谱

向量检索能回答"用户说过什么关于 Python 的内容",但图检索能回答"用户和 Python 什么关系——具体做什么、用哪些库、跟谁一起用"。

两者的区别:

向量检索:
"提到 Python" → 找到所有提到 Python 的对话片段

图谱检索:
"提到 Python" → 找到:
  - 用户使用 Python 做数据管道
  - 关联库:pandas, numpy
  - 同事:数据团队的张三也用
  - 项目:数据平台迁移中

图谱记忆的实现

图谱记忆在提取阶段构建实体关系图:

提取阶段:
原始对话 → 实体提取器 → 节点识别 → 关系推断 → 冲突检测 → 图存储
              ↓              ↓           ↓
          "Python"    "Python-数据管道"   "用户-A-使用→Python"
          "pandas"    "pandas-数据处理"   "Python-配套→pandas"

查询时,图谱遍历能找到间接关联:

cypher
// 查询:用户的技术栈关联了哪些工具?
MATCH (user:User {id: 'user_a'})-[:USES]->(tool:Tool)
OPTIONAL MATCH (tool)-[:INTEGRATES_WITH]->(related:Tool)
RETURN tool, related

什么时候该用图谱记忆?

Mem0 的实践建议:

  • 需要实体关系推理时:医疗病历关联、企业账户层级、系统依赖关系图
  • 简单个性化无需:用户偏好、历史记录这种纯向量就够
  • 图增强的副作用:延迟会增加(纯向量 p95 1.44s → 图增强 p95 2.59s),需要权衡

集成生态

Agent 框架集成

2026 年,记忆系统需要支持多样化的 Agent 框架——没有哪个框架一家独大。Mem0 在官方文档中列出了 13 个框架集成:

框架语言特点
LangChainPython生态最成熟,文档最全
LangGraphPython状态化 Agent 工作流
LlamaIndexPython文档密集型 RAG 管线
CrewAIPython多 Agent 团队协作
AutoGenPython对话式多 Agent 系统
MastraTypeScriptTypeScript 原生,工具调用集成
Vercel AI SDKTypeScriptWeb 应用一站式,单行代码集成

Mastra 的集成值得关注:@mastra/mem0 包将记忆暴露为两个工具(Mem0-memorizeMem0-remember),Agent 通过标准工具调用使用记忆,异步写入不阻塞响应生成。

语音 Agent 集成

语音 Agent 对记忆的需求比文本 Agent 更迫切——用户不能滚动历史记录、不能复制粘贴上下文。2026 年,ElevenLabs、LiveKit、Pipecat 等语音平台都接入了记忆系统。

语音场景的关键设计模式:

  • 异步写入:写入记忆不增加语音延迟
  • USER_ID 来自应用认证:记忆隔离绑定应用层认证,不需要单独的身份层
  • 限定检索范围:按 USER_ID 检索,避免跨用户记忆泄露

向量数据库兼容性

2026 年 Q1 的数据:一个成熟记忆系统需要支持 19 种向量数据库后端。

类别后端
自建/开源Qdrant, Chroma, Weaviate, Milvus, PGVector, Redis, FAISS
云托管Pinecone, Azure AI Search, MongoDB Atlas
图数据库Neo4j, Kuzu, Neptune Analytics
分布式Cassandra, Valkey

选择的实际经验:不要为了"最好的向量数据库"去换你已有的基础设施。用 PGVector 如果已经有 PostgreSQL,用 Redis 如果已经是缓存层,比引入一套新系统划算得多。


开放性挑战

尽管 2026 年记忆系统取得了显著进展,以下问题仍未完全解决:

1. 记忆精确度与应用层评估

LOCOMO 是通用的长期记忆基准,但它不捕获特定应用的质量。一个在 LOCOMO 上 66% 的系统的表现,在编码助手场景可能很好,在医疗场景可能很差。应用层面的记忆评估仍是一个手工定制的流程

2. 隐私与同意架构

用户级别的记忆需要同意和治理。用户如何查看、编辑、删除存储的记忆?团队如何审计存储了什么?记忆保留多久?目前这些是应用层的责任,记忆系统提供工具但不强制执行。

3. 跨会话身份识别

当前记忆模型假设稳定的 user_id。用户跨设备、跨认证方式(匿名 → 登录)时,判断是否是同一个人—并决定是否共享记忆空间—是一个非平凡的身份问题。

4. 记忆过时检测

随着记忆存储增长,"哪些记忆仍然准确"的问题越来越难。一条两年前的用户偏好可能已经不再适用。Mem0 的动态遗忘机制能降低低相关性条目的权重,但高相关度但已过时的记忆更难检测——用户今天还在用 TypeScript,但明天迁移到了 Rust。高度检索到的记忆如果突然过时,会变成"准确但有害"的误导。


总结

核心要点

  1. Agent 记忆是上下文管理的延伸:上下文是短期工作记忆,记忆是长期持久存储。两者互补,不能互相替代。

  2. 三类记忆各有用途:情景记忆(发生了什么)、语义记忆(知道什么)、程序性记忆(会做什么)。2025-2026 年,程序性记忆被正式引入记忆系统。

  3. 四阶段管道是标准架构:提取 → 存储 → 检索 → 注入。每个阶段都有独立的设计决策。

  4. 选择性记忆优于全量上下文:LOCOMO 基准测试表明,选择性记忆在准确率仅下降 6% 的前提下,延迟降低 91%,token 消耗降低 90%。

  5. 图增强记忆在实体关系场景有优势:Mem0g 比纯向量版准确率高 1.5 个百分点,适合多跳推理,但延迟成本增加了约一倍。

  6. 多范围记忆成为标准实践:四范围模型(组织/用户/Agent/会话)让记忆可以在不同粒度上隔离和共享。

快速入门

想在项目中引入 Agent 记忆系统,按以下步骤:

markdown
第 1 步:明确记忆需求
- 需要记住用户的哪些信息?
- 需要跨会话记住还是仅当前会话?
- 隐私和合规有什么要求?

第 2 步:选择记忆框架
- 小项目/原型:Mem0 或 LangMem
- 生产项目:Mem0 + Qdrant 或 PGVector
- 需要图谱:Mem0g + Neo4j 或 Kuzu

第 3 步:定义记忆范围
- 确定 user_id, session_id 的范围模型
- 设置记忆提取的过滤规则(哪些不存)

第 4 步:集成到 Agent
- 通过 Agent 框架的工具调用接入记忆
- 设置异步写入(不阻塞响应)
- 配置检索数量(3-5 条为佳)

第 5 步:监控和调优
- 观察记忆检索的准确率
- 定期清理过时记忆
- 根据使用反馈调整提取策略

推荐资源

阅读材料

框架和工具

  • Mem0 - 开源记忆层
  • LangMem - LangChain 记忆组件
  • Zep - 专用记忆管理平台

← 返回文章目录 | 继续学习:上下文安全与隐私 →

最近更新

基于 MIT LICENSE 许可发布