> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](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).

# 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-5：智能体记忆层次

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

## 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 周转向重视架构文档，目前优先级：架构 > 速度"
```

**真实案例**：OpenAI 公开的 [Dreaming 记忆系统](https://openai.com/index/chatgpt-memory-dreaming/) 即是这一模式的产品级实现——用后台进程从历史会话中自动综合记忆，并随时间修订（例如行程结束后，把“将去新加坡”改写为“已于 2026 年 7 月去过新加坡”）。它从依赖显式的“保存的记忆”演进到后台自动综合，正对应本节 §9.4.3 的显式记忆 → 隐式记忆；完整出处见附录 D。

这类系统的关键不只是“记住更多”，而是把长期记忆质量拆成三个可评估目标：能把有用背景带到后续对话中，能持续遵循用户偏好与约束，能随时间更新过期事实。OpenAI 的公开说明还强调，后台综合出的记忆应通过可见摘要让用户审阅、补充、纠正或限制使用范围。换言之，长期记忆不应成为不可见黑箱；它需要可回看、可改写、可撤销，才能在个性化和用户控制之间取得平衡。

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

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

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

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

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

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

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

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