AI Agent 生产级记忆系统目录结构

基于 OpenClaw 多 Agent 团队的真实生产环境，历时 17 天打磨。 为什么 Agent 需要记忆系统？ AI Agent 有一个致命缺陷：它没有真正的记忆。...
第一部分：为什么 Agent 需要记忆系统

1.1 Context Window 不是记忆

每个 LLM Agent 都有一个致命弱点：上下文窗口（Context Window）不等于记忆。
上下文窗口是临时的。当对话过长，系统会自动压缩（Compaction），丢弃早期内容。当 session 结束，一切归零。Agent 醒来时，对之前发生的事情一无所知——除非它写进了文件。

1. Session 1: 做了重要决策 A → 没写进文件 → Compaction
2. Session 2: Agent 完全不知道决策 A 的存在 → 重复讨论 → 浪费时间

复制代码

这不是理论问题。在实际运行中，我们观察到：

• Agent 在不同 session 中重复提出相同建议
  
• 跨频道（Telegram、Discord）的信息完全隔离
  
• Compaction 后 Agent 丢失了关键上下文
  

1.2 设计哲学

我们的核心原则只有一条：

文件 = 事实来源。你不写进文件的东西 = 你从来不知道的东西。

Agent 的记忆不在它的"脑子"里，而在磁盘上。Context window 是工作台，文件才是仓库。
这意味着：

• 所有重要信息必须实时写入文件
  
• Agent 每次启动都从文件读取状态
  
• 不依赖"记得去检查"，而是靠系统触发（cron、heartbeat）
  

1.3 本方案的定位

我们选择了 Markdown 文件 作为记忆的主要载体，而不是纯数据库方案。原因：

1. | 维度       | Markdown 文件               | 纯数据库     |
2. | ---------- | --------------------------- | ------------ |
3. | 可解释性   | 人类可直接阅读和编辑        | 需要查询工具 |
4. | 调试难度   | 打开文件就能看              | 需要 SQL/API |
5. | 版本控制   | git 天然支持                | 需要额外方案 |
6. | Agent 读写 | 原生支持（Read/Write 工具） | 需要额外集成 |
7. | 检索效率   | 较低（需要辅助索引）        | 较高         |

复制代码

我们的答案是混合方案：Markdown 作为事实来源（可读层），QMD 向量数据库作为检索加速层。写入 Markdown，索引自动同步。
第二部分：三层架构

2.1 短期层：

NOW.md
用途： Agent 的"工作台"，记录当前状态、优先级、阻塞项。
特点：

• 每次 heartbeat 覆写（Write），不追加
  
• 只保留当天的完成项
  
• 是 Compaction 的"救生筏"——Agent 压缩上下文后首先读这个文件
  

示例结构：
[code]# NOW.md - Workbench​>
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！