Memary：让 AI Agent 拥有"记忆"的开源中间件

想象一下：你和一位智能助手聊了一整天的项目需求，第二天再找它时，它完全"失忆"了——不记得你们讨论过的任何细节，需要从头解释一遍。这种尴尬，在 AI Agent 的世界里是常态。Memary 正是为解决这一问题而生：它为 AI Agent 构建了一套模仿人类记忆机制的"记忆层"，让 Agent 不仅能完成单次任务，更能在长期对话中持续积累知识、记住关键实体、理解上下文关联。

图1：Memary 官方 Logo

为什么 AI Agent 需要"记忆"

当前主流的 AI Agent 框架（如 LangChain Agent、AutoGPT）大多依赖上下文窗口（Context Window）来传递历史信息。以 GPT-4 的 128K token 上下文窗口为例，看似充裕，但在一个持续运行数周的个人助手场景中，累积的对话历史、实体信息、知识卡片会迅速填满这个窗口，导致早期的重要信息被"挤出"，Agent 的回答质量随之下降。更深层的问题在于：Agent 无法像人类一样，将零散的对话信息结构化存储并按需检索——这正是 Memary 试图填补的核心空白。

Memary 的设计灵感直接来源于认知科学中的情景记忆理论（Episodic Memory）：人类大脑并非简单记录所有事件，而是将信息编码为"情景"（Episodes），并与已有的知识网络建立关联，永久性地沉淀下来。Memary 将这一理论工程化，构建了两套互补的记忆系统。

图2：记忆模块架构——Memory Stream 记录事件，Entity Knowledge Store 构建知识网络

核心技术架构：双记忆系统

Memary 的核心架构包含两个相互协作的记忆组件：

1. Memory Stream（记忆流）——模拟人类的情景记忆。当你与 Agent 交互时，系统实时捕获对话中的实体（Entity），按时间顺序记录下来。例如你在聊天中提到"NVIDIA 最新的 RTX 5090"，Memory Stream 会将这条实体信息连同时间戳一起存入数据库。这种"事件日志"式的记录方式，保证了信息的完整性——任何一条对话片段都不会被遗忘。

2. Entity Knowledge Store（实体知识库）——模拟人类的语义记忆。与 Memory Stream 的线性记录不同，Entity Knowledge Store 会将相同实体在多次交互中出现的频次、关联关系进行聚合分析。如果你在不同会话中反复提到"A公司"，系统会逐渐理解"A公司"是一个重要实体，并追踪它与"收购""B公司"等关系的演变。实质上，这是一个基于图数据库（FalkorDB/Neo4j）构建的知识图谱。

图3：知识图谱可视化——实体节点与关系边的交互

两者协同工作的方式很有意思：当用户提出新问题时，Agent 会先查询 Entity Knowledge Store，找到相关的高频实体及其关系，生成针对性的 Cypher 查询，从图数据库中检索相关子图；随后，这些结构化的记忆信息被注入到 LLM 的提示词中，让 Agent 在"知道背景"的前提下作答。这就是 Memary 宣称的"Memory-Augmented RAG"策略——记忆增强的检索增强生成。

路由机制：ReAct + 知识图谱双轨

Memary 的 Agent 并非每次都调用知识图谱。它内置了一个路由模块（Router），通过意图识别决定处理路径：

• 需要知识图谱检索的查询（涉及之前讨论过的实体、历史事件）：路由到 RAG 分支，系统生成 Cypher 查询，从 FalkorDB/Neo4j 中检索相关记忆片段。
• 通用问答或需要实时信息的查询（新闻、地图、股票）：路由到 ReAct 分支，调用外部工具（Perplexity 搜索、Google Maps、股票 API）实时获取答案。

这种"按需路由"的策略避免了不必要的图数据库查询，也防止了记忆片段对简单问题的干扰。

图4：系统架构图——ReAct Agent 与知识图谱 RAG 双轨并行

工具生态：开箱即用的工具包

Memary 继承并扩展了 MemGPT 的工具集，内置了多个实用工具：

开发者可以通过 update_tools() 方法自由选择启用哪些工具。例如，只想保留搜索和定位功能时，只需传入 ["search", "locate"]。工具集的设计非常务实——Search 对应了 Agent 实时获取外部知识的需求，Locate 和 Stocks 则覆盖了日常生活助手的高频场景。

部署体验：Streamlit Web UI

Memary 提供了开箱即用的 Streamlit 可视化界面，用户可以通过浏览器与 Agent 对话，并实时观察记忆系统的运作状态。界面左侧显示 Agent 的最终回复，右侧则展示了知识图谱的可视化子图（基于 pyvis 构建的交互式图谱），下方还提供了 Memory Stream、Entity Knowledge Store 以及 Top 20 实体的高亮表格。

图5：Streamlit UI 中的记忆可视化——Memory Stream 表格（上）与知识图谱子图（下）

这个 Web UI 的存在对非技术用户非常友好——不需要写代码，直接配置 .env 中的 API Key 和数据库连接，运行 streamlit run streamlit_app/app.py 即可启动。

上手门槛与局限性

门槛方面： Memary 目前的最大挑战在于环境配置成本。虽然 pip install memary 一行命令即可安装，但完整运行需要：Python ≤ 3.11.9、Ollama 本地模型（或 OpenAI API Key）、FalkorDB/Neo4j 图数据库账号，以及可选的 Perplexity/Google Maps/Alpha Vantage API Key。文档中对这些依赖的配置说明较为分散，初次部署可能需要数小时调试。

局限性方面：

1. Python 版本限制严格：README 明确要求 Python ≤ 3.11.9，与某些新项目依赖的 Python 3.12+ 不兼容，可能导致包依赖冲突。
2. 记忆准确性依赖 LLM 实体提取：Memory Stream 的质量完全取决于底层 LLM 的实体识别能力。如果 LLM 遗漏了关键实体，这段信息就不会被记录。
3. 图数据库运维成本：需要额外部署 FalkorDB 或 Neo4j，增加了系统复杂度和运维负担。
4. 缺乏中文文档：目前 README 和官方文档均为英文，对中文开发者存在一定门槛。

行业意义与趋势

Memary 代表的并非一个孤立的项目，而是 "记忆增强型 AI Agent" 这一新兴赛道的缩影。从 MemGPT（2023年）到 Memary（2024年），再到各类 Vector Memory 方案，业界对"有状态的 Agent"的需求正在快速增长。随着 Agent 应用从"单次问答"向"长期任务助手"演进，记忆层的价值将愈发凸显——它是 Agent 从"工具"升级为"伙伴"的关键基础设施。

Memary 目前在 GitHub 上拥有 2600+ Stars，主题标签涵盖 agents、knowledge-graph、memory、multiagent-systems、rag，反映了其在 AI Agent + 知识图谱交叉领域的准确定位。随着 AI Agent 生态的持续扩张，这类记忆中间件的需求有望进一步释放。

项目快速概览

• ⭐ Stars: 2621
• 🔤 语言: Jupyter Notebook（Python 主导）
• 📦 核心依赖: llama-index, FalkorDB/Neo4j, Streamlit, Ollama/OpenAI
• 🧠 AI 模型: 支持 Ollama 本地模型（Llama3 等）或 OpenAI GPT 系列
• 🌐 Web UI: Streamlit（内置）
• 📊 部署难度: 中等（需配置多个 API Key 和图数据库）