MemOS 深度解析：3700+ Star 的 AI 记忆操作系统，比 Claude 更早把记忆和知识库分清楚了

本文由无忆研习社站长莫潇羽原创撰写，全文约 12000 字，预计阅读时间 30 分钟。转载请注明来源。

写在前面：为什么 AI 需要一个"记忆操作系统"？

每次打开 ChatGPT 或者 Claude，你是不是总要重复介绍自己——"我是做前端开发的"、"我喜欢简洁的代码风格"、"上次我们聊到的那个项目需求是……"？

这不是你的问题，也不是 AI 的 Bug。

这是当前大语言模型（LLM）架构层面的根本性缺陷——它们天生没有"记忆"。

作为无忆研习社的站长，莫潇羽这几年接触过大量 AI 开源项目，从最早的 ChatGPT API 封装，到后来的 LangChain、AutoGPT，再到各种 RAG 方案。但说实话，真正让我眼前一亮的"记忆解决方案"并不多。直到我发现了 MemOS——一个已经获得 3700+ Star 的 AI 记忆操作系统。

巧的是，就在这两天，Anthropic 刚刚被曝光正在为 Claude Cowork 开发「Knowledge Base + Memory」功能更新。但 MemOS 早在 2025 年 5 月就已经公开发布了论文，在理念和架构上走在了业界前面。

本文将从技术原理、架构设计、实战操作三个维度，带你彻底搞懂 MemOS。无论你是 AI 开发小白，还是想要构建具有长期记忆能力 Agent 的资深工程师，这篇文章都值得你收藏。

第一部分：理解问题的本质——当前 AI 记忆机制的四大痛点

在深入 MemOS 之前，我们需要先理解它到底要解决什么问题。莫潇羽认为，当前大语言模型在记忆方面存在四个核心痛点，这些痛点直接制约了 AI 应用的发展。

痛点一：每次对话都是"初次见面"——无状态的对话困境

现在的 LLM（大语言模型）本质上是无状态的。每当你发送一条消息，模型并不记得之前的任何交互。你看到的所谓"对话历史"，其实是每次请求时，系统把之前的聊天记录一股脑塞回给模型，让它"假装"记得。

这就像是每次去咖啡店，服务员都要重新认识你一样。哪怕你每天都去，每次都点同样的美式咖啡，服务员也不会主动帮你准备好——因为在他的世界里，每个顾客都是第一次见面。

这种方式存在三个严重问题：

1. Token 消耗巨大

每轮对话都要传输完整历史，对话越长，成本越高。以 GPT-4 为例，输入 Token 的价格约为 0.03 美元/千 Token。如果你的对话历史有 10000 个 Token，每次请求的成本就要 0.3 美元。一个小时内进行 20 次对话，光是重传历史的成本就要 6 美元。

2. 上下文窗口限制

即使是号称 200K 上下文窗口的 Claude，也装不下几个月的交互记录。按照平均每轮对话 500 Token 计算，200K 的窗口最多容纳 400 轮对话。如果你每天和 AI 交互 20 次，不到一个月就会撑爆上下文。

3. 无法跨会话延续

今天的对话结束，关闭浏览器，明天再打开——所有的上下文都消失了。你和 AI 之间积累的默契、它对你工作习惯的了解，全部归零。

痛点二：RAG 只能"查"，不能真正"记"——静态检索的局限

你可能会说，不是有 RAG（检索增强生成）吗？把文档扔进向量数据库，需要时检索不就行了？

这里莫潇羽要纠正一个常见的认知误区：RAG 和 Memory 是两码事。这个区分非常重要，理解了这一点，你才能真正理解 MemOS 的价值。

RAG 的本质是什么？

RAG（Retrieval-Augmented Generation）擅长的是静态知识检索。它的工作流程是：

1. 用户提问
2. 系统把问题转换成向量
3. 在向量数据库中搜索语义相似的文档片段
4. 把找到的内容拼接到 Prompt 中
5. 让 LLM 基于这些内容生成回答

这个流程有几个致命缺陷：

缺陷 1：无状态

RAG 不知道你是谁、你之前问过什么、你有什么偏好。它只是一个"检索引擎"，对所有人返回相同的结果。你问"Python 的 for 循环怎么写"，它找到相关文档返回给你。下次你问"那个循环语法"，它根本不知道你说的是 Python 还是 JavaScript。

