智能体记忆 Agent Memory

Agent Memory

智能体记忆是 Agent 框架中用于跨轮次、跨任务存储和检索历史信息的组件,分为感官记忆、短期/工作记忆、长期记忆三层,决定了 Agent 能否记住用户偏好、避免重复犯错以及完成多步长周期任务。

详细解释

**Agent Memory(智能体记忆,简称 Agent 记忆)**一句话:你用 Agent 帮你做「调研 20 家竞品 → 写报告 → 发给老板」这种跨 3 天、中间停了好几次的长周期任务,它第二天开工时还记不记得昨天已经调研了哪 15 家、每家结论是什么、昨天跟你确认过的写作风格要求是什么——记不住的 Agent 就是一次性的工具人,只能跑单轮;记得住的 Agent 才是真正的长期工作伙伴。

Agent 记忆借鉴了认知科学对人类记忆的三层分类:(1)Sensory Memory(感官记忆 / 极短期,毫秒到秒级,当前输入的瞬时缓存);(2)Short-term / Working Memory(短期/工作记忆,秒到分钟级,当前这轮对话和当前任务的推理上下文,对应 LLM 的 Context Window);(3)Long-term Memory(长期记忆,小时到年级,海量历史信息持久化存储,检索时按需加载到 Context Window)。绝大多数工程师说「Agent 记忆」时特指第三层长期记忆的工程实现(前两层本质就是 LLM Context 和输入 buffer,没什么工程花活)。

唯元智创 的 Agentic SDK 把三层记忆做了统一工程封装:Sensory Memory 做了 Last-N 对话 + Tool 输入的滑动窗口缓存(默认 20 轮,自动做 Token 预算管理),Working Memory 用了一个结构化的「Task Tracker JSON」把当前任务进度、已完成步骤、用户确认过的关键决策持久化到 Context 顶部,Long-term Memory 则对接任意 Vector Database 做 embedding 索引检索 + 关系图谱实体记忆;默认给每个用户独立一个 memory namespace,企业版还能支持「跨用户共享的组织记忆」(比如整个团队对某个客户的历史交互信息所有人都能检索到)。

Agent 记忆三层架构 + 工程实现建议

记忆层级人类对应容量保留时长工程实现方式7B 模型 Agent 推荐配置
① Sensory(感官 / 输入缓存)视觉听觉瞬时印象极大毫秒级最近 N 条消息的 raw 队列;Token 超限时按策略丢弃最老20 条最近消息;超限先丢工具的原始返回(通常最长)
② Working Memory(工作记忆)当前对话上下文+脑子里正在想的事LLM Context Window 上限会话期间当前对话历史 + 当前多步任务的结构化 Task Tracker(建议放在 System Prompt 顶部 JSON 格式,模型每步可读可写)Task Tracker 结构固定 1000 Token 以内;历史消息先压缩再截断
③ Long-term Memory(长期记忆)你几年前的经验和知识几乎无限(按存储)会话外永久保留(a)文本 embedding + 向量库语义检索;(b)结构化实体图谱(记住「用户A的预算上限2万」「客户B的CTO姓张」等三元组事实);(c)Reflection 总结记忆(Self-Reflection 生成的 lessons learned,每完成一个任务写入一次)3 路召回融合:向量 Top20 + 精确实体命中 + 最近 7 天任务总结;每轮取 Top 10 条注入 Context

设计 Agent 记忆系统的 4 个大坑(几乎所有新手都会踩)

  1. 坑 1:把整个历史对话原封不动塞进 Context,觉得就是「有记忆了」——大错特错。10 轮对话之后原始历史能吃掉 4K Token,里面 90% 是废话和工具原始返回,模型注意力被稀释,真正重要的事实(比如「用户是糖尿病人不能吃糖」这种致命约束)反而被淹没;正确做法是对话总结压缩 + 事实提取 + 只存 Key-Value 级的结构化事实,不要存原文。
  2. 坑 2:长期记忆只做向量语义检索,没有事实遗忘/冲突检测——用户第一次说「我预算 1 万」后来又改口说「预算 2 万」,两条记忆都在向量库里,检索时可能同时召回 1 万和 2 万,模型会混乱。必须加最新性权重:最近 7 天的记忆 ×3 权重、一个月前的 ×0.3;同时同一字段出现新版本时,旧版本标记为「已被版本 N 覆盖」不再参与召回。
  3. 坑 3:没有「记忆的写入权限控制」——工具调用失败的结果、用户在试错阶段说的废话全被写入长期记忆,下次检索出来一堆垃圾。推荐采用「三级写入门控」:自动写入的只有用户显式确认的内容;工具调用的中间结果默认只进 Working Memory 不进 Long-term;任务结束时触发一次 Self-Reflection 提炼 lessons learned,再写入长期记忆(这时候写入的才是真正有价值的经验)。
  4. 坑 4:用一个 7B 模型既做推理又做记忆检索的 embedding——7B 模型做 embedding 检索效果比专门的 embedding 模型(bge-large / text-embedding-3-large)差 20 个百分点以上,记忆检索不准就等于 Agent 失忆。记忆的 embedding 模型和推理模型一定要分开,推理用 70B 大模型,记忆检索用专门的强 embedding 小模型,成本低效果还好。

