04｜Memory 系统：让 Agent 拥有持久记忆

专栏定位：OpenClaw 从入门到精通（第 04 章）
适读人群：开发者、技术爱好者、AI应用创业者

摘要

你有没有遇到过这样的情况：一个 AI 助手每次对话都像重新认识你一样，完全不记得上次聊了什么。OpenClaw 的 Memory 系统就是为了解决这个问题。本章我们将深入探讨 OpenClaw 的三层记忆架构——对话历史、每日笔记（memory/YYYY-MM-DD.md）和长期记忆（MEMORY.md），了解它们各自的工作原理和使用场景，以及如何配置语义搜索让 Agent「想起」相关的旧记忆。更重要的是，我们会讨论如何避免记忆泄漏和隐私问题，确保敏感信息不被泄露到错误的上下文中。

SEO 摘要

OpenClaw Memory 系统详解：MEMORY.md 长期记忆机制、每日笔记 memory/YYYY-MM-DD.md、三层记忆架构、语义搜索配置、记忆写入时机与最佳实践、隐私保护与记忆泄漏防护。

目录

• 为什么 AI 需要记忆系统
• 三层记忆架构概述
• 短期记忆：对话历史
• 中期记忆：每日笔记（memory/YYYY-MM-DD.md）
• 长期记忆：MEMORY.md
• 语义搜索配置与向量嵌入
• 记忆写入时机与最佳实践
• 避免记忆泄漏与隐私保护
• 实战：构建项目知识库
• 常见错误与避坑指南
• 术语注释
• 面试高频问答
• 深度扩展
• 附录
• 系列总结（第 01-04 章）
• 版权声明

开篇

让我们先讲一个故事。

产品经理小张第一次使用某个 AI 助手时，问它：「我们的产品现在有哪些已知问题？」AI 说它不知道。小张花了半小时，把所有已知 Bug 整理成一个文档发给 AI，说「以后你得记得这些」。

一周后，小张问同样的问题。AI 说：「作为一个人工智能，我没有持续的记忆能力……」

小张怒了：「我明明让你记住的！」

这是很多 AI 助手的通病——它们没有真正的记忆系统。用户让它们「记住」的事情，要么根本没存，要么存在一个它们根本不会主动读取的地方。

OpenClaw 的 Memory 系统就是为了解决这个问题而设计的。它不是简单地把对话历史堆在一起，而是构建了一个有层次、有策略、有隐私保护的记忆系统。今天，我们就来深入理解这套系统。

核心知识点

1. 为什么 AI 需要记忆系统

1.1 上下文窗口的有限性

当前的 LLM 都有上下文窗口限制——GPT-4o 是 128K tokens，Claude 3.5 Sonnet 是 200K tokens。听起来很大，但实际使用中很快就会遇到瓶颈：

• 一个中等规模的代码项目（100个文件）可能就有 50 万 tokens
• 一年的工作对话记录可能有几百万 tokens
• 你不能让每次对话都从「宇宙大爆炸」开始

所以，必须有一个记忆系统来决定：哪些信息值得保留？保留在哪里？如何让 Agent 在需要的时候找到它们？

1.2 短期 vs 长期记忆的分工

人类的大脑也有类似的设计：

• 短期记忆：当前正在处理的信息，容量有限（约 7±2 个项目）
• 长期记忆：永久存储的知识，需要通过「巩固」过程才能从短期记忆转入

OpenClaw 的三层记忆架构正是模仿了这个设计：

• 对话历史 = 短期记忆（当前会话内）
• 每日笔记 = 工作日志（中等保留期）
• MEMORY.md = 长期知识库（永久保留的关键信息）

2. 三层记忆架构概述