缺陷 2：无时序

这是 RAG 最要命的问题。它分不清"去年喜欢 Adidas"和"今天换成了 Puma"。

让我用一个具体例子说明：

Day 1: 用户说"我喜欢 Adidas 运动鞋，穿着很舒服"
Day 30: 用户说"我的 Adidas 鞋子一个月就脱胶了，质量太差，再也不买了"
Day 31: 用户说"我换成 Puma 了，感觉不错"
Day 45: 用户问"你推荐什么运动鞋？"

传统 RAG 的做法：
- 把"推荐运动鞋"转换成向量
- 在数据库中搜索语义相似的内容
- 找到 Day 1 的记录"我喜欢 Adidas 运动鞋，穿着很舒服"（语义相似度最高）
- 返回：推荐 Adidas 运动鞋

结果：推荐了用户已经明确表示不想买的品牌

这就是 RAG 的本质局限——它只做语义匹配，不理解时间线和因果关系。它认为"喜欢 Adidas"和"运动鞋推荐"语义相似度高，就返回这条记录，完全忽略了后面的"负面反馈"和"品牌切换"。

缺陷 3：无关联

RAG 无法理解"上次那个 bug"指的是什么。它没有"上下文记忆"的概念，每次检索都是独立的。你说"帮我继续修那个 bug"，它只能傻眼——哪个 bug？什么 bug？

痛点三：记忆"孤岛"——无法互通的数据壁垒

如果你同时使用多个 AI 工具，你会发现一个尴尬的现实：每个工具都是独立的，记忆完全隔离。

• 工作用 Claude，它知道你的项目需求
• 写代码用 GitHub Copilot，它了解你的代码风格
• 日常聊天用 ChatGPT，它记得你的兴趣爱好

但这三个"AI 助手"之间，没有任何数据共享。你在 Claude 上积累的偏好设置，无法迁移到 ChatGPT；你在某个 Agent 项目里训练出的"人设"，换个环境就丢了。

更糟糕的是，即使是同一个产品，不同平台之间也可能存在记忆孤岛。MemOS 论文中指出：

"Any memory an AI develops on one platform (like a web browser) is trapped there and cannot be transferred to another (like a mobile app), forcing users to start from scratch."
"AI 在一个平台上形成的记忆被困在那里，无法转移到另一个平台。用户被迫从头开始。"

这种"记忆孤岛"现象，是阻碍 AI 真正个性化的最大障碍之一。

痛点四：知识无法持续演化——静态参数的困境

LLM 的知识主要存储在模型参数中，这些参数在预训练阶段就已经固定。虽然可以通过微调（Fine-tuning）更新模型知识，但这个过程成本极高、周期极长，远远跟不上现实世界知识的变化速度。

想象一下：你是一个电商客服 AI，需要记住：

• 产品目录每周更新
• 促销活动每天变化
• 用户偏好实时调整
• 客服话术持续优化

用传统的"参数固化"方式，你需要每周甚至每天重新训练模型。这在实际生产环境中几乎不可能实现。

第二部分：MemOS 的核心理念——把记忆当成一等公民

现在我们来正式介绍 MemOS。它的核心理念可以用一句话概括：

把记忆当成操作系统级别的资源来管理，就像 OS 管理 CPU、内存、磁盘一样。

这句话背后的含义非常深刻。在传统操作系统中，CPU 时间、内存空间、磁盘 I/O 都有专门的调度器进行管理——哪个进程优先执行、哪块内存可以被回收、哪些文件需要缓存。这些决策不是随机的，而是由一套精心设计的调度算法来完成。

MemOS 的思路是：AI 的记忆也需要这样一套管理系统。它不是简单地"把所有东西都记下来"，而是要回答以下关键问题：

• 哪些信息值得记住？（记忆筛选）
• 记住的信息存储在哪里？（记忆分层）
• 什么时候需要回忆这些信息？（记忆检索）
• 过时的信息如何处理？（记忆演化）
• 不同类型的记忆如何协调？（记忆调度）

MemOS 的三层记忆模型详解

