第27章 Agent记忆系统：短期记忆、长期记忆、向量记忆

27.1 为什么Agent需要记忆？

大模型本身是"无状态"的——每次调用都是独立的，它不记得之前说过什么、做过什么。如果没有记忆系统，Agent每次对话都像"失忆"一样，无法积累经验、无法记住用户偏好、无法完成需要多步的复杂任务。

没有记忆的Agent会遇到这些问题：

• 重复询问：每次对话都要重新问用户姓名、偏好、历史信息，用户体验极差
• 无法完成长任务：任务执行到一半，之前的中间结果就丢了，无法继续
• 无法学习进步：每次犯同样的错误，无法从历史经验中学习和改进
• 个性化不足：无法根据用户的历史行为和偏好提供个性化服务
• 上下文限制：大模型的上下文窗口有限（如GPT-4o是128K token），超长对话或大量历史数据无法全部放入

记忆系统的核心目标：让Agent能够"记住"重要信息，在需要时快速检索，在适当时机更新和遗忘，从而实现个性化、连续性、学习能力。

27.2 记忆系统的三层架构

借鉴人类记忆的分类（感觉记忆、短期记忆、长期记忆），Agent的记忆系统通常分为三层：

这三层记忆不是孤立的，而是协同工作的：

1. 写入：当前对话和任务状态存在短期记忆（上下文窗口）中；重要信息（用户偏好、任务结果）被提取出来，写入长期记忆；需要语义检索的信息同时向量化，存入向量记忆
2. 检索：当需要历史信息时，先从短期记忆中找（最近的对话）；如果短期记忆中没有，通过向量记忆语义检索找到相关的长期记忆；把检索到的记忆放入短期记忆（上下文窗口），供大模型使用
3. 更新：用户偏好变化时，更新长期记忆中的对应记录；任务完成后，更新任务状态和结果
4. 遗忘：过期的、错误的、不重要的记忆被清理或降权，避免记忆膨胀和干扰

27.3 短期记忆（Working Memory）

短期记忆是当前会话中保存在大模型上下文窗口中的信息，包括对话历史、工具调用记录、中间结果、当前任务状态。

27.3.1 短期记忆的内容

• 系统Prompt：Agent的角色定义、能力边界、行为规则（始终在上下文最前面）
• 对话历史：用户的每一条输入和Agent的每一条回复，按时间顺序排列
• 工具调用记录：调用了什么工具、参数是什么、返回结果是什么
• 中间结果：任务执行过程中产生的临时数据、分析结论、待确认信息
• 当前任务状态：任务目标、已完成步骤、待办步骤、当前关注点

27.3.2 短期记忆的挑战：上下文窗口限制

大模型的上下文窗口是有限的（GPT-4o是128K token，约9万字；Claude 3 Opus是200K token；一些开源模型只有4K-32K）。当对话越来越长、工具调用越来越多，短期记忆会超出窗口限制，导致：

• 早期的对话历史被"截断"，大模型忘记了之前说过什么
• 重要的中间结果丢失，任务无法继续
• 大模型"幻觉"，编造不存在的信息来填补空白
• 响应变慢，成本增加（token越多，调用越慢越贵）

27.3.3 短期记忆管理策略

策略1：滑动窗口（Sliding Window）
只保留最近的N轮对话，更早的对话直接丢弃。
优点：简单直接，实现容易。
缺点：可能丢失重要的早期信息（如用户的核心需求、之前确认的关键参数）。
适用：简单的闲聊场景，对历史信息依赖不高。

策略2：摘要压缩（Summary Compression）
当对话历史超过阈值时，把早期的对话历史让大模型生成摘要，用摘要代替原始对话。
例如：原始对话有50轮，超过了窗口限制。让大模型把前40轮生成一段500字的摘要，保留最近10轮的原始对话。上下文变成：[摘要] + [最近10轮原始对话]。
优点：保留了关键信息，节省了大量token。
缺点：摘要可能丢失细节；摘要本身需要一次大模型调用，增加延迟和成本。
适用：长对话、复杂任务，需要保留历史关键信息。

