ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

星辉: n8n转化-I-Spent-5-Days-Debugging-OpenClaw-Agent-Memory-中文版-2026-03-31

Browse Source
This commit is contained in:
weishen
2026-03-31 10:26:43 +08:00
parent 72ffc01856
commit 05fddbc0cf
1 changed files with 275 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

275
openclaw/content-out/I-Spent-5-Days-Debugging-OpenClaw-Agent-Memory-中文版.md Normal file
View File

@@ -0,0 +1,275 @@
# 5天血泪史：我的AI助理为什么总失忆？OpenClaw内存调试全记录
当你的AI助理像个金鱼一样只有7秒记忆，每次对话都要从头开始——这不是科幻，而是我花了5天时间解决的现实问题。从对话压缩到搜索失效，从系统臃肿到模型切换失忆，这是我用血泪换来的10条OpenClaw内存管理黄金法则。
# 5天血泪史：我的AI助理为什么总失忆？OpenClaw内存调试全记录
> 当你的AI助理像个金鱼一样只有7秒记忆，每次对话都要从头开始——这不是科幻，而是我花了5天时间解决的现实问题。
我叫Ramya，正在开发TweetSmash和LinkedMash两款社交书签工具。我的AI助理名叫Chiti，它运行在Telegram上，负责两个SaaS产品的客户支持、起草推文、管理发票，还要协调我和联合创始人的跨时区工作。
它就像我的初级员工——直到它开始频繁失忆。
不是那种微妙的遗忘。我花一个小时配置每日定时任务，切换模型后，Chiti表现得像我们从未交谈过。我提到两天前的决定，它一脸茫然。让它继续任务，它却从头开始。
于是我停止了功能开发，花了5天时间专门修复内存问题。以下是我发现的一切、我搞砸的一切，以及真正有效的一切。
## Day 1：长对话后的集体失忆
第一个问题描述简单，诊断痛苦。
长对话后，Chiti开始丢失早期上下文。不是逐渐丢失，而是突然消失。20条消息前告诉它的事情，没了。会话开始时做的决定？从未发生。
**罪魁祸首是压缩机制。** 当对话填满上下文窗口时，OpenClaw会将旧消息压缩成摘要，为新消息腾出空间。摘要抓住了要点，但丢掉了细节——姓名、数字、具体决定，统统消失。
> “这是设计使然。上下文窗口是有限的。但默认行为对一切一视同仁，这意味着你精心设计的第三条消息指令，和第七条消息的闲聊得到了相同待遇。”
**我的解决方案：**
启用压缩前的内存刷新。这告诉代理在压缩器运行前将重要上下文写入磁盘。
```json
{ "compaction": { "memoryFlush": { "enabled": true, "softThresholdTokens": 4000 } } }
```
当会话接近上下文限制时，OpenClaw触发一个静默回合，提醒代理在压缩擦除前将持久事实保存到memory/YYYY-MM-DD.md。代理写入重要内容，压缩运行，即使上下文摘要丢失，重要内容仍保留在磁盘上。
**关键洞察：**
压缩不是敌人。压缩过程中丢失信息才是。修复方法是确保任何值得记住的内容在压缩器触及前写入文件。如果只在上下文窗口中，它是临时的。如果在磁盘上，它就能存活。
## Day 2：搜索返回垃圾结果
随着每日日志积累和MEMORY.md增长，我需要代理真正找到东西。内置的内存搜索返回不相关结果或错过明显匹配。
**问题是搜索后端。** OpenClaw默认的基于SQLite的搜索使用向量嵌入（语义相似性）查找相关块。这对广泛查询有效，但在精确匹配上挣扎。我搜索特定客户名，却得到关于完全不同主题的结果，只是因为使用了相似语言。
**我的解决方案：**
切换到QMD作为内存搜索后端。QMD结合了BM25（关键词匹配）、向量嵌入和重新排序器。所以当我搜索“Charles支付失败”时，它找到包含这些确切词语的结果AND语义相关的结果，然后按相关性重新排序。
**关键洞察：**
纯语义搜索理论上听起来不错，但在专有名词、具体数字和确切短语上失败。混合搜索（关键词+向量+重新排序）对现实世界代理内存明显更好。如果你的代理找不到你知道在其文件中的内容，搜索后端可能是瓶颈，而不是文件本身。
## Day 3：代理找到了但不使用
这是最令人沮丧的一天。我确认搜索有效，可以手动查询并获得正确结果。但在实际对话中，即使相关上下文明显存在于内存中，Chiti也不会检索。
**问题是检索不是自动的。** 代理必须决定搜索。如果对话没有触发正确线索，它就不会查找。
**我的解决方案：**
在启动序列中添加明确的检索指令。不是希望代理在需要时搜索，而是告诉它何时搜索：
> 开始任何任务前：
> - 搜索每日日志获取相关上下文
> - 检查LEARNINGS.md获取此类任务的规则
> - 如果提到客户，搜索其历史记录
我还建立了检索测试。我在每日日志中植入特定标记——类似“标记：2026-02-20 — 在声称代码已推送前始终检查git状态。”然后等待，开始新会话，问：“昨天的标记是什么？”如果代理找到它，检索有效。如果没有，某些地方出错了。
**关键洞察：**
“信息存在”和“代理使用信息”之间有区别。你需要两者。搜索基础设施处理第一部分。启动指令和检索习惯处理第二部分。分别测试两者。
## Day 4：让它对压缩安全
此时我有了内存刷新、混合搜索和检索指令。但在特定场景中我仍然丢失上下文：非常长的会话，压缩运行多次。
**问题是内存刷新每个压缩周期只触发一次。** 如果会话足够长，有两三次压缩，只有第一次得到刷新处理。之后的一切都处于风险中。
**我的解决方案：**
配置上下文修剪与压缩协同工作：
```json
{ "contextPruning": { "mode": "cache-ttl", "ttl": "6h", "keepLastAssistants": 3 } }
```
这会在6小时后积极修剪旧上下文，同时保留最后3个助理响应。结合内存刷新，这意味着代理早期将重要内容写入磁盘，旧上下文在导致溢出前被清理。
**关键洞察：**
长会话是内存系统真正接受测试的地方。短对话很少触及压缩。是2小时的深度工作会话中你会丢失上下文且无法找出原因。在负载下测试你的内存系统，而不仅仅是在快速聊天中。
## Day 5：系统提示词臃肿了28%
这是所有事情都清晰的一天。我运行了/context detail并盯着数字。
我的代理在读取我的消息前加载了11,887个令牌的系统提示词。51个技能，其中20个我从未使用。MEMORY.md是200行公司维基，每个会话都加载。我有两个竞争的启动序列——一个在BOOT.md中（OpenClaw甚至不识别），一个埋在AGENTS.md的200行深处。
最糟糕的是，每次切换模型，Chiti忘记一切。没有交接协议。没有当前上下文的写回。直接消失。
**根本原因：**
OpenClaw在每个新会话上自动读取这些文件：AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、HEARTBEAT.md、MEMORY.md。
其他一切——LEARNINGS.md、每日日志、文档、参考文件——代理必须自己使用工具读取它们。如果读取这些文件的指令不在自动加载的文件中（特别是AGENTS.md），代理永远不会看到它们。
我的BOOT.md有整个启动序列。但OpenClaw不自动加载BOOT.md。所以指令就坐在那里，未读，什么都不做。
**我的解决方案：**
我进行了全面审计和清理：
- 将启动序列移到AGENTS.md顶部（启动指令唯一可靠的位置）
- 删除BOOT.md（OpenClaw不识别）
- 删除BOOTSTRAP.md（一次性入职文件，已完成，每个会话浪费361个令牌）
- 通过将参考文档移到docs/文件夹，将MEMORY.md从200行精简到90行
- 移除20个未使用的营销技能，每个会话消耗3,000个令牌
- 添加写入纪律：每个任务记录其结果，每个错误变成规则
- 添加交接协议：在任何模型切换或会话结束前，代理将当前上下文写入每日日志
**结果：**
- 系统提示词：11,887 → 8,529个令牌
- 技能：51 → 32
- 会话令牌：18,280 → 14,627
- 轻了28%。相同的代理。相同的模型。只是更少噪音。
**关键洞察：**
真正的修复不是添加更多文件。而是移除那些什么都不做的文件。系统提示词中的每个令牌都是代理在每个消息上携带的开销。未使用的技能、臃肿的内存文件、系统甚至不读取的文件——它们都在默默累积。
## 我希望在第1天就知道的10条规则
### 1. 只有这些文件自动加载：AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、HEARTBEAT.md、MEMORY.md
其他一切都需要AGENTS.md中的明确读取指令。如果不在启动序列中，代理不会看到它。BOOT.md在OpenClaw中不是真实存在。我用了好几周。它什么都没做。
### 2. 启动序列放在AGENTS.md顶部
不要在中间。不要在底部。最顶部。自动加载的文件被注入系统提示词，所以启动指令需要是代理处理的第一件事。
### 3. 写入纪律比读取纪律更重要
大多数人设置文件供代理读取，但从不强制执行写回。如果代理不将决定、结果和错误记录到磁盘，这些东西只存在于上下文窗口中。而上下文窗口会被压缩。写回是临时上下文变成永久记忆的方式。
### 4. 任务期间永远不要直接写入MEMORY.md
每日日志是原始且仅追加的。MEMORY.md是策划的长期记忆。如果你让代理向MEMORY.md转储任何内容，几周内它就会膨胀成200行的混乱。在定期审查期间（心跳或定时任务），通过从最近的每日日志中提炼见解来策划MEMORY.md。
### 5. LEARNINGS.md是最被低估的文件
代理犯的每个错误都应该变成一行规则。“在声称代码已推送前永远不要不检查git状态。”“不要在群聊中读取完整的MEMORY.md。”“在安排前始终确认用户的时区。”这些规则会复合。几周后，你的代理就有了从自己失败中构建的个人操作手册。
### 6. 测试检索，不仅仅是存储
存储信息和检索信息是不同的问題。我有文件被索引且可搜索但从未被访问，因为代理不知道查找它们。植入标记，跨会话测试，跨模型切换测试。如果代理找不到你昨天存储的内容，存储就不重要。
### 7. 交接协议是模型切换的修复
OpenClaw代理在切换模型时丢失所有上下文。新模型以新鲜上下文窗口开始——它只看到自动加载的文件。没有在切换前将当前状态转储到每日日志的交接协议，新模型不知道发生了什么。这是我几周来最大的痛点。
### 8. 定期运行/context detail
这个命令准确显示什么在消耗你的令牌。你忘记安装的技能，你未注意到的增长的文件，你从未使用的工具。我找到了20个未使用的技能，每个会话燃烧3,000个令牌。这是每个消息上3,000个令牌的开销，用于我从未碰过的功能。
### 9. 混合搜索击败纯语义搜索
BM25（关键词）+ 向量（含义）+ 重新排序比单独向量给出明显更好的结果。客户名、具体数字、确切短语——语义搜索会错过这些。关键词搜索抓住它们。两者都用。
### 10. 压缩不是敌人。未写入的上下文才是
我在意识到修复更简单之前花了几天时间对抗压缩：确保任何重要内容在压缩运行前写入文件。内存刷新自动处理这个。如果在磁盘上，它能在压缩中存活。如果只在对话中，它就有风险。
## 我的当前设置
```
workspace/
├── AGENTS.md (启动序列 + 写入纪律 + 交接协议)
├── SOUL.md (个性和行为)
├── IDENTITY.md (名称、角色)
├── USER.md (所有者信息)
├── TOOLS.md (工具使用指南)
├── HEARTBEAT.md (自主检查行为)
├── MEMORY.md (策划的长期记忆，~90行)
├── PROTOCOL_COST_EFFICIENCY.md
├── learnings/
│ └── LEARNINGS.md (错误中的规则)
├── memory/ (每日日志：YYYY-MM-DD.md)
├── docs/ (参考文档移出MEMORY.md)
│ ├── tweetsmash-arch.md
│ ├── knowledge-transfer.md
│ ├── infrastructure.md
│ └── group-chat-rules.md
└── skills/ (32个技能，从51个减少)
```
系统提示词：8,529个令牌。会话令牌：14,627个，占200,000上下文窗口的7.3%。代理启动，读取所需内容，写入所学内容，在模型切换前交接上下文。
我花了5天时间到达这里。大部分是忘记“更多文件等于更好内存”的假设。不是这样。纪律才是。我的实验仍在继续。
---
**关于作者：**
我正在与联合创始人一起开发TweetSmash和LinkedMash——带有社交书签功能的工具。我在X上分享我在生产环境中运行OpenClaw代理的所学：[@code_rams](https://x.com/code_rams)
*本文由比利哥效率实验室编译整理，关注我们获取更多AI Agent实战经验分享。*
---
## X/Twitter 文案
我的AI助理像金鱼一样只有7秒记忆，每次对话都要从头开始。花了5天时间调试OpenClaw内存系统，总结出10条血泪规则：
1. 只有7个文件自动加载，其他都需要明确指令
2. 启动序列必须放在AGENTS.md顶部
3. 写入纪律比读取纪律更重要
4. 永远不要任务期间直接写MEMORY.md
5. LEARNINGS.md是最被低估的文件
完整10条规则+配置示例👇
#AI #OpenClaw #Agent #内存管理
---
## 视频信息
**标题：** AI助理总失忆？5天调试血泪史，这10条规则能救你！
**口播脚本：
【0:00-0:10】开场钩子
（镜头：博主正脸，表情苦恼）
“你的AI助理是不是也这样？昨天刚教的东西，今天全忘了。每次对话都要从头开始，像个金鱼一样只有7秒记忆。我花了整整5天时间，才搞明白OpenClaw内存系统的所有坑。”
【0:11-0:30】问题引入
（镜头：切换屏幕演示，展示对话记录）
“我的AI助理Chiti，负责客户支持、写推文、管发票。但几周来，它一直在失忆。长对话后上下文丢失，搜索返回垃圾结果，最气人的是——它找到了信息但不用！”
【0:31-1:30】Day 1-3：三大核心问题
（镜头：分屏展示代码配置和问题现象）
“第一天：压缩机制导致集体失忆。解决方案？内存刷新配置。
第二天：搜索返回垃圾。纯语义搜索不行，必须用混合搜索。
第三天：代理找到了但不使用。检索不是自动的，需要明确指令。”
【1:31-2:30】Day 4-5：系统级优化
（镜头：展示/context detail命令输出）
“第四天：让系统对压缩安全。上下文修剪+内存刷新双保险。
第五天：震惊发现——系统提示词臃肿了28%！11,887个令牌中，20个技能我从未用过。”
【2:31-3:30】10条黄金规则
（镜头：逐条展示规则卡片）
“1. 只有7个文件自动加载
2. 启动序列放AGENTS.md顶部
3. 写入纪律比读取更重要
4. 别在任务期间写MEMORY.md
5. LEARNINGS.md最被低估
6. 测试检索，不只是存储
7. 交接协议解决模型切换失忆
8. 定期运行/context detail
9. 混合搜索优于纯语义
10. 压缩不是敌人，未写入的上下文才是”
【3:31-4:00】当前配置展示
（镜头：展示优化后的文件结构）
“现在我的系统：8,529个令牌，轻了28%。每日日志、学习记录、长期记忆分离管理。代理启动、读取、写入、交接，一气呵成。”
【4:01-4:30】结尾呼吁
（镜头：回归正脸）
“别再让你的AI助理失忆了。这10条规则，是我用5天血泪换来的。如果你也在用OpenClaw，评论区告诉我你踩过哪些坑？关注我，分享更多AI Agent实战经验！”
---
*封面图关键词：AI助理失忆 | OpenClaw内存调试 | 上下文压缩 | 混合搜索 | 系统优化*
*原文路径：/Users/weishen/Workspace/nexus/openclaw/content-queue/I Spent 5 Days Debugging My OpenClaw Agent's Memory.md*/