先关注后阅读，娇姐怕失去上进的你

先从一个问题开始

假设你是一位助理，每天要帮老板处理事务。老板在第一天就给了你一本厚厚的工作手册——足足 500 页。

情景 A：每次开始工作前，你把这 500 页手册从头到尾背一遍，才能开始干活。

情景 B：你只记住手册的目录，需要哪章就翻哪章。

显然，情景 B 更聪明。但绝大多数 AI Agent 今天的工作方式，恰恰更像情景 A。

重点：如何让 AI Agent 像聪明的助理一样——只在需要时才”翻书”，而不是每次都”背全书”。这件事能把 token 消耗降低 90% 以上，同时不损失任何知识。

什么是 Token？先建立直觉

Token 是 AI 处理文字的基本单位。中文大约每 1–2 个字对应 1 个 token，英文每 3–4 个字母对应 1 个 token。粗略记：1000 个中文字 ≈ 1000 个 token。

每次与 AI 对话，系统都需要把”对话上下文”打包发送给模型。这个上下文包括：

系统设定（告诉 AI 它是谁、有什么规则）
记忆文件（AI 需要”记住”的知识）
本次对话内容

上下文里的每一个 token，都是实实在在的成本。文件越大，每次对话花费越高。

OpenClaw 的两层记忆架构

OpenClaw 官方文档定义了两种记忆层，它们在加载方式上完全不同：

第一层：每日日志（自动加载）

memory/YYYY-MM-DD.md — 每天的对话日志，仅自动加载当天和昨天两个文件，其余历史日志不会自动注入。

第二层：长期记忆（条件加载）

MEMORY.md — 精心整理的长期知识库，仅在主会话（私聊）中加载，群组对话中不会加载，以避免个人隐私信息泄漏到群组上下文。

注意：MEMORY.md 并非”每次对话都加载”，而是仅限私聊主会话。这是 OpenClaw 官方设计，用于保护个人隐私。

按需读取的两个工具

对于不自动加载的历史日志和其他记忆文件，OpenClaw 提供了两个专门的按需读取工具：

工具	作用	适用场景
memory_search	语义搜索，BM25 + 向量混合检索	关键词模糊、不记得具体文件名时
memory_get	精确读取指定文件或特定行范围	知道具体文件路径，需要完整内容时

两者分工明确：memory_search 负责”找到”，memory_get 负责”读取”，平时都不会自动消耗 token。

一个具体的对话示例

以下展示了”按需读取”在 OpenClaw 实际工作中的流程：

用户说

帮我诊断一个系统性能问题。

AI 思考

用户要诊断问题，我先用 memory_search 找一下是否有相关的诊断规范。

AI 执行（两步）

1. 调用 memory_search，查询关键词”诊断规范” → 命中 memory/diagnostic-protocol.md

2. 调用 memory_get，精确读取该文件完整内容

只有这次对话消耗了这部分 token，下次对话不会自动加载它。

AI 回复

根据诊断规范，我将从以下几个维度检查你的系统……（基于刚读取的文件给出专业回答）

提示：关键点在于——AI 知道”去哪里找”信息，而不需要”一直持有”这些信息。

数字说话：两种方案的 Token 消耗对比

方案 A：把所有信息塞进 MEMORY.md（不推荐）

# MEMORY.md（50 KB）

## Agent 使用频率分析
[详细的表格和数据，5,000 tokens...]

## Token 消耗统计
[详细的统计数据，3,000 tokens...]

## 定时任务配置
[完整的配置说明，2,500 tokens...]

## 诊断规范
[详细的诊断步骤，2,000 tokens...]

场景	Token 消耗
每次对话基础消耗	≈ 12,500 tokens
一天 10 次对话	≈ 125,000 tokens
大部分时候	这些详细信息根本用不到，全部白白浪费

方案 B：精简索引 + 按需读取（推荐）

# MEMORY.md（2 KB，只有索引）

## 重要记忆索引
### 2026-03-13：性能优化
- 文件：memory/2026-03-13.md
- 关键发现：关闭 Cron 任务节省大量 token（个人实测）

### 诊断规范
- 文件：memory/diagnostic-protocol.md
- 适用场景：系统诊断的完整步骤

详细内容存放在独立的 memory/*.md 文件中，用 memory_search / memory_get 按需读取。

场景	Token 消耗
每次对话基础消耗（只含索引）	≈ 500 tokens
需要详细文件时（按需读取）	额外 5,000 tokens（仅该次）
一天 10 次对话（1-2 次需要详细文件）	≈ 10,000–15,000 tokens

成功：125,000 → 15,000，每天节省约 110,000 tokens，降幅约 88%。

索引机制：AI 怎么知道去哪里找？

这是整个方案的灵魂：MEMORY.md 不存储详细内容，只存储”索引”。

## 重要记忆索引

### 2026-03-13：性能优化与定时任务
- 文件：memory/2026-03-13.md
- 内容：Agent 使用频率、Token 消耗分析、定时任务配置
- 适用场景：讨论性能优化或 Cron 配置时

### 诊断规范
- 文件：memory/diagnostic-protocol.md
- 适用场景：用户报告系统异常时

### 菜谱收藏
- 文件：discoveries/recipes.md
- 适用场景：用户询问食谱相关问题

有了这个索引，实际对话流程变成：

1. 用户提问：”定时任务怎么配置？”

↓

2. AI 扫描 MEMORY.md 索引，匹配到相关文件

↓

3. 调用 memory_get，精确读取 memory/2026-03-13.md

↓

4. 基于读取到的详细内容，给出专业回答

类比：图书馆 vs. 背书

角色	低效方式（方案 A）	高效方式（方案 B）
MEMORY.md	整本百科全书（每次都读完）	图书馆目录索引（轻薄，快速检索）
memory/*.md	不存在（全塞进一个文件）	各章节书籍（需要时才取下来）
检索工具	无（全量注入）	memory_search + memory_get
知识丢失？	不会，但代价高昂	不会，随时可以找到

常见疑问解答

Q：AI 会”忘记”这些知识吗？

不会。OpenClaw 的记忆源头是磁盘上的 Markdown 文件，模型”记住”的就是写进这些文件的内容。索引始终在 MEMORY.md 里，详细文件一直在 memory/ 目录，随时可用 memory_get 精确读取。

Q：memory_search 搜不准怎么办？

OpenClaw 采用 BM25 + 向量混合检索，并支持切换到 QMD 本地引擎进一步提升召回率。如果查询较模糊，可以在索引的”适用场景”字段写得更具体，帮助 AI 更准确地触发读取。

Q：这个思路只适用于 OpenClaw 吗？

不是。OpenClaw 的记忆架构已被提取为独立开源库（memsearch），可插入任何 Agent 框架。核心原则通用：Markdown 文件是事实来源，向量索引是检索加速层，两者配合实现”轻量常驻 + 按需读取”。

总结：三个关键原则

#	原则	实践方式
1	轻量化常驻文件	MEMORY.md 只放索引，不塞详细内容
2	详情按需读取	用 memory_search 语义搜索，memory_get 精确读取
3	索引写清楚	“适用场景”字段越具体，AI 判断越准，读取越及时