策略3：重要信息提取（Key Information Extraction）
在对话过程中，实时提取重要信息（用户偏好、关键参数、任务结论），保存为结构化的"记忆卡片"，放入上下文。
例如：用户说"我叫张三，在北京，喜欢用经济舱"，提取为结构化信息：{"姓名":"张三","城市":"北京","舱位偏好":"经济舱"}。
优点：结构化信息占用token少，大模型容易理解和使用。
缺点：需要设计提取规则，可能遗漏重要信息。
适用：用户画像、偏好管理、任务关键参数记录。

策略4：分层记忆（Hierarchical Memory）
结合以上策略：最近的对话保留原始内容，稍早的对话用摘要，更早的重要信息提取为结构化卡片，需要时从长期记忆中检索。
优点：兼顾完整性和效率，是最常用的生产级方案。
缺点：实现复杂，需要精心设计各层的阈值和策略。
适用：生产级Agent应用，长任务、多轮对话。

27.3.4 短期记忆的最佳实践

• 系统Prompt放在最前面，确保大模型始终知道自己的角色和规则
• 工具调用结果要精简，只保留关键信息，不要把完整的API返回（可能几万字）都放入上下文
• 中间结果要结构化，用JSON或表格格式，方便大模型理解和后续使用
• 定期检查上下文长度，接近窗口限制时触发压缩或检索
• 重要信息及时写入长期记忆，不要只存在短期记忆中，避免被压缩或截断丢失

27.4 长期记忆（Long-term Memory）

长期记忆是跨会话、跨任务保存的持久化记忆，存储在外部数据库或文件系统中，不会因为会话结束而丢失。

27.4.1 长期记忆的类型

1. 用户画像记忆（User Profile）
关于用户的基本信息和偏好：

• 基本信息：姓名、年龄、性别、职业、所在地、联系方式
• 偏好设置：语言、风格、常用参数、默认选项
• 兴趣标签：关注的话题、行业、产品
• 行为习惯：常用功能、使用频率、操作习惯
• 历史交互：之前问过什么、做过什么、反馈如何

2. 任务记忆（Task Memory）
关于历史任务的记录：

• 任务目标和需求
• 任务执行过程（调用了哪些工具、步骤是什么）
• 任务结果和产出
• 用户反馈和评价
• 任务中遇到的问题和解决方案

3. 知识经验记忆（Knowledge & Experience）
Agent在执行任务过程中积累的知识和经验：

• 从工具返回结果中提取的事实性知识
• 从用户反馈中学到的正确做法
• 从失败案例中总结的经验教训
• 领域专业知识（如行业规则、最佳实践）

4. 实体关系记忆（Entity & Relation）
关于现实世界实体及其关系的结构化记忆：

• 实体：人、公司、产品、地点、事件等
• 关系：A是B的员工、A和B是合作伙伴、A位于B等
• 属性：实体的各种属性（公司的行业、产品的价格等）
• 通常用知识图谱（Knowledge Graph）存储

27.4.2 长期记忆的存储方式

生产级方案通常是混合存储：

• 用户画像、任务记录 → 关系型数据库（结构化、可查询）
• 对话历史、知识文档 → 向量数据库（语义检索）
• 实体关系 → 知识图谱（关联查询）
• 通过用户ID、任务ID等关联起来

27.4.3 长期记忆的写入机制

什么时候写入长期记忆？

• 显式触发：用户明确说"记住我喜欢XXX"、"保存这个结果"时
• 隐式提取：对话过程中自动识别重要信息（用户偏好、关键参数、任务结论），自动写入
• 任务结束时：任务完成后，把任务目标、过程、结果、反馈整理后写入
• 定期同步：定期把短期记忆中的重要信息同步到长期记忆

写入前的处理：

