AI Agent 记忆管理是决定 agent 好不好用的关键。长期跑 agent 的人多半会踩到「记忆」的坑：agent 完全忘记它是谁、在帮谁做事、之前做过什么。每次新对话开始，它就像刚入职的新人，需要从头介绍一切。

下面整理的是踩坑三个月后沉淀出来的记忆架构，重点不在技术名词，而在设计原则。

TL;DR：记忆管理的核心是「让每份文件保持短小」和「让位置本身就是索引」。不要先冲向量搜索，先把文件结构理清楚。

为什么 AI Agent 会失忆

语言模型没有真正的记忆。

Claude 也好、ChatGPT 也好，每次对话开始时都是一张白纸。会「记得用户」，是因为有东西在对话开始前把信息塞进了 prompt。

这个「塞进去的东西」就是 agent 的记忆系统。

问题出在 context window。这是语言模型一次能处理的文字量上限。Claude Opus 原生开放到 1M token，听起来很多，但 system prompt、工具定义、对话历史、记忆文件全加起来，很容易就冲到数万 K。

超过之后会怎样？模型开始忽略早期的内容。精心写的安全规则、行为准则，可能在长对话中被「挤出去」。Agent 的行为就开始飘。

惨痛经验：把所有东西塞进同一个文件

最初搭 OpenClaw 时，记忆系统很简单：一个 MEMORY.md 文件，什么都往里面丢。偏好写进去、项目状态写进去、工具使用规范写进去、对话记录也写进去。

两个月后这个文件长到 800 行。

记忆系统的坑

问题开始浮现。Agent 回应变笨、变蠢了，因为每次都要处理一大坨文字。更严重的是，它开始搞混信息：把 A 项目的规则套用到 B 项目，把上周的待办清单当成今天的。

用 token 计算工具量了一下：光是加载这份记忆文件，就吃掉 context window 的相当高比例。加上 system prompt 和工具定义，对话还没开始，已经用掉超过三成。剩下的空间要放对话历史和实际工作内容。

agent 表现越来越不稳定，根因在这。

三层记忆架构

把记忆系统推翻重建之后，灵感来自人脑的记忆分类：用户不会把所有记忆同时放在意识里，大部分存在「需要时才取用」的状态。

L0：索引层（每次自动加载）

一个文件：MEMORY.md，大约 60 行。

它不存任何实际内容，只做一件事：告诉 agent「什么信息在哪里」。

## L0 Boot（自动加载）
- SOUL.md：核心价值
- MIND.md：演化中的人格
- AGENTS.md：操作规则

## L1 Session（每次加载）
- brain.md：当下工作记忆，类似速记版
- TOOLS.md：本机工具和环境

## L2 On Demand（按需加载）
- memory/user/profile.md：基本信息
- memory/user/preferences.md：偏好设置
- projects/*/context.md：项目脉络

Agent 每次启动先读这份索引，根据当前任务，判断需要读哪些 L1 和 L2 的文件。

L1：工作记忆（每个 session 加载）

brain.md 是每天更新的文件。里面放的是「现在在做什么」「哪些事情卡住了」「等谁确认」。

这个文件大约 80-120 行，每天清理一次。昨天完成的任务移到 journal，只留进行中的。

TOOLS.md 列出 agent 能用的所有工具和 API。Agent 读完就知道自己「能做什么」，不会去尝试不存在的工具。

L2：主题记忆（按需加载）

这是拆分后最大的改善。

以前所有东西挤在一个文件里，现在按主题拆开：

  • memory/user/profile.md：基本信息，30 行
  • memory/user/preferences.md：沟通和工作偏好，40 行
  • memory/topics/：稳定的主题知识，每个文件不超过 100 行
  • projects/*/context.md：每个项目的脉络和注意事项

聊到保险的时候，agent 才去读保险相关的 context；聊到健身的时候，才读健身的。不相关的文件完全不加载。

效果

