# 9.4 智能体记忆与学习

## 9.4.0 状态（State）与记忆（Memory）的语义区分

在智能体工程实践中，需要清晰区分 **状态** 和 **记忆** 两个概念，尽管它们都涉及信息存储：

**状态（State）**

状态是工作流执行的可持久化进度记录。它包括：

* 当前执行步骤的输出（Step Outputs）
* 工作流的完成进度
* 中间计算结果与检查点（Checkpoints）
* 可被重放（Replay）和调试的执行轨迹

状态是 **面向计算过程** 的，主要目的是：

1. **可靠性**：在中断后能从检查点恢复，而不需要重新计算前面的步骤
2. **可观测性**：记录“系统做了什么”，便于调试和审计
3. **可重放性**：完整的输入和输出序列可以被重新执行，用于验证和测试

实现方式（如 OpenAI Responses、Azure State Persistence）通常将状态存储在专用的状态管理系统中，支持版本控制和原子性操作。

**记忆（Memory）**

记忆是为智能体学习和决策而保留的、经过精心整理的长期或短期的人类可理解的信息。包括：

* 用户偏好和背景知识
* 解决问题的经验教训
* 领域特定知识
* 对话摘要与关键决策点

记忆是 **面向推理和个性化** 的，主要目的是：

1. **个性化**：根据用户或领域的特征调整行为
2. **学习**：从过往经验中提取可复用的知识
3. **上下文连续性**：跨会话保持对话和交互的连贯性

实现方式（如 Vertex Agent Engine Sessions vs Memory Bank）将记忆存储在语义数据库或向量库中，支持检索和更新。

**两者在智能体中的配合**

状态保证了工作流的 **容错与可恢复性**，是工程健壮性的基础；记忆支撑了智能体的 **进化与个性化**，是智能体质量提升的动力。现代智能体平台（如 Azure Durable Functions 配合 Agent Memory）同时维护两个系统：状态管理器追踪执行进度，记忆管理器积累可复用知识。

## 9.4.1 智能体记忆的层次

智能体需要多层次的记忆系统：

```mermaid
graph TB
    subgraph "记忆层次"
        A["即时记忆"]
        B["会话记忆"]
        C["持久记忆"]
    end

    A --> |"压缩"| B
    B --> |"提炼"| C
```

图 9-6：智能体记忆层次

* **即时记忆**：当前任务的工作记忆，对应上下文窗口中的即时信息
* **会话记忆**：单次会话的完整历史，可压缩后保留要点
* **持久记忆**：跨会话保留的长期知识，存储在外部数据库中

## 9.4.2 记忆与状态信息类型

| 类型   | 示例            | 存储位置       |
| ---- | ------------- | ---------- |
| 事实   | 用户偏好、配置       | 持久记忆       |
| 经验   | 成功/失败的操作      | 持久记忆       |
| 技能   | 学到的解决方案       | 持久记忆       |
| 执行状态 | 当前任务进度、待恢复检查点 | 会话状态或检查点存储 |
| 细节   | 操作的具体参数       | 即时记忆       |

## 9.4.3 记忆更新机制

### 显式记忆

用户明确要求记住：

```
用户：请记住我喜欢简洁的回答风格
智能体：好的，我已记录您的偏好。
```

### 隐式记忆

从交互中自动学习：

```python
def analyze_interaction(history):
    patterns = extract_patterns(history)
    preferences = infer_preferences(history)
    corrections = find_corrections(history)

    update_memory(patterns, preferences, corrections)
```

### 反思记忆模式

反思是将短期经历转化为长期乃至“智慧”的关键。基于 **Reflexion** 框架的自我改进循环：

1. **Actor (执行者)**：尝试执行任务，生成轨迹。
2. **Evaluator (评估者)**：评估执行结果的质量（如测试通过率、准确性）。
3. **Self-Reflection (反思者)**：分析失败原因，生成“自我反思”，总结教训。
4. **Memory (记忆)**：将反思结果存入长期记忆。

