能否优化记忆层？而且我也没在参考文档里看到和记忆有关的东西？搞大项目的时候很痛苦。 || Can the memory layer be optimized? And I didn’t see anything related to memory in the reference document? It’s painful when working on big projects.

[hahy36]

能否优化记忆层？而且我也没在参考文档里看到和记忆有关的东西？（只看到一个agent.md）
要不然搞大项目的时候很痛苦。

这是我参考到的信息，不知道是否有用哈：
你的设备
├── ~/.openclaw/workspace/
│ ├── SOUL.md ← AI 的人格设定
│ ├── USER.md ← 你的信息
│ ├── MEMORY.md ← 长期记忆（精选）
│ └── memory/ ← 每日记忆（原始记录）
│ ├── 2026-03-01.md
│ ├── 2026-03-02.md
│ └── ...
核心差异：
特性公共 AIOpenClaw记忆存储云端（会话结束清空）本地硬盘（永久保存）记忆类型仅当前会话上下文短期 + 长期 + 每日记忆控制平台说了算你说了算记忆迁移无法导出随时备份/迁移从”每次都是陌生人”到”真正了解你的助手”，差一套记忆系统。
二、OpenClaw 记忆系统架构
OpenClaw 的记忆系统分为三层，每层有不同用途。
┌─────────────────────────────────────────┐
│ 短期记忆：会话上下文（Session Context） │ ← 当前对话
├─────────────────────────────────────────┤
│ 长期记忆：MEMORY.md（精选记忆） │ ← 重要信息
├─────────────────────────────────────────┤
│ 每日记忆：memory/YYYY-MM-DD.md（原始） │ ← 日常记录
└─────────────────────────────────────────┘

规范文档（你的知识库）：

1. PRD.md（产品需求文档） - 完整规格。你在构建什么、为谁构建、有什么功能、什么在范围内、什么明确在范围外。用户故事、成功标准、非目标，以及每个功能的具体标准。这是你的合同。AI 读了这个就知道"完成"对你来说是什么样子。没有这个？你不是在构建 App，你是在祈祷一个 App 出现。
2. APP_FLOW.md - 每个页面和每个用户导航路径都用 plain English 记录。什么触发每个流程。逐步序列与决策点、成功时发生什么、错误时发生什么，以及屏幕清单与路由。这防止 AI 猜测用户如何在 App 中移动。3. TECH_STACK.md - 每个包、依赖、API 和工具都锁定到确切版本。没有歧义。当 AI 看到"使用 React"，它可能选任何版本。当它看到"Next.js 14.1.0, React 18.2.0, TypeScript 5.3.3"，它构建的完全是你指定的。这份文档消除幻觉依赖和随机技术选择。4. FRONTEND_GUIDELINES.md - 你的完整设计系统。字体、带确切十六进制代码的调色板、间距刻度、布局规则、组件样式、响应式断点，以及 UI 库偏好。每个视觉决策都锁定。AI 参考这个来创建每个组件。不再有随机颜色或不一致的间距。5. BACKEND_STRUCTURE.md - 数据库模式，每张表、每列、类型和关系都定义好。认证逻辑、API 端点合约、存储规则，以及边缘情况。如果你用 Supabase，这份文档包含确切的 SQL 结构。AI 根据这个蓝图构建你的后端，而不是根据它自己的假设。6. IMPLEMENTATION_PLAN.md - 逐步构建序列。不是"构建 App"。更像是：步骤 1.1 初始化项目，步骤 1.2 从 TECH_STACK.md 安装依赖，步骤 1.3 创建文件夹结构，步骤 2.1 按照 FRONTEND_GUIDELINES.md 构建导航栏组件，等等。步骤越多，AI 猜测越少。AI 猜测越少，幻觉越少。这些文档相互引用。PRD 定义功能，APP FLOW 定义用户如何体验它们，TECH STACK 定义用什么构建它们，FRONTEND GUIDELINES 定义它们长什么样，BACKEND STRUCTURE 定义数据如何工作，IMPLEMENTATION PLAN 定义构建顺序。这是你的知识库。AI 会读这些并得到它所需的一切。两份会话文件（你的持久层）：CLAUDE.md - 这是 AI 每次会话自动首先读取的文件。它包含每个 AI 会话必须遵循的规则、约束、模式和上下文。你的技术栈摘要、文件命名约定、组件模式、设计系统令牌。它是允许的和禁止的。把它当作 AI 针对你特定项目的操作手册。Claude Code 可以从项目根目录读取这个，甚至不需要你要求。progress.txt - 这是所有人都漏掉的文件。这个文件跟踪已完成的内容、进行中的内容，以及接下来的内容。每次你完成一个功能，你更新这个文件。每次你开始新会话，每次你打开新终端窗口，每次你切换分支，AI 首先读取这个文件来获取你进度的上下文记忆。没有它，每个新会话都从零上下文开始，伴随着一大堆错误。有了它，AI 精确地从你离开的地方继续。这就是为什么这很重要：AI 在会话间没有记忆。 当你关闭终端、打开新终端，或开始新聊天时，一切都消失了。progress.txt 是你的外部记忆。它是会话之间的桥梁。虔诚地更新它。在每次实现完成功能后，详细记录构建了什么、什么有效、什么坏了、接下来做什么。