MemOS 将 AI 的记忆分为三种类型，这是理解整个系统的关键。莫潇羽认为这个分类方式非常优雅，它既借鉴了计算机系统的内存层次结构，又融合了认知科学对人类记忆的研究成果。

第一层：参数记忆（Parametric Memory）

参数记忆是编码在模型权重中的知识，通过预训练或微调获得。你可以把它理解为人类的"长期程序性记忆"或"内隐记忆"——骑自行车怎么骑、母语语法怎么用，这些是刻在神经网络里的，不需要刻意回忆就能自动运用。

技术特点：

• 存储形式：模型权重参数（Weights）
• 获取方式：预训练、微调（Fine-tuning）、LoRA 适配
• 更新成本：极高（需要重新训练或微调）
• 访问速度：最快（直接在推理时使用）
• 容量限制：受模型参数量限制
• 可编辑性：极差（难以精确修改特定知识）
• 可追溯性：极差（难以知道某个知识来自哪里）

适用场景：

• 基础语言能力（语法、常识）
• 领域通用知识（医学概念、法律术语）
• 高频使用的技能（代码补全模式、文档格式）

MemOS 的创新：

MemOS 提出了"动态参数记忆"的概念。通过 LoRA（Low-Rank Adaptation）等技术，可以把一些高频使用的知识"固化"到模型参数中，而不需要完整的微调。这就像是把常用的知识从"笔记本"转移到"大脑"里，访问更快、成本更低。

第二层：激活记忆（Activation Memory）

激活记忆是模型推理时产生的中间状态，最典型的就是 KV Cache（Key-Value 缓存）。你可以把它理解为人类的"工作记忆"或"短期记忆"——正在处理的信息、刚才看到的内容。

技术特点：

• 存储形式：KV Cache、Hidden States
• 获取方式：推理过程中自动生成
• 更新成本：低（每次推理自动更新）
• 访问速度：快（已经在 GPU 显存中）
• 容量限制：受上下文窗口限制
• 可编辑性：中等（可以通过特殊技术修改）
• 可追溯性：中等（知道来自当前对话）

适用场景：

• 当前对话的上下文理解
• 多轮对话的指代消解
• 实时任务的状态跟踪

MemOS 的创新：

传统的 KV Cache 在对话结束后就会被丢弃。但 MemOS 认为，有些激活记忆是有价值的，应该被"持久化"。比如，你经常和 AI 讨论某个项目，每次对话都会生成关于这个项目的 KV Cache。如果能把这些 Cache 保存下来，下次讨论时直接加载，就能大大节省计算成本和 Token 消耗。

这就是 MemOS 所说的"缓存"（Caching）机制：把高频使用的激活记忆"冻结"下来，供后续使用。

第三层：明文记忆（Plaintext Memory）

明文记忆是可以显式存储、检索、编辑的文本知识。传统的 RAG 用的就是这类记忆，但 MemOS 对它进行了系统化管理。你可以把它理解为人类的"外部记忆"或"笔记本"——写下来的东西，需要时翻阅。

技术特点：

• 存储形式：文本、JSON、向量嵌入
• 获取方式：显式写入、对话提取
• 更新成本：低（直接修改文本）
• 访问速度：中等（需要检索）
• 容量限制：几乎无限（外部存储）
• 可编辑性：极好（直接编辑文本）
• 可追溯性：极好（带有元数据）

适用场景：

• 用户偏好设置
• 项目需求文档
• 历史对话摘要
• 领域知识库

MemOS 的创新：

MemOS 不是简单地把明文记忆当作"静态文档"，而是引入了完整的生命周期管理：

1. 生成（Generation）：从对话中自动提取有价值的信息
2. 组织（Organization）：用树形或图形结构组织记忆
3. 演化（Evolution）：随着新信息的到来，更新或修正旧记忆
4. 归档（Archiving）：把不常用的记忆移到"冷存储"
5. 过期（Expiration）：自动清理过时或错误的记忆

三种记忆的动态流转

MemOS 最精妙的设计在于：这三种记忆不是割裂的，而是可以动态转换的。这就像计算机系统中，数据可以在 CPU 缓存、内存、硬盘之间流动一样。

明文记忆 ⟺ 激活记忆 ⟺ 参数记忆
（硬盘）    （内存）    （CPU缓存）

具体转换场景：