┌─────────────────────────────────────────────────────────┐
│                    三层记忆架构                           │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ┌─────────────────────────────────────────────────┐   │
│  │ Layer 1: 对话历史 (Conversation History)        │   │
│  │ • 当前会话的所有消息                              │   │
│  │ • 会话结束即清除                                 │   │
│  │ • 容量：受限于上下文窗口（通常是最近几千条）      │   │
│  └─────────────────────────────────────────────────┘   │
│                        ↓                                 │
│  ┌─────────────────────────────────────────────────┐   │
│  │ Layer 2: 每日笔记 (memory/YYYY-MM-DD.md)         │   │
│  │ • 当日工作日志                                  │   │
│  │ • 保留 30 天                                    │   │
│  │ • 按日期检索                                    │   │
│  └─────────────────────────────────────────────────┘   │
│                        ↓                                 │
│  ┌─────────────────────────────────────────────────┐   │
│  │ Layer 3: 长期记忆 (MEMORY.md)                   │   │
│  │ • 提炼后的重要信息                               │   │
│  │ • 永久保留                                      │   │
│  │ • 需要时才加载（不在群聊中加载）                  │   │
│  └─────────────────────────────────────────────────┘   │
│                                                         │
└─────────────────────────────────────────────────────────┘

3. 短期记忆：对话历史

3.1 工作原理

每次与 OpenClaw 对话，所有消息（用户的、Agent 的）都会记录在对话历史 中。这个历史记录：

• 在会话期间会被加载到上下文窗口
• 帮助 Agent 理解当前对话的来龙去脉
• 会话结束后不会主动保留（除非手动保存到 memory）

3.2 对话历史的局限

对话历史示例（Session #20260330-001）：

用户: 帮我看看项目里用户认证的代码
Agent: 好的，我先看一下认证相关的代码...
[Agent 执行了搜索和阅读]

Agent: 找到了用户认证在 src/auth/ 目录下。
主要文件有：
- login.ts: 处理登录逻辑
- token.ts: JWT token 管理
- middleware.ts: 认证中间件

你想先看哪个文件？

用户: 看一下 token.ts
[上下文窗口已经有约 2000 tokens 的历史]

Agent: [继续回答]

...

用户: （第二天）token.ts 的过期时间是多少？
[Agent 无法直接访问昨天的对话历史，除非...)

问题：昨天的会话信息已经不在对话历史中了。

3.3 如何弥补

OpenClaw 通过两个机制来弥补这个问题：

1. 每日笔记写入：在会话结束时，Agent 会把重要信息写入 memory/YYYY-MM-DD.md
2. 长期记忆提炼：把需要长期记住的信息提炼到 MEMORY.md

4. 中期记忆：每日笔记（memory/YYYY-MM-DD.md）

4.1 文件位置与命名

每日笔记存放在 .openclaw/memory/ 目录下，按日期命名：

.openclaw/
├── memory/
│   ├── 2026-03-28.md
│   ├── 2026-03-29.md
│   └── 2026-03-30.md   # 今天

4.2 每日笔记的格式

# Daily Notes - 2026-03-30

## Session 1 (09:00 - 09:45)

### User Request
用户询问项目认证模块的代码结构

### Actions Taken
- Read src/auth/login.ts
- Read src/auth/token.ts
- Read src/auth/middleware.ts
- 回答了用户关于 JWT 过期时间的问题（默认 24 小时）

### Key Findings
- 认证模块使用 JWT，包含 access_token 和 refresh_token
- token 过期时间可以通过环境变量 TOKEN_EXPIRY 调整
- refresh_token 策略：过期后自动续期，最多续期 7 天

### Decisions Made
- 用户同意将 token 过期时间从 24h 改为 12h（更安全）
- 决定下周添加双因素认证

### Follow-ups
- [x] 用户认证代码 review - 完成
- [ ] 双因素认证 - 计划下周
- [ ] 检查 refresh_token 续期逻辑是否有 bug

## Session 2 (14:00 - 14:30)

### User Request
用户询问日报生成 Bot 的 cron 配置

### Actions Taken
- 检查了 HEARTBEAT.md 配置
- 检查了 openclaw cron list
- 回答了关于 cron 表达式的问题

