在多代理大型语言模型（LLM）系统中，维持长期对话的上下文一致性是关键挑战之一。传统的上下文窗口机制容易导致 token 消耗过高和信息遗忘，而 episodic memory（情景记忆）作为一种模拟人类大脑事件存储的方式，能够高效捕捉和检索对话片段，从而支持代理间协作而不必反复加载完整历史。本文基于开源内存引擎 Memori，探讨如何设计 episodic memory 模块，实现多代理 LLM 的上下文感知响应。
Episodic Memory 在多代理 LLM 中的核心作用
Episodic memory 不同于语义记忆，它专注于时间序列化的具体事件记录，如用户查询、代理响应和交互转折点。在多代理系统中，例如一个研究代理与总结代理协作时，episodic memory 可以存储关键对话片段，确保后续响应基于历史事件而非孤立输入。这不仅提升了响应的连贯性，还降低了计算成本。根据相关研究，引入 episodic memory 可将长期交互的 token 使用量减少 80% 以上。
Memori 作为 SQL 原生内存引擎，已内置实体提取和上下文注入功能，非常适合扩展为 episodic memory 模块。其架构通过拦截 LLM 调用，在预调用阶段检索相关记忆，并在后调用阶段记录新事件。这种设计天然支持多代理框架，如 AutoGen 或 CrewAI，其中每个代理可共享或隔离 episodic 存储。
模块设计：存储与检索机制
存储结构设计
在 Memori 的 SQL 数据库中，我们可以扩展表结构以支持 episodic memory。具体而言，创建一个 episodes 表，包含以下字段：
- id: 唯一标识符（主键）。
- timestamp: 事件发生时间（ISO 8601 格式，支持精确到毫秒）。
- agent_id: 发起代理的 ID，支持多代理区分。
- summary: 事件摘要（使用 LLM 自动生成，长度控制在 50 tokens 内）。
- details: 完整对话片段（JSON 格式，包含用户输入、代理输出和元数据）。
- entities: 提取的关键实体（数组，如 {"user_preference": "fastapi_auth"}）。
- relevance_score: 初始相关性分数（基于 surprise 机制计算，范围 0-1）。
事件形成过程采用在线方式：每当对话转折（如主题变化或用户反馈）发生时，Memori 的 Memory Agent 触发存储。借鉴人类认知，使用 Bayesian surprise 度量新事件与近期记忆的差异，若 surprise > 0.5，则形成新 episode。同时，背景 Conscious Agent 每 6 小时运行一次，分析模式并提升高频 episode 到短期缓冲区。
例如，在一个多代理客服系统中，用户首次咨询 FastAPI 认证时，存储为 episode：{"timestamp": "2025-11-17T10:00:00", "summary": "用户请求 FastAPI 认证指导", "details": {"user": "Help with auth", "agent": "Suggest JWT implementation"}}。后续交互可直接引用此 episode，避免重复。
检索机制优化
检索是 episodic memory 的核心，支持上下文感知响应而不加载全历史。采用两阶段混合检索：
- 相似性检索：使用全文搜索和向量嵌入（Memori 支持 SQLite 的 FTS5 扩展）。给定当前查询，计算 cosine 相似度，阈值设为 0.7，仅返回 top-5 相关 episode。
- 时间连续检索：结合 recency 和 contiguity，确保检索到时间邻近的事件。例如，若当前时间为 T，优先检索 [T-1h, T] 内的 episode，权重为 e^{-λ(T - t)}，其中 λ=0.1（衰减率）。
在多代理场景下，检索时过滤 agent_id，实现代理间共享（如共享用户偏好）或隔离（如私有决策）。Memori 的 Auto Ingest 模式可动态触发此检索，注入到 LLM 提示中："基于以下 episode 上下文：{retrieved_episodes}"。
此机制确保响应高效：对于 1000+ episode 的数据库，检索时间 < 100ms，支持实时交互。
可落地工程参数与清单
为确保模块在生产环境中的可靠性，以下是关键参数配置：
- 缓冲大小：短期工作记忆缓冲 20 个 episode，超出时使用 LRU（Least Recently Used）驱逐。
- 相似阈值：0.75（可调，基于 A/B 测试调整，以平衡召回率和精度）。
- 超时参数：检索超时 200ms，存储延迟 < 50ms；若超时，回退到 conscious mode 的简单注入。
- 监控点：追踪 episode 存储率（目标 >95% 成功）、检索命中率（>80%）、token 节省率（基准 70%）。
- 回滚策略：若新 episode 导致响应偏差 > 10%（通过人类评估），自动回滚到上一个稳定版本，并标记为低相关。
实施清单：
- 集成 Memori：安装 memori SDK，配置数据库连接（如 PostgreSQL: "postgresql://user:pass@localhost/memori"），启用 conscious_ingest=True 和 auto_ingest=True。
- 扩展 schema：运行 SQL 脚本创建 episodes 表，添加触发器自动提取实体（使用 OpenAI API key）。
- 事件检测：自定义 Memory Agent 钩子，集成 surprise 计算（基于 KL 散度）。
- 检索接口：实现两阶段查询函数，集成到 LLM 调用前（e.g., client.chat.completions.create 前注入）。
- 多代理适配：在框架如 CrewAI 中，为每个代理分配 namespace（如 "agent_researcher"），共享核心 episode。
- 测试与部署：使用 LongBench 基准验证长期上下文任务，监控 Discord 社区反馈，部署到 Neon 或 Supabase 以支持云扩展。
- 安全考虑：加密 details 字段（AES-256），用户可导出 SQLite 文件实现零锁入。
通过这些参数，模块可在资源受限的环境中运行，例如单机 SQLite 处理 10k episode，而不牺牲性能。
潜在挑战与优化
尽管设计高效，但高并发多代理场景可能导致 DB 锁争用。优化方案包括分片存储（按 agent_id）或异步队列（如 Celery）。此外，episode 的主观性需通过用户反馈循环精炼，确保相关性。
总之，在 Memori 中集成 episodic memory 模块，不仅解决了多代理 LLM 的记忆瓶颈，还为工程实践提供了可操作路径。该设计强调观点驱动：从人类认知启发，到证据验证，再到参数落地，支持 AI 系统向更智能的长期交互演进。
资料来源：
- Memori GitHub 仓库：https://github.com/GibsonAI/Memori
- Das et al. (2024): Larimar: LLMs with Episodic Memory（arXiv 预印本）。
（正文字数约 1050）