智能体的"记忆"是生产环境中最容易被低估的能力。演示场景下,智能体似乎"自带"长期记忆——它能记住用户偏好、历史决策、过往对话。但生产场景下,这种"自带记忆"完全是错觉。智能体本身是无状态的,所有记忆都必须由外部系统提供。本文基于 Pinecone、Weaviate、Redis 在 2026 年的工程实践报告,梳理智能体记忆架构的三层设计。
第一层:临时记忆(进程内)
临时记忆是智能体进程内的数据结构,生命周期与进程一致。典型实现是 Python 字典、Go map,或更结构化的 dataclass。临时记忆的特点是访问零开销,但进程一旦结束,记忆就消失。
临时记忆适合存储"当前任务的瞬时状态":用户当前输入、模型上一次推理结果、本轮工具调用的返回值。这些信息不需要持久化,任务结束就可以丢弃。临时记忆的访问开销几乎为零,因为它就在进程内,不需要任何网络调用。
临时记忆的工程要点:避免无限制增长。Python 字典可以无限添加键,但如果不主动清理,会迅速膨胀到数百 MB,触发 OOM。常见做法是设置最大条目数,超过时按 LRU 策略淘汰。另一种做法是按"任务边界"清理:每完成一个子任务,清理该子任务产生的中间数据。
临时记忆的另一个要点:并发安全。如果智能体是多线程或多进程运行的,临时记忆必须做并发控制(加锁、无锁数据结构、actor 模式)。否则多个线程同时写入同一份记忆,会出现"读到的状态不一致"。
第二层:短期记忆(KV 存储)
短期记忆的典型实现是 Redis 或 Memcached,生命周期通常 7-30 天。短期记忆存储"跨会话但有时效的信息":用户最近 7 天的活动轨迹、最近 10 次对话摘要、最近 3 次工具调用的失败记录。
短期记忆的特点:访问延迟低(Redis 通常 < 1ms),支持丰富数据结构(字符串、哈希、列表、集合、有序集合),支持 TTL 自动过期。这些特性让 Redis 成为短期记忆的事实标准。
短期记忆的工程要点:命名空间设计。多个智能体共享同一 Redis 实例时,必须用命名空间隔离(例如 agent:{id}:memory:*)。否则一个智能体可能误读另一个智能体的记忆,造成跨用户信息泄露。命名空间也要在物理上隔离(用 Redis Cluster 的不同 slot),防止单个热点智能体压垮整个集群。
短期记忆的另一个要点:容量规划。短期记忆的增长速度通常超出预期——一个中等复杂度的任务,可能在 1 小时内产生 500 条记忆条目。生产环境需要按"每个智能体每分钟 X 条"的速率估算总容量,提前扩容。容量不足时,Redis 会触发淘汰策略,可能导致关键记忆被丢弃。
短期记忆还要考虑持久化。Redis 默认是内存存储,进程崩溃或重启会丢失数据。生产环境通常开启 RDB 或 AOF 持久化,把短期记忆的丢失风险降到最低。即便短期记忆丢失,智能体也可以重新构建(代价是丢失近期的用户上下文),影响有限。
第三层:长期记忆(向量数据库 + 文档数据库)
长期记忆的典型实现是向量数据库(Pinecone、Weaviate、Qdrant、Milvus)或文档数据库(MongoDB、Elasticsearch)。生命周期通常按业务规则决定——某些记忆永久保留(用户偏好),某些记忆定期归档(操作日志)。
长期记忆存储"跨会话、跨时间的持久信息":用户的历史偏好(语言、风格、工具选择)、业务规则(行业惯例、企业特定约束)、历史决策(过往类似任务的处理方式)。
长期记忆的工程要点:
- 写入校验。智能体不能"想写就写",必须经过规则校验或人工审批。否则 Agent 会把幻觉写进长期记忆,后续越用越偏。常见做法是"写入前先由另一个 LLM 做事实校验,校验通过才写入"。校验可以是"必做"(每个写入都校验),也可以是"抽样做"(10% 抽样)。
- 检索质量。向量检索不是"相似就返回",必须做重排序。向量检索召回的 Top-K,可能语义相似但事实无关。重排序模型(Reranker)能过滤掉这类噪声。Reranker 通常是基于 Cross-Encoder 的小模型,延迟低、效果好。
- 生命周期管理。长期记忆不能无限增长。常见做法是"按重要性分级":核心记忆(用户偏好、业务规则)永久保留;辅助记忆(操作日志)保留 90 天后归档。归档可以保留在冷存储,需要时再调出。
- 跨智能体一致性。多个智能体共享长期记忆时,必须有一致性保证。否则一个智能体写入"用户偏好 A",另一个智能体读到的可能是过期版本。常见做法是用分布式锁或乐观锁。
- 隐私与合规。长期记忆包含用户偏好、历史决策,可能涉及隐私。生产环境必须做脱敏处理(如姓名 → 哈希)、访问审计(谁读了哪些记忆)、合规校验(GDPR 删除请求)。
- 临时记忆查找当前任务的瞬时状态(零开销)。
- 短期记忆查找近期相关历史(< 10ms)。
- 长期记忆查找历史偏好和业务规则(< 100ms)。
- 模型基于三层记忆的合并上下文进行推理。
- 任务完成时:把"任务摘要"、"用户偏好变化"、"工具使用模式"写入短期记忆。
- 关键事件发生时:把"用户重大决策"、"业务规则确认"、"异常情况处理"写入长期记忆。
- 用户显式要求时:用户说"记住这个",智能体把信息写入长期记忆(需要人工校验)。
- 全量回灌:每次推理都读取全部相关记忆。简单但开销大,适合记忆量小的场景。
- 按相关性回灌:用向量检索 + 重排序,只回灌与当前任务最相关的 Top-K。开销可控,是生产环境的主流。
- 按规则回灌:用规则引擎判断哪些记忆相关(例如用户问"上周的订单",只回灌订单相关记忆)。开销最低,但规则需要人工维护。
- 先做临时记忆。把当前任务的状态管理起来,这是基线。可以用 Python dict、Go map 等简单数据结构。
- 再做短期记忆。用 Redis 实现,设置合理的 TTL。建议 TTL 设为 7-30 天,根据业务调整。
- 最后做长期记忆。向量数据库 + 文档数据库组合,写入要校验,读取要过滤。Pinecone / Weaviate 是向量数据库的常见选择。
- 三层记忆协同起来。模型推理时,合并三层记忆的上下文。建议做一个统一的"记忆管理器",封装三层记忆的访问。
- 建立记忆监控。看板上显示:三层记忆的容量、命中率、读取延迟。指标异常时,主动排查。
- 持续优化记忆写入策略。基于实际使用情况,调整"什么值得记忆"。定期做记忆审计,清理过时记忆。
- 与模型升级协同。模型升级时,重新评估记忆合并策略,可能可以简化某些步骤。
三层记忆的协同
三层记忆不是"互斥",而是"互补"。一个典型的智能体查询流程:
这种分层设计与计算机存储体系的金字塔(寄存器 → 缓存 → 内存 → 磁盘)异曲同工。越靠近模型、访问越快的信息,容量越小;越远离模型、访问越慢的信息,容量越大。
记忆的写入时机
记忆不是"全量写入",而是"按需写入"。常见写入时机:
写入策略的关键是"价值评估"——不是所有信息都值得记忆,只有"未来会用到"的信息才写入。价值评估可以由规则引擎完成(基于字段、来源、时间),也可以由另一个 LLM 完成(基于内容分析)。
记忆的读取策略
读取策略与写入策略同样重要。常见的读取策略:
生产环境通常组合使用:对核心记忆(用户偏好)用全量回灌,对辅助记忆(操作历史)用相关性回灌,对场景化记忆(订单)用规则回灌。
与模型能力的协同
记忆架构与模型能力协同。能力强的模型,可以处理更复杂的记忆合并(把三层记忆合并成连贯上下文);能力弱的模型,需要更精细的记忆预加工(把记忆整理成模型容易消化的形式)。
模型升级时,记忆架构也需要重新评估。新模型可能用更少的 token 表达同样的信息,旧的记忆合并策略可能需要调整。例如,新模型可能不再需要"摘要",直接读原文也能消化,这时可以省略摘要步骤,降低延迟。
落地建议
对于正在搭建智能体记忆系统的团队,建议按以下顺序推进:
结语
智能体的记忆不是"天然就有",而是"工程搭建出来"。三层记忆架构,从临时记忆到短期记忆再到长期记忆,提供了完整的记忆能力支撑。当这三层记忆协同工作,智能体才能从"无状态工具"变成"有记忆的执行者",真正成为企业的可靠助手。