### Key Findings
- 日报 Bot 配置在 cron_1，每天 08:00 执行
- 当前使用 DeepSeek 模型（速度快，成本低）
- 上周五发送失败了，需要检查原因

### Follow-ups
- [ ] 排查上周五日报发送失败的原因
- [ ] 考虑增加失败重试机制

4.3 每日笔记的检索

在每个新会话开始时，OpenClaw 会读取今天和昨天的每日笔记：

## Every Session

...

3. Read `memory/YYYY-MM-DD.md` (today + yesterday) for recent context

这意味着如果今天是 2026-03-31，OpenClaw 会读取：

• memory/2026-03-31.md（今天的笔记，可能刚开始写）
• memory/2026-03-30.md（昨天的完整笔记）

这样，Agent 能快速了解「最近发生了什么」。

4.4 自动清理策略

每日笔记会自动清理旧文件（默认保留 30 天），这是通过 OpenClaw 的维护脚本实现的：

# 在 .openclaw/ 目录下会有一个清理脚本
# 或者通过 cron 任务定期执行

find .openclaw/memory -name "*.md" -mtime +30 -delete

5. 长期记忆：MEMORY.md

5.1 什么时候写入 MEMORY.md

MEMORY.md 不是对话日志，而是提炼后的精华。以下是应该写入 MEMORY.md 的内容类型：

应该写入 MEMORY.md：

• 重要决策及其原因（如「为什么选择 PostgreSQL 而不是 MySQL」）
• 用户偏好和习惯（如「用户喜欢简短回复，邮件不要超过 500 字」）
• 项目关键信息（如「项目的 CI/CD 流程在哪里」）
• 重要联系人（如「技术负责人是张工，有问题找他」）
• 教训和踩坑记录（如「上次误删了生产数据库，再也不直接执行 DELETE」）

不应该写入 MEMORY.md：

• 普通的对话内容（放在每日笔记即可）
• 临时性的信息（如「今天的会议改到了 3 点」）
• 可以轻松重新获取的信息（如「Python 最新的版本号」）

5.2 MEMORY.md 的结构

# MEMORY.md - Long-Term Memory

_This file is read in main sessions only. Do not load in shared/group contexts for privacy._

## User Profile

### Basic Info
- **Name:** 张三
- **Role:** 技术总监
- **Timezone:** Asia/Shanghai
- **Language:** 中文

### Preferences
- 回复要简短精炼，不喜欢废话
- 技术问题喜欢直接给出解决方案，不喜欢绕弯子
- 习惯用飞书沟通，不经常看邮件

### Work Style
- 上午效率高，适合处理复杂技术问题
- 下午开会多，喜欢让 AI 提前准备材料
- 对 AI 的定位：第二大脑，帮他过滤和处理信息

## Project: 公司内部知识库

### Tech Stack
- 前端: Next.js + TypeScript
- 后端: FastAPI + Python
- 数据库: PostgreSQL 15
- 部署: Docker + Kubernetes

### Key People
- 开发负责人: 李四 (lishi@company.com)
- 运维负责人: 王五 (wangwu@company.com)
- 产品经理: 赵六 (zhaoliu@company.com)

### Important Decisions
- 2026-01-15: 决定使用飞书文档替代 Confluence（因为团队更熟悉飞书）
- 2026-02-20: 决定引入 AI 助手辅助代码审查
- 2026-03-01: 决定所有新项目必须包含测试用例

### Known Issues
- 当前搜索功能使用 MySQL FULLTEXT，性能较差，计划 Q2 迁移到 Elasticsearch
- 部分旧文档从 Confluence 迁移过来时有格式丢失

## Lessons Learned

### Don't Do This
- 绝对不要在生产服务器上直接执行 DELETE SQL（上次误删了 3 条数据）
- 不要在用户开会时打断，优先使用异步方式