**示例循环**：

```
--- 第一次尝试 ---
Actor: 尝试使用 requests 库抓取网页。
Evaluator: 失败，返回 403 Forbidden。
Self-Reflection: 目标网站有反爬策略，需要设置 User-Agent。

--- 第二次尝试 ---
Actor: (检索到上次的反思) 设置 User-Agent 伪装成浏览器重试。
Evaluator: 成功。
Memory Update: "抓取该网站时必须设置 User-Agent 头" -> 存入知识库。
```

这种机制让智能体不再重犯相同的错误。

## 9.4.4 从经验中学习

智能体可以从历史经验中学习：

### 成功经验复用

```
过去经验：处理类似问题时，方法 A 比方法 B 更有效

当前任务：遇到类似问题
决策：优先尝试方法 A
```

### 失败经验规避

```
过去经验：直接调用 API_X 会超时

当前任务：需要调用 API_X
决策：先检查连接状态，设置较长超时，或使用备用方案
```

## 9.4.5 知识积累

### 领域知识

随着使用积累领域知识：

```
初始：通用助手
↓ 多次医疗咨询后
积累：常见症状、推荐检查、就医建议
```

### 用户知识

了解特定用户：

```
用户画像：
- 技术背景：高级
- 沟通风格：喜欢详细解释
- 常见需求：代码审查、架构设计
```

## 9.4.6 记忆检索

在适当时机检索相关记忆：

```python
def retrieve_relevant_memory(current_context):
    # 1. 多路召回
    semantic_results = vector_search(current_context)  # 语义匹配
    keyword_results = keyword_search(current_context)  # 关键词匹配
    time_results = get_recent_ad_hoc(current_context)  # 时间相关

    # 2. 混合排序 (Retrieval Fusion)
    return reciprocal_rank_fusion([semantic_results, keyword_results, time_results])
```

**混合检索的核心：RRF (Reciprocal Rank Fusion)**

单一的检索方式往往有盲点（如向量搜索对专有名词不敏感），RRF 是一种无需训练的鲁棒排序算法，用于融合多个检索结果。

**算法原理**： 对于每一项文档 $d$，计算其融合得分： $$\text{Score}(d) = \sum\_{r \in R} \frac{1}{k + \text{rank}(r, d)}$$

* $R$：不同的检索器集合（如语义、关键词、时间）。
* $rank(r, d)$：文档 $d$ 在检索器 $r$ 结果中的排名（1, 2, 3...）。
* $k$：平滑常数（通常取 60），用于防止高排名文档主导分数。

**优势**：

* **零样本**：不需要任何训练数据，直接利用排名信息。
* **鲁棒性**：即使某个检索源效果很差，只要其他源可靠，最终结果依然准确。
* **公平性**：平衡了不同检索源的得分尺度差异。

## 9.4.7 记忆管理挑战

* **容量管理**：记忆不能无限增长，需按重要性排序、定期清理过时信息、压缩低频信息
* **一致性维护**：记忆可能过时或矛盾，需要版本追踪、冲突检测、定期验证
* **隐私保护**：敏感信息需要保护，包括访问控制、数据加密、保留策略

## 9.4.8 全时异步主动调度

传统的智能体记忆检索往往是“被动阻断式”的：接收用户指令 -> 检索关联记忆 -> 组合上下文 -> LLM 生成。这会导致明显的延迟，特别是当需要跨多个会话、多个 Agent 去检索深层记忆时，首 Token 时延经常无法满足实时业务要求。

前沿的智能体记忆架构（如 MemOS 提出的 Memory Cube）引入了 **全时异步主动调度** 的核心机制：

