MemoryOS：为 AI Agent 打造的「记忆操作系统」

你一定遇到过这种情况：AI 助手在单次对话中表现完美，但一旦开启新对话，它就彻底「失忆」了——不知道你是谁、你们的上一次讨论进展到哪、哪些偏好需要记住。

这正是当前 AI Agent 最大的痛点之一：缺乏持久记忆能力。大多数 Agent 系统只能依赖 RAG（检索增强生成）做简单的向量相似度检索，无法真正理解用户偏好、追踪对话演化、管理不同时间跨度的信息。

MemoryOS 正是为了解决这个问题而生——它被设计为 AI Agent 的「记忆操作系统」，于 2025 年 5 月由白嘉 AI 团队（BaiJia AI）发布，并在自然语言处理顶会 EMNLP 2025 上获得 Oral（口头报告）论文 接收，一亮相便获得学术界和工业界的双重关注。

🎯 什么是 MemoryOS？

MemoryOS 的核心理念是类比人类大脑的记忆分层机制，构建一套完整的 AI Agent 持久记忆系统。

人类的记忆分为多个层次：

• 工作记忆（Working Memory）对应瞬时上下文窗口
• 情景记忆（Episodic Memory）记录具体事件和经历
• 语义记忆（Semantic Memory）存储抽象知识和概念

MemoryOS 将这一生物启发模型完整工程化，对应三层记忆结构：

层级	类比	功能
短期记忆（Short-Term）	工作记忆	保存最近 10 次对话，deque 固定容量，FIFO 自动淘汰
中期记忆（Mid-Term）	情景记忆	保存 2000 个对话片段（Session），基于 FAISS 向量检索 + 热度（Heat）计算，热度高的记忆更频繁被召回
长期记忆（Long-Term）	语义记忆	保存 100 条核心知识（User Profile + Assistant Knowledge），向量化为 Embedding 持久存储

这套分层架构的精妙之处在于：它不是简单地把所有对话都往向量库里塞，而是通过热度机制动态判断哪些信息值得晋升为长期记忆，哪些信息可以淘汰——就像大脑会强化重要记忆、遗忘琐碎细节一样。

🔥 核心创新：热度驱动的记忆演化

MemoryOS 最有技术含量的设计是中期记忆的热度（Heat）计算模型。

# 热度的计算公式（来源：memoryos-pypi/mid_term.py）
def compute_segment_heat(session, alpha=1.0, beta=1.0, gamma=1.0, tau_hours=24):
    N_visit  = session.get("N_visit", 0)       # 访问次数
    L_interaction = session.get("L_interaction", 0)  # 交互长度
    R_recency = compute_time_decay(session["last_visit_time"], get_timestamp(), tau_hours)
    return alpha * N_visit + beta * L_interaction + gamma * R_recency

热度由三个维度共同决定：被访问的频率（N_visit）、交互内容的丰富程度（L_interaction）、距离最后一次访问的时间衰减（R_recency）。当一段对话的热度超过阈值（H_PROFILE_UPDATE_THRESHOLD = 5.0），系统会自动触发 LLM 提取关键知识，将这段对话「蒸馏」后存入长期记忆。

这个机制解决了传统 RAG 的核心问题：传统 RAG 对所有文档一视同仁，而 MemoryOS 通过热度动态区分信息的「重要性」，优先检索高热度的记忆，大幅提升 Agent 对用户的「了解程度」。

🏗️ 技术架构：模块化 + 多后端支持

MemoryOS 采用高度模块化的设计，提供三个独立的子包，分别适配不同的使用场景：

memoryos-chromadb —— 使用 ChromaDB 作为向量存储后端，适合需要持久化向量检索的生产环境。

memoryos-pypi —— 使用 FAISS（Facebook AI Similarity Search）作为向量引擎，适合追求极致性能的研究和开发场景。

memoryos-mcp —— MCP（Model Context Protocol）服务器实现，可以直接接入 Claude Desktop、Cursor 等支持 MCP 协议的开发工具，让 AI 直接「记住」开发者的编码习惯和项目背景。