### Preferences
- 写代码时先问清楚需求，不要急于动手
- 任何重大变更前必须给出至少两个方案对比

## Tools & Access

### Accounts
- GitHub: github.com/zhangsan-company
- 飞书: zhangsan@company.com
- AWS: arn:aws:iam::123456789:user/zhangsan

### API Keys Stored
- (none in MEMORY.md - stored in .env)

## Ongoing Tasks

- [ ] 调研 Elasticsearch 方案 (Q2 目标)
- [ ] 代码审查效率提升 (进行中)
- [ ] 新人培训材料整理 (计划中)

5.3 MEMORY.md 的隐私保护

最重要的规则：MEMORY.md 只在主会话（MAIN SESSION）中加载，不在群聊中加载。

这个规则在 AGENTS.md 中明确声明：

### 🧠 MEMORY.md - Your Long-Term Memory

- **ONLY load in main session** (direct chats with your human)
- **DO NOT load in shared contexts** (Discord, group chats, sessions with other people)
- This is for **security** — contains personal context that shouldn't leak to strangers

这是防止记忆泄漏的关键机制。想象一下，如果你在 MEMORY.md 中记录了「老板叫李总，他的邮箱是…」，然后在飞书群里被 Bot 不小心说出来了——这就是灾难性的隐私泄漏。

6. 语义搜索配置与向量嵌入

6.1 什么是语义搜索

普通的文本搜索是基于关键词匹配的（「搜索『认证』」只会找到包含「认证」这个词的笔记）。语义搜索则是基于含义的（「搜索『登录相关的代码』」会找到包含「登录」「login」「authentication」「token」等相关内容的笔记）。

OpenClaw 支持配置语义搜索，通过向量嵌入（Embedding）技术实现。

6.2 向量嵌入的工作原理

文本 → 向量模型 → 高维向量（一串数字）

"用户认证"      → [0.12, -0.34, 0.78, ...]  (128维度向量)
"登录逻辑"      → [0.11, -0.35, 0.79, ...]  (和"用户认证"相似)
"今天的天气"    → [0.89, 0.12, -0.45, ...]  (和"用户认证"不相似)

当需要搜索时，把查询也转为向量，然后在向量空间中找到最相似的记录。

6.3 OpenClaw 语义搜索配置

# 在 .env 中配置向量嵌入服务
OPENCLAW_EMBEDDING_PROVIDER=openai
OPENCLAW_EMBEDDING_MODEL=text-embedding-3-small
OPENCLAW_EMBEDDING_API_KEY=sk-xxxxxxxxxxxxxxxx

或者使用本地嵌入服务（如 Ollama）：

OPENCLAW_EMBEDDING_PROVIDER=ollama
OPENCLAW_EMBEDDING_MODEL=nomic-embed-text
OPENCLAW_EMBEDDING_URL=http://localhost:11434

6.4 语义搜索的使用

配置完成后，你可以在对话中让 OpenClaw 进行语义搜索：

openclaw chat "你有没有关于认证或者登录的记忆？帮我找一下"

OpenClaw 会：

1. 将查询转换为向量
2. 在每日笔记和 MEMORY.md 中搜索语义相似的内容
3. 返回最相关的结果

7. 记忆写入时机与最佳实践

7.1 什么时候应该写入记忆

主动写入（用户明确要求）：

• 用户说「帮我记住…」
• 用户说「这个信息很重要，以后都要知道」
• 用户纠正了 Agent 的某个行为，说「以后要这样而不是那样」

被动写入（在会话结束时自动提炼）：

• 会话时间超过 30 分钟
• 会话中讨论了重要的技术决策
• 会话中发现了新的 Bug 或问题
• 会话中用户提出了后续需要跟进的任务

7.2 写入记忆的标准流程

会话结束
    ↓
判断：这个会话有什么值得记住的吗？
    ↓ 是 ↓