1. 信息提取：从对话和工具结果中提取重要信息，过滤无关内容
2. 结构化：把提取的信息整理成结构化格式（JSON、表格），方便后续查询和使用
3. 去重：检查是否已存在相同或相似的记忆，避免重复
4. 冲突处理：如果新信息和已有记忆冲突（如用户改了偏好），更新旧记忆而不是新增
5. 打标签：给记忆打上分类标签（用户偏好/任务记录/知识经验）、时间戳、来源、置信度

27.4.4 长期记忆的检索机制

什么时候检索长期记忆？

• 用户提到历史信息（"我上次说的那个方案"、"按照我的偏好"）
• 任务需要用户信息（如订机票需要用户的姓名、身份证号）
• 遇到相似的问题或场景，参考历史经验
• 短期记忆中没有相关信息，需要从长期记忆中补充

检索方式：

• 精确匹配：按用户ID、字段名、关键词精确查询（如"查询用户张三的舱位偏好"）
• 语义检索：把查询向量化，在向量数据库中找语义相似的记忆（如"用户之前说过关于出行的偏好"）
• 混合检索：精确匹配+语义检索结合，先按用户ID过滤，再在该用户的记忆中做语义检索
• 时间加权：最近的记忆权重更高，更早的记忆权重更低
• 相关性排序：按和当前查询的语义相似度排序，取Top-K

检索后的处理：

1. 筛选：过滤掉不相关、过期、低置信度的记忆
2. 排序：按相关性、时间、重要性排序
3. 截断：只取Top-N条，避免占用太多上下文
4. 格式化：把记忆整理成大模型容易理解的格式（如"【历史记忆】用户偏好：经济舱；上次任务：2024-10-01预订北京→上海机票"）
5. 注入上下文：把格式化后的记忆放入大模型的上下文窗口（通常在系统Prompt之后、对话历史之前）

27.5 向量记忆（Vector Memory）

向量记忆是把记忆内容转换成向量（Embedding），存储在向量数据库中，通过语义相似度检索的记忆方式。它是长期记忆的"智能检索层"，让Agent能从海量记忆中快速找到语义相关的内容。

27.5.1 向量记忆的工作原理

写入过程：

1. 把记忆内容（文本）通过Embedding模型转换成向量（一组浮点数，如1536维）
2. 向量和原始文本、元数据（用户ID、时间、类型、标签）一起存入向量数据库
3. 向量数据库为向量建立索引，支持快速相似度检索

检索过程：

1. 把查询文本（如"用户之前说过什么关于出行的偏好"）通过同一个Embedding模型转换成向量
2. 在向量数据库中计算查询向量和所有记忆向量的相似度（通常用余弦相似度）
3. 返回相似度最高的Top-K条记忆
4. 把检索到的记忆注入大模型上下文

27.5.2 向量记忆 vs 关键词检索

生产级方案通常是混合检索：关键词检索（精确匹配）+ 向量检索（语义匹配），两种结果融合排序，兼顾精确性和召回率。

27.5.3 向量记忆的关键设计

1. 分块（Chunking）策略
长文本（如完整的对话历史、长文档）不能直接向量化，需要分成合适大小的块（Chunk）：

• 块大小：通常256-1024个token，太小语义不完整，太大检索不精准、占用上下文多
• 重叠（Overlap）：相邻块之间保留10%-20%的重叠，避免语义在边界处被切断
• 分块方式：按段落分、按语义分（用大模型判断语义边界）、按固定大小分
• 元数据：每个块带上原文位置、用户ID、时间、类型等元数据，方便过滤和溯源

2. Embedding模型选择
Embedding模型的质量直接决定向量检索的效果：

• OpenAI text-embedding-3：效果好，多语言支持，1536维，API调用，成本低
• BGE（BAAI）：开源中文效果好，支持本地化部署，1024维
• M3E：开源中文Embedding，适合中文场景
• GTE（阿里巴巴）：开源，多语言效果好
• 选择建议：中文场景优先BGE/M3E，多语言或需要API选OpenAI，数据敏感选开源本地化部署

3. 向量数据库选择

