> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 基于图的 Agent 记忆 - URL: https://www.hubwiz.com/blog/graph-based-agent-memory/ - Published: 2026-02-25T03:39:10.000Z - Updated: 2026-02-25T03:39:10.000Z - Description: LLM 驱动的 AI 代理可以生成代码、保持对话和做出决策。然而,由于上下文窗口限制,它们难以在随时间推移保留和利用过去的经验。基于图的记忆是这个问题的引人注目的答案。 - Author: admin - Tags: AGENT, #Import 2026-10-14 14:41 LLM 驱动的 AI 代理可以生成代码、保持对话和做出决策。然而,由于上下文窗口限制,它们难以在随时间推移保留和利用过去的经验。 基于图的记忆是这个问题的引人注目的答案。它将实体及其关系表示为节点和边,保留了扁平文本检索丢失的因果链和时间上下文。 本文主要基于调查论文"基于图的代理记忆调查"(arXiv:2602.05665),并辅以两个具体架构:MAGMA (arXiv:2601.03236) 和 DeepImageSearch (arXiv:2602.10809)。它们共同描绘了如何为智能代理设计记忆的全面图景。 **你将学到:** - 代理记忆的分类及其设计决策所隐含的内容 - 五种图结构模式、它们的优点和权衡 - 完整的记忆生命周期:提取、存储、检索和演化 - MAGMA 和 DeepImageSearch 如何在实践中实现这些想法 - 从哪些开源库和基准开始 ## 1、传统代理记忆的限制 在深入研究图之前,了解为什么更简单的方法会失败会有所帮助。 ### 1.1 基于文本的记忆 最直接的方法将过去的对话和文档存储为文本块,计算向量嵌入,并通过相似性进行检索(RAG)。 这有几个限制: - **丢失的关系** \- 实体之间的因果和依赖链接无法在扁平文本中表达 - **没有时间顺序** \- 信息的顺序和学习时间被丢弃 - **冗余和矛盾** \- 相一事实以不同的措辞存储可能会漂移成不一致 - **困难的多跳推理** \- 将多个事实组合成推理链需要额外的脚手架 ### 1.2 键值存储 结构化的键值格式提供快速查找,但无法表达键之间的关系。您可以分别存储"用户 A 喜欢 Python"和"用户 A 从事数据分析",但将这两个事实集成进行推理需要额外的逻辑。 ### 1.3 图解决什么 基于图的记忆在结构上解决了这些限制: ``` +-----------+ relationship +-----------+ | Entity | ───────────────> | Entity | +-----------+ +-----------+ | | | attribute temporal | v v +-----------+ +-----------+ | Property | | Event | +-----------+ +-----------+ | causal | v +-----------+ | Outcome | +-----------+ ``` 节点代表实体和概念。边代表它们的关系。这使以下成为可能: - **显式关系** \- "A 依赖于 B"和"C 导致 D"直接表示为边 - **时间顺序** \- 带时间戳的边保留信息的按时间顺序 - **矛盾检测** \- 关于同一实体的相互冲突的事实自然地浮现在图上 - **多跳推理** \- 图遍历将多个事实链接在一起,而无需额外的脚手架 ## 2、基于图的代理记忆分类 调查沿着三个轴组织代理记忆。理解此分类是任何记忆系统设计的起点。 ### 3.1 按时间范围 记忆根据其持久时间分为三类: - **感觉记忆** \- 持续几秒。缓冲最近的输入(当前提示词、最新 API 响应) - **短期记忆** \- 在任务持续时间内存在。保存工作状态(对话历史、临时记事本) - **长期记忆** \- 无限期持久化。累积知识和经验(知识图、用户档案) 像人类记忆模型一样,信息选择性地从感觉传递到短期,并从短期传递到长期。基于图的记忆主要服务于长期存储,但其与短期记忆的集成同样重要。 ### 3.2 按内容类型 记忆的内容分为两大类: **知识记忆**保存声明性事实和概念 - "Python 是一种动态类型语言,""Kubernetes 是容器编排工具。"这些通常结构化为具有 is-a 和 has-a 关系的知识图。 **经验记忆**保存过程知识和操作历史 - "此错误通过程序 X 解决,""用户喜欢响应格式 Y。"这些结构化为时间或情景图。 ### 3.3 按结构 记忆结构分为非结构化和结构化: ``` 记忆结构 / \ 非结构化 结构化 / \ / \ 自然 参数化 数据库 图 语言 (NN 权重) (SQL,KVS) (KG, 时间) ``` 基于图的记忆是一种结构化记忆形式。与非结构化方法相比,它在检索效率和推理能力方面表现出色,尽管构建成本较高。 ## 4、五种图结构模式 图结构的选择是核心设计决策。调查确定了五种模式,每种模式具有不同的特征和权衡。 ### 4.1 知识图 最广泛使用的结构。知识表示为三元组(主语、谓语、宾语),其中实体是节点,关系是边。 ``` Python ──is_a──> 编程语言 | ├──has_feature──> 动态类型 | └──used_for──> 数据科学 ──requires──> 统计学 ``` **优势:** - 可用的成熟数据模型(RDF、属性图) - 像 SPARQL 和 Cypher 这样的查询语言支持模式匹配 - 易于与大型知识库集成 - **最适合:** 技术文档、领域特定本体、常见问题/服务台知识库 **权衡:** 实体和关系提取的准确性直接决定质量。时间变化需要额外的时间戳注释。管理成本随规模增长。 ### 4.2 层次图 (DAG) 将信息组织为具有不同抽象层次的定向无环图。 ``` 项目目标 ├── 模块 A 设计 │ ├── 类 X 实现 │ └── 类 Y 实现 └── 模块 B 设计 └── API 端点设计 ``` **优势:** - 支持自上而下(概述到细节)和自下而上(细节到概述)导航 - 显式地管理信息粒度 - 任务分解的自然匹配 **最适合:** 任务分解和进度跟踪、分层文档摘要、多代理系统中的责任分配 ### 4.3 时间图 将时间信息直接嵌入到图结构中。调查描述了两种变体。 **双时间图**跟踪两个时间轴 - 事实何时有效以及何时被记录: ``` (Alice, works_at, Company_A, valid: 2020-2023, recorded: 2023-01) (Alice, works_at, Company_B, valid: 2023-present, recorded: 2023-06) ``` **时间知识图 (TKG)** 将三元组扩展为带时间戳的四元组: ``` (Alice, promoted_to, 高级工程师, 2024-Q1) ``` **优势:** - 管理信息新鲜度,自动降低旧数据的优先级 - 跟踪信息的确切已知时间 - 检测模式和趋势 **最适合:** 对话上下文跟踪、用户偏好演化、事件时间线记录 ### 4.4 超图 在标准图中,每条边恰好连接两个节点。在超图中,单条超边可以同时连接任意数量的节点。 ``` 超边:"2024-01-15 团队会议" 连接节点: [Alice, Bob, Carol, Agenda_X, Decision_Y] ``` **优势:** - 在单条边中自然地表示多对多关系 - 在建模复合事件和上下文方面表现出色 - 避免标准图对相同关系所需的边爆炸 **最适合:** 多参与者事件、共同创作和协作建模、复杂的规则表达式 **权衡:** 大多数图数据库不原生支持。查询设计变得更加复杂。 ### 4.5 混合图 结合上述多种结构。在实践中,单一结构很少满足所有要求,使得混合设计成为现实系统的务实选择。下面讨论的 MAGMA 就是一个主要示例。 **五种模式的比较:** - **知识图** — 中等表达能力、高检索效率、易于实现。最适合知识管理和常见问题 - **层次图** — 中等表达能力、高检索效率、中等实现。最适合任务分解和摘要 - **时间图** — 高表达能力、中等检索效率、中等实现。最适合对话跟踪和变化检测 - **超图** — 最高表达能力、低检索效率、难以实现。最适合复合事件和多对多关系 - **混合** — 最高表达能力、中等检索效率、难以实现。最适合一般生产系统 ## 5、MAGMA: 用多个图分离关系 MAGMA(记忆增强的基于图的多代理架构),在 arXiv:2601.03236 中提出,通过四个正交图层管理记忆。 ### 5.1 四个图层 MAGMA 的核心见解是将不同类型的关系分离到专用图中: ``` ┌─────────────────────────────────────────────────┐ │ MAGMA 记忆系统 │ ├─────────────┬─────────────┬────────┬────────────┤ │ 语义 │ 时间 │ 因果 │ 实体 │ ├─────────────┼─────────────┼────────┼────────────┤ │ 概念 A │ 事件1(t=1) │原因 A │ 人员 X │ │ ↕ 相关 │ ↓ 跟随 │ ↓ │ ↔ 工作 │ │ 概念 B │ 事件2(t=2) │结果 B│ 人员 Y │ │ ↕ 属于 │ ↓ 跟随 │ ↓ │ ↔ 使用 │ │ 概念 C │ 事件3(t=3) │结果 C│ 工具 Z │ └─────────────┴─────────────┴────────┴────────────┘ ``` **语义图**管理主题之间的概念关联 — 相似性、属于和层次关系。它支持基于意义的检索。 **时间图**记录事件的按时间顺序和因果链 — 何时发生了什么,以及随后发生了什么。 **因果图**明确地建模因果和影响关系,实现"为什么会发生这种情况?"推理。 **实体图**跟踪现实世界实体之间的关系 — 人员、组织、工具 — 代表社交网络和组织结构。 ### 5.2 双流记忆演化 MAGMA 以两种不同的速度更新记忆: ``` ┌──────────────────┐ │ 新信息 │ └────────┬─────────┘ ┌────────────┴────────────┐ ▼ ▼ ┌──────────────────────┐ ┌──────────────────────────┐ │ 快速流 │ │ 慢速流 │ │ (突触 │ │ (结构 │ │ 摄入) │ │ 整合) │ └──────────┬───────────┘ └──────────┬───────────────┘ ▼ ▼ ┌──────────────────────┐ ┌──────────────────────────┐ │ 短期记忆 │ │ 长期记忆 │ │ (即时可用) │ │ (结构化、合并) │ └──────────┬───────────┘ └───────────────────────────┘ │ 选择性传输 ▲ └──────────────────────────────────┘ ``` **快速流**将新信息立即摄取到短期记忆中,推迟结构分析以优先考虑实时可用性。 **慢速流**分析短期记忆,检测重复,解决矛盾,推断关系,并将结果整合到长期图中。 这种设计反映了人脑中海马体(短期)和新皮层(长期)的关系。 ### 5.3 自适应遍历策略 在检索时,MAGMA 根据查询意图动态切换其图探索策略: - **事实检查查询** — 优先考虑实体图和语义图 - **时间线跟踪查询** — 专注于时间图 - **根本原因分析查询** — 从因果图开始进行多跳推理 跨图层的意图感知权重调整每种查询类型的遍历优先级。 ### 5.4 基准测试结果 MAGMA 在 LoCoMo 基准上取得了 **0.700** 的分数 —— 比基线(如完整上下文(0.563)和 RAG (0.542))有显著改进。最大的收益似乎出现在需要多跳推理和时间跟踪的问题上。 ## 6、设计记忆生命周期 操作基于图的记忆需要设计四个阶段,形成一个连贯的生命周期。 ### 6.1 提取 提取阶段从原始信息源中检测图元素(节点、边、属性)。有三种方法: **基于 LLM 的提取**使用大型语言模型从文本中识别实体和关系。提示工程指定提取模式。 这是一个简化的示例: ``` from openai import OpenAI client = OpenAI() def extract_relations(text: str) -> list[dict]: """从文本中提取实体和关系。""" prompt = f""" 从以下文本中提取实体和关系。 输出格式: {{"subject": "...", "predicate": "...", "object": "..."}} 文本: {text} """ response = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], response_format={"type": "json_object"}, ) return response.choices[0].message.content ``` **基于规则的提取**使用正则表达式和语法解析来检测特定模式。精度更高但覆盖范围有限。 **混合提取**结合两者 —— LLM 广泛提取,而规则提高精度。 ### 6.2 存储 存储阶段将提取的信息写入图数据库。关键设计决策包括: - **节点粒度** — 句子级、实体级或块级 - **边类型模式** — 自由形式描述 vs. 预定义类型本体 - **元数据** — 时间戳、置信度分数、来源归属 - **索引** — 向量索引(用于语义搜索)与图索引(用于结构查询)一起 在实践中,存储在 Neo4j 或 FalkorDB 中的属性图是最常见的实现。 ### 6.3 检索 检索阶段从存储的记忆中获取相关信息以响应查询。下节涵盖三种检索范式。 ### 6.4 演化 演化阶段通过整合、压缩和矛盾解决持续改进记忆质量。详细信息遵循在演化部分。 完整生命周期流程如下: ``` ┌──────────────┐ │ 信息 │ │ 来源 │ │ (对话│ │ 文档, API) │ └──────┬───────┘ ▼ ┌──────────────┐ ┌──────────────┐ │ 提取 │ │ 演化 │ │ (检测 │ │ (合并, │ │ 实体 & │ │ 压缩, │ │ 关系) │ │ 解决) │ └──────┬───────┘ └──────▲───────┘ ▼ │ ┌──────────────┐ │ │ 存储 │───────────────┘ │ (写入到 │ │ 图 DB) │ └──────┬───────┘ ▼ ┌──────────────┐ │ 检索 │ │ (查询- │ │ 基于) │ └──────┬───────┘ ▼ ┌──────────────┐ │ 代理 │──── 反馈 ────┐ │ 响应 │ │ └──────────────┘ ▼ ┌──────────────┐ │ 演化 │ └──────────────┘ ``` ## 7、三种检索范式 从基于图的记忆检索信息遵循三种范式。实际系统通常结合多种方法。 ### 7.1 语义检索 使用向量嵌入的基于相似性的检索。它根据语义邻近度将查询与记忆匹配。 **工作原理:** - 将图节点和边转换为文本表示 - 为文本计算向量嵌入 - 计算与查询嵌入的余弦相似度 - 返回最相似的前 K 个结果 **图特定扩展:** - **图嵌入** — 像 Node2Vec 和 TransE 这样的算法生成结构感知的嵌入 - **子图检索** — 不仅返回匹配的节点,还返回其 1 跳和 2 跳邻居 - **社区检索** — 利用图聚类返回整个相关社区 ### 7.2 结构化检索 利用图的结构化属性进行精确查询。 **基于规则的检索**使用预定义模式进行搜索: ``` // Cypher 查询:获取 Alice 的 2 跳邻域 MATCH (p:Person {name: "Alice"})-[r*1..2]-(related) RETURN p, r, related ``` **时间检索**在特定时间窗口内获取信息: ``` // 获取 2024 年第一季度的事件,按时间顺序排列 MATCH (e:Event) WHERE e.timestamp >= datetime("2024-01-01") AND e.timestamp <= datetime("2024-03-31") RETURN e ORDER BY e.timestamp ``` **图遍历**从特定节点开始,并使用 BFS、DFS 或最短路径算法沿着边跟随以发现相关信息。 ### 7.3 基于策略的检索 使用强化学习或基于代理的方法来动态优化检索策略。 **基于 RL 的方法**将检索质量视为奖励信号,并自动调整参数,如检索计数、遍历深度和过滤条件。 **基于代理的方法**部署一个专门的检索代理,分析查询并选择最佳搜索策略。MAGMA 的自适应遍历策略属于此类。 **比较三种范式:** - **语义** — 在基于意义的相似性方面表现强劲,但可能遗漏结构关系。最适合开放式问答 - **结构化** — 精确的模式匹配,但不太灵活。最适合公式化查询和时间序列分析 - **基于策略** — 动态优化,但训练成本高。最适合复杂的多跳推理 ## 8、记忆演化机制 基于图的记忆必须在初始存储后持续演化。调查将演化分为两类。 ### 8.1 内部自演化 仅通过内部处理改进记忆质量。 **整合**合并相关记忆并减少冗余。关于同一实体的多个节点被合并;相似的边被统一。 ``` 整合前: 整合后: ┌──────────────────┐ │ Alice: 工程师 │ ─┐ ├──────────────────┤ │ ┌───────────────────────────┐ │ Alice: Python │ ─┼────> │ Alice: 工程师 / Python │ │ 开发商 │ │ │ │ 开发商 / 团队负责人 │ ├──────────────────┤ │ └───────────────────────────┘ │ Alice: 团队负责人 │ ─┘ └──────────────────┘ ``` **图推理**从现有边推断新关系。如果"A 管理 B"和"B 管理 C,"系统通过传递性推理推导"A 是 C 的高级经理"。 **重组**重组图本身 — 修剪低频节点,优化频繁访问的子图的索引,并调整层次结构。 ### 8.2 外部自探索 通过外部反馈和主动信息收集改进记忆。 **反馈驱动的方法**结合关于代理输出的用户反馈。"这个答案不正确"信号降低相关节点的置信度分数。 **主动探索**检测记忆中的空白和歧义,并主动收集信息。如果系统确定"我缺乏关于用户技术栈的信息,"它会在下一次交互中提出澄清问题。 MAGMA 的双流方法有效地实现了这些演化机制 — 快速流在实时摄入信息,而慢速流处理结构整合和质量改进。 ## 9、实际应用:DeepImageSearch 案例研究 DeepImageSearch (arXiv:2602.10809) 在实际的视觉搜索系统中演示了基于图的记忆。它能够对用户的照片集合进行自然语言查询。 ### 9.1 记忆图结构 DeepImageSearch 用四种节点类型表示照片集合信息: ``` ┌──────────────────┐ │ 照片集 │ │ (旅行相册) │ └───┬──────────┬───┘ │ │ ▼ ▼ ┌────────┐ ┌────────┐ │ 照片 1│ │ 照片 2│ └─┬──┬──┬┘ └─┬──┬──┬┘ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ 艾菲尔 铁塔 Alice 咖啡馆 Alice Bob 塔 (风投) (人)(风投)(人)(人) (风投) ``` - **照片** — 具有元数据(日期、地点、标题)的单个照片 - **照片集** — 照片组(旅行、活动) - **视觉线索** — 照片内的视觉元素(地标、物体、场景) - **人员** — 出现在照片中的人员 这些节点之间的边支持像"Alice 和 Bob 在巴黎旅行期间拍摄的照片"这样的复合查询。 ### 9.2 双重记忆系统 DeepImageSearch 使用两种互补的记忆类型: **显式状态记忆**以结构化形式维护用户的搜索状态 — 搜索条件(人员、地点、时间范围)作为 JSON 管理,随对话进展更新。 **压缩上下文记忆**保存过去对话历史的汇总版本。与携带完整对话不同,它压缩为仅关键信息,在上下文窗口限制内工作。 ### 9.3 ImageSeeker 代理 ImageSeeker 代理使用专用工具编排搜索: - **search\_photos** — 对记忆图执行查询 - **view\_photo** — 检索关于特定照片的详细信息 - **view\_photoset** — 获取相册级别的信息 - **ask\_user** — 向用户请求澄清信息 对于像"去年夏天在海滩拍摄的照片"这样的查询,代理在时间图上缩小时间范围,然后通过视觉线索节点识别海滩相关的照片。 此案例研究表明,基于图的记忆不仅对知识管理有效,而且对多模态信息检索也有效。 ## 10、入门:库和基准 这里是与构建基于图的代理记忆最相关的开源库和评估基准。 ### 10.1 关键开源库 调查涵盖了 11 个库。这里有六个最值得注意的: - **Mem0** (25k+ GitHub 星) — 专注于具有自动添加/删除的用户级内存管理。支持知识图。最受欢迎且最容易采用 - **Graphiti** (3k+ 星) — 由 Zep 构建。在时间知识图方面表现出色,整合情景和语义记忆 - **Cognee** (2k+ 星) — 使用 ECL(提取-认知化-加载)管道进行自动结构化记忆构建 - **LangMem** (1k+ 星) — 与 LangChain 生态系统集成。提供用于记忆形成、更新和删除的标准化 API - **OpenMemory** (1k+ 星) — 作为 MCP(模型上下文协议)服务器运行,实现跨代理内存共享 - **MemoryScope** (500+ 星) — 专为长期对话设计,支持双语和反思/整合内存管理 这里是使用 Mem0 和图内存的基本示例: ``` from mem0 import Memory # 使用 Neo4j 配置图内存 config = { "graph_store": { "provider": "neo4j", "config": { "url": "bolt://localhost:7687", "username": "neo4j", "password": "password", }, }, "version": "v1.1", } m = Memory.from_config(config) # 添加记忆 m.add( "Alice 擅长 Python 和 TypeScript,目前领导微服务设计", user_id="alice", ) # 搜索记忆 results = m.search("Alice 的技术栈", user_id="alice") for result in results: print(result) ``` 以及使用 Graphiti 进行时间记忆的示例: ``` from graphiti_core import Graphiti from datetime import datetime # 初始化 Graphiti graphiti = Graphiti( neo4j_uri="bolt://localhost:7687", neo4j_user="neo4j", neo4j_password="password", ) # 添加带时间上下文的片段 await graphiti.add_episode( name="meeting_2024_01", episode_body="Alice 提出了 Kubernetes 迁移计划。Bob 提出了担忧,但团队最终同意继续进行。", source_description="团队会议记录", reference_time=datetime(2024, 1, 15), ) # 搜索 results = await graphiti.search("Kubernetes 迁移历史") ``` ### 10.2 选择基准 调查编目了 53 个基准。这里按类别最有用: - **长期对话** — **LoCoMo** 评估从长对话中信息检索和推理。**LongMemEval** 测试五种记忆能力:信息提取、多会话推理、时间推理、知识更新和拒绝判断 - **知识图** — **FB15k-237** 评估知识图完成(链接预测) - **个性化** — **LaMP** 测试基于用户档案的响应个性化 - **多代理** — **Sotopia** 评估社交交互中的记忆使用 LoCoMo 和 LongMemEval 特别适合对代理记忆系统进行全面评估。MAGMA 在 LoCoMo 上相对于基线的实质性改进为基于图的方法提供了强有力的证据。 ## 11、关键要点 **从分类法开始。** 将您的记忆需求沿三个轴分类 — 时间范围(感觉、短期、长期)、内容类型(知识、经验)和结构(非结构化、结构化) — 然后选择适合您需求的设计。 **图结构是一种权衡。** 知识图多功能且易于采用。时间图和超图提供更丰富的表达能力。对于生产系统,像 MAGMA 这样的混合方法是一个强有力的默认选择。 **设计完整生命周期。** 提取、存储、检索和演化形成一个连续循环。演化机制 — 整合、推理、重组 — 是长期质量的关键。 **结合检索范式。** 语义、结构化和基于策略的检索各自都有盲点。混合它们可以覆盖不同的查询类型。 **利用现有库。** Mem0、Graphiti 和 Cognee 正在迅速成熟。在这些框架上构建比从头开始要高效得多。 基于图的记忆赋予代理真正从经验中学习的能力。我希望本文中的设计模式有助于您将这种能力带到您自己的代理系统。 --- 原文链接: [Graph-Based Agent Memory: A Complete Guide to Structure, Retrieval, and Evolution](https://shibuiyusuke.medium.com/graph-based-agent-memory-a-complete-guide-to-structure-retrieval-and-evolution-6f91637ad078?ref=hubwiz.com) 汇智网翻译整理,转载请标明出处