判断：这个信息应该写入哪个层级？
    ├─→ 当天工作记录 → memory/YYYY-MM-DD.md
    ├─→ 需要长期保留 → MEMORY.md
    └─→ 两者都要
    ↓ 否
结束

7.3 最佳实践：记忆的提炼原则

从具体到抽象：不要记录「用户问了 token.ts 的过期时间」这种具体对话，而要提炼成「token.ts 默认 24 小时过期，可通过 TOKEN_EXPIRY 调整」。

包含上下文：只写「刷新 token 策略有问题」没有用，要写「刷新 token 策略有问题——续期逻辑在 token 过期后立即失效，需在过期前 5 分钟触发续期」。

标记行动项：如果记忆中有未完成的任务，要明确标记：

### Follow-ups
- [ ] Elasticsearch 调研（Q2 目标）
- [ ] 双因素认证实现（下周）

8. 避免记忆泄漏与隐私保护

8.1 记忆泄漏的常见场景

场景 1：群聊中意外引用 MEMORY.md 内容

问题：用户 A 和 Bot 在群聊中，Bot 引用了 MEMORY.md 中关于用户 B 的信息

原因：AGENTS.md 没有正确配置 MEMORY.md 的加载规则

场景 2：跨项目记忆混淆

问题：用户有两个不同客户的项目，Bot 把 A 项目的信息用到了 B 项目中

原因：MEMORY.md 中没有用项目标签区分不同上下文

场景 3：敏感信息写入可被其他会话访问的地方

问题：用户让 Bot 记住了一个密码，Bot 写入了 MEMORY.md，后来在公开场合被泄露

原因：MEMORY.md 是明文存储的，不应该存放真正的敏感信息

8.2 隐私保护配置

规则 1：敏感信息不写入文本文件

## Sensitive Information Rules

- API keys, passwords, tokens → .env only (never in any .md file)
- Personal identifiable information (PII) → minimize, use pseudonyms if possible
- Financial information → never store in text files

规则 2：MEMORY.md 不在群聊中加载

## Memory Loading Rules

### Main Session (1:1 private chat):
- Load MEMORY.md
- Load today's and yesterday's daily notes
- Full context available

### Group Chats:
- NEVER load MEMORY.md
- Only load today's daily notes (if relevant to current discussion)
- Be conservative about what to reference

规则 3：按项目隔离记忆

# MEMORY.md

## Project: Alpha (客户A)

[仅与项目 Alpha 相关的信息]

## Project: Beta (客户B)

[仅与项目 Beta 相关的信息]

[不在项目上下文中的全局信息]

在 AGENTS.md 中指定当前项目：

## Project Context

When user specifies a project, activate that project's memory context:
- Check which project folder we're working in
- Load only the relevant project's section from MEMORY.md
- If no project specified, ask "Which project are you working on?"

8.3 记忆的加密存储（高级）

对于需要额外保护的场景，可以配置 OpenClaw 使用加密存储：

# 在 .env 中启用加密
OPENCLAW_MEMORY_ENCRYPT=true
OPENCLAW_MEMORY_ENCRYPTION_KEY=your-256-bit-key

这样 MEMORY.md 的内容会以加密形式存储，即使文件被访问也无法直接读取。

实战：构建项目知识库

让我们通过一个完整案例来演示如何构建一个项目知识库。

需求

小李是一个全栈工程师，同时参与两个项目：

• 项目 A：公司的内部管理系统（React + Node.js）
• 项目 B：给客户做的电商平台（Next.js + Python）

他希望 OpenClaw 能记住每个项目的上下文，避免每次都要重新解释。

配置方案

第一步：为每个项目创建独立的记忆目录

.openclaw/
├── memory/
│   ├── projects/
│   │   ├── project-a/        # 项目 A 专属笔记
│   │   │   └── memory.md
│   │   └── project-b/        # 项目 B 专属笔记
│   │       └── memory.md
│   └── daily/                # 每日全局笔记
│       └── YYYY-MM-DD.md
├── MEMORY.md                 # 全局长期记忆（用户偏好等）
└── USER.md