• Milvus：开源、高性能、分布式、适合大规模（亿级向量），生产级首选
• Pinecone：全托管、无需运维、性能好，SaaS服务，成本较高
• Chroma：轻量、简单、适合原型和中小规模，嵌入式部署
• pgvector：PostgreSQL插件，关系型+向量混合查询，适合已有PG的团队
• Weaviate：开源、支持混合检索、内置向量化，功能丰富
• 选择建议：大规模生产选Milvus，快速原型选Chroma，已有PG选pgvector，不想运维选Pinecone

4. 检索优化

• Top-K：返回最相关的K条，通常K=3-10，太少召回不足，太多噪音多、占用上下文
• 相似度阈值：设置最低相似度阈值，低于阈值的结果不返回，避免不相关内容
• 重排序（Reranker）：向量检索返回Top-N后，用更精确的Reranker模型重新排序，取Top-K，提升精准度
• 查询改写：把用户的模糊查询改写成更适合检索的查询（如补充上下文、拆分复杂查询）
• 过滤：按用户ID、时间范围、类型标签先过滤，再在子集中做语义检索，提升精准度和效率

27.6 记忆的更新与遗忘机制

记忆不是只增不减的，需要有更新和遗忘机制，否则记忆会越来越膨胀，旧的、错误的、不重要的记忆会干扰检索效果。

27.6.1 记忆更新

什么时候更新记忆？

• 用户偏好变化（如"我现在喜欢坐商务舱了"）→ 更新用户画像中的偏好字段
• 信息更正（如"上次说的时间不对，应该是下周"）→ 更新任务记录中的时间
• 知识更新（如政策变化、产品版本更新）→ 更新知识经验记忆
• 补充信息（如用户后来补充了更多细节）→ 在原有记忆上补充，而不是新增重复记忆

更新策略：

• 覆盖更新：新信息直接覆盖旧信息（适用于用户偏好等单值字段）
• 版本管理：保留历史版本，标记最新版本（适用于需要追溯的场景，如任务记录）
• 合并更新：新信息和旧信息合并，取并集（适用于多值字段，如用户的兴趣标签）
• 冲突检测：新信息和旧信息冲突时，标记冲突，让用户确认或按时间取最新

27.6.2 记忆遗忘

为什么需要遗忘？

• 记忆膨胀：记忆越来越多，检索变慢、成本增加、噪音增多
• 过时信息：旧的政策、过期的任务、失效的偏好，保留会误导Agent
• 错误信息：之前记错的、用户纠正过的信息，保留会干扰
• 隐私合规：用户要求删除数据、数据保留期限到期，需要删除

遗忘策略：

• 时间衰减：给记忆设置有效期，过期自动降权或删除（如临时任务记忆保留30天）
• 使用频率：长期不被检索的记忆，降低权重或归档（不删除但不参与常规检索）
• 重要性分级：给记忆打重要性标签（高/中/低），低重要性的优先遗忘
• 手动删除：用户可以手动删除特定记忆（"忘掉我说过的XXX"）
• 批量清理：定期清理过期的、错误的、重复的记忆
• 归档而非删除：重要的历史记忆可以归档到冷存储，不参与常规检索，但需要时可以调出

27.6.3 记忆的质量控制

• 置信度：给每条记忆打置信度分（如0.9=用户明确说的，0.5=推断的），低置信度的记忆使用时要谨慎
• 来源追溯：每条记忆记录来源（哪次对话、哪个工具返回、用户明确说的还是推断的），方便验证和纠错
• 去重：写入前检查是否已有相同或高度相似的记忆，避免重复
• 一致性检查：定期检查记忆之间的矛盾（如用户偏好同时记录了"经济舱"和"商务舱"），发现矛盾标记出来
• 用户可查看：让用户能查看Agent记住了自己的哪些信息，可以编辑和删除，提升信任感和可控性

27.7 实战：设计一个用户画像记忆系统

让我们通过一个完整的实战案例，看看如何设计和实现一个用户画像记忆系统。

