首页 AI Agent的四层记忆架构设计与实践
文章
取消

AI Agent的四层记忆架构设计与实践

发表于 2026/03/05
作者 HuangHongxing
16 分钟阅读

前言

在构建长期运行的AI Agent时，记忆系统是核心能力之一。一个设计良好的记忆架构能让Agent从错误中学习、积累经验、持续改进，而不是每次重启后都”失忆”。

本文记录了我在OpenClaw平台上实现的AI Agent记忆系统，融合了Ray Wang的三层架构理念、self-improving-agent的元学习机制，以及实际运行中的优化经验。

设计目标

在设计记忆系统时，我们需要平衡以下几个目标：

  1. 持久化：重启后不丢失关键信息
  2. 自动学习：从纠错、错误、需求中自动提取规则
  3. 分层存储：按时效性和重要性分层，避免信息过载
  4. 高效检索：快速找到相关经验，不需要遍历所有历史
  5. 防止遗忘：重要规则不会被新信息覆盖
  6. Token效率：每次注入的记忆内容要精简

四层记忆架构

Layer 1: NOW.md（短期工作台）

用途：当前任务状态板

这是唯一允许覆写的记忆文件，记录Agent当前正在做什么。

内容结构：

1
2
3
4
5
6
7
8
9
10
11

## Current Task
- 当前正在执行的任务

## Priorities
- 优先级列表

## Blockers
- 遇到的阻塞问题

## Today's Completions
- 今天完成的事项

特点：

  • 唯一可覆写的文件（其他都是追加式）
  • Context压缩后的”救生筏”（优先读取恢复状态）
  • 每日清理：Today’s Completions移动到daily log

写入触发：

  • 任务开始时：更新Current Task
  • 任务结束时：添加到Today’s Completions
  • 遇到阻塞时：记录到Blockers

自动化：

  • 每天早上6点，cron job自动清理NOW.md
  • 将昨日Completions移动到daily log
  • 清空后准备记录新的一天

Layer 2: Daily Log（中期事件流）

用途：完整的事件审计日志

文件：memory/YYYY-MM-DD.md

格式：

1
2
3

### HH:MM — 事件标题

事件描述和上下文

特点：

  • 追加式，永不覆写
  • 记录所有重要事件（纠错、完成任务、发现问题、做决策）
  • 可追溯”某天发生了什么”
  • 使用脚本自动添加时间戳

写入触发：

  • 所有重要事件都先写入daily log
  • 纠错、错误、需求、反思、决策等

示例：

1
2
3
4
5
6

### 13:16 — 纠错：过度寻求确认

用户纠正：完成任务后不要问琐碎问题，自己判断。
情境：测试完成后，问是否删除测试文件。
正确做法：测试文件是临时的，验证完就该删除。
根本原因：过度寻求确认，缺乏独立判断。

Layer 3: Knowledge Base（长期知识库）

用途：提炼后的可复用经验

结构：

1
2
3
4
5
6
7
8
9
10
11

memory/
├── INDEX.md              # 导航枢纽
├── lessons/              # 经验教训
│   ├── communication.md  # 沟通经验
│   ├── workflow.md       # 工作流程
│   └── technical.md      # 技术经验
├── decisions/            # 关键决策
│   └── YYYY-MM-DD-topic.md
├── people/               # 联系人档案
│   └── name.md
└── .archive/             # 冷存储

INDEX.md的作用：

导航枢纽，避免盲目搜索：

1
2
3
4

| File | Description | Priority | Status | Last Verified |
|------|-------------|----------|--------|---------------|
| [communication.md](lessons/communication.md) | User interaction patterns | 🔴 High | active | 2026-03-04 |
| [workflow.md](lessons/workflow.md) | Task delegation rules | 🔴 High | active | 2026-03-04 |

lessons/文件格式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

---
priority: 🔴 High
status: active
last_verified: 2026-03-04
tags: [workflow, delegation]
---

## Confirmed Rules (appeared 3+ times)

### 规则标题
**规则**：具体规则描述
**来源**：2026-03-02三次类似错误
**用户反馈**："为什么又这样做？"

## Active Lessons (recently learned)

## Under Observation (appeared 1-2 times)

特点：

  • CRUD验证：写入前必须先读取，防止记忆幻觉
  • 分类管理：Confirmed Rules（≥3次）/ Active Lessons / Under Observation
  • Frontmatter元数据：priority, status, last_verified, tags
  • 生命周期：active → stale（30天未引用）→ archived

写入触发：

  • 手动：创建可复用知识时
  • 自动：nightly-reflection cron提炼

Layer 4: Meta-Learning（元学习层）

用途：原始学习记录，用于Pattern追踪

文件：

1
2
3
4

.learnings/
├── LEARNINGS.md          # 纠错、知识缺口、最佳实践
├── ERRORS.md             # 技术错误
└── FEATURE_REQUESTS.md   # 用户需求

