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

04Memory 系统让 Agent 拥有持久记忆文章目录04Memory 系统让 Agent 拥有持久记忆摘要SEO 摘要目录开篇核心知识点1. 为什么 AI 需要记忆系统1.1 上下文窗口的有限性1.2 短期 vs 长期记忆的分工2. 三层记忆架构概述3. 短期记忆对话历史3.1 工作原理3.2 对话历史的局限3.3 如何弥补4. 中期记忆每日笔记memory/YYYY-MM-DD.md4.1 文件位置与命名4.2 每日笔记的格式4.3 每日笔记的检索4.4 自动清理策略5. 长期记忆MEMORY.md5.1 什么时候写入 MEMORY.md5.2 MEMORY.md 的结构5.3 MEMORY.md 的隐私保护6. 语义搜索配置与向量嵌入6.1 什么是语义搜索6.2 向量嵌入的工作原理6.3 OpenClaw 语义搜索配置6.4 语义搜索的使用7. 记忆写入时机与最佳实践7.1 什么时候应该写入记忆7.2 写入记忆的标准流程7.3 最佳实践记忆的提炼原则8. 避免记忆泄漏与隐私保护8.1 记忆泄漏的常见场景8.2 隐私保护配置8.3 记忆的加密存储高级实战构建项目知识库需求配置方案常见错误与避坑指南错误 1把所有对话都写入 MEMORY.md错误 2在 MEMORY.md 中存储明文密码错误 3群聊中不小心引用了 MEMORY.md错误 4项目记忆混淆错误 5忘记定期清理每日笔记术语注释面试高频问答深度扩展深度 1记忆的主动提炼机制深度 2向量数据库与语义记忆高级深度 3多模态记忆——图片和文件附录A.1 三层记忆对比表A.2 记忆写入检查清单A.3 记忆维护周期系列总结第 01-04 章版权声明专栏定位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 tokensClaude 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 理解当前对话的来龙去脉会话结束后不会主动保留除非手动保存到 memory3.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 通过两个机制来弥补这个问题每日笔记写入在会话结束时Agent 会把重要信息写入memory/YYYY-MM-DD.md长期记忆提炼把需要长期记住的信息提炼到MEMORY.md4. 中期记忆每日笔记memory/YYYY-MM-DD.md4.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-31OpenClaw 会读取memory/2026-03-31.md今天的笔记可能刚开始写memory/2026-03-30.md昨天的完整笔记这样Agent 能快速了解「最近发生了什么」。4.4 自动清理策略每日笔记会自动清理旧文件默认保留 30 天这是通过 OpenClaw 的维护脚本实现的# 在 .openclaw/ 目录下会有一个清理脚本# 或者通过 cron 任务定期执行find.openclaw/memory-name*.md-mtime30-delete5. 长期记忆MEMORY.md5.1 什么时候写入 MEMORY.mdMEMORY.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 - 开发负责人: 李四 (lishicompany.com) - 运维负责人: 王五 (wangwucompany.com) - 产品经理: 赵六 (zhaoliucompany.com) ### Important Decisions - 2026-01-15: 决定使用飞书文档替代 Confluence因为团队更熟悉飞书 - 2026-02-20: 决定引入 AI 助手辅助代码审查 - 2026-03-01: 决定所有新项目必须包含测试用例 ### Known Issues - 当前搜索功能使用 MySQL FULLTEXT性能较差计划 Q2 迁移到 Elasticsearch - 部分旧文档从 Confluence 迁移过来时有格式丢失 ## Lessons Learned ### Dont Do This - 绝对不要在生产服务器上直接执行 DELETE SQL上次误删了 3 条数据 - 不要在用户开会时打断优先使用异步方式 ### Preferences - 写代码时先问清楚需求不要急于动手 - 任何重大变更前必须给出至少两个方案对比 ## Tools Access ### Accounts - GitHub: github.com/zhangsan-company - 飞书: zhangsancompany.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 shouldnt 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_PROVIDERopenaiOPENCLAW_EMBEDDING_MODELtext-embedding-3-smallOPENCLAW_EMBEDDING_API_KEYsk-xxxxxxxxxxxxxxxx或者使用本地嵌入服务如 OllamaOPENCLAW_EMBEDDING_PROVIDERollamaOPENCLAW_EMBEDDING_MODELnomic-embed-textOPENCLAW_EMBEDDING_URLhttp://localhost:114346.4 语义搜索的使用配置完成后你可以在对话中让 OpenClaw 进行语义搜索openclaw chat你有没有关于认证或者登录的记忆帮我找一下OpenClaw 会将查询转换为向量在每日笔记和 MEMORY.md 中搜索语义相似的内容返回最相关的结果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规则 2MEMORY.md 不在群聊中加载## Memory Loading Rules ### Main Session (1:1 private chat): - Load MEMORY.md - Load todays and yesterdays daily notes - Full context available ### Group Chats: - NEVER load MEMORY.md - Only load todays 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 projects memory context: - Check which project folder were working in - Load only the relevant projects section from MEMORY.md - If no project specified, ask Which project are you working on?8.3 记忆的加密存储高级对于需要额外保护的场景可以配置 OpenClaw 使用加密存储# 在 .env 中启用加密OPENCLAW_MEMORY_ENCRYPTtrueOPENCLAW_MEMORY_ENCRYPTION_KEYyour-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 计划) ## 关键人员 - 技术负责人: 张工 (zhangcompany.com) - 负责架构决策 - 产品经理: 李经理 (licompany.com) - 需求管理 - 测试负责人: 王测 (wangcompany.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 projects specific memory file → Confirm Got it, working on [Project Name]. Ill keep that context in mind.错误 5忘记定期清理每日笔记症状memory/目录越来越大占用大量磁盘空间。解决配置自动清理 cron 任务openclawcronadd0 3 * * *--name清理旧记忆--prompt清理 memory/ 目录下 30 天以前的文件术语注释术语英文解释上下文窗口Context WindowLLM 单次可以处理的最大 token 数量短期记忆Short-term Memory当前会话的对话历史中期记忆Medium-term Memory每日笔记memory/YYYY-MM-DD.md保留 30 天长期记忆Long-term MemoryMEMORY.md永久保留的关键信息语义搜索Semantic Search基于含义而非关键词的搜索方式向量嵌入Embedding将文本转为高维向量的技术记忆泄漏Memory Leak敏感信息被泄露到不应出现的上下文中面试高频问答Q1OpenClaw 的三层记忆架构解决了什么问题回答解决了上下文窗口有限和记忆分层的实际需求。短期记忆对话历史处理当前会话中期记忆每日笔记记录工作进展保留 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_STOREpinecone# 或 qdrant, weaviate, chromadbOPENCLAW_VECTOR_API_KEYxxxOPENCLAW_VECTOR_INDEXopenclaw-memory# 配置嵌入服务OPENCLAW_EMBEDDING_PROVIDERopenaiOPENCLAW_EMBEDDING_MODELtext-embedding-3-small集成后OpenClaw 会当新记忆写入时自动生成向量并存入向量数据库当查询时使用语义搜索找到最相关的记忆而不只是关键词匹配这解决了传统文本搜索的局限性——「搜索『认证机制』」会找到所有和认证相关的笔记即使它们没有包含「认证」这个词。深度 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 dialogFile: attachments/2026-03-30/error-screenshot-001.pngContext: 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-upA.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 安装和管理各种技能大幅扩展它的能力边界。版权声明本文为原创技术实践文章禁止未经授权的全文转载引用请注明出处与本文链接。