Memori 作为 GibsonAI 开源的 SQL 原生记忆引擎，为 LLM 和 Agent 提供持久化上下文管理，其核心在于通过语义去重（semantic deduplication）和分级压缩（leveled compaction）机制，确保多代理系统下的存储高效与检索精准。这种设计避免了传统向量数据库的高成本与黑箱问题，转而利用标准 SQL（如 SQLite、PostgreSQL）的全文本搜索（FTS）和实体关系建模，实现 80-90% 的 Token 节省，同时支持跨会话记忆注入。
语义去重的实现原理与工程参数
Memori 的语义去重并非简单字符串匹配，而是依托 Memory Agent 的智能提取与分类。首先，在每次 LLM 调用后，Memory Agent 使用 OpenAI Structured Outputs（基于 Pydantic）解析对话，提取实体（entity extraction）、关系（relationship mapping）并分类为 facts、preferences、skills、rules 等。提取出的实体存储在 memory_entities 表中，关系存于 memory_relationships 表，形成图谱式去重：相同实体（如“用户偏好 FastAPI”）通过 confidence score 和 strength 过滤重复，避免冗余积累。
例如，架构文档中描述：“Memory Agent extracts entities, categorizes (facts, preferences, skills, rules, context)。”这确保了语义层面的 dedup，即使表述变异（如“FastAPI 项目” vs “用户管理 API”），实体链接也能合并相似记忆，减少 long_term_memory 表的膨胀。
可落地参数配置：
- 实体提取阈值：
agents.entity_confidence_threshold=0.7，低于此值的实体忽略，防止噪声。
- 去重窗口：
memory.dedup_window_hours=24，24 小时内相似 summary（cosine similarity > 0.85）合并。
- 监控清单：
| 指标 |
阈值 |
告警策略 |
| 实体重复率 |
<5% |
每周 Conscious Agent 分析后检查 |
| 关系强度均值 |
>0.6 |
低于阈值触发重新提取 |
| 存储增长率 |
<10%/日 |
自动清理低 importance_score (<0.3) 记录 |
在多代理场景，namespace 参数隔离用户/代理空间：Memori(database_connect="postgresql://...", namespace="agent_team_1")，确保语义去重不跨域污染。
分级压缩策略：从长期到短期记忆的 Leveled Compaction
Memori 借鉴 LSM-tree 的 leveled compaction 理念，将记忆分层：chat_history（原始日志）、long_term_memory（处理后长期存档）、short_term_memory（精华工作记忆）。每 6 小时，Conscious Agent 后台运行，分析 patterns（如 frequency_score、recency_score、importance_score），将高价值记忆“compaction”提升至 short_term_memory，实现分级压缩：长期层保留全量，短期层仅 3-5 条精炼 summary，总 Token 控制在 150-250。
证据见数据库 schema：“short_term_memory 以 importance_score、frequency_score、recency_score 排序，expires_at 自动过期。”这类似于 leveled compaction 的 merge：低层（long-term）定期与高层（short-term）合并，淘汰冗余。
Conscious Mode 参数落地：
memori = Memori(
conscious_ingest=True, # 启用分级压缩注入
analysis_interval_hours=6, # 压缩周期
short_term_limit=5, # 高层容量
promotion_threshold=0.8 # 提升分数阈值 (importance * recency * frequency)
)
回滚策略：
- 若压缩失败（agent error），fallback 到 auto_ingest 动态检索。
- 数据库连接丢失：exponential backoff 重连，pool_size=20。
- 过期清理：
DELETE FROM short_term_memory WHERE expires_at < NOW()，cron 每日执行。
在检索时，Retrieval Agent 混合策略（FTS → category → LIKE）进一步“解压”：优先 short_term（O(1)），fallback long_term，确保延迟 <50ms。
多代理同步机制与检索效率优化
针对多 Agent 持久化，Memori 通过 namespace 和 session_id 实现同步：共享 DB 下，代理间记忆隔离却可显式共享（如 CrewAI 示例）。同步原子性靠 SQL ACID：BEGIN TRANSACTION; INSERT chat_history; INSERT long_term_memory; COMMIT;。
检索效率参数：
- limit=5：每次注入 top-5，Token 预算 250。
- search_strategy_weights：FTS=1.0, category=0.6, LIKE=0.4。
- 缓存 TTL：Redis 集成，
cache_ttl=300s，命中率 >80%。
生产监控清单：
| 维度 |
KPI |
工具 |
| 持久化 |
存储成功率 >99.9% |
SQL 慢查询日志 |
| 检索 |
召回@5 >0.85 |
Relevance_scores 直方图 |
| 同步 |
跨代理一致性延迟 <1s |
namespace 锁超时 |
| 压缩 |
短期记忆 Token 占比 <20% |
db_stats 查询 |
风险控制：若语义去重遗漏（LLM agent 幻觉），设置 manual_override=True，允许工具调用 search_memory 补救。相比 Milvus 等 vector DB，Memori 无 embedding 开销，查询纯 SQL，成本降 80%，但海量非结构化场景需 hybrid（SQL + 外部 embedding）。
部署示例（FastAPI 多代理）：
from memori import Memori
memori = Memori(database_connect="sqlite:///agents.db", namespace="multi_agent")
memori.enable()
性能基准：单机 PostgreSQL，QPS 1000+，内存 <500MB。
总结：Memori 的语义去重、分级压缩与同步机制，提供 Agent 记忆的“生产级”解决方案。核心是 SQL 的透明性 + Agent 的智能，落地参数如上，即可实现高效持久化。资料来源：https://github.com/GibsonAI/Memori，https://memorilabs.ai/docs/open-source/architecture。
（正文字数：1268）