重建之后，context window 的基础占用从超过三成降到一成五左右。Agent 的回应质量明显提升，混淆的情况几乎消失。

维护也变容易。哪个主题的信息过时了，直接去那个文件改，不用在大文件里找。

五个设计原则

踩坑之后沉淀出五个原则，每次调整记忆系统都会对照。

原则一：位置就是索引

不要搞复杂的搜索机制。把文件放在正确的位置，位置本身就告诉 agent 该什么时候读它。

projects/health/context.md 放在 health 项目文件夹里。Agent 在处理 health 相关任务时自然会去那个文件夹找东西。不需要向量数据库，不需要 embedding search。

原则二：每份文件不超过 200 行

超过 200 行就该拆。

200 行大约是 3000-4000 token，对 agent 来说是「读完之后还能好好处理」的范围。超过这个量，建议将内容外部化，另存新的文件。

原则三：一条信息只存一个地方

SSoT（Single Source of Truth）。同一条信息存在两个地方，迟早会不一致，然后 agent 就会搞混。

判断方法：如果某个项目消失了，这条信息在其他场景还会用到吗？不会 → 放项目里。会 → 放个人文件。

原则四：区分「稳定」和「流动」

有些信息很少变（生日、偏好的沟通方式）。有些信息每天在变（今天的待办、这周的 sprint 进度）。

稳定的信息放在 L2 的 profile 和 topics 里，很少动。流动的信息放在一个特殊的文件里，每天更新。把这两种东西混在一起，是记忆系统变混乱的主因。

原则五：定期蒸馏（压缩）

记忆会累积。三个月前的 sprint 记录、半年前的对话心得，不清理，文件就会越来越肥。

每周做一次记忆 review。重要的洞察蒸馏到 MIND.md（agent 的核心认知），过时的记录归档到 archive/。筛选标准很严格：只有影响 agent 行为的「身份级」洞察才会留在核心文件里。

记忆架构设计

可以直接套用的文件结构

要为自己的 AI agent 建记忆系统，建议的起点：

memory/
├── MEMORY.md          # 索引（60 行以内）
├── brain.md           # 今天在做什么（每天更新）
├── user/
│   ├── profile.md     # 个人基本信息
│   └── preferences.md # 个人偏好
├── topics/
│   ├── topic-a.md     # 稳定的主题知识
│   └── topic-b.md
└── archive/           # 过期的东西

每个文件开头写一行注解，说明这个文件是什么、什么时候该读它。Agent 看到这行就知道要不要继续读下去。

让 AI 帮你设计记忆系统：三组可复制的 Prompt

设计记忆系统最难的一步通常是开始动手。技术其实都有公开资料可以查，卡住的是「该怎么把自己的东西分类」。下面三组 prompt 可以直接丢给 Claude 或 ChatGPT，让它帮忙起一个初版架构，再照着实际使用情境调整。

Prompt 1：让 AI 分析现有的文件结构

场景： 手上已经一堆零散的 .md 文件、Google Doc、或 Notion 页面，想整理成 agent 可以用的记忆系统。 适用工具： Claude（推荐，长 context 处理力最好）、ChatGPT 使用方式： 把现有的目录结构或文件清单贴进去，让 AI 帮忙分类。

想把下面这些文件整理成 AI agent 的记忆系统，请你帮忙做三件事：

1. 把文件分成三类：
   - L1（每次对话自动加载，例如个人偏好、当前工作）
   - L2（按主题加载，例如特定项目、特定知识领域）
   - L3（历史存档，平常不加载）

2. 找出明显的问题：
   - 有没有重复的信息放在不同文件
   - 有没有文件太长需要拆分（超过 200 行）
   - 有没有文件内容太杂应该分成多个文件

3. 给出一个推荐的新文件结构，包含：
   - 每个文件建议的路径和名称
   - 每个文件应该放什么内容
   - 哪些旧文件要合并或拆分

