引言：为什么记忆是 Agent 的短板

每个会话结束，AI 助手都会”失忆”。对于长期陪伴用户的个人助手，如何把经验、偏好与知识沉淀下来，是工程化的关键挑战。OpenClaw 以文件为基础构建了一套可持久化的记忆体系。本文梳理从 MEMORY.md、USER.md 到语义搜索的完整实现路径，帮助开发者打造不丢失上下文的助手。

记忆的分层：全局与每日

OpenClaw 将记忆划分为长期与短期两层。长期记忆存放在根目录的 MEMORY.md（全局、经过精心维护）与 USER.md（用户画像与偏好）；短期记忆则以日期命名的日志文件记录每日发生的原始事件。

# 工作区目录结构
MEMORY.md          # 长期精炼记忆（主会话加载）
USER.md            # 用户偏好与画像
KNOWN_ISSUES.md    # 已知问题与踩坑记录
memory/
  2026-11-01.md    # 每日原始日志
  2026-11-02.md

这种”精炼 + 原始”的分层，让长期记忆保持高信噪比，而每日日志则忠实记录细节，供回溯。

写入时机：何时该落盘

记忆的价值在于”可复现”。并非所有对话都值得记忆，需要遵循明确的触发规则：重要的用户偏好、学到的经验、踩过的坑、重大决策都应写入对应文件。

# 值得写入记忆的内容示例
- 用户偏好：回复风格、时区、称呼
- 经验：某个命令的正确用法、某工具的坑
- 决策：项目选型、架构变更
- 待办：长期任务进度

养成”任务结束即记录”的习惯，把散落在会话中的信息主动沉淀到文件，是记忆系统能否真正起效的前提。

语义搜索：从线性读取到检索式记忆

当记忆文件不断增长，线性阅读会消耗大量上下文。OpenClaw 支持对记忆文件做语义搜索，将相关片段快速召回，而无需加载全部历史。这本质上是一种”检索增强”的记忆管理。

# 语义搜索流程（伪代码）
query = "博客发布流程"
results = semantic_search(query, scope="memory/*.md")
# 返回与 query 相关度最高的记忆片段

通过语义搜索，助手能在回答前精准召回历史决策与偏好，既保留长期记忆，又不撑爆上下文窗口。

会话启动：自动加载上下文

每次会话开始时，OpenClaw 会读取今日与昨日的日志、USER.md、长期记忆等文件，形成”开机即知来龙去脉”的初始上下文。这让新会话无需用户重述，即可延续之前的任务与偏好。

# 启动时加载顺序
1. SOUL.md  -> 角色与风格
2. USER.md  -> 用户画像
3. memory/今日 + 昨日 -> 最近上下文
4. MEMORY.md -> 长期记忆（主会话）
5. KNOWN_ISSUES.md -> 已知问题

这种自动加载机制，让助手在每次对话开始时都”记得自己是谁、在帮谁、之前做到哪一步”。

结语

记忆系统的本质，是把”会话内”的临时知识转化为”会话间”的持久资产。通过分层文件、明确的写入时机、语义搜索与启动加载，OpenClaw 让助手摆脱了”每次重新开始”的宿命。对开发者而言，理解这套机制，就能设计出真正具备长期记忆的智能体——这不仅是一项技术，更是一种工程习惯的养成。