Agent中记忆机制你会怎么做？

用户23238158461
0 阅读5分钟

@TOC

前言

如果不加记忆机制，在Agent系统中会出现什么问题呢？

一、多轮对话秒忘记

这是最直观的效果。用户问了上句，在下一个对话中再次询问之前关联的知识，Agent只能靠猜测来回答，这极有可能会出现幻觉。这在智能客服，订票助手等Agent系统中，是带来灾难性的后果。

二、工具调用陷入死循环

在ReAct或Plan-and-Solve这在需要自主规划的Agent架构中，记忆记录了Agent过去做过什么和做出的结果是什么。

  • 现象示例：Agent尝试调用一个天气API，由于网络超时或入参错误，API报错了。如果没有记忆机制，在下一个思考周期里，Agent会忘记之前调用过一次天气API失败的经历，它会极其固执地再次调用这个错误的API，直到触发最大Max Iterations(如果你配置了)或者直接死循环，烧光Token。

三、无法提供个性化服务

企业中在做一个产品出来，很看重用户留存和精准推荐。没有记忆机制，便无法沉淀用户画像，无法简历业务壁垒。

引入记忆机制

一、短期记忆

短期记忆适合保存当前会话或任务执行过程中的临时信息，包含用户输入历史、中间计算结果、上下文状态等，通常采用有限长度的缓冲区或缓动窗口实现，当超出容量限制进行总结摘要，剪枝等操作。

存储介质
  • 内存：最常见的实现方案是基于内存的数据结构，比如使用HashMap来存储会话上下文，键是会话ID，值是对话历史的链表。
    • 应用场景：适合单任务自动化脚本，比如自动写周报
    • 优点：实现简单，读写速度极快，零外部依赖
    • 缺点：进程重启、发生Crash，记忆全部丢失，且无法进行多实例的横向扩展。
  • 关系型数据库MySQL/PostgreSQL
    • 应用场景：适合大多数场景
    • 优点：数据可以持久化，支持复杂的条件查询，比如审计，回溯
    • 缺点：抗不住高并发，频繁读写会对数据库I/O造成巨大压力，延迟过高。
  • 分布式缓存redis
    • 应用场景：生产环境的绝对主力
    • 优点：读写延迟低，原生支持TTL，非常适合会话自动过期；支持分布式
实现方式

在具体的工程化实现方案中，会启用滑动窗口+摘要。滑动窗口保留最近的5-8轮对话，窗口超出后进行脱水摘要总结。用System Prompt+Window+Summary维护对话连贯性。当摘要过多，比如10轮摘要后，将旧的摘要提取出核心知识点或关键语义片段做Embedding后存到向量数据库。这个时候，还会拿着用户当前问题，去向量数据库反向检索相关的“旧摘要片段”，如有相关，以Context的形式按需注入。 还有，摘要和对于的原始对话压缩后，还要存入MySQL作为数据的唯一真实来源，保证数据不丢失。

短期记忆流程图如下： 在这里插入图片描述

二、长期记忆

长期记忆负责持久化存储重要知识和经验，包含用户偏好、历史交互模式、学习到的规则等，常通过向量数据库、知识图谱或结构化存储。

存储介质
  • 传统数据库MySQL/MongoDB：适合存储结构化数据，存关键字，比如user_id:123，多用于BM25检索。但是无法很好支持语义模糊检索。
  • 向量数据库Milvus/ChromaDB/QDrant：适合存储非结构化数据，是Agent长期记忆的常用存储方式。通过把历史对话或用户行为做Embedding后存入，通过HNSW等算法进行语义相似度检索。但是缺乏精准的逻辑关系。
  • 图数据库Neo4j或GraphRAG：能将长期记忆抽象为实体和关系，比如[User]->[Prefers]->[Python]，能够处理复杂的推理记忆。但图查询的延迟高，维护起来成本也较大。

记忆机制实现方式

上面介绍了短期+长期记忆。那么下面我们就来讨论如何设计一个能用，好用的记忆机制实现方案。 我的实现方案中不会短期+长期记忆分开看，而是将其视为一个“分层存储+实时路由”的统一管道。我将其设计成三层记忆模式——热记忆、温记忆、冷记忆

  1. 热记忆层：响应最快，支持实时交互
    • 存储内容：存储着当前对话的原始文本，使用Redis来存储——Key=Session ID、Value=List
    • 工程细节：
      • 滑动窗口：只保留最近5-8轮。不存储工具调用结果(有噪声)，只存储最终LLM的回复文本。
      • 过期机制：利用Redis的TTL(如：30分钟)，超过时间未交互则自动销毁，节约内存。
  2. 温记忆层：异步LLM摘要，支持承上启下
    • 存储内容：超时滑动窗口对话的Summary。
    • 工程细节：利用消息队列，将超出部分放入消息队列，由后台Worker调用小模型去更新这个会话的Summary。将其压缩成极简的KV键对描述。
  3. 冷记忆：跨会话沉淀知识
    • 存储内容：
      • 向量库：存放对话历的Embedding、用户习惯、过往解决的问题。
      • 结构化库MySQL：存用户画像、权限标签、业务元数据。还要存完整的历史记录和经过整理的会话全貌。

大致流程图如下： 在这里插入图片描述

问题

  • 为什么热记忆不存到MySQL？ 完全可以存，但必须分场景。
    • 如果业务场景是低频、强一致性的(比如：OA系统、审批流、法律文档问题)，存MySQL是极佳的选择。因为这类业务不怕几百毫秒的读取延迟，但是很注重数据的可靠性和审计。
    • 如果是高频、高并发的Agent(比如：智能助手、陪聊、实时代码助手)，用MySQL来存旧不合适了。I/O和读写延迟都是问题。
avatar
文章
阅读
粉丝