智能体记忆系统设计
·
1. 名词解释
本节对记忆系统涉及的核心概念进行定义，详见原文附录。
2. 业务背景
2.1 智能体系统的痛点
由于大模型本身的上下文窗口限制，以及长 Token 造成的性能问题，行业主流智能体系统通常会对记忆部分进行精细化管理，兼顾智能体的性能表现及记忆能力。
通用痛点如下：
| 痛点类别 | 说明 |
|---|---|
| 上下文窗口限制 | 大模型输入长度受限，无法承载全部历史记忆 |
| 长 Token 性能问题 | 上下文越长，推理耗时越高，响应变慢 |
| 跨会话遗忘 | 新会话无法继承前序会话的关键信息 |
| 个性化需求 | 不同用户有不同的偏好和画像，需个性化匹配 |
2.2 客户智能体记忆管理 — 首发场景
以客户智能体为例，面向广泛的商务同事，存在突出的产品交互体验及用户画像匹配的个性化需求。
2.2.1 用户偏好场景（中长期记忆）
示例：用户 A 是一名地区销售，平时更关注小米、华为、OPPO、唯品会相关客户；客户 A 是唯品会客户，托寄物类型通常是服装、鞋履等，双十一、618 等购物节前后有较大业务量。
记忆存储流程：
用户输入 query → Agent 回复 → 记忆管理工具抽取用户偏好属性 → 更新用户偏好数据库
记忆检索流程：
用户输入 query → 记忆管理工具调用用户偏好数据库 → 输出用户偏好属性 → Agent 业务处理及回复
3. 开源框架调研
| 框架 | 特点 | 备注 |
|---|---|---|
| MIRIX | 支持多模态记忆（可记忆图片内容），技术栈简单 | 推荐选型 |
| ReMe | 使用 FlowLLM 开发 | 学习成本高，优化成本高 |
| Mem0 / memOS | — | 所有记忆保存在一起，检索慢 |
| Clawdbot_memory | — | 参见附录 |
推荐选型：MIRIX — 支持多模态记忆，开发技术栈相对简单；ReMe 使用 FlowLLM 开发，学习与优化成本高。
4. 总体架构
4.1 系统架构
系统分为两大核心层：
┌─────────────────────────────────────────────────┐
│ 智能体记忆系统 │
├─────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ 记忆管理层 (Memory Management) │ │
│ │ │ │
│ │ · 记忆分类缓存 │ │
│ │ · 用户偏好分类 │ │
│ │ · 历史关注问题归档 │ │
│ │ · 时间/周期问题缓存 │ │
│ │ · 记忆总结、压缩、淘汰 │ │
│ │ · 精准检索 │ │
│ │ │ │
│ │ 目标: 最小化上下文 → 降低耗时 │ │
│ │ 解决跨会话遗忘问题 │ │
│ └───────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ 记忆数据沉淀层 (Data Sedimentation) │ │
│ │ │ │
│ │ · 共同关注问题抽取 │ │
│ │ · 生成大模型训练数据集 │ │
│ │ · 垂域模型微调训练 │ │
│ │ · 知识库数据沉淀 │ │
│ └───────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────┘
记忆管理层：实现对记忆进行分类缓存，定时对数据进行分类（用户偏好分类、历史关注问题归档、时间/周期问题缓存等），以实现历史问题查询、个人偏好管理、个性化推荐等。同时对记忆进行总结、压缩、淘汰和精准检索，有效实现最小化上下文，压缩会话上下文大小，降低耗时，解决跨会话遗忘问题。
记忆数据沉淀层：实现对共同关注问题的抽取，生成大模型训练的数据集，用于垂域模型微调训练或知识库数据沉淀。
4.2 技术架构
┌──────────────────────────────────────────────────────────────┐
│ 智能体记忆系统技术架构 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────┐ │
│ │ 记忆接入层 │ · 多模态数据提取与记忆分类 │
│ │ (Access Layer) │ · 消息队列实现负载均衡和流量削峰 │
│ └────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────┐ │
│ │ 记忆加工层 │ · 合并、淘汰、压缩、沉淀等独立算子 │
│ │ (Processing Layer)│ · Pipeline 计算加工 │
│ │ │ · 满足检索性能和精准度 │
│ └────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────┐ │
│ │ 可视化运维层 │ · 记忆可视化分析和修改 │
│ │ (Ops Layer) │ · 批量更新（政策变化/数据权限变更） │
│ │ │ · 新用户记忆初始化/迁移 │
│ │ │ · 集成到智能体平台中 │
│ └────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
- 记忆接入层：负责多模态数据提取和记忆分类，使用消息队列实现负载均衡和流量削峰，防止接入性能问题
- 记忆加工层：对已接入记忆进行进一步加工，针对不同类型的记忆加工任务（合并、淘汰、压缩、沉淀等）封装成独立算子，组成 Pipeline 进行计算
- 可视化运维层：针对记忆进行可视化分析和修改，应对政策变化或数据权限变更等情况；对用户记忆进行批量更新、新用户记忆初始化或迁移（将作为公共能力集成到智能体平台中）
5. 核心功能设计
整体功能设计是一个自上而下的链式记忆处理链条：
记忆接入加工 → 记忆检索 → 检索频次缓存 → 日级别总结/淘汰/抽取/沉淀
目标：以最小成本实现具有完整核心功能的 MVP 产品。
5.1 产品用户记忆层级设计
记忆分类名词解释：
| 记忆类型 | 说明 | 时效性 |
|---|---|---|
| 短期记忆 | 当前会话内的上下文信息 | 会话级 |
| 中期记忆 | 跨会话的用户偏好、习惯等 | 跨会话 |
| 长期记忆 | 经沉淀和总结的领域知识 | 持久化 |
| 集体记忆 | 多用户共享的共性记忆 | 共享级 |
设计逻辑：
- 每一个接入的智能体独立在一个空间中（按照 MaSS（Memory as a Service） 思路设计，将集成在智能体开放平台中）
- 每一个空间下，每个用户拥有自己独立的记忆
- 根据记忆的来源和通识性，将记忆归类到集体记忆中，方便记忆共享，降低大模型对同类问题的推理频率
┌──────────────────────────────────────┐
│ Agent Space │
│ ┌────────────────────────────────┐ │
│ │ 集体记忆 (Shared) │ │
│ │ · 共性领域知识 │ │
│ │ · 专家抽取记忆 │ │
│ └────────────────────────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ 用户 A 记忆 │ │ 用户 B 记忆 │ │
│ │ · 个人偏好 │ │ · 个人偏好 │ │
│ │ · 历史关注 │ │ · 历史关注 │ │
│ └─────────────┘ └─────────────┘ │
└──────────────────────────────────────┘
5.2 记忆保存加工设计
设计逻辑：
- 所有保存记忆功能异步处理，通过线程池消费内化
- 依据大模型和提示词规则构造记忆主题分类算子，实现对记忆进行分类（有效解决了 Mem0 所有记忆保存在一起导致检索慢的问题）
- 每种类型的记忆通过对应的分类主题记忆算子链进行加工处理写入（ReMe 和 MIRIX 都有类似设计，可直接借鉴）
输入记忆 → 异步线程池 → 记忆主题分类算子 → 分类主题算子链加工 → 写入对应记忆库
5.3 记忆检索逻辑设计
设计逻辑：
- 核心依旧是记忆主题分类算子，对 query 进行分类（可能得到多个分类 topic）
- 并发对对应分类进行相似度查询，并对结果进行整合
- 返回内容，或依据自定义规则构造出新的上下文提示词返回
用户 query → 记忆主题分类算子 → 多 topic 分类 → 并发相似度查询 → 结果整合 → 返回/构造上下文提示词
5.4 记忆分级缓存设计
设计逻辑：
- 所有记忆先写入记忆历史表中用于存档追溯（后续性能问题可考虑 ELK 或 Kafka 异步记录等方式）
- 通过定时任务对 Redis 缓存中的数据进行刷写（热点数据 + 最近数据），保障请求尽量命中 Redis，实现访问加速
记忆写入 → 记忆历史表（存档追溯）
↓
Redis 缓存（热点数据 + 最近数据）
↓
定时任务刷写 → 保障 Redis 命中率 → 访问加速
5.5 专家记忆抽取
设计逻辑：
- 配置定义专家规则和专家对应的提示词
- 基于大模型和用户的长期记忆，实现对大多数用户共有的领域记忆进行抽取、归档，并生成版本
- 用于后续垂域模型训练使用
专家规则配置 + 提示词 → 大模型 + 用户长期记忆 → 领域记忆抽取 → 归档 + 版本管理 → 垂域模型训练数据集
5.6 记忆总结
设计逻辑：
- 基于大模型评估记忆间的相关性，对记忆的相关性进行分组
- 通过大模型将相关性强的多条记忆合并成为一条，并更新元数据信息（元信息用于记忆遗忘淘汰使用）
- 删除合并前的数据，并插入新数据
记忆集合 → 大模型评估相关性 → 分组 → 合并为单条记忆 → 更新元数据 → 删除旧数据 + 插入新数据
5.7 记忆遗忘淘汰
淘汰算法：
评分公式：important（重要性评分）
初始状态： important = 5, freq = 1, time = now()
检索命中： freq += 1, time = now()
每 freq 增加 3，important += 1
过期衰减： 当 time + expire ≤ now 时，important -= 1
淘汰条件： 当 important ≤ 0 时，删除记忆
| 参数 | 说明 |
|---|---|
important |
重要性评分，默认初始值 5 |
freq |
访问频次，默认初始值 1 |
time |
最后访问时间，默认 now() |
expire |
过期阈值，与 time 配合进行衰减 |
核心机制：
- 频次加增：每次检索命中 freq +1，每 freq 增加 3 则 important +1
- 时间衰减：超过 expire 时 important -1
- 零值淘汰：important ≤ 0 时删除记忆
5.8 记忆编辑可运维（可集成到开放平台）
记忆可视化编辑内容可单独成为一个产品服务。
MIRIX 自带一个基于 React 写的可视化模块，可以基于它来二次开发。
运维场景：
| 场景 | 说明 |
|---|---|
| 政策变化 | 批量更新用户记忆 |
| 数据权限变更 | 修改记忆可见范围 |
| 新用户初始化 | 记忆模板初始化 |
| 用户迁移 | 记忆数据迁移 |
6. MVP 版本部署方案
详见原文附录中的部署架构图。
7. 实施路径
详见原文附录中的分阶段实施计划。
8. 附录
8.1 框架调研资料
- 记忆框架调研：mem0 & memOS
- 记忆框架调研：Clawdbot_memory
- 大模型记忆管理预研报告
8.2 参考开源项目
- MIRIX（推荐选型）
- ReMe
- Mem0 / memOS
8.3 参考论文
详见原文完整列表。
设计要点总结
| 要点 | 核心思路 |
|---|---|
| 架构理念 | MaSS（Memory as a Service），记忆即服务 |
| 分类策略 | 记忆主题分类算子，避免 Mem0 的全量混合存储问题 |
| 加工模式 | 独立算子 Pipeline（合并/淘汰/压缩/沉淀） |
| 缓存策略 | Redis 分级缓存 + 定时刷写，保障命中率 |
| 淘汰算法 | important 颏次加增 + 时间衰减，零值淘汰 |
| 推荐框架 | MIRIX（多模态支持、技术栈简单） |
| MVP 目标 | 最小成本实现完整核心功能链 |
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
4
0- 0
已为社区贡献21条内容
所有评论(0)