1. 明文 → 激活（缓存/预热）

当某段明文知识被频繁访问时，MemOS 可以自动将其"编译"成激活记忆。比如，你的公司有一份产品手册，每次客服对话都会用到。与其每次都从向量数据库检索再让模型重新"理解"，不如提前生成 KV Cache，直接注入到模型的上下文中。

这个过程就像是把常用的文件从硬盘复制到内存，下次访问时速度更快。

2. 激活 → 参数（固化/学习）

当某个知识或技能需要"深度学习"时，可以通过 LoRA 等技术将其"固化"到模型参数中。比如，你的 AI 助手在过去一个月的对话中学会了你公司的业务术语和沟通风格。与其每次都在 Prompt 中提醒它，不如把这些知识微调到模型里，让它"真正掌握"。

这个过程就像是把知识从"笔记"转化为"肌肉记忆"。

3. 参数 → 明文（归档/导出）

当某些参数知识变得过时，或者需要迁移到其他模型时，可以将其"导出"回明文形式。比如，一个微调过的模型要升级到新版本，旧的微调知识可以先导出为文档，然后用新方法重新学习。

这个过程就像是把"肌肉记忆"写成"操作手册"，方便传承和迁移。

4. 明文 ⟺ 激活 ⟺ 参数（全链路演化）

在实际应用中，一条知识可能经历完整的生命周期：

1. 用户说"我们公司的退款政策是 7 天无理由退换"
2. MemOS 提取这条信息，存储为明文记忆
3. 客服 AI 频繁用到这条信息，MemOS 将其缓存为激活记忆
4. 一个月后，公司政策更新为"15 天无理由退换"
5. MemOS 检测到冲突，更新明文记忆，清除旧的激活缓存
6. 如果这条知识被证明长期重要，可以考虑微调到参数中

这种动态流转机制，让 MemOS 实现了记忆的"自我优化"——热数据往上走、冷数据往下沉，跟计算机的内存层次结构（Cache → RAM → Disk）如出一辙。

第三部分：MemOS 架构深度剖析

理解了核心理念，我们来看 MemOS 的具体架构实现。作为无忆研习社的站长，莫潇羽特意研读了 MemOS 的论文和源码，为大家详细梳理其技术架构。

核心抽象：MemCube（记忆立方体）

MemCube 是 MemOS 最核心的抽象单元，你可以把它理解为一个"标准化的记忆容器"。就像操作系统用"进程"来抽象运行中的程序一样，MemOS 用 MemCube 来抽象各种类型的记忆。

每个 MemCube 包含两个核心组成部分：

1. Payload（负载）

这是实际的记忆内容，可以是多种形式：

文本负载：

{
  "type": "text",
  "content": "用户偏好：喜欢简洁的代码风格，倾向使用 TypeScript",
  "encoding": "utf-8"
}

KV Cache 负载：

{
  "type": "kv_cache",
  "keys": [[0.1, 0.2, ...], ...],
  "values": [[0.3, 0.4, ...], ...],
  "layers": 32
}

LoRA 权重负载：

{
  "type": "lora",
  "rank": 8,
  "alpha": 16,
  "weights": {
    "q_proj": [...],
    "v_proj": [...]
  }
}

2. Metadata（元数据）

这是描述记忆的各种属性，对于记忆的管理和调度至关重要：

{
  "cube_id": "mem_cube_001",
  "user_id": "user_12345",
  "project_id": "proj_67890",
  "source": "conversation",
  "source_id": "conv_2025_01_15_001",
  "created_at": "2025-01-15T10:30:00Z",
  "updated_at": "2025-01-15T14:20:00Z",
  "expires_at": "2025-04-15T10:30:00Z",
  "importance_score": 0.85,
  "access_count": 42,
  "last_accessed": "2025-01-19T09:15:00Z",
  "version": 3,
  "tags": ["preference", "coding_style"],
  "access_control": {
    "owner": "user_12345",
    "read": ["team_dev"],
    "write": ["user_12345"]
  },
  "lineage": {
    "parent_cubes": ["mem_cube_000"],
    "derived_from": "conversation_extraction"
  }
}

关键元数据字段说明：

通过这种标准化的封装，MemOS 可以对记忆进行追踪、调度、权限控制和演化，将记忆从单纯的"数据"提升为"可管理的系统资源"。