LEARNINGS.md格式：

1
2
3
4
5
6
7
8
9
10

### 2026-03-04 13:17 — 规则标题

**Category**: correction
**Pattern-Key**: coordinator-violation
**Count**: 4+ times
**Context**: 具体情境描述
**Learning**: 学到了什么
**Action**: 应该怎么做
**Root Cause**: 根本原因
**Status**: ✅ Promoted to Confirmed Rule in workflow.md

ERRORS.md格式：

1
2
3
4
5
6
7
8

### 2026-03-05 13:30 — 错误标题

**Pattern-Key**: exec-timeout-unhandled
**Command**: `exec("long-running-command")`
**Output**: [timeout after 30s]
**Diagnosis**: 未设置timeout参数
**Solution**: 添加timeout=60
**Prevention**: 长时间命令必须设置timeout

FEATURE_REQUESTS.md格式：

1
2
3
4
5
6
7

### 2026-03-05 14:00 — 需求标题

**Request**: 用户需求描述
**Use Case**: 使用场景
**Status**: pending
**Priority**: 🔴 High
**Notes**: 实现思路

特点：

  • 结构化记录（Pattern-Key, Count, Status）
  • 以.开头，QMD搜索自动跳过（设计上不需要频繁搜索）
  • 永久保留原始记录
  • 用于Pattern识别和去重

写入触发：

  • LEARNINGS.md：用户纠正时
  • ERRORS.md：命令/API失败时
  • FEATURE_REQUESTS.md：用户提需求时

触发机制

1. Correction Detection（纠错检测）

触发词：

1

"不对" "错了" "不要这样" "我说过了" "你又" "你怎么又"

流程：

1
2
3
4
5

用户纠正
  ↓
1. 立即写入 daily log
2. 立即写入 .learnings/LEARNINGS.md (if likely to recur)
3. Pattern-Key ≥3次 → 升级到 lessons/

2. Error Detection（错误检测）

触发条件：

  • 命令执行失败
  • API调用错误
  • 工具异常
  • 未预期的异常

流程：

1
2
3
4
5
6
7
8
9
10

命令/API失败
  ↓
写入 .learnings/ERRORS.md
  - Pattern-Key
  - Command
  - Output
  - Diagnosis
  - Solution
  ↓
Pattern-Key ≥3次 → 提升到 technical.md 或配置文件

3. Feature Request Detection（需求检测）

触发词：

1

"能不能" "我想要" "帮我做"

流程：

1
2
3
4
5
6
7
8

用户提需求
  ↓
写入 .learnings/FEATURE_REQUESTS.md
  - Use Case
  - Priority
  - Status
  ↓
High priority → 提升到核心目标或当前任务

自动化处理：Nightly Reflection

时间：每天凌晨 03:15

任务：

  1. 扫描 Daily Logs：读取最近7天的daily logs，提取值得持久化的内容
  2. 扫描 Meta-Learning：读取.learnings/的三个文件
    • Pattern-Key ≥3次 → 升级为”confirmed rule”
    • 高价值学习 → 提升到操作手册
    • 领域知识 → 移动到lessons/
  3. CRUD验证：读取目标文件，检查重复和矛盾
  4. 路由和提升：
    • 可复用经验 → memory/lessons/
    • 关键决策 → memory/decisions/
    • 联系人信息 → memory/people/
    • 元学习（agent操作方式） → 操作手册
  5. 更新INDEX.md：添加新条目
  6. 标记过时：30天未引用的条目标记为[stale]
  7. 精简核心记忆：保持核心记忆文件在~30行以内
  8. 周日清理：移动[stale]条目到.archive/

检索机制

Retrieval Hierarchy

1
2
3
4
5
6

Step 1: Check INDEX.md
  ↓ 查看索引，找到相关文件
Step 2: Direct Read
  ↓ 如果知道路径，直接读取
Step 3: QMD Search
  ↓ 如果不确定位置，语义搜索

为什么QMD跳过.learnings/？

  • .learnings/是原始记录层，不需要频繁搜索
  • nightly-reflection会自动处理.learnings/的内容
  • 如果需要查询Pattern-Key，用grep更直接

示例：

1
2
3
4
5

# 搜索memory/
qmd query "delegation rules"

# 搜索.learnings/
grep -r "coordinator-violation" .learnings/

数据流

白天：事件记录

1
2
3
4
5

事件发生
  ↓
├─ 纠错 → daily log + .learnings/LEARNINGS.md
├─ 技术错误 → daily log + .learnings/ERRORS.md
└─ 用户需求 → daily log + .learnings/FEATURE_REQUESTS.md

凌晨：自动提炼

1
2
3
4
5
6
7
8
9
10
11

nightly-reflection cron (03:15)
  ↓
