智能体学习13——记忆管理（Memory Management）

文章目录第8章：记忆管理（Memory Management）一、核心概念：为什么智能体需要记忆？二、六种应用场景三、ADK 记忆架构：三大核心组件四、源码解构：Session 管理4.1 SessionService 三种实现4.2 消息处理的完整循环五、源码解构：State 管理5.1 State 的三种前缀5.2 方式一：output_key（简单方式）5.3 方式二：state_delta（标准方式）5.4 ⚠️ 反模式：不要直接修改 state六、源码解构：MemoryService 长期记忆6.1 MemoryService 两种实现6.2 长期记忆的工作流程七、源码解构：LangChain 记忆管理7.1 ChatMessageHistory（手动管理）7.2 ConversationBufferMemory（自动集成）7.3 LangGraph 长期记忆（BaseStore）7.4 三种长期记忆类型八、框架对比总结九、关键要点十、与前几章的联系第8章：记忆管理（Memory Management）来源：《智能体设计模式：智能系统构建实战指南》学习日期：2026-04-07一、核心概念：为什么智能体需要记忆？一句话：没有记忆的智能体就是无状态的问答机器，无法保持上下文、学习经验或个性化响应。打个比方：无记忆智能体：像一个每天失忆的员工，每次对话都从零开始有记忆智能体：像一个经验丰富的助手，记得你的偏好、历史对话和任务进度记忆的两大分类：类型类比存储位置生命周期容量短期记忆工作记忆LLM 上下文窗口单次会话内有限（受窗口限制）长期记忆长期知识库外部存储（向量数据库等）跨会话持久理论无限短期记忆的局限：上下文窗口容量有限，只能保留最近的信息长上下文模型（如 Gemini 2M）只是扩大了容量，本质仍是临时的每次处理全部上下文内容成本高、效率低会话结束后信息丢失长期记忆的实现：信息转换为数值向量存储通过语义搜索检索（而非关键词匹配）检索结果整合到短期上下文中，实现知识融合二、六种应用场景场景短期记忆用途长期记忆用途聊天机器人保持对话连贯性回忆用户偏好和历史问题任务型智能体跟踪前序步骤和当前进度访问不在当前上下文中的用户数据个性化体验当前交互的即时调整存储用户偏好、历史行为学习与提升当前任务的即时反馈保存成功策略、错误和新知识信息检索（RAG）当前查询上下文知识库中的文档和数据自主系统即时环境感知地图、路线、通用环境知识三、ADK 记忆架构：三大核心组件ADK 通过三个核心概念管理记忆：┌─────────────────────────────────────────────┐ │ Memory（记忆） │ │ 可检索的信息仓库（跨会话） │ │ 管理：MemoryService │ ├─────────────────────────────────────────────┤ │ Session（会话） │ │ 单个聊天线程 │ │ 包含：events + state │ │ 管理：SessionService │ ├─────────────────────────────────────────────┤ │ State（临时数据） │ │ 会话内的动态数据字典 │ │ 前缀：user: / app: / temp: │ └─────────────────────────────────────────────┘四、源码解构：Session 管理4.1 SessionService 三种实现# 1. 内存存储（测试用，不持久化）fromgoogle.adk.sessionsimportInMemorySessionService session_service=InMemorySessionService()# 2. 数据库存储（生产环境，可靠持久化）fromgoogle.adk.sessionsimportDatabaseSessionService db_url="sqlite:///./my_agent_data.db"session_service=DatabaseSessionService(db_url=db_url)# 3. Vertex AI 云端（大规模生产部署）fromgoogle.adk.sessionsimportVertexAiSessionService session_service=VertexAiSessionService(project="your-gcp-project-id",location="us-central1")源码解读：SessionService是会话生命周期管理器，负责创建、恢复、记录、终止会话三种实现的区别在于持久化能力：内存 → SQLite → GCP 云端选择依据：测试用内存，生产用数据库或云端4.2 消息处理的完整循环收到消息 → Runner 通过 SessionService 获取/创建 Session → 智能体利用 Session 的上下文（state + events）处理消息 → 生成响应，可能更新 state → Runner 封装为 Event → session_service.append_event() 记录事件并更新 state → Session 等待下一条消息关键理解：每次消息交换都是一个完整的"读取-处理-写入"循环，append_event是唯一的官方状态更新入口。五、源码解构：State 管理5.1 State 的三种前缀前缀作用域生命周期示例无前缀当前会话会话结束后丢失{"task_status": "active"}user:用户级跨会话共享"user:login_count"app:应用级所有用户共享"app:global_config"temp:本轮处理不持久化"temp:validation_needed"5.2 方式一：output_key（简单方式）fromgoogle.adk.agentsimportLlmAgentfromgoogle.adk.sessionsimportInMemorySessionServicefromgoogle.adk.runnersimportRunnerfromgoogle.genai.typesimportContent,Part greeting_agent=LlmAgent(name=