三层架构设计详解

MemOS 采用经典的三层架构，每一层都有明确的职责边界：

接口层（Interface Layer）

职责：与用户或上游系统交互，解析自然语言请求，识别记忆相关意图。

核心组件：

1. MemReader（记忆读取器）

这是接口层的核心，负责将用户的自然语言输入翻译成结构化的记忆操作链。

例如，用户说："帮我回忆一下上周和张总讨论的技术方案细节"

MemReader 会将其解析为：

{
  "intent": "memory_retrieval",
  "time_range": {
    "start": "2025-01-13",
    "end": "2025-01-19"
  },
  "entities": [
    {"type": "person", "name": "张总"},
    {"type": "topic", "name": "技术方案"}
  ],
  "memory_scope": "conversation",
  "output_format": "detailed_summary"
}

MemReader 的关键能力：

• 时间表达式解析：理解"上周"、"去年 Q4"、"三天前"等自然语言时间
• 实体识别：提取人名、项目名、概念名等
• 意图分类：判断是检索、更新、删除还是查询记忆
• 上下文推断：在多轮对话中，推断省略的细节

2. Memory API（记忆接口）

提供标准化的 API 套件，包括：

操作层（Operation Layer）

职责：记忆的调度、组织和生命周期管理。这是 MemOS 的"大脑"。

核心组件：

1. MemScheduler（记忆调度器）

这是操作层最核心的组件，负责决定"什么时候使用什么记忆"。

MemScheduler 的工作流程：

1. 接收来自接口层的记忆操作请求
2. 根据任务类型和用户画像，确定需要哪些记忆
3. 从不同的记忆池（参数/激活/明文）中检索候选记忆
4. 根据调度策略（相关性、新鲜度、重要性）排序
5. 考虑上下文窗口限制，选择最终注入的记忆
6. 返回给 LLM 进行推理

调度策略的关键因素：

2. MemLifecycle（记忆生命周期管理器）

管理每个 MemCube 的状态转换：

[创建] → [活跃] → [休眠] → [归档] → [过期/删除]
   ↑         ↓
   └─ [激活] ←┘

状态说明：

• 创建：新记忆被提取或导入
• 活跃：正在被频繁访问
• 休眠：一段时间未被访问，但仍保留
• 归档：长期未访问，移至冷存储
• 过期：超过保留期限，等待删除
• 激活：休眠记忆被重新访问，回到活跃状态

3. MemOperator（记忆操作器）

负责记忆的语义和结构化组织：

树形组织：

用户偏好
├── 编程偏好
│   ├── 语言：TypeScript
│   ├── 风格：函数式
│   └── 框架：React
├── 工作习惯
│   ├── 工作时间：10:00-22:00
│   └── 沟通方式：异步为主
└── 个人信息
    ├── 姓名：莫潇羽
    └── 角色：技术博主

图形组织：

除了树形结构，MemOS 还支持图形结构来表示复杂的语义关系：

[张总] --参与--> [A项目技术评审]
    |                    |
    |                    |
    v                    v
[决策者]           [微服务方案] --优于--> [单体方案]

这种图形结构特别适合表示：

• 人物关系网络
• 事件因果链
• 概念关联图

基础设施层（Infrastructure Layer）

职责：记忆的持久化存储、访问控制和跨平台互操作。

核心组件：

1. MemVault（记忆保险库）

归档记忆的存储系统，支持多种后端：

• 本地文件系统
• 对象存储（S3、MinIO）
• 图数据库（Neo4j、NebulaGraph）
• 向量数据库（Milvus、Pinecone）

2. MemGovernance（记忆治理）

访问控制和权限管理：

• 多租户隔离
• 细粒度权限控制（读/写/删除）
• 审计日志
• 数据加密

3. MemStore / MemLoader / MemDumper

记忆的迁移和互操作工具：

• MemStore：支持 Agent 间的记忆上传/下载
• MemLoader：从外部系统导入记忆
• MemDumper：将记忆导出为标准格式

执行流程示例

假设用户说："帮我回忆一下上周讨论的技术方案"

步骤 1：接口层处理

MemReader 解析请求：