核心依赖：

• FAISS（中期+长期记忆向量检索）
• Sentence Transformers（all-MiniLM-L6-v2 默认 embedding 模型）
• OpenAI API（核心 LLM 调用，支持自定义 base_url 兼容国内模型）
• Python 3.10+

调用流程（以 memoryos-pypi 为例）：

from memoryos import Memoryos

agent = Memoryos(
    user_id="alice",
    openai_api_key="sk-...",
    data_storage_path="./memory_data/alice",
    short_term_capacity=10,
    mid_term_capacity=2000,
    long_term_knowledge_capacity=100,
    llm_model="gpt-4o-mini",
    embedding_model_name="all-MiniLM-L6-v2"
)

# Agent 回复时，自动从三层记忆检索相关内容
response = agent.run(query="用户上次说喜欢什么来着？", conversation_history=history)

🌐 Playground：开箱即用的 Web 演示

项目自带 memoryos-playground/memdemo 子目录，包含一个完整的 Gradio 风格 Web UI（单页 HTML + JavaScript），支持：

• 实时对话输入与 Agent 回复展示
• 三层记忆的可视化状态监控（短期/中期/长期各存了什么）
• 记忆检索结果的透明化展示（让用户看到 Agent「想起了」什么）
• 示例对话数据预填充（sample_conversations.json），无需手动构造

图1：MemoryOS Playground 演示界面，支持实时查看三层记忆状态

🧪 评估体系：LocoMoCo 基准

项目在 eval/ 目录下实现了完整的评估框架，核心是 LocoMoCo（Long-term Conversation Memory Consolidation）基准数据集，专门测试 Agent 在长时间跨度内的记忆保持和检索能力。

评估覆盖四个维度：

维度	测试目标
short_term_memory	近期对话是否被正确保存和检索
mid_term_memory	中期会话热度的演化是否符合预期
long_term_memory	知识是否被正确蒸馏和长期保持
dynamic_update	用户偏好变化时记忆是否动态更新

评估使用了 locomo10.json 数据集（280万字符），涵盖真实用户对话场景。

⚠️ 局限性与挑战

尽管设计精巧，MemoryOS 也存在一些需要注意的问题：

1. API 成本问题：系统依赖 LLM 进行知识蒸馏（从中期记忆提炼到长期记忆），每次热度触发都会调用 OpenAI API。在高并发场景下，这可能带来可观的 API 费用。

2. Embedding 模型局限：默认使用 all-MiniLM-L6-v2（384 维向量），对于中文语义理解能力有限，国内用户可能需要替换为 BGE-m3 等中文 embedding 模型。

3. 并非完全本地化：虽然数据存储在本地，但核心推理仍依赖外部 LLM API（OpenAI 或兼容 API），无法做到完全离线运行。

4. ChromaDB vs FAISS 选择：生产环境推荐 memoryos-chromadb（更好的 CRUD 支持），但项目文档对两者的适用场景说明不够清晰，新用户可能选错版本。

📈 影响力与行业意义

MemoryOS 于 2025 年 5 月发布，至今已获得 1,460 Stars 和 142 Forks，在 GitHub Trending 上多日登顶 Python trending 榜单。项目在知乎、CSDN 等国内技术社区引发广泛讨论，BaiJia AI 团队还建立了微信群和 Discord 社区。

从行业角度看，MemoryOS 填补了记忆增强 Agent 方向的开源工具空白。与 Mem0（另一款商业化记忆系统）相比，MemoryOS 的差异化在于：

• 完整的热度驱动的记忆演化机制，而非静态 RAG
• 学术论文支撑（EMNLP 2025 Oral），有明确的理论依据
• 多后端灵活切换（ChromaDB / FAISS / MCP）

EMNLP 2025 论文链接： https://arxiv.org/abs/2506.06326

图2：MemoryOS 三层记忆架构全景，展示短期→中期→长期的完整数据流