---

Can the memory layer be optimized? And I didn’t see anything related to memory in the reference document? (Only one agent.md is seen)
Otherwise it will be very painful when working on big projects.

This is the information I came across, I don’t know if it’s useful:
your device
├── ~/.openclaw/workspace/
│ ├── SOUL.md ← AI personality settings
│ ├── USER.md ← Your information
│ ├── MEMORY.md ← Long-term memory (selected)
│ └── memory/ ← Daily memory (original record)
│ ├── 2026-03-01.md
│ ├── 2026-03-02.md
│ └── ...
Core differences:
Features Public AIOpenClaw memory storage cloud (cleared at the end of the session) local hard drive (saved permanently) Memory type only current session context short-term + long-term + daily memory control platform has the final say, you have the final say Memory migration cannot be exported and backed up/migrated at any time From "a stranger every time" to "an assistant who truly understands you", there is a lack of a memory system.
2. OpenClaw memory system architecture
OpenClaw's memory system is divided into three layers, each with a different purpose.
┌────────────────────────────────────────────
│ Short-term memory: Session Context │ ← Current conversation
├──────────────────────────────────────────┤
│ Long Term Memory: MEMORY.md (Selected Memory) │ ← Important Information
├──────────────────────────────────────────┤
│ Daily memory: memory/YYYY-MM-DD.md (original) │ ← Daily record
└──────────────────────────────────────────┘

Specification documents (your knowledge base):

1. PRD.md (Product Requirements Document) - complete specifications. What are you building, who are you building for, what functionality is there, what is in scope and what is explicitly out of scope. User stories, success criteria, non-goals, and specific criteria for each feature. This is your contract. The AI ​​reads this and knows what "done" looks like to you. Don't have this? You’re not building an app, you’re praying for one to appear.
2. APP_FLOW.md - Every page and every user navigation path is recorded in plain English. What triggers each process. Step-by-step sequences and decision points, what happens on success, what happens on error, and screen listings and routing. This prevents the AI ​​from guessing how the user moves within the app. 3. TECH_STACK.md - Every package, dependency, API and tool is locked to an exact version. There is no ambiguity. When the AI ​​sees "Use React", it may choose any version. When it sees "Next.js 14.1.0, React 18.2.0, TypeScript 5.3.3", it builds exactly what you specified. This document eliminates illusory dependencies and random technology choices. 4. FRONTEND_GUIDELINES.md - Your complete design system. Fonts, palettes with exact hex codes, spacing ticks, layout rules, component styles, responsive breakpoints, and UI library preferences. Every visual decision is locked. The AI ​​refers to this to create each component. No more random colors or inconsistent spacing. 5. BACKEND_STRUCTURE.md - database schema, each table, column, type and relationship are defined. Authentication logic, API endpoint contracts, storage rules, and edge cases. If you use Supabase, this document contains the exact SQL structure. AI builds your backend based on this blueprint, not its own assumptions. 6. IMPLEMENTATION_PLAN.md - Build a sequence step by step. Not "Building Apps". More like: step 1.1 initialize the project, step 1.2 install dependencies from TECH_STACK.md, step 1.3 create the folder structure, step 2.1 build the navigation bar component according to FRONTEND_GUIDELINES.md, etc. The more steps there are, the less guesswork the AI ​​has to do. The less the AI ​​guesses, the fewer hallucinations it has. These documents reference each other. PRD defines features, APP FLOW defines how users experience them, TECH STACK defines what to build them with, FRONTEND GUIDELINES defines what they look like, BACKEND STRUCTURE defines how data works, and IMPLEMENTATION PLAN defines the build order. This is your knowledge base. The AI ​​will read these and get everything it needs. Two session files (your persistence layer): CLAUDE.md - This is the file that AI automatically reads first for each session. It contains the rules, constraints, patterns, and context that every AI session must follow. Summary of your technology stack, file naming conventions, component patterns, design system tokens. It is allowed and forbidden. Think of it as an AI operations manual for your specific project. Claude Code can read this from the project root without you even asking. progress.txt - This is the file everyone misses. This file keeps track of what's been done, what's in progress, and what's next. Every time you complete a feature, you update this file. Every time you start a new session, every time you open a new terminal window, every time you switch branches, the AI ​​first reads this file to get contextual memory of your progress. Without it, every new session starts with zero context, along with a bunch of errors. With it, the AI ​​continues exactly where you left off. Here's why this matters: AI has no memory between sessions. When you close the terminal, open a new terminal, or start a new chat, everything is gone. progress.txt is your external memory. It is a bridge between sessions. Update it prayerfully. After each implementation completes functionality, keep detailed records of what was built, what worked, what broke, and what to do next.

