在多代理 LLM 系统（Multi-Agent LLM Systems）中，代理之间需要共享知识、协调行动，并维持长期上下文，以实现复杂任务的协作。传统向量数据库虽能处理语义相似性检索，但往往忽略实体间层次关系，导致查询效率低下和语义深度不足。构建分层知识图谱（Hierarchical Knowledge Graphs）成为关键解决方案，它通过多层节点和边表示抽象概念到具体事实的层次结构，支持可扩展的事实检索和上下文融合。本文聚焦于开源内存引擎 Memori，阐述如何利用其内置实体提取与关系映射功能，构造高效的分层知识图谱，优化多代理系统的性能。
Memori 作为 GibsonAI 推出的 SQL 原生内存引擎，专为 LLM 和 AI 代理设计，支持一行代码集成（如 memori.enable()），将对话和交互持久化存储在标准 SQL 数据库（如 SQLite、PostgreSQL）中。其核心优势在于零供应商锁定、80-90% 成本节省，以及智能内存管理：自动实体提取（Entity Extraction）、关系映射（Relationship Mapping）和上下文优先级排序。这些功能天然支持知识图谱构建，尤其在多代理场景下，通过命名空间（Namespace）隔离不同代理的记忆，确保共享知识的安全与一致性。
观点一：分层知识图谱提升多代理系统的可扩展性。证据显示，Memori 的关系映射能将非结构化对话转化为结构化三元组（实体-关系-实体），如“代理A-协作-代理B”或“任务X-依赖-资源Y”。在分层设计中，上层节点代表抽象概念（如“协作框架”），下层扩展为具体事实（如“代理A 处理用户查询”）。根据 Memori 架构，后台 Conscious Agent 每 6 小时分析模式，将长期记忆提升至短期存储，支持动态图更新。这避免了传统 RAG（Retrieval-Augmented Generation）在长序列中的 token 爆炸问题，查询延迟降低至毫秒级。
为实现分层结构，首先配置 Memori 的内存模式：结合 Conscious Mode（一次性工作记忆注入）和 Auto Mode（动态查询搜索）。在初始化时，设置 database_connect 为 PostgreSQL 以支持复杂索引：
from memori import Memori
memori = Memori(
database_connect="postgresql://user:pass@localhost/memori",
conscious_ingest=True,
auto_ingest=True,
openai_api_key="sk-..."
)
memori.enable()
在多代理集成中，使用 LiteLLM 回调拦截调用，对于每个代理交互，Memori 的 Memory Agent 提取实体（如代理 ID、任务类型）和关系（如“依赖”“融合”）。构建分层图时，可自定义 SQL schema：创建层次表（hierarchical_entities），上层为 category（如“系统级知识”），下层为 instance（如具体事实）。例如，SQL 查询可递归遍历层次：
WITH RECURSIVE graph AS (
SELECT id, entity, relation, parent_id FROM entities WHERE parent_id IS NULL
UNION ALL
SELECT e.id, e.entity, e.relation, e.parent_id FROM entities e
INNER JOIN graph g ON e.parent_id = g.id
)
SELECT * FROM graph WHERE entity LIKE '%task%';
这支持多跳查询（Multi-Hop），如从“系统目标”追溯到“代理具体行动”，提升语义深度。
观点二：优化查询效率与语义深度是工程核心。Memori 的 SQL-native 存储避免了向量 DB 的黑箱问题，证据在于其全文搜索索引和聚合查询，能在 O(1) 时间检索相关子图。相比专用图 DB（如 Neo4j），Memori 更轻量，适合多代理的分布式部署。但需注意规模化风险：实体提取依赖 LLM（如 GPT-4o-mini），准确率约 90%，可能引入噪声。为此，设置阈值参数：相似度阈值 > 0.8 才添加关系，避免图膨胀。
可落地参数与清单：
-
集成清单：
- 安装：pip install memorisdk
- 配置命名空间：export MEMORI_MEMORY_NAMESPACE="multi-agent-graph"
- 代理隔离：每个代理使用独特 session_id，如 "agent-{id}-graph"
- 背景任务：启用 Conscious Agent，间隔 3600 秒分析图连通性。
-
查询优化参数：
- 索引：CREATE INDEX idx_relation ON entities(relation); -- 加速关系遍历
- 阈值：auto_ingest_threshold=0.75（语义相似度），防止低质事实注入
- 层次深度：限制 max_depth=5，避免查询爆炸
- 融合策略：使用 SQL JOIN 融合上下文，注入提示时限 top_k=10 相关事实。
-
监控与回滚策略：
- 监控点：图节点数 < 10k/代理；查询延迟 < 500ms；提取准确率 > 85%（通过采样验证）
- 风险限：若图冲突率 > 5%，触发 LLM-based 更新解析器，删除冗余边
- 回滚：备份 SQLite 文件，每日快照；异常时切换至只读模式，fallback 到基本 RAG
在实践案例中，对于一个客服多代理系统，上层图存储“客户偏好层次”（如“一般-具体产品”），下层融合交互事实。Memori 自动优先级排序，确保查询时注入高相关子图，响应连贯性提升 2-4 倍。
观点三：Memori 的图构建支持上下文融合，适用于生产级多代理。证据来自其多代理集成示例（如 CrewAI、AutoGen），共享记忆通过 SQL 视图实现跨代理检索。语义深度通过关系权重（e.g., 边属性存储置信度）增强，优化如使用 PGVector 扩展添加向量辅助，但保持 SQL 核心。
总之，在 Memori 中构建分层知识图谱，不仅实现了可扩展检索，还降低了多代理系统的复杂性。通过上述参数与清单，开发者可快速落地，监控风险，确保稳定。未来，随着 Memori 更新，分层图将进一步融入 CRDT 版本控制，支持分布式同步。
资料来源：