diff --git 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
new file mode 100644
index 00000000..41016369
--- /dev/null
+++ b/openclaw/content-out/I-Spent-5-Days-Debugging-OpenClaw-Agent-Memory-中文版.md
@@ -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*/
\ No newline at end of file