27.7.1 场景定义

目标：为旅行助手Agent设计用户画像记忆系统，能记住用户的基本信息、出行偏好、历史行程，提供个性化服务。

核心需求：

• 记住用户的基本信息（姓名、身份证号、常用手机号、邮箱）
• 记住用户的出行偏好（舱位等级、座位偏好、酒店星级、饮食禁忌）
• 记录历史行程（去过哪里、什么时候、什么目的）
• 根据用户画像自动填充表单、推荐选项
• 用户可以查看、编辑、删除自己的画像信息

27.7.2 数据结构设计

用户基本信息表（user_profile）：

{
  "user_id": "u_12345",
  "name": "张三",
  "id_number": "310xxxxxxxxxxxx123",  // 加密存储
  "phone": "138xxxx1234",
  "email": "zhangsan@example.com",
  "city": "上海",
  "company": "ABC科技有限公司",
  "created_at": "2024-01-15",
  "updated_at": "2024-10-15"
}

用户偏好表（user_preferences）：

{
  "user_id": "u_12345",
  "flight": {
    "cabin_class": "经济舱",
    "seat_preference": "靠窗",
    "airline_preference": ["东方航空", "南方航空"],
    "departure_time_preference": "上午"
  },
  "hotel": {
    "star_preference": "四星级",
    "brand_preference": ["希尔顿", "万豪"],
    "room_type": "大床房"
  },
  "diet": {
    "restrictions": ["不吃辣"],
    "preferences": ["粤菜", "日料"]
  },
  "updated_at": "2024-10-15",
  "confidence": {
    "cabin_class": 0.95,  // 用户明确说过
    "seat_preference": 0.8  // 从历史行为推断
  }
}

历史行程表（trip_history）：

{
  "user_id": "u_12345",
  "trips": [
    {
      "trip_id": "t_001",
      "destination": "北京",
      "departure_date": "2024-09-10",
      "return_date": "2024-09-12",
      "purpose": "商务出差",
      "flight": "MU5678 经济舱",
      "hotel": "北京希尔顿 大床房",
      "feedback": "酒店位置好，航班时间合适"
    },
    {
      "trip_id": "t_002",
      "destination": "三亚",
      "departure_date": "2024-07-20",
      "return_date": "2024-07-25",
      "purpose": "家庭旅游",
      "feedback": "很好"
    }
  ]
}

27.7.3 记忆写入流程

场景：用户说"帮我订下周三去北京的机票，我叫张三，身份证号310xxx，喜欢坐经济舱靠窗的位置"

步骤1：信息提取
Agent从用户输入中提取关键信息：

• 姓名：张三
• 身份证号：310xxx
• 目的地：北京
• 出发时间：下周三
• 舱位偏好：经济舱
• 座位偏好：靠窗

步骤2：检查已有记忆
查询user_profile和user_preferences表，看是否已有该用户的信息：

• 如果是新用户 → 创建新的用户画像记录
• 如果是老用户 → 检查新信息和已有记忆是否一致

步骤3：写入/更新记忆

• 姓名、身份证号 → 写入user_profile（如果是新信息或有更新）
• 舱位偏好、座位偏好 → 写入user_preferences，置信度设为0.95（用户明确说的）
• 本次行程 → 任务完成后写入trip_history

步骤4：向量化（可选）
把用户偏好、历史行程的文本描述向量化，存入向量数据库，支持语义检索（如"用户之前去北京住过什么酒店"）。

27.7.4 记忆检索流程

场景：用户说"帮我安排下周去北京的出差"

步骤1：识别需要的记忆
Agent判断需要：用户基本信息（订机票需要姓名、身份证号）、出行偏好（舱位、座位）、历史行程（参考之前的安排）。

步骤2：精确检索
按user_id查询user_profile和user_preferences表，获取结构化的用户信息和偏好。

步骤3：语义检索（可选）
如果需要更灵活的信息（如"用户之前去北京的体验"），把查询向量化，在该用户的历史行程向量中检索。

