在多代理 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()
在多代理框架中集成：
- 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）。
冲突解析策略：
- 优先级排序：规则类记忆 > 技能 > 事实。配置
memory_priorities={"rules": 1.0, "facts": 0.7}。
- 版本控制：每个记忆条目带 timestamp + agent_id，检索时用 SQL 查询
SELECT * FROM memories WHERE entity='project_auth' ORDER BY priority DESC, timestamp DESC LIMIT 1。
- 仲裁注入：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"。
协调工程化：跨代理工作流清单
为确保协调可靠，提供以下可落地清单：
-
初始化阶段：
- 建表脚本：Memori 自动创建
memories、entities、relationships 表。
- 环境变量：
MEMORI_DATABASE_CONNECTION_STRING、MEMORI_MEMORY_NAMESPACE。
-
检索优化：
| 参数 |
默认值 |
多代理推荐 |
说明 |
| retrieval_top_k |
10 |
5 |
限 token 预算 |
| semantic_ranking_weight |
0.5 |
0.7 |
提升嵌入相似度 |
| namespace_scope |
"user" |
"team" |
共享范围 |
-
监控与回滚：
- 指标：检索命中率 >90%、注入 token 占比 <30%、冲突率 <5%。
- 查询：
SELECT COUNT(*) FROM memories WHERE resolved_conflict=true;。
- 回滚：
memori.rollback_last_ingest() 或 SQL DELETE WHERE agent_id='faulty_agent'。
-
生产扩展：
- 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 字）