在多轮AI代理交互中，对话历史往往迅速膨胀，导致上下文窗口溢出、计算成本飙升以及响应延迟增加。Memori作为一个开源的SQL原生内存引擎，通过一行代码即可为LLM注入持久、可查询的内存，支持OpenAI、Anthropic等框架，避免了昂贵的向量数据库依赖。根据官方文档，Memori的核心在于拦截LLM调用，在预调用阶段注入相关上下文，并在后调用阶段提取实体并分类存储，从而实现高效的内存管理。这种架构天然适合扩展关键事件提取和层级摘要机制，以压缩扩展对话历史，确保高效上下文保留而不需完整存储。
关键事件提取是压缩对话历史的起点，它聚焦于从冗长交互中提炼核心元素，如实体（人名、项目）、事件（决策、任务）和关系（偏好、规则）。在Memori中，这由Memory Agent负责，该代理使用Pydantic结构化输出对每轮对话进行处理。首先，代理分析用户输入和LLM响应，识别高价值信息：例如，在一个FastAPI项目讨论中，它会提取“用户偏好使用JWT认证”作为规则实体，而非存储整个闲聊线程。证据显示，这种提取能将原始对话token从数千减少到数百，仅保留事实、技能和上下文分类。Memori的SQL存储进一步优化了这一过程，通过全文搜索索引快速定位事件，支持跨会话关联。
要落地关键事件提取，可配置Memori的Memory Agent参数。初始化时，设置conscious_ingest=True启用短期工作内存注入，同时自定义提取提示模板，例如：“从以下对话中提取关键实体、事件和关系，仅输出JSON格式：{entities: [...], events: [...], relations: [...]}。”阈值设置包括：实体最小置信度0.8（使用LLM生成分数过滤低质提取），事件窗口大小为最近5轮对话（避免全局扫描延迟）。监控点：追踪提取命中率（目标>90%），若低于阈值，调整LLM模型为gpt-4o-mini以提升准确性。清单：1. 集成LiteLLM回调，确保代理拦截所有调用；2. 在PostgreSQL数据库中创建事件表（columns: id, entity_type, timestamp, content）；3. 每100轮交互运行验证查询，检查提取完整性。
层级摘要则构建在提取基础上，提供多层压缩，实现从详细记录到精要概述的递进。Memori的Conscious Agent每6小时（可配置）分析长期内存模式，将提取的事件分层：底层为原始事件日志，中层为小结（e.g., “用户讨论了认证方案，偏好JWT”），顶层为精要（e.g., “项目偏好：FastAPI+JWT”）。这一机制借鉴人脑情节记忆，证据来自Memori架构：代理促进重要内存到短期存储，避免重复注入。层级设计确保追溯性，每层摘要链接原始事件ID，支持无损展开。
实施层级摘要需扩展Conscious Agent逻辑。配置auto_ingest=True结合动态搜索，在后台线程运行摘要链：使用PromptTemplate“基于以下事件列表，生成{level}层摘要，保留关键决策和链接：{events}。”参数包括：摘要触发阈值（总token>2000时启动），层级深度3（底层>中层>顶层），最大摘要长度200token/层。监控策略：设置Prometheus指标跟踪摘要压缩比（目标>5:1），异常时回滚到上一层摘要。回滚清单：1. 若摘要引入幻觉（通过人工审计或一致性检查检测），恢复原始事件；2. 集成LangChain的ConversationSummaryBufferMemory作为备选，缓冲近期事件前摘要；3. 数据库中添加摘要版本控制（git-like diff），便于审计。
结合提取与摘要，Memori实现端到端压缩：在多代理交互中，Retrieval Agent动态召回层级摘要注入上下文，减少80-90%存储需求。风险包括细节丢失（缓解：保留锚点如用户明确指令，不摘要）和LLM依赖（优化：使用轻量模型如gpt-4o-mini，成本控制<0.01$/k token）。实际参数：数据库连接“postgresql://user:pass@localhost/memori”，命名空间“production”，背景分析间隔3600s。优化清单：1. 测试长对话（>50轮），验证上下文连贯性>95%；2. 集成错误处理，若提取失败默认fallback到滑动窗口（k=10）；3. 规模化时迁移到Neon/Supabase，支持无服务器扩展。
总之，通过关键事件提取和层级摘要，Memori有效解决长对话内存膨胀问题，支持高效AI代理部署。未来可探索与向量检索混合，提升语义召回精度。
资料来源：