Memori 多代理记忆协调：分层嵌入与同步检索实现

在多代理 LLM 系统（如 CrewAI 或 AutoGen）中，代理间记忆孤岛会导致重复计算、上下文丢失和决策冲突。Memori 开源引擎通过 SQL-native 分层嵌入机制，提供统一的记忆层，实现同步检索、冲突解决与协调。本文聚焦其在多代理场景下的工程化落地，强调可操作参数与监控策略，避免单纯复述项目描述，转而给出直接可用的集成清单。

多代理记忆痛点与 Memori 核心架构

传统多代理系统往往为每个代理维护独立向量库或上下文，导致跨代理知识不同步。例如，研究员代理提取的事实无法及时注入决策代理，造成低效协作。Memori 采用拦截式架构（interceptor），在 LLM 调用前后自动注入 / 提取记忆，存储于标准 SQL 数据库（如 PostgreSQL）。其分层设计包括：

• 短期工作记忆（Conscious Mode）：实时注入高优先级上下文，支持 one-shot 检索。
• 长期记忆（Auto Mode）：动态全文搜索 + 语义排序，按需拉取历史。
• 后台 Conscious Agent：每 6 小时分析模式，将长期记忆提升至短期层，实现分层嵌入（hierarchical embeddings）。

这种设计无需额外向量 DB，节省 80-90% 成本，仅用 SQL 全文本索引 + 实体提取（Pydantic-based）即可。证据显示，Memori 已集成 CrewAI、AutoGen 等框架，支持共享记忆空间。[1]

同步检索实现：统一命名空间与检索参数

同步检索是多代理协调基础。Memori 通过 memory_namespace 参数隔离 / 共享记忆，例如为团队代理设置共享 namespace="team_project"，单个代理用 "agent_researcher"。

关键参数配置：

from memori import Memori, ConfigManager

config = ConfigManager()
config.auto_load()  # 从环境变量加载
memori = Memori(
    database_connect="postgresql://user:pass@localhost/memori_db",
    conscious_ingest=True,  # 启用短期记忆注入
    auto_ingest=True,       # 动态长期检索
    memory_namespace="multi_agent_team",  # 共享命名空间
    openai_api_key="sk-..."
)
memori.enable()  # 全局拦截 LLM 调用

在多代理框架中集成：

• CrewAI 示例：为 Crew 创建共享 Memori 实例，所有任务代理复用同一 DB。检索阈值设 retrieval_top_k=5，限短期记忆 3 条 + 长期 2 条，避免 token 超限。
• AutoGen 示例：GroupChat 中注入 Memori 上下文，代理间消息自动记录，实现跨轮次同步。

落地时，先用 SQLite 测试：sqlite:///multi_agent_memory.db，确认检索延迟 < 200ms 后再迁 PostgreSQL（支持并发）。

冲突解决机制：实体关系映射与优先级仲裁

冲突常见于代理异构知识，例如研究员代理偏好事实，决策代理强调规则。Memori 的 Memory Agent 自动分类记忆为 facts/preferences/skills/rules/context，并构建实体关系图（entity extraction + relationship mapping）。

冲突解析策略：

1. 优先级排序：规则类记忆 > 技能 > 事实。配置 memory_priorities={"rules": 1.0, "facts": 0.7}。
2. 版本控制：每个记忆条目带 timestamp + agent_id，检索时用 SQL 查询 SELECT * FROM memories WHERE entity='project_auth' ORDER BY priority DESC, timestamp DESC LIMIT 1。
3. 仲裁注入：Pre-call 时，Retrieval Agent 融合多源记忆，若冲突则 prompt LLM 仲裁："基于以下冲突记忆 [mem1, mem2]，选择一致版本"。

参数调优：

• conflict_resolution_threshold=0.8：语义相似度 >0.8 时合并，否则隔离。
• 后台任务间隔：conscious_promotion_interval=21600 秒（6 小时），监控推广率 >20%。

实际部署中，添加日志钩子：logging_level="DEBUG"，追踪冲突事件如 "Entity 'auth_method' updated by agent_decision overriding agent_research"。

协调工程化：跨代理工作流清单

为确保协调可靠，提供以下可落地清单：

1. 初始化阶段：

   • 建表脚本：Memori 自动创建 memories、entities、relationships 表。
   • 环境变量：MEMORI_DATABASE_CONNECTION_STRING、MEMORI_MEMORY_NAMESPACE。

2. 检索优化：

   参数	默认值	多代理推荐	说明
   retrieval_top_k	10	5	限 token 预算
   semantic_ranking_weight	0.5	0.7	提升嵌入相似度
   namespace_scope	"user"	"team"	共享范围

3. 监控与回滚：

   • 指标：检索命中率 >90%、注入 token 占比 <30%、冲突率 <5%。
   • 查询：SELECT COUNT(*) FROM memories WHERE resolved_conflict=true;。
   • 回滚：memori.rollback_last_ingest() 或 SQL DELETE WHERE agent_id='faulty_agent'。

4. 生产扩展：

   • Neon/Supabase：serverless PostgreSQL，连接串 postgresql://user@ep-*.neon.tech/memori。
   • 多租户：tenant_id 列分区表。
   • 测试：模拟 10 代理 x 100 轮对话，验证同步延迟 <1s。

此方案已在 Memori 的 Swarms/CamelAI 示例中验证，支持 100+ LLM 模型，无厂商锁定。

风险限界与最佳实践

潜在风险：高并发下 SQL 瓶颈，限流至 100 QPS；LLM 幻觉污染记忆，用 ingest_validation=True 过滤低置信输出。最佳实践：从小规模（2-3 代理）起步，渐进共享 namespace。

资料来源： [1] GitHub - GibsonAI/Memori: Open-Source Memory Engine for LLMs, AI Agents & Multi-Agent Systems. https://github.com/GibsonAI/Memori
[2] Memori Documentation: https://memorilabs.ai/docs

（正文约 1050 字）