第二步：配置项目上下文加载

在 .openclaw/AGENTS.md 中添加：

## Project Memory

When I start a session or when the user mentions a project, I should:

1. Identify which project context is active:
   - Check the current working directory
   - Or ask the user "Which project are you working on?"
   
2. Load the relevant project memory:
   - For Project A: read `.openclaw/memory/projects/project-a/memory.md`
   - For Project B: read `.openclaw/memory/projects/project-b/memory.md`

3. Keep project contexts separate to avoid confusion

## Project Memory Templates

### Project Memory File Structure (memory/projects/[project-name]/memory.md)

```markdown
# [Project Name] - Project Memory

## Project Overview
[1-2 sentence description]

## Tech Stack
[Technology choices and versions]

## Key People
- Tech Lead: [Name] ([email])
- Product Manager: [Name] ([email])

## Architecture Decisions
- [Date]: [Decision] because [reason]

## Current Status
- Phase: [development/staging/production]
- Main concerns: [list]

## Known Issues
- [Issue]: [status/notes]

## Next Steps
- [ ] [Action item]

**第三步：项目记忆文件示例**

`.openclaw/memory/projects/project-a/memory.md`：

```markdown
# 项目 A - 内部管理系统

## 项目概述
公司内部使用的员工管理、审批流程、项目管理平台。

## 技术栈
- 前端: React 18 + TypeScript + Ant Design
- 后端: Node.js 20 + Express + TypeScript
- 数据库: PostgreSQL 15
- 部署: Docker Compose (当前), K8s (Q3 计划)

## 关键人员
- 技术负责人: 张工 (zhang@company.com) - 负责架构决策
- 产品经理: 李经理 (li@company.com) - 需求管理
- 测试负责人: 王测 (wang@company.com) - QA

## 重要决策记录
- 2026-01: 选择 Ant Design 而不是 Material UI（团队更熟悉，社区更大）
- 2026-02: 审批流程从同步改为异步（使用消息队列）
- 2026-03: 决定废弃旧的 REST API，全面转向 GraphQL

## 当前状态
- Phase: 开发阶段，计划 Q2 上线
- Main concerns: 
  - GraphQL 迁移进度（已完成 60%）
  - 审批流程性能优化（批量审批时响应慢）
  - 移动端适配（当前仅支持桌面）

## 已知问题
- Issue #234: 批量审批 > 100 条时超时
- Issue #256: 移动端表单提交按钮被键盘遮挡
- Issue #301: 导出 Excel 中文乱码

## 下一步计划
- [ ] 完成 GraphQL 迁移（预计 2 周）
- [ ] 修复批量审批超时问题
- [ ] 移动端适配
- [ ] 上线前安全审计

第四步：测试

# 在项目 A 目录下启动对话
cd ~/projects/project-a
openclaw chat "现在项目 A 最紧急的问题是什么？"

# 期望输出：
# 根据项目记忆，当前最紧急的问题是：
# 1. GraphQL 迁移进度（已完成 60%，计划 Q2 上线）
# 2. 批量审批超时 Issue #234
# ...

常见错误与避坑指南

错误 1：把所有对话都写入 MEMORY.md

症状： MEMORY.md 越来越长，上下文加载变慢，Agent 开始「健忘」——因为 MEMORY.md 太大，部分内容被截断。

原因： 没有理解三层记忆的分工。

解决： 严格区分：

• 对话详情 → 每日笔记
• 重要提炼 → MEMORY.md
• 不要把「用户问了什么」记进去，而要把「用户需要知道什么」记进去

错误 2：在 MEMORY.md 中存储明文密码

症状： 密码被泄露或被用于不当目的。

原因： MEMORY.md 是明文文件，任何有文件访问权限的人都能看到。

解决： MEMORY.md 只存储元数据，敏感信息存 .env：

# 错误 ❌
## API Keys
- AWS: my-secret-key-xxx