{
  "intent": "memory_retrieval",
  "time_range": {"relative": "last_week"},
  "topic": "技术方案",
  "memory_types": ["conversation", "document"]
}

步骤 2：操作层调度

MemScheduler 执行检索：

1. 从明文记忆池中搜索"技术方案"相关的 MemCube
2. 过滤时间范围为"上周"
3. 按相关性和时间排序
4. 选择 Top-K 个结果

MemOperator 组织结果：

找到 3 条相关记忆：
1. [高相关] 2025-01-15 与张总讨论微服务架构方案
2. [中相关] 2025-01-16 API 网关选型会议纪要
3. [低相关] 2025-01-17 数据库分库分表讨论

步骤 3：基础设施层支持

MemVault 提供存储访问

MemGovernance 验证用户权限

步骤 4：返回结果

将组织好的记忆注入到 LLM 的上下文中，生成回复：

"根据我的记忆，上周您讨论了以下技术方案：
微服务架构方案（1月15日与张总讨论）：决定采用 Kubernetes + Istio 的方案，预计分 3 个阶段实施...
API 网关选型（1月16日会议）：最终选择了 Kong，主要考虑到..."

整个流程形成一个闭环：从输入到激活、从转换到存储、再到复用——每一步都由 MemCube 承载，每一步都可追踪。

第四部分：MemOS vs RAG——本质区别的深度对比

很多同学会问：MemOS 和 RAG 到底有什么区别？为什么不直接用 RAG？

莫潇羽用一张详细的对比表来说明：

打个形象的比方：

• RAG 像一个图书馆检索系统：你问什么，它就去书架上找最相关的书。找到了就给你，找不到就说没有。它不记得你上次借了什么书，也不会因为你是老读者就给你特别推荐。
• MemOS 像一个有记忆的私人助理：它不仅帮你找书，还记得你上次借了什么、你喜欢什么类型、你现在正在做什么项目。它会根据你的阅读历史和当前需求，主动推荐相关的书籍。更重要的是，它知道哪些信息是新的、哪些是旧的，不会给你过时的建议。

第五部分：MemOS vs Claude Memory——理念对比

就在最近，Anthropic 也推出了 Claude Memory 功能。那么 MemOS 和 Claude Memory 有什么异同呢？

Claude Memory 的设计理念

根据 Anthropic 的官方文档和最新曝光的信息，Claude Memory 采用了一种基于文件的透明架构：

1. 存储方式：记忆存储在简单的 Markdown 文件（CLAUDE.md）中
2. 检索方式：将整个记忆文件加载到上下文窗口中
3. 管理方式：用户手动管理记忆文件
4. 分层结构：支持用户级、项目级、团队级的记忆层次

两者的异同

莫潇羽的观点

两者其实代表了不同的设计哲学：

• Claude Memory 追求简单和透明，让用户完全掌控自己的记忆。这对于个人用户和小团队来说很友好，但在大规模、复杂场景下可能会遇到瓶颈。
• MemOS 追求系统化和自动化，提供完整的记忆管理框架。这对于企业级应用和复杂的 Agent 系统更有优势，但学习曲线相对陡峭。

如果你只是想让 AI 记住你的偏好，Claude Memory 可能就够了。但如果你要构建一个有复杂记忆需求的 AI 系统，MemOS 的架构设计更值得参考。

第六部分：实战教程——从零开始使用 MemOS

说了这么多理论，现在进入实操环节。莫潇羽将手把手教你如何使用 MemOS，分为云端和本地两种方式。

方式一：使用 MemOS Cloud（推荐新手）

如果你只是想快速体验，不想折腾本地部署，可以使用 MemOS 提供的云服务。

第一步：注册账号获取 API Key

访问 MemOS 控制台：

https://memos-dashboard.openmem.net

注册账号后，进入 API 密钥控制台，点击"创建新密钥"，生成一个 API Key 并妥善保存。

第二步：创建知识库

在控制台的"知识库"页面，点击"新建知识库"：

1. 填写基本信息
• 知识库名称：如"我的工作笔记"
• 描述：可选
2. 上传内容
• 支持的格式：PDF、Word、TXT、Markdown
• 支持添加网页 URL（自动抓取内容）
• 支持手动输入文本
3. 等待处理

MemOS 会自动完成以下步骤：

