养虾日记

2026-04-03 09:44:13 +08:00
parent 30a5610464
commit ab1dfbba7e
11 changed files with 18 additions and 11 deletions
--- a/openclaw/content-out/I-Spent-5-Days-Debugging-OpenClaw-Agent-Memory-中文版.md
+++ b/openclaw/content-out/I-Spent-5-Days-Debugging-OpenClaw-Agent-Memory-中文版.md
@@ -1,285 +0,0 @@
-# 养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录
-
-![[IMG-20260331114331769.png]]
-当你的AI助理像个金鱼一样只有7秒记忆，每次对话都要从头开始——这不是科幻，而是我花了5天时间解决的现实问题。从对话压缩到搜索失效，从系统臃肿到模型切换失忆，这是我用血泪换来的10条OpenClaw内存管理黄金法则。
-
-# 5天血泪史：我的AI助理为什么总失忆？OpenClaw内存调试全记录
-
-> 当你的AI助理像个金鱼一样只有7秒记忆，每次对话都要从头开始——这不是科幻，而是我花了5天时间解决的现实问题。
-
-我叫比利哥，正在研究如何利用AI提高工作效率。我的OpenClaw AI助理名叫星辉，它运行在Telegram上，负责管理我的个人任务规划、日程安排、搜集资料、起草推文、文件整理。
-
-从开始"雇佣"它，它就像我的初级员工——直到它开始频繁失忆。
-
-不是那种微妙的遗忘。我花一个小时配置每日定时任务，切换模型后，星辉表现得像我们从未交谈过。我提到两天前的讨论决定，它一脸茫然。让它继续任务，它却从头开始。
-
-于是我停止了我手头的其他工作，花了5天时间专门修复OpenClaw的记忆问题。以下是我发现的一切、我搞砸的一切，以及真正有效的一切。
-
-## Day 1：长对话后的集体失忆
-
-第一个问题描述简单，诊断痛苦。
-
-长对话后，星辉开始丢失早期上下文。不是逐渐丢失，而是突然消失。20条消息前告诉它的事情，没了。会话开始时做的决定？从未发生。
-
-**罪魁祸首是压缩机制。** 当对话填满Context Window时，OpenClaw会将旧消息压缩成摘要，为新消息腾出空间。摘要抓住了要点，但丢掉了细节——姓名、数字、具体决定，统统消失。
-
-> “这是设计使然。上下文窗口是有限的。但默认行为对一切一视同仁，这意味着你精心设计的第三条消息指令，和第七条消息的闲聊得到了相同待遇。”
-
-**我的解决方案：**
-启用压缩前的内存刷新。这告诉代理在压缩器运行前将重要上下文写入磁盘。
-```json
-{
-  "compaction": {
-    "memoryFlush": {
-      "enabled": true,
-      "softThresholdTokens": 4000
-    }
-  }
-}
-```
-
-当会话接近上下文限制时，OpenClaw触发一个静默回合，提醒Agent在压缩擦除前将持久事实保存到memory/YYYY-MM-DD.md。代理写入重要内容，压缩运行，即使上下文摘要丢失，重要内容仍保留在磁盘上。
-不过这里要声明一下，4000这个数值要根据你使用的模型来考虑，如果你是使用Gemini/GTP-4.1/Claud等大模型通常上下文窗口可以达到32K/128K/200K tokens, 那么4000这个数值就太保守了，会导致频繁的summary, 上下文"碎片化"，reasoning质量下降。
-
-**关键洞察：**
-压缩不是敌人。压缩过程中丢失信息才是。修复方法是确保任何值得记住的内容在压缩器触及前写入文件。如果只在上下文窗口中，它是临时的。如果在磁盘上，它就能存活。
-
-## Day 2：搜索返回垃圾结果
-
-随着每日日志积累和MEMORY.md增长，我需要星辉开始真正找到东西。内置的内存搜索返回不相关结果或错过明显匹配。
-
-**问题是搜索后端。** OpenClaw默认的基于SQLite的搜索使用向量嵌入（语义相似性）查找相关块。这对广泛查询有效，但在精确匹配上挣扎。我搜索特定内容，却得到关于完全不同主题的结果，只是因为使用了相似语言。
-
-**我的解决方案：**
-切换到QMD作为内存搜索后端。QMD结合了BM25（关键词匹配）、向量嵌入和重新排序器。所以当我搜索“n8n工作流执行结果”时，它找到包含这些确切词语的结果AND语义相关的结果，然后按相关性重新排序。
-
-**关键洞察：**
-纯语义搜索理论上听起来不错，但在专有名词、具体数字和确切短语上失败。混合搜索（关键词+向量+重新排序）对现实世界代理内存明显更好。如果你的代理找不到你知道在其文件中的内容，搜索后端可能是瓶颈，而不是文件本身。
-
-## Day 3：Agent找到了但不使用
-
-这是最令人沮丧的一天。我确认搜索是有效，可以手动查询并获得正确结果。但在实际对话中，即使相关上下文明显存在于内存中，星辉也不会检索。
-
-**问题是检索不是自动的。** Agent必须决定搜索。如果对话没有触发正确线索，它就不会查找。
-
-**我的解决方案：**
-在启动序列中添加明确的检索指令。不是希望代理在需要时搜索，而是告诉它何时搜索：
-
-> 开始任何任务前：
-> - 搜索每日日志(memory/YYYY-MM-DD.md)获取相关上下文
-> - 检查LEARNINGS.md获取此类任务的规则
-> - 如果提到客户，搜索其历史记录
-
-我还建立了检索测试。我在每日日志中植入特定标记——类似“标记：2026-02-20 — 在笔记更新后自动运行笔记同步到git”然后等待，开始新会话，测试问：“昨天的标记是什么？”如果Agent找到它，检索有效。如果没有，某些地方出错了。
-
-**关键洞察：**
-“信息存在”和“Agent使用信息”之间有区别。你需要两者。搜索基础设施处理第一部分。启动指令和检索习惯处理第二部分。分别测试两者。
-
-## Day 4：让它对压缩安全
-
-此时我有了内存刷新、混合搜索和检索指令。但在特定场景中我仍然丢失上下文：非常长的会话，压缩运行多次。
-
-**问题是内存刷新每个压缩周期只触发一次。** 如果会话足够长，有两三次压缩，只有第一次得到刷新处理。之后的一切都处于风险中。
-
-**我的解决方案：**
-
-配置上下文修剪与压缩协同工作：
-
-```json
-{
-  "contextPruning": {
-    "mode": "cache-ttl",
-    "ttl": "6h",
-    "keepLastAssistants": 3
-  }
-}
-```
-
-这会在6小时后积极修剪旧上下文，同时保留最后3个Assistants响应。结合内存刷新，这意味着Agent早期将重要内容写入磁盘，旧上下文在导致溢出前被清理。
-
-**关键洞察：**
-长会话是内存系统真正接受测试的地方。短对话很少触及压缩。是2小时的深度工作会话中你会丢失上下文且无法找出原因。在负载下测试你的内存系统，而不仅仅是在快速聊天中。
-
-## Day 5：系统提示词臃肿了28%
-
-这是所有事情都清晰的一天。我运行了/context detail并盯着数字。
-
-我的代理在读取我的消息前加载了20,9652个令牌的系统提示词。54个技能，其中20个我从未使用。我有两个竞争的启动序列——一个在BOOT.md中（OpenClaw甚至不识别），一个埋在AGENTS.md的200行深处。
-
-最糟糕的是，每次切换模型，星辉忘记一切。没有交接协议。没有当前上下文的写回。直接消失。
-
-**根本原因：**
-
-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个令牌
- 添加写入纪律：每个任务记录其结果，每个错误变成规则
- 添加交接协议：在任何模型切换或会话结束前，代理将当前上下文写入每日日志
-
-**结果：**
-
- 系统提示词：20,9652 → 9,349个令牌
- 技能：51 → 31
- 会话令牌：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)
-│   ├── knowledge-transfer.md
-│   ├── infrastructure.md
-│   └── group-chat-rules.md
-└── skills/ (32个技能，从51个减少)
-```
-
-系统提示词：8,529个令牌。会话令牌：14,627个，占200,000上下文窗口的7.3%。Agent启动，读取所需内容，写入所学内容，在模型切换前交接上下文。
-
-我花了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*/
--- a/openclaw/xingshu/我用
+++ b/openclaw/xingshu/我用
@@ -1,59 +0,0 @@
-# 我用 AI Agent 管了 28 万张照片：一次真实的多设备照片整理实战
-
-### 照片越多，备份越乱
-
-我拍了十几年照片。
-
-从最早的 Nikon D70s、Canon EOS 450D，到后来的 iPhone、华为、小米、OPPO——每一台设备都在往 NAS 里塞照片。年复一年，日积月累，最后堆出了 **28 万个文件，占用超过 200GB**。
-
-问题来了：**你知道你有多少张照片吗？你知道它们都在哪儿吗？**
-
-我的 MobileBackup 目录里躺着 68 个设备文件夹，每个文件夹名字都是一串设备型号。有些是手机，有些是相机，有些我甚至认不出来是哪个年代的什么机器。截图、连拍、微信压缩图、HEIC 格式、JPEG 格式、RAW 文件——全混在一起。
-
-更让人头疼的是**重复**。同一张照片，iPhone 备份一次，华为手机备份一次，百度网盘同步一次，最后又手动往 NAS 里拷了一次。一个场景四五个副本，谁是原图都分不清。
-
-### 我试过的那些"方案"
-
-老实说，我不是没想过解决这个问题。
-
-试过 NAS 自带的 Synology Photos，内置重复检测——效果一般，误报率高得离谱。试过 Mac 上的第三方照片管理工具，扫描速度慢到我睡着了还没跑完。试过自己写 Shell 脚本跑 md5sum，跑了两天发现目录结构太乱，脚本跑一半崩了。
-
-直到最近开始认真用 OpenClaw——我的 AI Agent 操作系统。
-
-我没有给 OpenClaw 下达"去重"这样的简单指令。我只是说：**"我有个目录，里面照片很多，来源很杂，我想整理一下，有什么方案？"**
-
-然后它开始分析。
-
-### AI Agent 的思维方式不一样
-
-它没有直接推荐工具，而是先问了几个关键问题：照片格式有哪些？重复的定义是"完全相同内容"还是"同一场景的连拍"？低质量图片的判断标准是什么？删除策略是什么？
-
-这几个问题让我意识到，我之前所有的失败尝试，都是因为我在**没有想清楚问题的情况下就开始动手**。
-
-OpenClaw 帮我把一个模糊的"我想整理照片"变成了一个可执行的方案：
-
- **精确去重**：MD5 哈希比对，只删真正相同的文件
- **小文件清理**：低于 100KB 的图片大概率是截图或微信压缩图，直接移走
- **安全第一**：所有待删文件不进回收站直接删，而是先移到 `To-Be-Deleted` 目录，我可以随时检查确认
-
-方案确定后，它又主动想到了一件事：**68 个目录，28 万个文件，一次跑完不现实**。于是它帮我把任务拆成了 8 批次，每天凌晨 0 点自动执行一批，全程无需我介入。
-
-### 真正让我惊讶的地方
-
-不是它写得有多好，而是它的**思维方式**。
-
-作为一个搞了十几年技术的人，我习惯了自己想方案、自己写脚本、自己承担风险。AI Agent 的出现并没有改变这一点——它不是来替代我的，它是来当我的**架构师和顾问**的。
-
-它帮我把模糊的想法变成了清晰的结构，把大任务拆成了可执行的批次，把风险控制在了可接受的范围内。而这一切，都是在我只说了一句"我想整理照片"之后发生的。
-
-### 凌晨 0 点的任务
-
-写好脚本、定好计划、设好 Cron 任务之后，这件事就交给 OpenClaw 去跑了。明天凌晨，B1 批次（iPhone 目录，69,204 个文件）会第一个开始扫描。执行完毕后会通过 Telegram 给我发一份 Summary 报告：发现了多少重复文件、移除了多少小文件、总共清理了多少空间。
-
-我只需要睡醒看一眼手机。
-
-28 万张照片，68 个设备，十几年的积累——现在有了一个可以信任的自动化流程来处理它们。这大概就是 AI Agent 对我来说真正的价值：**不是某个单点能力的提升，而是思维方式的升级**。
-
---
-
-*2026-03-31*