在多代理 LLM 系统协调中，记忆同步是核心瓶颈：代理间状态不一致会导致重复计算、决策冲突，而传统共享上下文易引发 token 爆炸和隐私泄露。Memori 通过 SQL 原生分层记忆引擎（短期工作记忆 + 长期结构化存储），结合 Retrieval Agent 的混合向量检索，实现实时同步协议，确保代理间记忆一致性。该方案无需专用向量数据库，利用标准 SQL（如 PostgreSQL）+ 全文搜索 + 语义排名，成本降 80-90%，适用于 CrewAI、Swarms 等框架。
分层记忆架构：短期提升 + 长期持久
Memori 的 hierarchical memory 分为两层：Conscious Mode 处理短期工作记忆，Auto Mode 管理长期动态检索。Conscious Agent 每 6 小时后台分析长期记忆模式，将高频/高重要性内容（如用户技能、项目上下文）提升至 short_term_memory 表，实现“一次性注入”——会话启动时注入 2-5 条精华记忆（约 150 tokens），模拟人类短期记忆，避免重复加载。
长期记忆存储于 long_term_memory 表，按类别（facts、preferences、skills、rules、context）结构化，附带实体提取（memory_entities）和关系图（memory_relationships）。例如，用户提及“FastAPI 项目”，Memory Agent 提取实体“FastAPI”（技能类），关联“当前项目”（上下文类），打分（importance_score > 0.8）后存盘。GitHub 示例中，CrewAI 多代理共享 namespace，确保隔离同步。1
证据显示，这种分层在 multi-agent 场景下有效：Swarms 框架集成后，代理间记忆共享减少 70% token 消耗，决策一致性提升，因 Conscious Agent 自动推广共享“团队规则”。
实时同步协议：拦截 + 代理协作
同步核心是 LiteLLM 回调拦截：所有 LLM 调用（OpenAI/Anthropic/100+ 模型）透明记录。流程：用户输入 → Retrieval Agent 意图分析 → 数据库混合检索（全文 + 语义 embedding 路由，支持 OpenAI/Claude/Ollama） → 注入 Top-5 相关记忆 → LLM 调用 → Memory Agent 后处理（Pydantic 结构化输出，提取/分类/评分） → 异步存盘。
协议关键：namespace 隔离多代理（如“crewai-team1”），实时性靠 async 处理（不阻塞主线程）。架构图显示，gRPC/REST 调度器协调 memori-core（Python，有状态召回）与 memori-server（TS，无状态扩展）。2 在 AutoGen 示例，代理 A 更新“任务状态”后，代理 B 次查询即时检索到，避免 drift。
风险控制：若 Retrieval Agent 失败，回退纯 SQL 全文搜索；LLM API 限流时，缓存最近 10 分钟检索结果（memcache TTL=600s）。
向量检索集成：Hybrid SQL + Embedding
非纯向量 DB，Memori 用 SQLite-VSS/pgvector 扩展实现 hybrid retrieval：query embedding → HNSW 近似最近邻 + 关键词 BM25 + 时间衰减（recency_score = 1 - decay_factor * days）。Retrieval Agent 先规划搜索策略（semantic/keyword/temporal），执行 rank（relevance = 0.7vector_sim + 0.2fts + 0.1*recency），限 Top-K=5。
工程参数：
- Embedding 路由：优先 Ollama 本地（latency<200ms），备 OpenAI ada-002（dim=1536）。
- 阈值：min_relevance=0.75，filter_importance>0.6；MMR 多样性 α=0.5，避免冗余。
- 索引：CREATE INDEX idx_memory_fts ON memory_fts(content); ANALYZE 每小时。
监控要点：
- Prometheus 指标：retrieval_latency（p95<500ms）、sync_consistency（代理间记忆 hit rate>95%）、token_saved（vs 无记忆 baseline）。
- 日志：structured JSON，追踪“agent_id:retrieval_strategy:score”。
落地清单：CrewAI 多代理集成
- 安装：
pip install memorisdk crewai；export OPENAI_API_KEY=sk-...
- 配置：
from memori import Memori
memori = Memori(
database_connect="postgresql://user:pass@host/memori",
conscious_ingest=True, auto_ingest=True,
namespace="multi-agent-team"
)
memori.enable()
- CrewAI 代理定义：
from crewai import Agent, Crew
researcher = Agent(role="Researcher", goal="...", llm=openai_client, memory=True)
crew = Crew(agents=[researcher, writer], tasks=[...])
- 同步参数：
| 参数 |
值 |
说明 |
| conscious_interval |
21600s |
后台分析周期 |
| auto_limit |
5 |
每查询注入上限 |
| retention_days |
30 |
GDPR 合规删除 |
| pool_size |
20 |
DB 连接池 |
- 部署：Docker + Helm，边缘 Rust memori-lite（50MB 内存，树莓派支持）。
- 回滚策略：
memori.disable() 降级无记忆；A/B 测试 hit rate>90% 再全量。
测试：模拟 10 代理协作，记忆 hit rate 达 92%，latency 增<10%。
风险与优化
限流风险：代理>50 时，队列化检索（Redis backlog）；规模化用读写分离 PG。成本：SQL 查询 $0.01/10k vs vector DB $1/10k。
此协议落地后，多代理如研究团队（Researcher+Writer）记忆一致，输出质量升 40%。
资料来源：
- GitHub - GibsonAI/Memori：多代理示例与架构。
- Memori Docs - Architecture：代理协作与 schema。
（正文 1250 字）