步骤4：注入上下文
把检索到的用户画像信息格式化，注入大模型上下文：

【用户画像】
姓名：张三
身份证号：310xxx
常用手机：138xxxx1234
出发城市：上海

【出行偏好】
舱位：经济舱（置信度0.95）
座位：靠窗（置信度0.8）
常用航空：东方航空、南方航空
酒店偏好：四星级、希尔顿/万豪、大床房

【历史行程参考】
- 2024-09-10 北京商务出差：MU5678经济舱，北京希尔顿大床房，反馈"酒店位置好"
- 2024-07-20 三亚家庭旅游

步骤5：使用记忆
大模型根据用户画像，自动填充订机票表单（姓名、身份证号、舱位、座位），推荐符合偏好的航班和酒店，参考历史行程给出建议。

27.7.5 记忆管理界面

给用户提供一个"我的记忆"管理界面：

• 查看：用户可以查看Agent记住了自己的哪些信息（基本信息、偏好、历史行程）
• 编辑：用户可以修改不准确的信息（如"我的座位偏好改成靠过道"）
• 删除：用户可以删除特定记忆（"忘掉我之前的历史行程"）或全部记忆（"清除所有关于我的数据"）
• 来源：每条记忆显示来源（"您在2024-10-15的对话中明确说的"），增加透明度
• 置信度：显示每条记忆的置信度，低置信度的标记为"推断，可确认"

27.8 常见问题与优化技巧

问题1：记忆检索不精准，经常返回不相关的内容
原因：分块不合理、Embedding模型不适合、检索参数不对、缺少过滤。
解决：

• 优化分块策略，调整块大小和重叠
• 换更适合的Embedding模型（中文场景用BGE/M3E）
• 调整Top-K和相似度阈值
• 增加过滤条件（按用户ID、时间、类型过滤）
• 加入Reranker重排序，提升精准度
• 做查询改写，把模糊查询改写成更适合检索的查询

问题2：记忆太多，检索慢、成本高
原因：记忆无限制增长，没有遗忘和归档机制。
解决：

• 实现遗忘机制，过期的、不重要的记忆降权或归档
• 冷热分离，热记忆（最近3个月）在高性能存储，冷记忆归档到低成本存储
• 按用户分区，每个用户的记忆独立存储和检索
• 向量数据库用分布式部署，水平扩展
• 缓存常用检索结果，减少重复计算

问题3：记忆冲突，Agent记住了矛盾的信息
原因：用户偏好变化了，但旧记忆没有更新；不同来源的信息矛盾。
解决：

• 写入时做冲突检测，发现矛盾标记出来
• 按时间取最新，新信息覆盖旧信息
• 让用户确认冲突的信息（"您之前说喜欢经济舱，现在说商务舱，以哪个为准？"）
• 版本管理，保留历史版本，标记当前生效版本
• 定期做一致性检查，发现并清理矛盾记忆

问题4：用户担心隐私，不愿意让Agent记住信息
原因：用户不知道Agent记住了什么、怎么用、能不能删除。
解决：

• 透明化：明确告诉用户会记住什么、用来做什么
• 可控性：提供记忆管理界面，用户可以查看、编辑、删除
• 最小化：只记住完成任务必需的信息，不收集无关信息
• 安全存储：敏感信息（身份证号、手机号）加密存储，访问有权限控制
• 合规：遵守数据保护法规（如个人信息保护法），用户有权删除数据
• 默认设置：默认只记住当前会话，跨会话记忆需要用户明确授权

问题5：短期记忆超出上下文窗口，重要信息丢失
原因：对话太长、工具返回结果太多、没有记忆管理策略。
解决：

• 实现滑动窗口，只保留最近N轮对话
• 实现摘要压缩，早期对话用摘要代替
• 重要信息及时提取为结构化记忆卡片，放入上下文
• 工具返回结果精简，只保留关键信息
• 需要历史信息时从长期记忆检索，而不是全部放在上下文
• 选择更大上下文窗口的模型（如Claude 3 Opus 200K）

