记忆系统短期记忆、长期记忆、向量记忆Agent 要持续完成任务、记住用户偏好必须有记忆系统。这篇讲 Agent 的三层记忆架构短期工作记忆、长期对话记忆、向量知识库记忆各自的作用、实现方式、以及怎么设计合理的记忆机制。大家好我是黒漂技术佬。人有短期记忆和长期记忆Agent 也一样。普通对话只有当前窗口的上下文聊多了就忘了前面说过什么。真正的 Agent 需要多层记忆系统才能记住用户偏好、历史对话、专业知识。这篇讲 Agent 的记忆体系短期记忆、长期记忆、向量记忆分别是什么、怎么实现、有哪些常见问题。一、为什么需要记忆系统普通对话的问题只有当前对话的上下文关了窗口就全没了对话太长超出上下文窗口前面的就忘了每次对话都是「第一次见面」不记得用户是谁、偏好什么没有外部知识库只能靠模型训练时的知识Agent 需要的记忆能力记住当前任务的进展做到哪一步了、中间结果是什么记住用户是谁名字、偏好、历史对话记住专业知识企业内部文档、产品手册、FAQ从经验中学习之前做过类似的任务这次做得更好三层记忆架构┌─────────────────────────────────┐ │ 短期记忆工作记忆 │ │ 当前对话、当前任务上下文 │ │ 存在上下文窗口里快但容量小 │ ├─────────────────────────────────┤ │ 长期记忆对话记忆 │ │ 历史对话记录、用户画像 │ │ 存在数据库里量大但要检索 │ ├─────────────────────────────────┤ │ 向量记忆知识库记忆 │ │ 文档、FAQ、产品知识 │ │ 存在向量数据库语义检索 │ └─────────────────────────────────┘二、短期记忆工作记忆是什么当前对话轮次里的内容就是模型的上下文窗口。对话历史工具调用的中间结果当前任务的执行状态存在哪里直接在 messages 数组里每次调用 API 都传过去。特点快直接在上下文里模型立刻能用准原始信息没有损失容量有限受模型上下文窗口限制4k、8k、32k、128k临时对话结束就没了短期记忆的问题1. 上下文溢出对话太长token 超过模型限制前面的被截断就忘了。2. 长上下文效果下降虽然很多模型号称 128k 上下文但实际越长效果越差中间的内容容易「lost in the middle」。3. 成本高上下文越长每次调用 token 越多越贵。优化策略策略 1滑动窗口只保留最近 N 轮对话老的丢掉。# 只保留最近10轮iflen(messages)20:messagesmessages[-20:]简单粗暴适合不重要的闲聊。策略 2摘要记忆老的对话做摘要用摘要代替原文节省 token。[历史摘要] 用户之前问过A、B、C三个问题主要关心价格和功能。 [最近对话] 用户那售后呢 助手...既保留了关键信息又省 token。策略 3关键信息提取提取用户的核心信息名字、偏好、关键事实存起来每次拼到系统提示词里。用户信息 - 姓名张三 - 职业程序员 - 偏好喜欢简洁的回答 - 关注AI Agent 相关技术三、长期记忆对话记忆是什么跨会话的记忆记住用户之前所有的对话和偏好。用户画像姓名、职业、兴趣、语言风格偏好历史对话记录之前做过的任务、达成的共识存储方式存在数据库里MySQL、PostgreSQL、MongoDB 都行表conversation - id - user_id - message - role (user/assistant) - timestamp - embedding可选语义检索用怎么用不是把所有历史都塞上下文而是检索相关的历史拿出来。方式 1按时间取最近的把最近几次对话的摘要拼进去。方式 2语义检索把历史对话向量化当前问题去检索最相关的历史对话。用户当前问题那个API怎么调用 检索相关历史 - 3天前用户问过XX接口的鉴权方式 - 1周前讨论过API的限流规则 把相关历史拼到上下文里模型就知道「哦之前聊过这个」用户画像User Profile从历史对话里提取结构化的用户信息存在用户档案里{name:张三,role:后端开发,company:某科技公司,preferences:{language:中文,style:简洁直接,detail_level:中等},interests:[AI Agent,RAG,云原生],known_facts:[使用Python开发,团队有5个人,在做智能客服项目]}每次对话前把用户画像拼到系统提示词里Agent 就「认识」用户了。怎么更新画像对话中发现新信息自动提取更新可以专门让模型判断「这段对话有没有新的用户信息需要记住」四、向量记忆知识库记忆是什么外部知识库比如产品文档、FAQ、内部手册、历史工单……向量化后存在向量数据库里需要的时候检索出来。就是 RAG检索增强生成那一套。工作流程文档 → 分块 → 向量化 → 存入向量数据库 用户提问 → 问题向量化 → 向量检索 → 拿到相关片段 → 拼进上下文 → 模型生成回答跟长期记忆的区别长期记忆用户的历史对话、个人信息跟特定用户相关向量记忆通用知识库所有用户共享的知识常用的向量数据库Chroma轻量本地文件开发方便Pinecone云服务托管型Weaviate功能全开源Milvus开源高性能企业级Qdrant开源Rust 写的性能好pgvectorPostgreSQL 插件已有 PG 的话方便检索优化不是简单搜一下就完了要优化召回率混合检索向量检索 关键词检索BM25重排序召回一批之后用 reranker 模型精排查询改写把用户问题改写成更适合检索的关键词分块策略合理的 chunk 大小和重叠RAG 优化是个大学问后面专门有一篇讲 RAG Agent 的结合。五、记忆的读写流程读记忆检索每次回答问题前从各层记忆里取相关内容用户提问 ↓ ┌─ 读向量记忆检索相关知识库 ─┐ ├─ 读长期记忆检索相关历史对话 ┤ └─ 读短期记忆当前对话上下文 ─┘ ↓ 拼到 prompt 里 ↓ 模型生成回答写记忆存储回答完之后更新记忆对话结束 ↓ ┌─ 写入短期记忆加入 messages ──┐ ├─ 写入长期记忆存对话记录 ─────┤ ├─ 更新用户画像提取新信息 ─────┤ └─ 可选写入知识库新的知识 ─┘反思式记忆更高级的做法对话结束后让模型自己总结「这次对话有什么需要记住的」请总结这段对话中需要记住的用户信息和关键事实 格式为JSON包含preferences和facts两个字段。把总结出来的结构化信息更新到长期记忆里。六、记忆的常见问题问题 1记忆太多上下文装不下解决不是全量塞而是检索相关的用摘要代替原文分层重要的留着不重要的归档问题 2记忆过时了用户偏好变了、知识更新了旧记忆会误导。解决带时间戳新的优先定期更新知识库用户画像可以覆盖更新冲突时以最新为准问题 3记忆冲突前后说的不一样比如用户先说「我用Python」后来又说「我主要写Java」。解决以最新的为准可以保留历史版本但当前用最新的重要的冲突可以主动问用户确认问题 4幻觉 记忆 放大幻觉检索到的信息如果不准确模型照着胡说比纯对话更像真的。解决知识库内容要保证质量回答要标注来源不确定的就说不确定不要编问题 5隐私问题用户对话记录存起来涉及隐私。解决脱敏处理明确告知用户数据用途提供删除记忆的功能遵守相关法规GDPR、个人信息保护法等七、不同类型 Agent 的记忆需求客服 Agent短期记忆当前对话上下文记住用户问过什么长期记忆用户历史工单、用户等级、偏好向量记忆产品知识库、FAQ、工单历史个人助理 Agent短期记忆当前任务进展长期记忆用户日程、联系人、偏好、习惯向量记忆用户的文档、笔记、收藏数据分析 Agent短期记忆当前查询上下文长期记忆历史查询记录、常用指标、用户习惯向量记忆数据字典、表结构说明、指标定义代码 Agent短期记忆当前代码上下文、错误信息长期记忆项目结构、技术栈、编码规范向量记忆API 文档、代码库、最佳实践八、记忆系统设计建议1. 从简到繁先做最简单的滑动窗口短期记忆 向量知识库跑通了再加长期记忆和用户画像。2. 记忆不是越多越好塞太多无关记忆反而干扰模型注意力分散。相关的才是有用的。3. 记忆要可管理用户能查看自己的记忆能删除特定记忆能清空所有记忆4. 重要的记忆放系统提示词用户名字、核心偏好这种高频重要信息直接拼在系统提示词最前面比检索靠谱。5. 带时间戳所有记忆都带时间新的优先旧的降级。九、本篇小结Agent 记忆分三层短期记忆上下文、长期记忆用户历史、向量记忆知识库短期记忆对话上下文快但容量有限优化用滑动窗口和摘要长期记忆跨会话的用户历史和画像用数据库存检索相关的使用向量记忆知识库 RAG文档向量化语义检索所有用户共享记忆读写回答前检索相关记忆回答后更新记忆常见问题上下文溢出、记忆过时、记忆冲突、幻觉放大、隐私设计原则从简到繁、相关优先、可管理、重要信息放系统提示词下一篇讲规划能力Agent 怎么把大任务拆成小步骤、多步推理怎么做、常见的规划方法。我是黒漂技术佬。