# 正确 ✅
## API Keys
- AWS: 见 .env (不写在 md 文件中)

错误 3：群聊中不小心引用了 MEMORY.md

症状： 在飞书群中，Bot 说出了用户不应该在群里听到的内容。

解决： 务必在 AGENTS.md 中明确标注：

## Memory Loading Rules

**MEMORY.md 只在主会话（1:1私聊）中加载。**
**在群聊中，Agent 绝对不能读取或引用 MEMORY.md 的内容。**

错误 4：项目记忆混淆

症状： 把项目 A 的技术决策用到了项目 B 上。

解决： 每次会话开始时，明确确认项目上下文：

## Project Confirmation

If I detect work on a project but project context is unclear:
→ Ask "Which project are you working on?"
→ Load that project's specific memory file
→ Confirm "Got it, working on [Project Name]. I'll keep that context in mind."

错误 5：忘记定期清理每日笔记

症状： memory/ 目录越来越大，占用大量磁盘空间。

解决： 配置自动清理 cron 任务：

openclaw cron add "0 3 * * *" --name "清理旧记忆" --prompt "清理 memory/ 目录下 30 天以前的文件"

术语注释

术语	英文	解释
上下文窗口	Context Window	LLM 单次可以处理的最大 token 数量
短期记忆	Short-term Memory	当前会话的对话历史
中期记忆	Medium-term Memory	每日笔记（memory/YYYY-MM-DD.md），保留 30 天
长期记忆	Long-term Memory	MEMORY.md，永久保留的关键信息
语义搜索	Semantic Search	基于含义而非关键词的搜索方式
向量嵌入	Embedding	将文本转为高维向量的技术
记忆泄漏	Memory Leak	敏感信息被泄露到不应出现的上下文中

面试高频问答

Q1：OpenClaw 的三层记忆架构解决了什么问题？

回答：解决了上下文窗口有限和记忆分层的实际需求。短期记忆（对话历史）处理当前会话；中期记忆（每日笔记）记录工作进展，保留 30 天；长期记忆（MEMORY.md）提炼最重要的知识，永久保留。这样既保证 Agent 能「记住」关键信息，又不会让上下文无限膨胀。分层还支持隐私隔离——MEMORY.md 不在群聊中加载，防止敏感信息泄露。

Q2：如何设计一个好的 MEMORY.md 结构？

回答：MEMORY.md 应该像「精华版的工作手册」，而不是「聊天记录摘要」。结构上建议分板块：用户 Profile（偏好、习惯）、项目知识（每个项目一节）、工具访问（账号信息元数据）、教训总结。写入原则是「从具体到抽象」——把「用户问了 token 问题」提炼成「token 默认 24h 过期，可配置」。定期（比如每周）回顾 MEMORY.md，删除过时信息，保持精简。

Q3：如何防止记忆泄漏？

回答：有三个层次的防护。第一是文件级别的隐私规则——MEMORY.md 只在主会话加载，不在群聊加载，这由 AGENTS.md 控制。第二是内容级别的敏感信息隔离——API keys、密码等绝不写入 .md 文件，只放在 .env。第三是项目级别的记忆隔离——多项目时，用目录结构或标签区分不同项目的记忆，防止上下文混淆。

深度扩展

深度 1：记忆的主动提炼机制

OpenClaw 支持在会话结束时自动提炼记忆，而不需要用户手动触发。关键是在 AGENTS.md 中定义提炼规则：

## Session End Memory Consolidation

When a session ends (user says goodbye or session is idle > 30 min), I should:

1. Review the conversation highlights
2. Write to `memory/YYYY-MM-DD.md`:
   - Key decisions made
   - Action items and their status
   - Anything that needs follow-up
   
3. If something is IMPORTANT and LONG-TERM relevant:
   - Extract it and write to MEMORY.md
   - Ask myself: "Will this matter in 6 months?"
   