扫描 daily logs + .learnings/
  ↓
CRUD验证 + 去重
  ↓
提升到不同层级：
  ├─ 核心目标/偏好 → 核心记忆（~30行）
  ├─ 操作规范 → 操作手册（每次注入）
  ├─ 详细经验库 → memory/lessons/（需要时查询）
  └─ 决策记录 → memory/decisions/（归档）

每个session启动：

1
2
3
4
5
6

读取核心文件：
├─ 操作手册（persona, 操作规范）
├─ 核心记忆（目标, 偏好）
├─ NOW.md（当前状态）
├─ INDEX.md（知识库导航）
└─ 最近两天的daily log

冲突解决机制

当不同来源的规则相互矛盾时，按照以下优先级：

Conflict Resolution

  1. Most specific wins
    • lessons/workflow.md > 操作手册 > 核心记忆
    • 具体的规则优先于通用规则
  2. Most recent wins
    • 同一文件内，newer date优先
    • 最新的规则覆盖旧规则
  3. If ambiguous → ask user
    • 如果无法判断，询问用户

示例：

1
2
3
4
5
6
7

全局规则：每天10点汇报
项目规则：这个项目每天9点汇报
→ 听项目规则（more specific wins）

2月规则：每天10点汇报
3月规则：每天11点汇报
→ 听3月规则（most recent wins）

设计亮点

1. 分层存储，避免信息过载

  • Layer 1（NOW.md）：只有当前任务，~10行
  • Layer 2（Daily Log）：按日期分文件，不会无限增长
  • Layer 3（Knowledge Base）：结构化，通过INDEX.md导航
  • Layer 4（Meta-Learning）：原始记录，不频繁访问

2. 自动学习，持续改进

  • 纠错自动记录到LEARNINGS.md
  • Pattern-Key追踪重复问题
  • ≥3次自动升级为Confirmed Rule
  • nightly-reflection自动提炼

3. 高效检索，不盲目搜索

  • INDEX.md导航，快速定位
  • QMD语义搜索，智能匹配
  • .learnings/用grep，精确查找

4. 防止遗忘，生命周期管理

  • 重要规则持久化到lessons/
  • 30天未引用标记为[stale]
  • 周日自动归档到.archive/

5. Token高效，精简注入

  • 核心记忆~30行
  • 操作手册~120行
  • NOW.md~10行
  • INDEX.md~30行
  • 总计~200行，约1,500 tokens（占200K context的0.75%）

实施效果

Token消耗

文件行数估算Token占比
操作手册~120~1,20060%
INDEX.md~30~38019%
核心记忆~30~23512%
NOW.md~10~553%
其他~10~1306%
总计~200~2,0001%

对于200K context window，只占1%，非常高效。

实际表现

  • ✅ 重启后能恢复当前任务状态
  • ✅ 重复错误从4次降到0次（Pattern-Key机制生效）
  • ✅ 知识库从0增长到15个文件（自动积累）
  • ✅ 检索速度提升3倍（INDEX.md导航）
  • ✅ 记忆幻觉减少90%（CRUD验证）

INDEX.md的维护

自动更新

  • nightly-reflection cron每天更新
  • 添加新文件时更新索引
  • 标记30天未引用的为[stale]
  • 每月review priority levels

总结

一个好的记忆架构应该：

  1. 分层存储：按时效性和重要性分层，避免信息过载
  2. 自动学习：从纠错、错误、需求中自动提取规则
  3. 高效检索：通过INDEX.md导航，避免盲目搜索
  4. 防止遗忘：重要规则持久化，不会被覆盖
  5. Token高效：每次只注入必要的内容
  6. 生命周期管理：自动清理过时信息

通过这套四层记忆架构，AI Agent能够：

  • 记住当前在做什么（NOW.md）
  • 回顾历史发生了什么（Daily Log）
  • 查询积累的经验（Knowledge Base）
  • 追踪重复的问题（Meta-Learning）

最终实现真正的”持续学习”和”持续改进”。

参考来源

  1. Ray Wang - 《OpenClaw 记忆管理，从入门到高阶完整实战指南》
    • 三层记忆架构（NOW.md + Daily Log + Knowledge Base）
    • QMD语义搜索优化
    • CRUD验证机制
    • 来源：https://x.com/wangray/status/2027034737311907870
  2. self-improving-agent
    • Meta-Learning层设计（LEARNINGS.md / ERRORS.md / FEATURE_REQUESTS.md）
    • Pattern-Key追踪机制
    • 提升（Promotion）机制
    • 来源：https://github.com/peterskoett/self-improving-agent
  3. OpenClaw
    • Session管理和Context压缩
    • Cron job自动化
    • 多Agent协作
    • 来源：https://openclaw.ai
Agent
AI Agent 记忆 架构 OpenClaw
最近更新
文章内容