文件清单：
[贴上文件清单，可以用 ls -la 或 tree 命令的输出]

使用情境：
[描述主要会用这个 agent 做什么，例如：日常工作助理、写作伙伴、代码 reviewer]

第一次跑这个 prompt 会拿到一个初版建议。不要全盘照收，挑认同的部分先改，跑一周看看实际用起来顺不顺，再来第二轮调整。

Prompt 2：让 AI 帮你规划记忆分层

场景： 还没有现成文件，想从零开始设计记忆分层。 适用工具： Claude、ChatGPT、Gemini

要为 AI agent 设计一套记忆系统，请你根据以下情境，给出一个三层的记忆架构。

情境：
  身份：[例如：自由工作者、学生、产品经理]
  主要任务：[例如：写作、项目管理、研究资料整理]
  每天会跟 agent 讨论的事：[列三到五项]
  偏好的互动方式：[例如：中文、直接、不要绕圈]
  Context window 限制：[例如:Claude Opus/ChatGPT 1M]

请设计：

L0（索引层，每次都读）
  一份 MEMORY.md 的内容，列出所有文件的路径和用途。

L1（工作记忆，每个 session 加载）
  推荐 2 到 3 个文件，各自负责什么、预估几行。

L2（主题记忆，按需加载）
  推荐 4 到 8 个主题文件，各自放什么内容、什么时候会被触发加载。

请给出每个文件的：
  1. 文件路径和名称
  2. 预估行数
  3. 应该包含的内容（条列）
  4. 更新频率（每次、每天、每周、每月）

最后算一下：总共占 context window 大概多少 token，确认有没有超过 20%。

算 token 这一步很重要。第一次设计时没算，做完发现 L0+L1 就吃掉 25% 的 context，后来只好砍掉两个文件。请 AI 帮忙算一遍可以省掉这个坑。

Prompt 3：让 AI 帮你写 brain.md 模板

场景： 决定开始用 brain.md 记工作记忆，但不知道该放什么、怎么排。 适用工具： Claude、ChatGPT

请设计一份 brain.md 模板，这份 AI agent 每次对话会自动读的「当下工作记忆」文件。

工作模式：
  同时进行的项目数：[例如：3 个]
  每天会换项目切换几次：[例如：4 到 6 次]
  常卡住的原因：[例如：等别人回复、信息不足、技术难题]
  希望 agent 看完这份 brain.md 之后能做什么：[例如：掌握今天在忙什么、提醒等哪些回复、知道有没有卡住]

请写一份模板，包含：

1. 文件头注释：一句话说明这份文件是什么、更新规则
2. 「今天的焦点」区块：今天最重要的一到两件事
3. 「进行中」区块：每个项目用什么结构记进度
4. 「等回复」区块：谁、等什么、等多久
5. 「卡住的地方」区块：问题、目前尝试过的、打算下一步怎么办
6. 「今天的小事」区块：15 分钟内可以收掉的琐事
7. 底部：更新时间戳记

请控制在 80 行以内，每个区块用实际示例填好（标记为示例，之后会改掉）。
风格：口语、简短，不要正式报告的语气。

模板拿到之后，第一周会觉得很多栏位用不到，第二周开始会发现有些东西想记但没有栏位。这是正常的，模板本来就该跟着使用节奏演化。

RAG 和向量数据库：另一种记忆管理方式

文件系统不是唯一做法。记忆量很大（几百份文档、几千页的知识库）时，用 RAG（Retrieval-Augmented Generation）搭配向量数据库会更合适。

RAG 的运作方式：把文档切成小段、用 embedding 模型转成向量、存进向量数据库（像 Pinecone、Weaviate、Chroma）。Agent 需要回答问题时，先用语义搜索找出相关的段落，再把这些段落喂进 prompt 让模型生成回复。

Dify 的 RAG 功能是开箱即用的：上传 PDF 或 Word，它自动做切段、embedding、建索引。对客服机器人或知识库问答这类场景很方便。