27.9 产品经理视角：记忆系统的设计注意事项

1. 记忆不是越多越好，要精准、有用
很多产品经理以为记忆越多越智能，其实不然。无用的、错误的、过时的记忆会干扰检索效果，降低Agent的准确性。记忆系统的核心是"记住该记住的，忘掉该忘掉的"，而不是无差别地记住一切。

2. 记忆要透明、可控，用户信任是前提
用户对Agent记住自己的信息天然有顾虑。产品设计必须让记忆透明化（用户知道记住了什么）、可控化（用户可以编辑和删除）、安全化（敏感信息加密、不滥用）。没有用户信任，记忆系统再强大也没用。

3. 区分"明确记住"和"推断记住"，置信度很重要
用户明确说的信息（"我喜欢经济舱"）和Agent从行为推断的信息（"用户经常买经济舱，推断喜欢经济舱"）可信度不同。产品设计要区分这两种记忆，给推断记忆打置信度标签，使用时要谨慎，必要时向用户确认。

4. 记忆系统要有纠错机制，允许用户纠正
Agent一定会记错信息（理解错、推断错、过时了）。产品设计必须有便捷的纠错机制：用户可以说"不对，我是XXX"、"忘掉那个"，Agent能立即纠正。如果用户发现记错了却没法改，会失去信任。

5. 记忆的价值在于"用起来"，而不是"存起来"
很多系统存了大量用户数据，但Agent在对话时根本不会用，等于白存。记忆系统的设计要确保：在合适的时机检索到合适的记忆，注入上下文，真正影响Agent的行为。记忆的价值体现在个性化服务、减少重复询问、提升任务效率，而不是数据库里存了多少数据。

6. 从简单开始，逐步迭代
记忆系统可以很复杂（三层架构、向量检索、知识图谱、遗忘机制），但不要一开始就做全套。建议从最简单的开始：

• 第一阶段：当前会话的短期记忆（对话历史），能完成多轮对话即可
• 第二阶段：用户基本信息和偏好的长期记忆（结构化存储），能记住用户是谁、喜欢什么
• 第三阶段：向量记忆和语义检索，能从历史对话和文档中找到相关信息
• 第四阶段：记忆更新、遗忘、质量控制等高级机制

7. 评估记忆系统的效果
记忆系统好不好，要用数据说话：

• 记忆准确率：Agent记住的信息中有多少是正确的
• 检索命中率：需要记忆时，有多少次能检索到相关记忆
• 重复询问率：Agent重复询问用户已经提供过的信息的比例（越低越好）
• 用户满意度：用户对个性化服务的满意度评分
• 任务完成率：有记忆辅助 vs 无记忆辅助的任务完成率对比
• 记忆使用率：检索到的记忆中有多少被Agent实际使用了

27.10 本章小结

记忆系统是Agent的核心能力之一，让Agent从"每次失忆"变成"能记住、能学习、能个性化"。

三层记忆架构：

• 短期记忆：当前会话的上下文窗口，存对话历史、工具记录、中间结果，受窗口限制，需要滑动窗口、摘要压缩等管理策略
• 长期记忆：跨会话的持久化存储，存用户画像、任务记录、知识经验，用关系型/文档数据库，有写入、检索、更新机制
• 向量记忆：语义检索层，把记忆向量化存入向量数据库，通过语义相似度检索，是长期记忆的智能检索层

关键机制：

• 写入：显式触发+隐式提取，写入前做信息提取、结构化、去重、冲突处理、打标签
• 检索：精确匹配+语义检索+混合检索，检索后做筛选、排序、截断、格式化、注入上下��
• 更新：覆盖更新、版本管理、合并更新、冲突检测，确保记忆及时准确
• 遗忘：时间衰减、使用频率、重要性分级、手动删除、批量清理、归档，避免记忆膨胀
• 质量控制：置信度、来源追溯、去重、一致性检查、用户可查看编辑