• 文档解析
• 内容分段
• 向量化
• 记忆生成

1. 获取知识库 ID

处理完成后，在列表页复制知识库 ID（格式如 kb_xxxxxxxxxxxx）

第三步：安装依赖

pip install openai requests

第四步：编写代码

创建一个 Python 文件 memos_demo.py：

import os
import json
import requests
from openai import OpenAI

# ==================== 配置区域 ====================
# 替换为你的 API Key
MEMOS_API_KEY = "你的_MemOS_API_Key"
OPENAI_API_KEY = "你的_OpenAI_API_Key"

# MemOS API 基础地址
MEMOS_BASE_URL = "https://memos.memtensor.cn/api/openmem/v1"

# 你的知识库 ID 列表（可以有多个）
KNOWLEDGE_BASE_IDS = ["你的_知识库ID"]

# ==================== 记忆助手类 ====================
class MemoryAssistant:
    """
    基于 MemOS 的记忆增强助手
    """

    def __init__(self):
        self.openai_client = OpenAI(api_key=OPENAI_API_KEY)
        self.memos_headers = {
            "Authorization": f"Bearer {MEMOS_API_KEY}",
            "Content-Type": "application/json"
        }

    def search_memory(self, user_id: str, query: str, top_k: int = 5) -> list:
        """
        搜索相关记忆

        Args:
            user_id: 用户标识
            query: 搜索查询
            top_k: 返回结果数量

        Returns:
            相关记忆列表
        """
        try:
            response = requests.post(
                f"{MEMOS_BASE_URL}/memory/search",
                headers=self.memos_headers,
                json={
                    "user_id": user_id,
                    "query": query,
                    "knowledge_base_ids": KNOWLEDGE_BASE_IDS,
                    "top_k": top_k
                }
            )
            response.raise_for_status()
            return response.json().get("memories", [])
        except Exception as e:
            print(f"搜索记忆失败: {e}")
            return []

    def add_memory(self, user_id: str, content: str, metadata: dict = None):
        """
        添加新记忆

        Args:
            user_id: 用户标识
            content: 记忆内容
            metadata: 额外元数据
        """
        try:
            response = requests.post(
                f"{MEMOS_BASE_URL}/memory/add",
                headers=self.memos_headers,
                json={
                    "user_id": user_id,
                    "content": content,
                    "metadata": metadata or {},
                    "knowledge_base_ids": KNOWLEDGE_BASE_IDS
                }
            )
            response.raise_for_status()
            print("记忆添加成功")
        except Exception as e:
            print(f"添加记忆失败: {e}")

    def format_memories(self, memories: list) -> str:
        """
        格式化记忆为 Prompt 文本
        """
        if not memories:
            return "暂无相关记忆。"

        formatted = "以下是你对该用户的相关记忆：\n\n"
        for i, mem in enumerate(memories, 1):
            content = mem.get("content", "")
            timestamp = mem.get("created_at", "未知时间")
            score = mem.get("relevance_score", 0)
            formatted += f"{i}. [{timestamp}] (相关度: {score:.2f})\n   {content}\n\n"

        return formatted

    def chat(self, user_id: str, message: str) -> str:
        """
        主对话函数

        Args:
            user_id: 用户标识
            message: 用户消息

        Returns:
            AI 回复
        """
        # 1. 搜索相关记忆
        memories = self.search_memory(user_id, message)
        memory_context = self.format_memories(memories)

        # 2. 构建系统提示词
        system_prompt = f"""你是一个有记忆能力的 AI 助手。你可以记住用户的偏好、历史对话和相关信息。

{memory_context}

请基于以上记忆和用户的新问题进行回答。如果记忆中没有相关信息，请诚实地说明。
在回答时，你可以自然地引用记忆中的信息，但不要生硬地列出所有记忆内容。"""

        # 3. 调用 LLM 生成回复
        response = self.openai_client.chat.completions.create(
            model="gpt-4o-mini",  # 或使用其他模型
            messages=[
                {"role": "system", "content": system_prompt},
                {"role": "user", "content": message}
            ],
            temperature=0.7
        )

        assistant_reply = response.choices[0].message.content

        # 4. 将对话存入记忆（可选）
        # 可以选择性地将重要对话存入记忆