实战上选文件系统的常见场景：记忆量只有几十个 .md 文件，用向量搜索反而多此一举。RAG 的优势在有上百份文档要管时体现出来，比手动维护文件结构有效率。

不同工具的记忆管理比较

工具记忆方式自由度适合场景
Claude Code文件系统（.md/.json）最高，完全自订个人工作流、需要精细控制
Dify内建向量 DB + RAG中，平台提供框架知识库问答、客服机器人
Coze平台内建低，无法自订底层轻量使用、不需复杂记忆
自建完全自订最高有特殊记忆需求的商业产品

选记忆方案的关键问题是：记忆量有多大、需不需要语义搜索、愿不愿意花时间维护架构。量小、结构清楚就用文件系统；量大、需要搜索就用向量数据库。

踩坑补充

工作速记版 brain.md 膨胀

brain.md 应该是工作记忆，轻薄短小。曾有一段时间忘了清理，它长到 300-500 行。里面有两周前的待办、一个月前的进度更新、早就结案的 bug 记录。

Agent 加载这份 brain.md 之后，把一个月前的 bug 当成今天的任务去修，修了半小时才被发现。

可靠的规则：brain.md 每天清理，超过三天的项目如果还在，要嘛更新状态，要嘛移到 journal。这边如果你有搭配 OpenClaw（龙虾），可以使用 cron job 进行 daily optimization 来辅助。

记忆冲突

曾经在 profile.md 里写「偏好用繁体中文」，但在某个项目的 context.md 里写「这个项目用英文」。Agent 碰到需要用中文还英文的判断时，两份文件都读到了，结果写出一段中英夹杂的东西。

解法是在 context.md 里明确写「本项目语言：英文（覆盖全域偏好）」，让 agent 知道有冲突时该听谁的。

FAQ

AI Agent 的记忆存在哪里？

大部分 agent 框架用文本文件存在本机或云端。每次对话开始时，把相关的记忆文件内容喂进 prompt。实战常用的是 .md 文件系统放在本机。

记忆文件多大会出问题？

取决于模型的 context window 大小。以 Claude Opus 为例，原生 context window 是 1M token。经验法则是超过 1000 行就该拆，总加载量控制在 context window 的 20% 以内。

怎么让 agent 知道该读哪些记忆？

用一个索引文件列出所有记忆文件的位置和用途。Agent 每次启动先读索引，根据当前任务判断要不要读某个主题文件。靠的是索引文件的清楚描述，不是花俏的算法。

什么是 RAG？AI Agent 如何用它？

RAG 是检索增强生成。把文档切段、转向量、存进数据库，agent 回答问题时先搜相关段落，再根据搜到的内容生成回复。Dify 内建这功能，Claude Code 可以搭配外部向量 DB。

AI Agent 如何记住对话？

模型本身不会记。靠的是每次对话开始前，把之前的摘要或记忆文件加载 prompt。实战做法是蒸馏重要信息成短文档，存在固定位置，agent 启动时自动读取。

记忆系统会拖慢回应速度吗？

会。加载越多记忆，prompt 越长，处理越慢。基础加载控制在 context window 的 15-20%，回应速度不会有明显感觉。超过 30% 就会变慢。

用向量数据库还是文件系统管记忆？

看场景。记忆量大、需要语义搜索就用向量数据库。记忆量在几十个文件以内、结构清楚，文件系统更简单可控。

延伸阅读

小企鹅的经验

主力 stack 是 OpenClaw 上的 Opus / Sonnet / Codex 三 agent，记忆全部走文件系统（.md），不接向量数据库。实战下来最痛的就是记忆这块：要处理好记忆又不让 agent 失忆非常困难，诀窍就是上面写的那五条原则 ， 越干净越能记得住。记忆量不大、需要随时手动编辑，是选文件系统而不是 RAG 的两个主因。

整理：Penna｜小企鹅 Penchan