产品经理视角：记忆不是越多越好，要精准有用；要透明可控，用户信任是前提；区分明确记住和推断记住；要有纠错机制；记忆的价值在于用起来；从简单开始逐步迭代；用数据评估效果。

记忆系统是Agent个性化和连续性的基础，掌握它的设计原理和最佳实践，是AI产品经理设计智能Agent产品的核心技能。下一章我们会讲多Agent协作——当一个Agent不够用时，怎么让多个Agent分工配合。

📝 本章练习（5题）

答案与解析请在 互动学习看板 中作答查看。

📚 AI产品经理实战训练营 课程目录（44 章）

1. 第1章 AI产品经理是做什么的？和传统PM有什么区别？
2. 第2章 2026年AI产品经理就业市场：哪些行业在招？薪资多少？
3. 第3章 零经验转行AI产品经理的3条路径
4. 第4章 AI产品全景图：从聊天机器人到Agent，一文搞懂
5. 第5章 AI产品经理能力模型：你需要掌握哪些技能？
6. 第6章 实战：拆解3个你每天在用的AI产品
7. 第7章 大模型是什么？用大白话讲清楚
8. 第8章 主流大模型对比：GPT-4o、Claude、DeepSeek、豆包、Kimi怎么选？
9. 第9章 Prompt入门：写好提示词的5个原则
10. 第10章 Prompt进阶：System Prompt、COT思维链、Few-shot示例
11. 第11章 结构化输出：让大模型返回JSON、表格、代码
12. 第12章 Prompt优化实战：从垃圾Prompt到高质量Prompt
13. 第13章 大模型的"幻觉"问题：产品经理怎么应对？
14. 第14章 实战：为一个智能客服设计完整Prompt体系
15. 第15章 RAG是什么？为什么企业都在做知识库？
16. 第16章 RAG工作原理：文档→分块→向量→检索→生成
17. 第17章 向量数据库选型：Milvus、Pinecone、Chroma、pgvector怎么选？
18. 第18章 Embedding模型选型：OpenAI、BGE、M3E、GTE对比
19. 第19章 Reranker重排序：让检索结果更精准
20. 第20章 查询改写与混合检索：提升召回率的实战技巧
21. 第21章 知识库运营：文档治理、更新机制、效果监控
22. 第22章 实战：从零搭建一个企业知识库（完整流程）
23. 第23章 Agent是什么？和聊天机器人有什么区别？
24. 第24章 Agent核心能力：感知、规划、工具调用、记忆
25. 第25章 主流Agent框架与协议：Agent Harness、MCP、A2A全解析
26. 第26章 工具调用（Function Calling）原理与实战
27. 第27章 Agent记忆系统：短期记忆、长期记忆、向量记忆
28. 第28章 多Agent协作：多个智能体怎么分工配合？
29. 第29章 Agent评估体系：成功率、成本、延迟怎么监控？
30. 第30章 实战：设计一个制造业生产异常处理Agent
31. 第31章 AI产品需求分析：怎么识别真需求还是伪需求？
32. 第32章 AI产品竞品分析：怎么调研和拆解竞品？
33. 第33章 AI产品PRD撰写：技术可行性、数据需求、评估指标
34. 第34章 AI产品原型设计：对话流、状态机、异常处理
35. 第35章 AI产品数据指标体系：从DAU到模型准确率，全面监控
36. 第36章 AI项目管理：从需求到上线的全流程管控
37. 第37章 实战项目1：从零搭建制造业AI智能质检系统
38. 第38章 实战项目2：从零搭建企业级AI知识库（RAG系统）
39. 第39章 AI产品经理简历优化：让HR一眼看中你
40. 第40章 项目经验包装：把普通项目讲成亮眼案例
41. 第41章 AI产品经理面试常见问题：提前准备，从容应对
42. 第42章 案例分析面试：用结构化思维征服面试官
43. 第43章 薪资谈判：拿到你应得的报酬
44. 第44章 入职前3个月：快速站稳脚跟，建立信任