4. If the session was > 30 minutes:
   - Write a more detailed summary to daily notes
   - Include specific code files discussed, decisions made

这样，OpenClaw 会在每次会话结束时自动「复盘」，确保重要的东西被记住。

深度 2：向量数据库与语义记忆（高级）

对于需要更强大记忆检索的场景，可以集成向量数据库：

# 在 .env 中配置向量数据库
OPENCLAW_VECTOR_STORE=pinecone  # 或 qdrant, weaviate, chromadb
OPENCLAW_VECTOR_API_KEY=xxx
OPENCLAW_VECTOR_INDEX=openclaw-memory

# 配置嵌入服务
OPENCLAW_EMBEDDING_PROVIDER=openai
OPENCLAW_EMBEDDING_MODEL=text-embedding-3-small

集成后，OpenClaw 会：

1. 当新记忆写入时，自动生成向量并存入向量数据库
2. 当查询时，使用语义搜索找到最相关的记忆，而不只是关键词匹配

这解决了传统文本搜索的局限性——「搜索『认证机制』」会找到所有和认证相关的笔记，即使它们没有包含「认证」这个词。

深度 3：多模态记忆——图片和文件

OpenClaw 的 Memory 系统也支持非文本内容的记忆：

## Multimodal Memory

When the user shares an image or file:
- Save it to `.openclaw/memory/attachments/YYYY-MM-DD/`
- Write a reference in daily notes:

[2026-03-30 10:30] User shared screenshot of error dialog
File: attachments/2026-03-30/error-screenshot-001.png
Context: Appears when trying to upload files > 10MB

- If the image contains important info (diagram, architecture), 
extract and summarize in text format for future searchability

这样，即使是很久以前的一张截图，你也可以通过描述（「那个上传文件的报错截图」）找到它。

附录

A.1 三层记忆对比表

维度	对话历史	每日笔记	MEMORY.md
保留期	会话内	30 天	永久
容量	受上下文窗口限制	无限制（按日期组织）	建议 < 50KB
检索方式	自动加载	按日期 + 搜索	关键词 + 语义
隐私保护	会话内	视内容而定	仅主会话加载
内容类型	原始对话	工作日志	提炼精华

A.2 记忆写入检查清单

写记忆前，问自己这些问题：

• 这个信息在 6 个月后还有价值吗？→ 如果是，写入 MEMORY.md
• 这个信息今天需要用到吗？→ 如果是，写入每日笔记
• 这个信息可以用一句话总结吗？→ 提炼后再写入
• 这个信息包含敏感内容吗？→ 如果是，检查隐私规则
• 这个信息有后续行动项吗？→ 标记为 Follow-up

A.3 记忆维护周期

频率	动作	执行者
每次会话结束	提炼重要记忆到每日笔记	OpenClaw 自动
每周	回顾每日笔记，更新 MEMORY.md	用户 + OpenClaw
每月	清理 30 天前的每日笔记	OpenClaw cron
每季度	大规模回顾 MEMORY.md	用户

系列总结（第 01-04 章）

通过前四章的学习，我们对 OpenClaw 有了全面深入的理解：

第 01 章： 安装与环境配置，Hello World 体验
第 02 章： 配置文件体系与 Gateway 架构
第 03 章： SOUL.md 与 AGENTS.md，打造 Agent 人格与工作流程
第 04 章： Memory 三层记忆系统，防止记忆泄漏

现在你已经掌握了 OpenClaw 的核心理论体系。下一章我们将进入技能扩展的世界——学习 OpenClaw 的 Skills 架构，了解如何通过 Skill 扩展 Agent 的能力，包括内置的 coding-agent、feishu-*、weather 等技能，以及如何使用 ClawHub 技能市场。读完第 05 章，你将能够为 OpenClaw 安装和管理各种技能，大幅扩展它的能力边界。

版权声明

本文为原创技术实践文章，禁止未经授权的全文转载；引用请注明出处与本文链接。