[atomicdjt]

For large-project work, I think there is an important distinction between personal memory and project continuity. They should not be the same store.

A useful project-memory layer needs at least four properties that a generic MEMORY.md does not guarantee:

1. Provenance — where did this fact/decision come from: user instruction, repository state, test result, issue, or model inference?
2. Freshness / invalidation — a remembered statement like “the API lives in src/api.ts” must stop being trusted after the repo changes underneath it.
3. Decision state — distinguish proposed, accepted, implemented, verified, and superseded. Otherwise old plans become accidental requirements.
4. Recoverable continuation — a new session should be able to reconstruct what is true now, what was attempted, what failed, and the next unresolved dependency without replaying the whole chat.

So I would keep something like:

user memory       -> stable preferences / identity
project facts     -> repo-derived, refreshable
project decisions -> provenance + status + supersedes
session journal   -> append-only work log
working summary   -> regenerated projection, not source of truth

The last point matters a lot: progress.txt or a generated summary is excellent as a fast bootstrap artifact, but it should be treated as a projection of authoritative project state, not the authority itself. Otherwise one stale summary can poison every subsequent session.

A practical implementation could attach {source, observed_at, source_revision, confidence/status} to durable memories and invalidate repo-derived entries when their source revision no longer matches. That would make long-running Kimi CLI projects much safer than simply retaining more tokens or more markdown forever.

[atomicdjt]

@yun520-1 agreed on the invalidation-trigger distinction — decay and invalidation solve different problems. One small schema distinction I would preserve, though: retention class and decision lifecycle are orthogonal.

CORE / LEARNED / EPHEMERAL answers how this memory is retained/retrieved. proposed / accepted / implemented / verified / superseded answers what state the decision is in. A LEARNED decision can later become superseded without ceasing to be useful historical evidence, so I would avoid encoding lifecycle only through the memory layer.

Something like this stays composable:

memory_class: CORE | LEARNED | EPHEMERAL
decision_status: proposed | accepted | implemented | verified | superseded | null
freshness: current | stale | unknown
sources: [{ path/ref, revision/content_hash }]
supersedes: [record_id]

For repo-derived facts, I would also avoid invalidating everything on every repository commit if possible. Bind a fact to the smallest source set that supports it (for example file/blob hashes or explicit source refs), mark it stale when one of those dependencies changes, and regenerate the working projection from records that still pass freshness + status gates. That gives you selective invalidation instead of either trusting stale memory or throwing away valid memory on unrelated edits.

Three useful regression cases would be: (1) unrelated file edit leaves a fact current; (2) supporting source edit marks the fact stale before retrieval can treat it as current truth; (3) a superseded decision remains queryable as history but is excluded from the default planning context.

That would keep the long-term store useful as evidence while making the session bootstrap a safe projection of current state rather than a growing pile of remembered assertions.