1. **碎片时间利用**：将用户阅读答案、思考、输入（打字）的每一秒“空档时间”充分利用起来。
2. **主动行为预测**：系统在后台部署轻量级意图预测模型，预判 Agent 下一步可能需要的领域知识与偏好。
3. **状态“就绪（Ready）”**：在用户的查询真正触发前，系统已在后台并行地将各类记忆（文档、会话、偏好）抽取、组合并预热加载到高速缓存中。当 Prompt 最终到达时，所需的增强上下文便已如构建好的“魔方（Cube）”般瞬间就位，仅需几毫秒即可完成轻量读取。

这种将“单轮串行检索”拆解分解为“多轮全时异步预读”的调度架构，将是未来高性能 Agent 系统的标准动力引擎。

## 9.4.9 跨会话记忆持久化

对于需要跨越多个会话的长期任务，记忆持久化是关键。Claude Code 等生产级系统采用的最佳实践包括：

### MEMORY.md 索引文件

维护一个结构化的 `MEMORY.md` 文件作为跨会话记忆的入口：

**容量与结构**：

* **大小限制**：最多 200 行或 25KB，确保可快速加载
* **每条记忆**：约 150 字符，包含标签和简要描述
* **四种记忆类型**：
  * **项目模式**（Project Patterns）：架构决策、代码风格、模块依赖关系
  * **用户偏好**（User Preferences）：代码格式、沟通风格、优先级偏好
  * **工具配置**（Tool Configs）：常用命令别名、环境变量名、密钥名称、权限范围和配置位置
  * **领域知识**（Domain Knowledge）：业务规则、技术约束、常见陷阱

记忆文件不得保存真实 secret、token、密码、Cookie、登录状态、生产连接串或个人敏感信息。需要记录凭据依赖时，只记录占位变量名、用途、权限范围和批准的配置位置。

**加载策略**：新会话启动时，系统首先加载 MEMORY.md，使用其内容增强初始上下文。由于体积小，加载时间 < 100ms，不会影响 TTFT。

### 记忆“做梦”（Dreaming）机制

当跨越多个会话进行长期项目时，智能体定期执行“做梦”操作来清理和整合记忆：

**执行时机**：

* 项目完成时
* 每次大型功能交付后
* 当 MEMORY.md 接近容量上限时

**处理流程**：

1. **回顾**（Review）：扫描过去会话的日志，识别对当前项目的影响
2. **合并**（Merge）：当发现相同主题的多条旧记忆时，合并它们
3. **去重**（Deduplicate）：消除矛盾的记忆，保留最新信息
4. **时间归一化**：将相对日期（“上周”）转换为绝对日期（“2026-04-15”），便于长期追踪

**示例**：

```
旧记忆 A（第 1 周）："用户倾向快速迭代，不需要长文档"
旧记忆 B（第 3 周）："用户要求详细的架构文档"
做梦结果：合并为"第 1 周偏好快速迭代，第 3 周转向重视架构文档，目前优先级：架构 > 速度"
```

## 9.4.10 记忆与上下文的协作

记忆系统与上下文工程密切配合：

**1. 记忆提供长期信息**

将持久记忆检索到当前上下文。这是最基础的协作模式。当用户提问涉及到之前的会话或特定知识时，系统从记忆模块中检索相关内容，并将其注入到当前的 Prompt 上下文中。这解决了 LLM 固有上下文窗口有限和无记忆的问题。

**2. 上下文产生新记忆**

从当前交互中提取值得记忆的内容。在对话过程中，上下文窗口中不断产生新的信息。系统需要实时或定期分析上下文，提取出有价值的信息（如用户偏好、新事实、关键决策），并将其写入到记忆模块中。这是智能体不断学习和进化的基础。

**3. 记忆优化上下文**

了解用户后可以简化上下文。随着对用户记忆的加深，智能体可以更精准地理解用户意图，从而不需要在上下文中反复包含冗长的说明或背景信息。例如，如果记忆中已经知道用户是 Python 专家，上下文中的代码解释就可以更加精简，节省 Token 并提升沟通效率。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/context_engineering_guide/di-san-bu-fen-jin-jie-ji-shu-yu-jia-gou/09_agents/9.4_agent_memory.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.