常见问题

Working Memory 太大了,20 轮对话后 Context 就满了,怎么办?有什么压缩算法推荐?
不要盲目套什么抽象总结压缩算法,Working Memory 压缩按性价比分三步走,能解决 99% 的场景:(1)最外层先做「Tool 结果的摘要压缩」——工具调用返回的长文本(比如一次网页搜索返回了 10 篇文章)不要把 10 篇原文全存,用一次小 LLM 调用把每篇压缩成 3 行摘要,Token 量直接降到原来的 1/10,这条能解决 80% 的 Context 膨胀;(2)第二步做「对话轮次级事实抽取」——每 5 轮历史对话用一次 Prompt 让模型把这 5 轮里的关键事实提取成编号条目(用户新决定了什么、确认了什么、拒绝了什么、下一步计划是什么),每条不超过 20 字,然后把原始 5 轮对话替换成这几条事实,Token 又能砍 2/3;(3)第三步才是「全量摘要」,前两步做完 Context 还是超限时,才让模型把整个历史对话总结成 300 字以内的「当前会话至今情况报告」,丢掉原始对话正文只保留这个报告 + 最近 5 轮。按这个顺序做压缩,事实丢失率比直接上来就全局总结低 80%,不会出现「压缩完了关键约束全没了」的情况。
长期记忆向量检索经常召回一些根本不相关的内容,怎么优化?
Agent 记忆的检索和普通 RAG 检索不一样——它有两个特殊的强信号大多数工程师忘了用,用上之后召回准确率会提升 30% 至 50%:(1)「命名实体精确匹配」——用户现在问的问题里如果出现了具体的人名、公司名、项目名、订单号这些精确实体,长期记忆里只要有完全匹配相同实体的,一定要给极高权重(甚至先于向量检索结果展示),不要只靠向量相似度;向量相似度在这种实体精确问题上经常犯傻,会把「预算 2 万的公司 A」和「预算 2 万的公司 B」搞混;(2)「记忆写入时的结构化标签过滤」——每条长期记忆写入时,让模型同时打上几个分类标签(这是关于「用户偏好」、「业务约束」、「历史决策」还是「外部知识」?),检索时先根据当前 Query 只在相关标签的子集里搜,根本不要去不相干的记忆类型里瞎找;(3)Rerank 交叉编码器作为最后一步重排——向量召回 Top 50 之后,用 CrossEncoder 再做一次精细语义匹配取 Top 5,虽然多花 50ms 但准确率再涨 15%。这三条组合起来用,记忆误召回率基本能降到 < 5%。
用户隐私合规怎么做?Agent 记忆里存了很多用户敏感数据能直接存向量库吗?
绝对不能直接裸存——先做脱敏再存,同时配套 4 条合规机制,2025 年的数据合规(GDPR/个保法/行业监管)就不会出问题。(1)PII 脱敏写入——任何记忆在写向量库之前,先跑一遍 PII 识别,把手机号/身份证/银行卡/地址这些个人隐私信息替换成脱敏占位符,原文加密存隔离的 PII Vault,检索时再按需解密回填;(2)按用户/项目做 Namespace 隔离——绝对不能把不同客户的记忆存在同一个向量集合里,查询时强制带上 Namespace 过滤,绝不能出现 A 客户的 Agent 能检索到 B 客户记忆的事故;(3)自动 TTL 和遗忘接口——用户注销账户时,对应 Namespace 下所有记忆必须有一键物理删除接口(个保法遗忘权要求),同时所有记忆默认设 1 至 3 年自动过期 TTL(根据行业合规要求调整),过期自动删;(4)记忆写入审计日志——谁写入了什么记忆、什么时候通过哪次对话写入的、检索时哪条被 Agent 用了,每一笔都要打审计日志,保留 6 个月以上,合规检查时能拿出来。AI Compliance & Privacy 里面的 4 条最佳实践对 Agent 记忆完全适用,直接照搬即可。