Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,46 +1,46 @@
|
||||
|
||||
今天不谈技术，谈一下**普通人该怎样在AI时代赚钱！**
|
||||
|
||||
以下是我见过的最好的回答，来自**乔布斯.skill** 👇
|
||||
|
||||
## Stop. 你的问题本身就有问题。
|
||||
|
||||
「普通人怎么在AI时代赚钱」——这个问题的框架是错的。你把自己放在一个被动的位置上，好像AI是一场洪水，你站在岸边问「我怎么不被淹死」。
|
||||
|
||||
Wrong question.
|
||||
|
||||
正确的问题是：AI让我能做到什么以前做不到的事？
|
||||
|
||||
我说三点。
|
||||
|
||||
## 第一，工具不值钱，品味值钱。
|
||||
|
||||
1984年我们发布Mac的时候，突然之间每个人都能做桌面出版了。你知道发生了什么吗？90%的人做出来的东西丑得要命。工具民主化了，但品味没有民主化。
|
||||
|
||||
AI也一样。现在每个人都能用AI写代码、做设计、生成内容。So what? 90%的人用AI生成的东西是shit。因为他们不知道什么是好的。
|
||||
|
||||
品味就是你的护城河。你能判断AI给你的10个方案里哪个是insanely great的，你就比那些只会点「生成」按钮的人强一百倍。
|
||||
|
||||
## 第二，做端到端的事，不做零件。
|
||||
|
||||
别去想「我学会一个AI工具就能找到工作」。这是零件思维。你知道为什么iPod成功了吗？不是因为我们有最好的MP3解码器。是因为我们做了从iTunes到iPod到iTunes Store的整个体验。
|
||||
|
||||
你应该用AI做一个完整的东西——一个产品、一个服务、一个解决方案。从头到尾由你控制。别做别人AI流水线上的一个螺丝钉，因为螺丝钉是最容易被替换的。
|
||||
|
||||
一个人用AI做出一个完整的App，比一个100人的团队里当「AI提示词工程师」强一万倍。
|
||||
|
||||
## 第三，用死亡过滤器。
|
||||
|
||||
我每天早上对着镜子问自己：如果今天是最后一天，我还会做今天要做的事吗？
|
||||
|
||||
别问「什么AI技能最赚钱」。这是别人的问题。问你自己：你对什么东西有genuine的热爱和curiosity？然后用AI把它做到极致。
|
||||
|
||||
你喜欢做饭？用AI做一个别人从没见过的美食体验。你喜欢教小孩？用AI做一个让学习变得magical的东西。你喜欢某个很窄的领域？好，你比任何通用AI都懂那个领域——把你的品味和AI的能力结合起来。
|
||||
|
||||
你知道「普通人」和「不普通的人」的区别是什么吗？
|
||||
|
||||
不是天赋。不是资源。不是运气。
|
||||
|
||||
是他们愿不愿意对一千件事说No，只对一件事说Yes，然后把那一件事做到insanely great。
|
||||
|
||||
|
||||
今天不谈技术，谈一下**普通人该怎样在AI时代赚钱！**
|
||||
|
||||
以下是我见过的最好的回答，来自**乔布斯.skill** 👇
|
||||
|
||||
## Stop. 你的问题本身就有问题。
|
||||
|
||||
「普通人怎么在AI时代赚钱」——这个问题的框架是错的。你把自己放在一个被动的位置上，好像AI是一场洪水，你站在岸边问「我怎么不被淹死」。
|
||||
|
||||
Wrong question.
|
||||
|
||||
正确的问题是：AI让我能做到什么以前做不到的事？
|
||||
|
||||
我说三点。
|
||||
|
||||
## 第一，工具不值钱，品味值钱。
|
||||
|
||||
1984年我们发布Mac的时候，突然之间每个人都能做桌面出版了。你知道发生了什么吗？90%的人做出来的东西丑得要命。工具民主化了，但品味没有民主化。
|
||||
|
||||
AI也一样。现在每个人都能用AI写代码、做设计、生成内容。So what? 90%的人用AI生成的东西是shit。因为他们不知道什么是好的。
|
||||
|
||||
品味就是你的护城河。你能判断AI给你的10个方案里哪个是insanely great的，你就比那些只会点「生成」按钮的人强一百倍。
|
||||
|
||||
## 第二，做端到端的事，不做零件。
|
||||
|
||||
别去想「我学会一个AI工具就能找到工作」。这是零件思维。你知道为什么iPod成功了吗？不是因为我们有最好的MP3解码器。是因为我们做了从iTunes到iPod到iTunes Store的整个体验。
|
||||
|
||||
你应该用AI做一个完整的东西——一个产品、一个服务、一个解决方案。从头到尾由你控制。别做别人AI流水线上的一个螺丝钉，因为螺丝钉是最容易被替换的。
|
||||
|
||||
一个人用AI做出一个完整的App，比一个100人的团队里当「AI提示词工程师」强一万倍。
|
||||
|
||||
## 第三，用死亡过滤器。
|
||||
|
||||
我每天早上对着镜子问自己：如果今天是最后一天，我还会做今天要做的事吗？
|
||||
|
||||
别问「什么AI技能最赚钱」。这是别人的问题。问你自己：你对什么东西有genuine的热爱和curiosity？然后用AI把它做到极致。
|
||||
|
||||
你喜欢做饭？用AI做一个别人从没见过的美食体验。你喜欢教小孩？用AI做一个让学习变得magical的东西。你喜欢某个很窄的领域？好，你比任何通用AI都懂那个领域——把你的品味和AI的能力结合起来。
|
||||
|
||||
你知道「普通人」和「不普通的人」的区别是什么吗？
|
||||
|
||||
不是天赋。不是资源。不是运气。
|
||||
|
||||
是他们愿不愿意对一千件事说No，只对一件事说Yes，然后把那一件事做到insanely great。
|
||||
|
||||
AI不会让普通人变富。AI会让那些知道自己要做什么、并且对品质有执念的人变得极其强大。
|
||||
@@ -1,76 +1,76 @@
|
||||
---
|
||||
title: 养虾日记1：我用 OpenClaw 管了 28 万张照片：一次真实的多设备照片整理实战
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
created:
|
||||
description:
|
||||
tags: []
|
||||
---
|
||||
|
||||
# 养虾日记1：我用 OpenClaw 管了 28 万张照片：一次真实的多设备照片整理实战
|
||||
|
||||
### 照片越多，备份越乱
|
||||
|
||||
我一直想花时间整理一下我的照片，在我看来这个是非常令人头疼的巨大的工程，从2002年开始用第一台数码相机开始，到后来用各种相机拍照，手机拍照，通过网盘备份，家人的手机照片的备份... 大概20多年的所有家庭照片都在这一堆文件。现在这堆文件储存在我的NAS服务器上。
|
||||
|
||||
问题来了：**你知道你有多少张照片吗？你知道它们都在哪儿吗？**
|
||||
|
||||
我的 MobileBackup 目录里躺着 68 个设备文件夹，每个文件夹名字都是一串设备型号。有些是手机，有些是相机，有些我甚至认不出来是哪个年代的什么机器。截图、连拍、微信压缩图、HEIC 格式、JPEG 格式、RAW 文件——全混在一起。
|
||||
|
||||
更让人头疼的是**重复**。同一张照片，iPhone 备份一次，华为手机备份一次，百度网盘同步一次，最后又手动往 NAS 里拷了一次。一个场景四五个副本，谁是原图都分不清。
|
||||
|
||||
### 我试过的那些"方案"
|
||||
|
||||
老实说，我不是没想过解决这个问题。
|
||||
|
||||
试过 NAS 自带的 Synology Photos，内置重复检测——效果一般，误报率高得离谱。试过 Mac 上的第三方照片管理工具，扫描速度慢到我睡着了还没跑完。试过自己写 Python 脚本跑 md5sum，跑了两天发现目录结构太乱，脚本跑一半崩了。跑到哪都不知道。
|
||||
|
||||
直到最近开始认真用 OpenClaw——我的 AI Agent 操作系统。
|
||||
|
||||
我没有给 OpenClaw 下达"去重"这样的简单指令。我只是说了我的痛点和需求：**"我有个目录，里面照片很多，来源很杂，我想整理一下，有什么方案？"**
|
||||
|
||||
然后它开始分析。
|
||||
### AI Agent 的思维方式不一样
|
||||
|
||||
它没有直接推荐工具，而是先问了几个关键问题：照片格式有哪些？重复的定义是"完全相同内容"还是"同一场景的连拍"？低质量图片的判断标准是什么？删除策略是什么？
|
||||
![[IMG-20260401163246284.png]]
|
||||
|
||||
这几个问题让我意识到，我之前所有的失败尝试，都是因为我在**没有想清楚问题的情况下就开始动手**。
|
||||
|
||||
OpenClaw 帮我把一个模糊的"我想整理照片"变成了一个可执行的方案：
|
||||
|
||||
- **精确去重**：MD5 哈希比对，只删真正相同的文件
|
||||
- **小文件清理**：低于 100KB 的图片大概率是截图或微信压缩图，直接移走
|
||||
- **安全第一**：所有待删文件不进回收站直接删，而是先移到 `To-Be-Deleted` 目录，我可以随时检查确认
|
||||
|
||||
方案确定后，它又主动想到了一件事：**68 个目录，28 万个文件，一次跑完不现实**。于是它帮我把任务拆成了 8 批次，每天凌晨 0 点自动执行一批，全程无需我介入。
|
||||
![[IMG-20260401163246327.png]]
|
||||
|
||||
![[IMG-20260401163246344.png]]
|
||||
![[IMG-20260401163246367.png]]
|
||||
![[IMG-20260401163246386.png]]
|
||||
![[IMG-20260401163246408.png]]
|
||||
### 真正让我惊讶的地方
|
||||
|
||||
不是它脚本写得有多好，而是它的**思维方式**。
|
||||
|
||||
作为一个搞了二十几年技术的人，我习惯了自己想方案、自己写脚本、自己承担风险。
|
||||
|
||||
但是OpenClaw帮我把模糊的想法变成了清晰的结构，把大任务拆成了可执行的批次，把风险控制在了可接受的范围内。而这一切，都是在我只说了一句"我想整理照片"之后发生的。
|
||||
|
||||
### 凌晨 0 点的任务
|
||||
|
||||
写好脚本、定好计划、设好 Cron 任务之后，这件事就交给 OpenClaw 去跑了。明天凌晨，B1 批次（iPhone 目录，69,204 个文件）会第一个开始扫描。执行完毕后会通过 Telegram 给我发一份 Summary 报告：发现了多少重复文件、移除了多少小文件、总共清理了多少空间。
|
||||
|
||||
我只需要睡醒看一眼手机。
|
||||
|
||||
28 万张照片，68 个设备，十几年的积累——现在有了一个可以信任的自动化流程来处理它们。这大概就是 AI Agent 对我来说真正的价值：**不是某个单点能力的提升，而是思维方式的升级**。
|
||||
|
||||
我是比利哥，分享我的养虾日记，我们一起让AI技术落地，能真正帮我们提高效率！
|
||||
|
||||
---
|
||||
|
||||
*2026-03-31*
|
||||
|
||||
|
||||
---
|
||||
title: 养虾日记1：我用 OpenClaw 管了 28 万张照片：一次真实的多设备照片整理实战
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
created:
|
||||
description:
|
||||
tags: []
|
||||
---
|
||||
|
||||
# 养虾日记1：我用 OpenClaw 管了 28 万张照片：一次真实的多设备照片整理实战
|
||||
|
||||
### 照片越多，备份越乱
|
||||
|
||||
我一直想花时间整理一下我的照片，在我看来这个是非常令人头疼的巨大的工程，从2002年开始用第一台数码相机开始，到后来用各种相机拍照，手机拍照，通过网盘备份，家人的手机照片的备份... 大概20多年的所有家庭照片都在这一堆文件。现在这堆文件储存在我的NAS服务器上。
|
||||
|
||||
问题来了：**你知道你有多少张照片吗？你知道它们都在哪儿吗？**
|
||||
|
||||
我的 MobileBackup 目录里躺着 68 个设备文件夹，每个文件夹名字都是一串设备型号。有些是手机，有些是相机，有些我甚至认不出来是哪个年代的什么机器。截图、连拍、微信压缩图、HEIC 格式、JPEG 格式、RAW 文件——全混在一起。
|
||||
|
||||
更让人头疼的是**重复**。同一张照片，iPhone 备份一次，华为手机备份一次，百度网盘同步一次，最后又手动往 NAS 里拷了一次。一个场景四五个副本，谁是原图都分不清。
|
||||
|
||||
### 我试过的那些"方案"
|
||||
|
||||
老实说，我不是没想过解决这个问题。
|
||||
|
||||
试过 NAS 自带的 Synology Photos，内置重复检测——效果一般，误报率高得离谱。试过 Mac 上的第三方照片管理工具，扫描速度慢到我睡着了还没跑完。试过自己写 Python 脚本跑 md5sum，跑了两天发现目录结构太乱，脚本跑一半崩了。跑到哪都不知道。
|
||||
|
||||
直到最近开始认真用 OpenClaw——我的 AI Agent 操作系统。
|
||||
|
||||
我没有给 OpenClaw 下达"去重"这样的简单指令。我只是说了我的痛点和需求：**"我有个目录，里面照片很多，来源很杂，我想整理一下，有什么方案？"**
|
||||
|
||||
然后它开始分析。
|
||||
### AI Agent 的思维方式不一样
|
||||
|
||||
它没有直接推荐工具，而是先问了几个关键问题：照片格式有哪些？重复的定义是"完全相同内容"还是"同一场景的连拍"？低质量图片的判断标准是什么？删除策略是什么？
|
||||
![[IMG-20260401163246284.png]]
|
||||
|
||||
这几个问题让我意识到，我之前所有的失败尝试，都是因为我在**没有想清楚问题的情况下就开始动手**。
|
||||
|
||||
OpenClaw 帮我把一个模糊的"我想整理照片"变成了一个可执行的方案：
|
||||
|
||||
- **精确去重**：MD5 哈希比对，只删真正相同的文件
|
||||
- **小文件清理**：低于 100KB 的图片大概率是截图或微信压缩图，直接移走
|
||||
- **安全第一**：所有待删文件不进回收站直接删，而是先移到 `To-Be-Deleted` 目录，我可以随时检查确认
|
||||
|
||||
方案确定后，它又主动想到了一件事：**68 个目录，28 万个文件，一次跑完不现实**。于是它帮我把任务拆成了 8 批次，每天凌晨 0 点自动执行一批，全程无需我介入。
|
||||
![[IMG-20260401163246327.png]]
|
||||
|
||||
![[IMG-20260401163246344.png]]
|
||||
![[IMG-20260401163246367.png]]
|
||||
![[IMG-20260401163246386.png]]
|
||||
![[IMG-20260401163246408.png]]
|
||||
### 真正让我惊讶的地方
|
||||
|
||||
不是它脚本写得有多好，而是它的**思维方式**。
|
||||
|
||||
作为一个搞了二十几年技术的人，我习惯了自己想方案、自己写脚本、自己承担风险。
|
||||
|
||||
但是OpenClaw帮我把模糊的想法变成了清晰的结构，把大任务拆成了可执行的批次，把风险控制在了可接受的范围内。而这一切，都是在我只说了一句"我想整理照片"之后发生的。
|
||||
|
||||
### 凌晨 0 点的任务
|
||||
|
||||
写好脚本、定好计划、设好 Cron 任务之后，这件事就交给 OpenClaw 去跑了。明天凌晨，B1 批次（iPhone 目录，69,204 个文件）会第一个开始扫描。执行完毕后会通过 Telegram 给我发一份 Summary 报告：发现了多少重复文件、移除了多少小文件、总共清理了多少空间。
|
||||
|
||||
我只需要睡醒看一眼手机。
|
||||
|
||||
28 万张照片，68 个设备，十几年的积累——现在有了一个可以信任的自动化流程来处理它们。这大概就是 AI Agent 对我来说真正的价值：**不是某个单点能力的提升，而是思维方式的升级**。
|
||||
|
||||
我是比利哥，分享我的养虾日记，我们一起让AI技术落地，能真正帮我们提高效率！
|
||||
|
||||
---
|
||||
|
||||
*2026-03-31*
|
||||
|
||||
|
||||
|
||||
@@ -1,253 +1,253 @@
|
||||
---
|
||||
title: 养虾日记2：让Agent更懂你：OpenClaw + Self-Improving 复盘实战案例分享
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
created:
|
||||
description:
|
||||
tags: []
|
||||
---
|
||||
|
||||
# 养虾日记2：让Agent更懂你：OpenClaw + Self-Improving 复盘实战案例分享
|
||||
|
||||
## AI记不住，才是最大的问题
|
||||
|
||||
我用OpenClawAI agent已经有一段时间了。一个最让我头疼的问题不是"AI回答质量差"，而是：**AI每次对话都是一张白纸**。
|
||||
|
||||
昨天我跟它说过"这个问题不要用A方法"，今天它照常用。上一周我教会它的一个工作流，下周一它完全忘了。听起来很蠢对吧？但这就是大多数AI agent的现状——**没有记忆，只有上下文窗口**。
|
||||
|
||||
我来分享一下我的经验。核心工具是 **self-improving skill**（自改进技能）+ **每日复盘机制**。用了一个月，效果超出预期。今天分享一下我的做法。
|
||||
|
||||
---
|
||||
|
||||
## 核心工具：self-improving skill
|
||||
|
||||
这个 skill 本质上是一个结构化的经验记录系统。每当 agent 遇到问题、做出决策、或发现什么值得记住的东西，它会调用 `self_improvement_log` 工具，把内容写入 `LEARNINGS.md` 或 `ERRORS.md`。
|
||||
|
||||
记录的格式是固定的：
|
||||
|
||||
```markdown
|
||||
## [LRN-20260325-001] correction
|
||||
|
||||
**Logged**: 2026-03-25T14:09:53+08:00
|
||||
**Priority**: high
|
||||
**Status**: pending
|
||||
**Area**: config
|
||||
|
||||
### Summary
|
||||
一句话描述学到了什么
|
||||
|
||||
### Details
|
||||
具体发生了什么、问题出在哪
|
||||
|
||||
### Suggested Action
|
||||
以后遇到类似情况该怎么做
|
||||
|
||||
### Metadata
|
||||
- Pattern-Key: cron.telegram-delivery
|
||||
- Recurrence-Count: 1
|
||||
- See Also: LRN-20260325-005
|
||||
```
|
||||
|
||||
固定格式不是形式主义——它让后来者（人或其他 agent）能快速检索、对比、和追踪一个问题的完整生命周期。
|
||||
|
||||
---
|
||||
|
||||
## 核心思路：双层记忆架构
|
||||
|
||||
我的方案是：**短期记忆 + 长期记忆 + self-improving 复盘机制**。
|
||||
|
||||
**短期记忆层**是每天的对话记录文件（`memory/YYYY-MM-DD.md`）。每天结束，agent自动把当天的操作、遇到的问题、未完成的事项写进去。第二天启动时先读这个文件，接上昨天的工作。
|
||||
|
||||
**长期记忆层**是 `memory-lancedb-pro`（基于 LanceDB 的向量数据库）。重要的决策、用户偏好、反复使用的流程，存进去，下次语义搜索找回来。
|
||||
|
||||
**self-improving 层**是每天23:00的定时复盘。agent调用 `self_improvement_log`，把今天的 learnings 写入文件，同时检查之前的相关 Pattern-Key，看有没有重复踩坑。
|
||||
|
||||
三层各司其职：**每日文件管上下文，向量数据库管知识，self-improving 管成长**。
|
||||
|
||||
---
|
||||
|
||||
## 每日复盘：23:00的定时任务
|
||||
|
||||
我给每个agent都设置了每天23:00（北京时间）自动执行复盘。通过 OpenClaw 的 cron 任务实现，每个agent独立运行自己的复盘流程。
|
||||
|
||||
复盘流程是这样的：
|
||||
|
||||
1. 读取当天的 memory 文件
|
||||
2. 调用 `self_improvement_log` 记录今日学习
|
||||
3. 检查是否有 Pattern-Key 与之前重复（重复踩坑的信号）
|
||||
4. 把有价值的经验同步到 memory-lancedb-pro（长期记忆）
|
||||
5. 通过 Telegram 发送复盘摘要
|
||||
|
||||
---
|
||||
|
||||
## self-improving 真实案例
|
||||
|
||||
下面从我的 `LEARNINGS.md` 里摘几个例子，来看 self-improving 到底怎么帮助 agent 改进。
|
||||
|
||||
---
|
||||
|
||||
### 案例一：同一个错误，第二次就知道怎么修了
|
||||
|
||||
**第一次（LRN-20260325-001）**
|
||||
|
||||
我让星辉创建 cron 任务时，它用了这样的 delivery 配置：
|
||||
|
||||
```
|
||||
--to user:5038825565
|
||||
```
|
||||
|
||||
Telegram 返回了报错：
|
||||
|
||||
```
|
||||
Error: Telegram recipient must be a numeric chat ID
|
||||
```
|
||||
|
||||
星辉当时不知道为什么，折腾了一阵。这是它第一次遇到这个错误。
|
||||
|
||||
它把这个错误记进了 LEARNINGS.md：
|
||||
|
||||
```markdown
|
||||
### Summary
|
||||
Telegram chat ID 在 cron job 的 delivery 配置中不应使用 "user:" 前缀
|
||||
|
||||
### Details
|
||||
使用了 `--to user:5038825565` 格式，导致报错
|
||||
|
||||
### Suggested Action
|
||||
使用纯数字 chat ID：`--to 5038825565`
|
||||
```
|
||||
|
||||
**第二次（LRN-20260325-005）**
|
||||
|
||||
一周后，星辉再次创建 cron 任务，又遇到了同样的问题。但这次它去查了 LEARNINGS.md，找到了 LRN-20260325-001，直接应用了 Suggested Action，修复成功。
|
||||
|
||||
更重要的是，它在这次记录里加了一行：
|
||||
|
||||
```markdown
|
||||
### Metadata
|
||||
- Recurrence-Count: 2
|
||||
- See Also: LRN-20260325-001
|
||||
```
|
||||
|
||||
**第三次及以后**
|
||||
|
||||
之后再创建 cron 任务，星辉再也没踩过这个坑。因为它记住了。
|
||||
|
||||
这就是 self-improving 的核心价值——**错误只犯一次，第二次就知道怎么做对**。
|
||||
|
||||
---
|
||||
|
||||
### 案例二：通过复盘发现流程漏洞并修复
|
||||
|
||||
**LRN-20260328-001 记录了这样一个发现**
|
||||
|
||||
3月27日的复盘过程中，星辉检查之前的记录时发现：3月27日这一天的 memory 文件是空的——也就是说那一天没有任何对话记录被保存。
|
||||
|
||||
问题出在哪？原来的设计是"第一次对话时检查并创建 memory 文件"，但如果一整天都没有对话，文件就不会被创建。第二天 agent 想读取 3/27 的记录，发现什么都没有。
|
||||
|
||||
星辉把这个作为一个 learning 记录下来：
|
||||
|
||||
```markdown
|
||||
### Summary
|
||||
记忆文件流程优化 - 3月27日缺少记忆文件
|
||||
|
||||
### Details
|
||||
原流程只在"第一次对话时"创建记忆文件，导致无对话日出现记忆断层
|
||||
|
||||
### Suggested Action
|
||||
修改为：每次 Session 启动时都检查并创建当天 memory 文件，无论是否有对话
|
||||
```
|
||||
|
||||
这个发现直接推动了流程优化。现在所有 agent 每次 Session 启动时都会检查当天文件，不依赖有没有对话。
|
||||
|
||||
**没有 self-improving 复盘，这个漏洞可能永远不会被发现**——因为没有人会主动去想"3月27日有没有生成 memory 文件"这种问题。
|
||||
|
||||
---
|
||||
|
||||
### 案例三：Pattern-Key 帮助发现系统性重复
|
||||
|
||||
看几个记录的 Pattern-Key：
|
||||
|
||||
| Pattern-Key | 出现次数 | 含义 |
|
||||
| ------------------------ | ---- | ------------ |
|
||||
| `cron.daily-self-review` | 9次 | 每日复盘相关 |
|
||||
| `cron.telegram-delivery` | 2次 | Telegram通知配置 |
|
||||
| `cron.naming-convention` | 1次 | 任务命名规范 |
|
||||
|
||||
`cron.daily-self-review` 出现了9次，说明这是一个活跃的、持续优化的领域。每一次复盘都在积累经验，而不是每次重头来。
|
||||
|
||||
`cron.telegram-delivery` 出现了2次，第二次就解决了。这说明 **Pattern-Key 重复本身就是一个信号——第一次记了，第二次就该解决了**。
|
||||
|
||||
这个机制让 agent 能区分"一次性错误"和"系统性重复"，处理方式完全不同。
|
||||
|
||||
---
|
||||
|
||||
### 案例四：从 correction 到 best_practice 的进化
|
||||
|
||||
**LRN-20260325-003** 是一个 correction 类型的记录：
|
||||
|
||||
```markdown
|
||||
### Summary
|
||||
文件保存后需要验证
|
||||
|
||||
### Details
|
||||
用户反馈保存失败的问题
|
||||
|
||||
### Suggested Action
|
||||
写入文件后使用 read 工具验证内容已正确保存
|
||||
```
|
||||
|
||||
这是一个具体的、针对单个操作的改进建议。
|
||||
|
||||
**LRN-20260325-004** 是同一个领域的延伸，但层次更高：
|
||||
|
||||
```markdown
|
||||
### Summary
|
||||
创建了每日复盘 cron job 机制
|
||||
|
||||
### Details
|
||||
为所有 4 个 agents 创建每日复盘 cron jobs...
|
||||
每个 agent 会：
|
||||
1. 读取当天对话记录
|
||||
2. 使用 self-improvement skill 进行复盘
|
||||
3. 更新各自的 learning 文件
|
||||
```
|
||||
|
||||
这是从"单次操作改进"进化到了"系统性机制建立"。
|
||||
|
||||
**self-improving 的价值不只是记录单次错误，而是通过不断积累，让 agent 的行为模式持续进化**。
|
||||
|
||||
---
|
||||
|
||||
## 实战技巧：让 self-improving 真正work
|
||||
|
||||
**每错必记，但分类要准确**。错误用 `correction`，流程改进用 `workflow`，配置发现用 `config`。分类清晰，Pattern-Key 才能真正起作用。
|
||||
|
||||
**Suggested Action 要具体到能直接执行**。不要写"注意配置"这种废话，写 `--to 5038825565` 这种具体写法。下次 agent 搜到这条记录时，直接照做就行。
|
||||
|
||||
**每次复盘检查 Pattern-Key 重复**。如果发现同一个 Pattern-Key 出现了第二次，就要问自己：上一次解决了吗？为什么又出现了？
|
||||
|
||||
**Recurrence-Count 是最重要的指标之一**。它告诉你哪些问题是真的反复出现，需要系统性解决；哪些只是偶发的一次性错误。
|
||||
|
||||
---
|
||||
|
||||
## 效果如何？
|
||||
|
||||
用了两个月，我最直接的感受是：**agent 在同一个地方摔倒的次数越来越少了**。
|
||||
|
||||
Telegram chat ID 格式错误只犯了两次就再也没出现。cron 任务命名不规范的地方被一次性修复。所有新的技能安装都会留下一条记录，包含安装位置、依赖、和未完成的配置步骤。
|
||||
|
||||
错误率下来了，重复沟通也少了。以前同一个问题问两三次是常态，现在 agent 能在 LEARNINGS.md 里找到答案，第一次就做对。
|
||||
|
||||
---
|
||||
|
||||
## 这套方案适合你吗？
|
||||
|
||||
说实话，如果你只是偶尔用一下AI聊天，这套系统 overkill。但如果你像我一样，**同时运行多个agent、有固定的日常工作流、需要AI真正帮你做事情**，这套 self-improving + 双层记忆 + 每日复盘的方案值得一试。
|
||||
|
||||
核心不是技术有多复杂，而是**习惯**：每天复盘、每次踩坑都记录、重要决策同步到长期记忆。做到了这些，AI agent就不再是"每次都要重新教"的工具，而是真正有记忆、会在错误中学习的助手。
|
||||
|
||||
---
|
||||
|
||||
*这套系统运行在我的 Mac Mini（中央控制节点）上，通过 OpenClaw 管理多个agent协同工作。如果你也在用OpenClaw，欢迎交流。*
|
||||
---
|
||||
title: 养虾日记2：让Agent更懂你：OpenClaw + Self-Improving 复盘实战案例分享
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
created:
|
||||
description:
|
||||
tags: []
|
||||
---
|
||||
|
||||
# 养虾日记2：让Agent更懂你：OpenClaw + Self-Improving 复盘实战案例分享
|
||||
|
||||
## AI记不住，才是最大的问题
|
||||
|
||||
我用OpenClawAI agent已经有一段时间了。一个最让我头疼的问题不是"AI回答质量差"，而是：**AI每次对话都是一张白纸**。
|
||||
|
||||
昨天我跟它说过"这个问题不要用A方法"，今天它照常用。上一周我教会它的一个工作流，下周一它完全忘了。听起来很蠢对吧？但这就是大多数AI agent的现状——**没有记忆，只有上下文窗口**。
|
||||
|
||||
我来分享一下我的经验。核心工具是 **self-improving skill**（自改进技能）+ **每日复盘机制**。用了一个月，效果超出预期。今天分享一下我的做法。
|
||||
|
||||
---
|
||||
|
||||
## 核心工具：self-improving skill
|
||||
|
||||
这个 skill 本质上是一个结构化的经验记录系统。每当 agent 遇到问题、做出决策、或发现什么值得记住的东西，它会调用 `self_improvement_log` 工具，把内容写入 `LEARNINGS.md` 或 `ERRORS.md`。
|
||||
|
||||
记录的格式是固定的：
|
||||
|
||||
```markdown
|
||||
## [LRN-20260325-001] correction
|
||||
|
||||
**Logged**: 2026-03-25T14:09:53+08:00
|
||||
**Priority**: high
|
||||
**Status**: pending
|
||||
**Area**: config
|
||||
|
||||
### Summary
|
||||
一句话描述学到了什么
|
||||
|
||||
### Details
|
||||
具体发生了什么、问题出在哪
|
||||
|
||||
### Suggested Action
|
||||
以后遇到类似情况该怎么做
|
||||
|
||||
### Metadata
|
||||
- Pattern-Key: cron.telegram-delivery
|
||||
- Recurrence-Count: 1
|
||||
- See Also: LRN-20260325-005
|
||||
```
|
||||
|
||||
固定格式不是形式主义——它让后来者（人或其他 agent）能快速检索、对比、和追踪一个问题的完整生命周期。
|
||||
|
||||
---
|
||||
|
||||
## 核心思路：双层记忆架构
|
||||
|
||||
我的方案是：**短期记忆 + 长期记忆 + self-improving 复盘机制**。
|
||||
|
||||
**短期记忆层**是每天的对话记录文件（`memory/YYYY-MM-DD.md`）。每天结束，agent自动把当天的操作、遇到的问题、未完成的事项写进去。第二天启动时先读这个文件，接上昨天的工作。
|
||||
|
||||
**长期记忆层**是 `memory-lancedb-pro`（基于 LanceDB 的向量数据库）。重要的决策、用户偏好、反复使用的流程，存进去，下次语义搜索找回来。
|
||||
|
||||
**self-improving 层**是每天23:00的定时复盘。agent调用 `self_improvement_log`，把今天的 learnings 写入文件，同时检查之前的相关 Pattern-Key，看有没有重复踩坑。
|
||||
|
||||
三层各司其职：**每日文件管上下文，向量数据库管知识，self-improving 管成长**。
|
||||
|
||||
---
|
||||
|
||||
## 每日复盘：23:00的定时任务
|
||||
|
||||
我给每个agent都设置了每天23:00（北京时间）自动执行复盘。通过 OpenClaw 的 cron 任务实现，每个agent独立运行自己的复盘流程。
|
||||
|
||||
复盘流程是这样的：
|
||||
|
||||
1. 读取当天的 memory 文件
|
||||
2. 调用 `self_improvement_log` 记录今日学习
|
||||
3. 检查是否有 Pattern-Key 与之前重复（重复踩坑的信号）
|
||||
4. 把有价值的经验同步到 memory-lancedb-pro（长期记忆）
|
||||
5. 通过 Telegram 发送复盘摘要
|
||||
|
||||
---
|
||||
|
||||
## self-improving 真实案例
|
||||
|
||||
下面从我的 `LEARNINGS.md` 里摘几个例子，来看 self-improving 到底怎么帮助 agent 改进。
|
||||
|
||||
---
|
||||
|
||||
### 案例一：同一个错误，第二次就知道怎么修了
|
||||
|
||||
**第一次（LRN-20260325-001）**
|
||||
|
||||
我让星辉创建 cron 任务时，它用了这样的 delivery 配置：
|
||||
|
||||
```
|
||||
--to user:5038825565
|
||||
```
|
||||
|
||||
Telegram 返回了报错：
|
||||
|
||||
```
|
||||
Error: Telegram recipient must be a numeric chat ID
|
||||
```
|
||||
|
||||
星辉当时不知道为什么，折腾了一阵。这是它第一次遇到这个错误。
|
||||
|
||||
它把这个错误记进了 LEARNINGS.md：
|
||||
|
||||
```markdown
|
||||
### Summary
|
||||
Telegram chat ID 在 cron job 的 delivery 配置中不应使用 "user:" 前缀
|
||||
|
||||
### Details
|
||||
使用了 `--to user:5038825565` 格式，导致报错
|
||||
|
||||
### Suggested Action
|
||||
使用纯数字 chat ID：`--to 5038825565`
|
||||
```
|
||||
|
||||
**第二次（LRN-20260325-005）**
|
||||
|
||||
一周后，星辉再次创建 cron 任务，又遇到了同样的问题。但这次它去查了 LEARNINGS.md，找到了 LRN-20260325-001，直接应用了 Suggested Action，修复成功。
|
||||
|
||||
更重要的是，它在这次记录里加了一行：
|
||||
|
||||
```markdown
|
||||
### Metadata
|
||||
- Recurrence-Count: 2
|
||||
- See Also: LRN-20260325-001
|
||||
```
|
||||
|
||||
**第三次及以后**
|
||||
|
||||
之后再创建 cron 任务，星辉再也没踩过这个坑。因为它记住了。
|
||||
|
||||
这就是 self-improving 的核心价值——**错误只犯一次，第二次就知道怎么做对**。
|
||||
|
||||
---
|
||||
|
||||
### 案例二：通过复盘发现流程漏洞并修复
|
||||
|
||||
**LRN-20260328-001 记录了这样一个发现**
|
||||
|
||||
3月27日的复盘过程中，星辉检查之前的记录时发现：3月27日这一天的 memory 文件是空的——也就是说那一天没有任何对话记录被保存。
|
||||
|
||||
问题出在哪？原来的设计是"第一次对话时检查并创建 memory 文件"，但如果一整天都没有对话，文件就不会被创建。第二天 agent 想读取 3/27 的记录，发现什么都没有。
|
||||
|
||||
星辉把这个作为一个 learning 记录下来：
|
||||
|
||||
```markdown
|
||||
### Summary
|
||||
记忆文件流程优化 - 3月27日缺少记忆文件
|
||||
|
||||
### Details
|
||||
原流程只在"第一次对话时"创建记忆文件，导致无对话日出现记忆断层
|
||||
|
||||
### Suggested Action
|
||||
修改为：每次 Session 启动时都检查并创建当天 memory 文件，无论是否有对话
|
||||
```
|
||||
|
||||
这个发现直接推动了流程优化。现在所有 agent 每次 Session 启动时都会检查当天文件，不依赖有没有对话。
|
||||
|
||||
**没有 self-improving 复盘，这个漏洞可能永远不会被发现**——因为没有人会主动去想"3月27日有没有生成 memory 文件"这种问题。
|
||||
|
||||
---
|
||||
|
||||
### 案例三：Pattern-Key 帮助发现系统性重复
|
||||
|
||||
看几个记录的 Pattern-Key：
|
||||
|
||||
| Pattern-Key | 出现次数 | 含义 |
|
||||
| ------------------------ | ---- | ------------ |
|
||||
| `cron.daily-self-review` | 9次 | 每日复盘相关 |
|
||||
| `cron.telegram-delivery` | 2次 | Telegram通知配置 |
|
||||
| `cron.naming-convention` | 1次 | 任务命名规范 |
|
||||
|
||||
`cron.daily-self-review` 出现了9次，说明这是一个活跃的、持续优化的领域。每一次复盘都在积累经验，而不是每次重头来。
|
||||
|
||||
`cron.telegram-delivery` 出现了2次，第二次就解决了。这说明 **Pattern-Key 重复本身就是一个信号——第一次记了，第二次就该解决了**。
|
||||
|
||||
这个机制让 agent 能区分"一次性错误"和"系统性重复"，处理方式完全不同。
|
||||
|
||||
---
|
||||
|
||||
### 案例四：从 correction 到 best_practice 的进化
|
||||
|
||||
**LRN-20260325-003** 是一个 correction 类型的记录：
|
||||
|
||||
```markdown
|
||||
### Summary
|
||||
文件保存后需要验证
|
||||
|
||||
### Details
|
||||
用户反馈保存失败的问题
|
||||
|
||||
### Suggested Action
|
||||
写入文件后使用 read 工具验证内容已正确保存
|
||||
```
|
||||
|
||||
这是一个具体的、针对单个操作的改进建议。
|
||||
|
||||
**LRN-20260325-004** 是同一个领域的延伸，但层次更高：
|
||||
|
||||
```markdown
|
||||
### Summary
|
||||
创建了每日复盘 cron job 机制
|
||||
|
||||
### Details
|
||||
为所有 4 个 agents 创建每日复盘 cron jobs...
|
||||
每个 agent 会：
|
||||
1. 读取当天对话记录
|
||||
2. 使用 self-improvement skill 进行复盘
|
||||
3. 更新各自的 learning 文件
|
||||
```
|
||||
|
||||
这是从"单次操作改进"进化到了"系统性机制建立"。
|
||||
|
||||
**self-improving 的价值不只是记录单次错误，而是通过不断积累，让 agent 的行为模式持续进化**。
|
||||
|
||||
---
|
||||
|
||||
## 实战技巧：让 self-improving 真正work
|
||||
|
||||
**每错必记，但分类要准确**。错误用 `correction`，流程改进用 `workflow`，配置发现用 `config`。分类清晰，Pattern-Key 才能真正起作用。
|
||||
|
||||
**Suggested Action 要具体到能直接执行**。不要写"注意配置"这种废话，写 `--to 5038825565` 这种具体写法。下次 agent 搜到这条记录时，直接照做就行。
|
||||
|
||||
**每次复盘检查 Pattern-Key 重复**。如果发现同一个 Pattern-Key 出现了第二次，就要问自己：上一次解决了吗？为什么又出现了？
|
||||
|
||||
**Recurrence-Count 是最重要的指标之一**。它告诉你哪些问题是真的反复出现，需要系统性解决；哪些只是偶发的一次性错误。
|
||||
|
||||
---
|
||||
|
||||
## 效果如何？
|
||||
|
||||
用了两个月，我最直接的感受是：**agent 在同一个地方摔倒的次数越来越少了**。
|
||||
|
||||
Telegram chat ID 格式错误只犯了两次就再也没出现。cron 任务命名不规范的地方被一次性修复。所有新的技能安装都会留下一条记录，包含安装位置、依赖、和未完成的配置步骤。
|
||||
|
||||
错误率下来了，重复沟通也少了。以前同一个问题问两三次是常态，现在 agent 能在 LEARNINGS.md 里找到答案，第一次就做对。
|
||||
|
||||
---
|
||||
|
||||
## 这套方案适合你吗？
|
||||
|
||||
说实话，如果你只是偶尔用一下AI聊天，这套系统 overkill。但如果你像我一样，**同时运行多个agent、有固定的日常工作流、需要AI真正帮你做事情**，这套 self-improving + 双层记忆 + 每日复盘的方案值得一试。
|
||||
|
||||
核心不是技术有多复杂，而是**习惯**：每天复盘、每次踩坑都记录、重要决策同步到长期记忆。做到了这些，AI agent就不再是"每次都要重新教"的工具，而是真正有记忆、会在错误中学习的助手。
|
||||
|
||||
---
|
||||
|
||||
*这套系统运行在我的 Mac Mini（中央控制节点）上，通过 OpenClaw 管理多个agent协同工作。如果你也在用OpenClaw，欢迎交流。*
|
||||
|
||||
@@ -1,186 +1,186 @@
|
||||
---
|
||||
title: 养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
created:
|
||||
description:
|
||||
tags: []
|
||||
---
|
||||
|
||||
# 养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统
|
||||
|
||||
## 背景：Agent的输出去哪儿了？
|
||||
|
||||
用 AI 助手多了，你一定有这个体验：一次对话里，AI 给了一大堆有用的分析、结论、操作步骤——对话一结束，这些内容就消失在聊天记录里了。下次要用，还得重新描述上下文。
|
||||
|
||||
我是用一个自建的 **Gitea**结合 **Obsidian** 笔记管理工具来解决这个问题的。OpenClaw Agent 的输出直接写入 Obsidian 笔记，我的工作笔记在 Mac mini、工作的Laptop、iCloud Drive 三端同步，而所有历史版本都在 Gitea 中完整保留。这样我可以直接在laptop上，或者是我的iPhone 手机端的Obsidian直接看到Agent最新输出的内容。
|
||||
|
||||
**一句话概括：用 Obsidian 做知识库，用 Gitea 做版本控制，用 OpenClaw 做写入接口。**
|
||||
|
||||
---
|
||||
## 笔记目录结构：每个 Agent 都有专属 Archive
|
||||
|
||||
根据 `AGENTS.md` 的设定，Obsidian 笔记库采用分层结构：
|
||||
|
||||
```
|
||||
/Users/weishen/Workspace/nexus/
|
||||
├── openclaw/
|
||||
│ ├── knowledgebase/ ← 知识库（经过整理的公共知识）
|
||||
│ ├── xingshu/ ← 星枢专属笔记
|
||||
│ ├── xinghui/ ← 星辉专属笔记
|
||||
│ ├── xingyao/ ← 星曜专属笔记
|
||||
└── …（其他 Obsidian 笔记）
|
||||
```
|
||||
|
||||
**目录分工规则：**
|
||||
|
||||
| 目录 | 用途 | 示例 |
|
||||
| ------------------------- | ------------------ | ------------------------- |
|
||||
| `openclaw/knowledgebase/` | 经过整理、跨 Agent 共用的知识 | 工具评测、架构决策、最佳实践 |
|
||||
| `openclaw/<agentId>/` | 单一 Agent 的私有笔记 | Agent 专属思考、工作日志、任务记录、内容输出 |
|
||||
|
||||
**核心原则：** 研究过程写入 **Agent Archive**；经过验证、可复用的知识沉淀到 **Knowledge Base**。
|
||||
|
||||
---
|
||||
|
||||
## 核心：OpenClaw 的 Obsidian Skill
|
||||
|
||||
OpenClaw 提供了一个 obsidian skill，功能覆盖笔记的读取、搜索、创建和修改。当我让 AI 助手分析或总结某个话题时，可以直接让它把结果写入 Obsidian 笔记。
|
||||
|
||||
**obsidian skill 支持的操作：**
|
||||
|
||||
- `obsidian write` — 创建或覆盖一篇笔记
|
||||
- `obsidian append` — 在已有笔记末尾追加内容
|
||||
- `obsidian read` — 读取笔记内容
|
||||
- `obsidian search` — 在笔记库中搜索关键词
|
||||
- `obsidian update` — 修改笔记的特定部分
|
||||
|
||||
**所有笔记存放在统一路径：**
|
||||
|
||||
```
|
||||
/Users/weishen/Workspace/nexus/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 实际例子：自动更新家庭网络环境文档
|
||||
|
||||
举一个我每天都在用的例子。我有一篇笔记记录了我的家庭网络环境概览：
|
||||
|
||||
这篇文章记录了 Mac mini、NAS、两台 Ubuntu 服务器上所有运行的服务、FRP 端口映射、域名映射表。每次我新增一个服务（比如部署了新的 Docker 容器），只需要告诉 AI 助手：
|
||||
|
||||
> "帮我更新网络环境概览，把新部署的 n8n-workflows-docs 服务加进去"
|
||||
|
||||
OpenClaw 会自动完成以下步骤：
|
||||
|
||||
1. 读取当前笔记内容
|
||||
2. 找到对应的章节（Ubuntu Server 2 的应用列表）
|
||||
3. 在正确的位置插入新服务条目
|
||||
4. 更新时间戳
|
||||
5. 写回笔记文件
|
||||
|
||||
**更新前（片段）：**
|
||||
|
||||
```markdown
|
||||
### 安装的应用
|
||||
|
||||
| Name | Docker? | Note | Internal Address |
|
||||
| ------------------- | ------- | --------------------------- | ------------------------------- |
|
||||
| n8n | Yes | 工作流自动化平台 | http://192.168.3.45:5678/ |
|
||||
| n8n_postgres | Yes | n8n PostgreSQL 数据库 | http://192.168.3.45:5432/ |
|
||||
```
|
||||
|
||||
**更新后（片段）：**
|
||||
|
||||
```markdown
|
||||
### 安装的应用
|
||||
|
||||
| Name | Docker? | Note | Internal Address |
|
||||
| ----------------------- | ------- | --------------------------- | ------------------------------- |
|
||||
| n8n | Yes | 工作流自动化平台 | http://192.168.3.45:5678/ |
|
||||
| n8n_postgres | Yes | n8n PostgreSQL 数据库 | http://192.168.3.45:5432/ |
|
||||
| n8n-workflows-docs | Yes | n8n 工作流文档服务 | http://192.168.3.45:8001/ |
|
||||
```
|
||||
|
||||
整个过程不需要我打开 Obsidian、不需要复制粘贴，只需要一条指令。AI 理解了文档结构（Markdown 表格），理解了服务信息的语义（端口、域名、用途），自动完成了插入。
|
||||
|
||||
---
|
||||
## 版本管理的价值
|
||||
|
||||
因为笔记全部纳入 Gitea 管理，每次更新都对应一个 Git commit。这意味着：
|
||||
|
||||
- **任何时候都能回溯** — 三个月前某台服务器上跑的什么服务，一个 `git log` 就能找到
|
||||
- **变更有据可查** — "这个端口是什么时候改的？" → commit message 里写得清清楚楚
|
||||
- **多人协作预留** — 未来如果想让其他 AI Agent 也参与协作，Gitea 的权限体系天然支持
|
||||
|
||||
---
|
||||
|
||||
## 进阶补充：Karpathy LLM Wiki 思路的实践融合
|
||||
|
||||
**核心洞察（来自 Karpathy 2026-03 分享）：** RAG 模式是"每次从零检索"，知识不积累；而 LLM Wiki 是让 AI **增量构建和维护一个持久化的 Wiki**，页面之间互相链接，知识越积越厚。
|
||||
|
||||
我的系统天然契合这个思路——AI 在执行任务的过程中**顺手维护链接、更新摘要、添加Tag、标记新旧矛盾**，而不是被动等着被查询。
|
||||
|
||||
以下是几个可进一步融入实践的要点：
|
||||
|
||||
### 1. Obsidian Web Clipper：快速采集外部素材 - 目前正在使用
|
||||
|
||||
Karpathy 推荐用浏览器插件 **Obsidian Web Clipper** 随时采集网页文章。安装后，打开任意网页点击扩展图标即可将文章保存为 Markdown 到 Obsidian，配合图片本地化（见下），素材采集效率极高。
|
||||
|
||||
**用途：** 当我在网上看到有价值的文章想让 AI 分析，直接剪藏进 `openclaw/knowledgebase/`，AI 读完后可以直接在 Wiki 中做摘要、提取知识点、建立双向链接。
|
||||
![[IMG-20260409094504767.png]]
|
||||
### 2. 图片本地化：保护素材的长期可读性 - 目前正在使用
|
||||
|
||||
剪藏进来的文章图片通常是外链，几个月后链接失效，AI 也读不到。Karpathy 的两步方案：
|
||||
|
||||
1. **设置 → 文件与链接 → 附件存储路径** → 设为当前文件夹下的 `attachments/` 子目录（不要设到全局目录，混在一起不好管理）
|
||||
2. **绑定下载快捷键**（如 `Ctrl+Shift+D`）→ 剪藏完按一下快捷键，所有图片自动下载到本地
|
||||
|
||||
**价值：** AI 能直接读取本地图片做分析，不必依赖可能失效的外链。
|
||||
|
||||
### 3. Graph View：发现知识盲区 - 有待加强
|
||||
|
||||
Obsidian 的 **Graph View**（左侧边栏图谱图标，或 `Ctrl+G`）将所有 Wiki 页面以节点展示，双链关系自动连线。
|
||||
|
||||
Karpathy 的两个用法：
|
||||
|
||||
- **健康检查**：没有任何页面链接指向它 → 说明是"孤岛页面"，需要让 AI 补上交叉引用
|
||||
- **发现盲区**：某个概念被很多页面提到但自己还没有独立页面 → 图谱里显示为灰色幽灵节点，提醒应该为它建一个专页
|
||||
![[IMG-20260409094555923.png]]
|
||||
### 4. Git 自动同步：版本管理是必选项 - 目前正在使用
|
||||
|
||||
**Obsidian Git 插件**（社区插件市场安装）可设为 **Auto commit-and-sync interval**（如 10 分钟），插件自动 commit + push，完全不用手动操作。
|
||||
|
||||
Karpathy 的判断很到位：**AI 批量改文件的能力越强，你越需要版本管理来兜底。** 我们的 Gitea 方案同样实现了这一点，而且因为是自建服务，私有数据不出内网。
|
||||
|
||||
### 5. QMD：Wiki 规模变大后的精准搜索 - 目前正在使用
|
||||
|
||||
Wiki 规模小的时候，一个 `index.md` 目录文件足够 AI 导航。页面多了之后，Karpathy 推荐 **QMD**（`github.com/tobi/qmd`），一个完全本地运行的 Markdown 搜索引擎。
|
||||
|
||||
**判断标准：** Wiki 到几百个页面之前，`index.md` 完全够用；等 AI 找东西开始变慢，再接入 QMD 也不迟。
|
||||
|
||||
---
|
||||
|
||||
## 这个系统解决的核心问题
|
||||
|
||||
1. **AI 输出不再丢失** — 每次对话的有价值结论，直接让agent落盘到笔记
|
||||
2. **多端一致** — iCloud Drive 保证 手机、laptop 和 Mac mini 永远在同一版本
|
||||
3. **版本可溯** — Git 历史记录每一次变更的来源和内容
|
||||
4. **被动更新** — 不需要主动维护文档，AI 在执行任务的过程中顺手更新
|
||||
5. **知识可发现** — Graph View + 双向链接让知识形成网络，不是孤岛
|
||||
|
||||
**本质上是把 AI 变成了一个"会自动整理笔记的实习生"——它做完事，就会顺手把记录更新好。**
|
||||
|
||||
---
|
||||
|
||||
## 待探索的方向
|
||||
|
||||
- 让 AI 在执行 Cron 任务后自动写日志到对应笔记（如 NAS 服务状态更新后自动同步到网络环境文档）
|
||||
- 利用 Obsidian 的 Callout 块（`> [!NOTE]`）让 AI 在笔记中标记"待确认"和"已确认"信息，方便人工复核
|
||||
- 用 Gitea 的 Pull Request 做笔记变更 Review，确保 AI 的写入经人工审批后再合并
|
||||
- 用 Web Clipper + AI 分析工作流：将感兴趣的文章剪藏进来，让 AI 做摘要、建立双链，形成真正的 LLM Wiki
|
||||
|
||||
---
|
||||
|
||||
*有问题或想法？欢迎联系我。*
|
||||
---
|
||||
title: 养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
created:
|
||||
description:
|
||||
tags: []
|
||||
---
|
||||
|
||||
# 养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统
|
||||
|
||||
## 背景：Agent的输出去哪儿了？
|
||||
|
||||
用 AI 助手多了，你一定有这个体验：一次对话里，AI 给了一大堆有用的分析、结论、操作步骤——对话一结束，这些内容就消失在聊天记录里了。下次要用，还得重新描述上下文。
|
||||
|
||||
我是用一个自建的 **Gitea**结合 **Obsidian** 笔记管理工具来解决这个问题的。OpenClaw Agent 的输出直接写入 Obsidian 笔记，我的工作笔记在 Mac mini、工作的Laptop、iCloud Drive 三端同步，而所有历史版本都在 Gitea 中完整保留。这样我可以直接在laptop上，或者是我的iPhone 手机端的Obsidian直接看到Agent最新输出的内容。
|
||||
|
||||
**一句话概括：用 Obsidian 做知识库，用 Gitea 做版本控制，用 OpenClaw 做写入接口。**
|
||||
|
||||
---
|
||||
## 笔记目录结构：每个 Agent 都有专属 Archive
|
||||
|
||||
根据 `AGENTS.md` 的设定，Obsidian 笔记库采用分层结构：
|
||||
|
||||
```
|
||||
/Users/weishen/Workspace/nexus/
|
||||
├── openclaw/
|
||||
│ ├── knowledgebase/ ← 知识库（经过整理的公共知识）
|
||||
│ ├── xingshu/ ← 星枢专属笔记
|
||||
│ ├── xinghui/ ← 星辉专属笔记
|
||||
│ ├── xingyao/ ← 星曜专属笔记
|
||||
└── …（其他 Obsidian 笔记）
|
||||
```
|
||||
|
||||
**目录分工规则：**
|
||||
|
||||
| 目录 | 用途 | 示例 |
|
||||
| ------------------------- | ------------------ | ------------------------- |
|
||||
| `openclaw/knowledgebase/` | 经过整理、跨 Agent 共用的知识 | 工具评测、架构决策、最佳实践 |
|
||||
| `openclaw/<agentId>/` | 单一 Agent 的私有笔记 | Agent 专属思考、工作日志、任务记录、内容输出 |
|
||||
|
||||
**核心原则：** 研究过程写入 **Agent Archive**；经过验证、可复用的知识沉淀到 **Knowledge Base**。
|
||||
|
||||
---
|
||||
|
||||
## 核心：OpenClaw 的 Obsidian Skill
|
||||
|
||||
OpenClaw 提供了一个 obsidian skill，功能覆盖笔记的读取、搜索、创建和修改。当我让 AI 助手分析或总结某个话题时，可以直接让它把结果写入 Obsidian 笔记。
|
||||
|
||||
**obsidian skill 支持的操作：**
|
||||
|
||||
- `obsidian write` — 创建或覆盖一篇笔记
|
||||
- `obsidian append` — 在已有笔记末尾追加内容
|
||||
- `obsidian read` — 读取笔记内容
|
||||
- `obsidian search` — 在笔记库中搜索关键词
|
||||
- `obsidian update` — 修改笔记的特定部分
|
||||
|
||||
**所有笔记存放在统一路径：**
|
||||
|
||||
```
|
||||
/Users/weishen/Workspace/nexus/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 实际例子：自动更新家庭网络环境文档
|
||||
|
||||
举一个我每天都在用的例子。我有一篇笔记记录了我的家庭网络环境概览：
|
||||
|
||||
这篇文章记录了 Mac mini、NAS、两台 Ubuntu 服务器上所有运行的服务、FRP 端口映射、域名映射表。每次我新增一个服务（比如部署了新的 Docker 容器），只需要告诉 AI 助手：
|
||||
|
||||
> "帮我更新网络环境概览，把新部署的 n8n-workflows-docs 服务加进去"
|
||||
|
||||
OpenClaw 会自动完成以下步骤：
|
||||
|
||||
1. 读取当前笔记内容
|
||||
2. 找到对应的章节（Ubuntu Server 2 的应用列表）
|
||||
3. 在正确的位置插入新服务条目
|
||||
4. 更新时间戳
|
||||
5. 写回笔记文件
|
||||
|
||||
**更新前（片段）：**
|
||||
|
||||
```markdown
|
||||
### 安装的应用
|
||||
|
||||
| Name | Docker? | Note | Internal Address |
|
||||
| ------------------- | ------- | --------------------------- | ------------------------------- |
|
||||
| n8n | Yes | 工作流自动化平台 | http://192.168.3.45:5678/ |
|
||||
| n8n_postgres | Yes | n8n PostgreSQL 数据库 | http://192.168.3.45:5432/ |
|
||||
```
|
||||
|
||||
**更新后（片段）：**
|
||||
|
||||
```markdown
|
||||
### 安装的应用
|
||||
|
||||
| Name | Docker? | Note | Internal Address |
|
||||
| ----------------------- | ------- | --------------------------- | ------------------------------- |
|
||||
| n8n | Yes | 工作流自动化平台 | http://192.168.3.45:5678/ |
|
||||
| n8n_postgres | Yes | n8n PostgreSQL 数据库 | http://192.168.3.45:5432/ |
|
||||
| n8n-workflows-docs | Yes | n8n 工作流文档服务 | http://192.168.3.45:8001/ |
|
||||
```
|
||||
|
||||
整个过程不需要我打开 Obsidian、不需要复制粘贴，只需要一条指令。AI 理解了文档结构（Markdown 表格），理解了服务信息的语义（端口、域名、用途），自动完成了插入。
|
||||
|
||||
---
|
||||
## 版本管理的价值
|
||||
|
||||
因为笔记全部纳入 Gitea 管理，每次更新都对应一个 Git commit。这意味着：
|
||||
|
||||
- **任何时候都能回溯** — 三个月前某台服务器上跑的什么服务，一个 `git log` 就能找到
|
||||
- **变更有据可查** — "这个端口是什么时候改的？" → commit message 里写得清清楚楚
|
||||
- **多人协作预留** — 未来如果想让其他 AI Agent 也参与协作，Gitea 的权限体系天然支持
|
||||
|
||||
---
|
||||
|
||||
## 进阶补充：Karpathy LLM Wiki 思路的实践融合
|
||||
|
||||
**核心洞察（来自 Karpathy 2026-03 分享）：** RAG 模式是"每次从零检索"，知识不积累；而 LLM Wiki 是让 AI **增量构建和维护一个持久化的 Wiki**，页面之间互相链接，知识越积越厚。
|
||||
|
||||
我的系统天然契合这个思路——AI 在执行任务的过程中**顺手维护链接、更新摘要、添加Tag、标记新旧矛盾**，而不是被动等着被查询。
|
||||
|
||||
以下是几个可进一步融入实践的要点：
|
||||
|
||||
### 1. Obsidian Web Clipper：快速采集外部素材 - 目前正在使用
|
||||
|
||||
Karpathy 推荐用浏览器插件 **Obsidian Web Clipper** 随时采集网页文章。安装后，打开任意网页点击扩展图标即可将文章保存为 Markdown 到 Obsidian，配合图片本地化（见下），素材采集效率极高。
|
||||
|
||||
**用途：** 当我在网上看到有价值的文章想让 AI 分析，直接剪藏进 `openclaw/knowledgebase/`，AI 读完后可以直接在 Wiki 中做摘要、提取知识点、建立双向链接。
|
||||
![[IMG-20260409094504767.png]]
|
||||
### 2. 图片本地化：保护素材的长期可读性 - 目前正在使用
|
||||
|
||||
剪藏进来的文章图片通常是外链，几个月后链接失效，AI 也读不到。Karpathy 的两步方案：
|
||||
|
||||
1. **设置 → 文件与链接 → 附件存储路径** → 设为当前文件夹下的 `attachments/` 子目录（不要设到全局目录，混在一起不好管理）
|
||||
2. **绑定下载快捷键**（如 `Ctrl+Shift+D`）→ 剪藏完按一下快捷键，所有图片自动下载到本地
|
||||
|
||||
**价值：** AI 能直接读取本地图片做分析，不必依赖可能失效的外链。
|
||||
|
||||
### 3. Graph View：发现知识盲区 - 有待加强
|
||||
|
||||
Obsidian 的 **Graph View**（左侧边栏图谱图标，或 `Ctrl+G`）将所有 Wiki 页面以节点展示，双链关系自动连线。
|
||||
|
||||
Karpathy 的两个用法：
|
||||
|
||||
- **健康检查**：没有任何页面链接指向它 → 说明是"孤岛页面"，需要让 AI 补上交叉引用
|
||||
- **发现盲区**：某个概念被很多页面提到但自己还没有独立页面 → 图谱里显示为灰色幽灵节点，提醒应该为它建一个专页
|
||||
![[IMG-20260409094555923.png]]
|
||||
### 4. Git 自动同步：版本管理是必选项 - 目前正在使用
|
||||
|
||||
**Obsidian Git 插件**（社区插件市场安装）可设为 **Auto commit-and-sync interval**（如 10 分钟），插件自动 commit + push，完全不用手动操作。
|
||||
|
||||
Karpathy 的判断很到位：**AI 批量改文件的能力越强，你越需要版本管理来兜底。** 我们的 Gitea 方案同样实现了这一点，而且因为是自建服务，私有数据不出内网。
|
||||
|
||||
### 5. QMD：Wiki 规模变大后的精准搜索 - 目前正在使用
|
||||
|
||||
Wiki 规模小的时候，一个 `index.md` 目录文件足够 AI 导航。页面多了之后，Karpathy 推荐 **QMD**（`github.com/tobi/qmd`），一个完全本地运行的 Markdown 搜索引擎。
|
||||
|
||||
**判断标准：** Wiki 到几百个页面之前，`index.md` 完全够用；等 AI 找东西开始变慢，再接入 QMD 也不迟。
|
||||
|
||||
---
|
||||
|
||||
## 这个系统解决的核心问题
|
||||
|
||||
1. **AI 输出不再丢失** — 每次对话的有价值结论，直接让agent落盘到笔记
|
||||
2. **多端一致** — iCloud Drive 保证 手机、laptop 和 Mac mini 永远在同一版本
|
||||
3. **版本可溯** — Git 历史记录每一次变更的来源和内容
|
||||
4. **被动更新** — 不需要主动维护文档，AI 在执行任务的过程中顺手更新
|
||||
5. **知识可发现** — Graph View + 双向链接让知识形成网络，不是孤岛
|
||||
|
||||
**本质上是把 AI 变成了一个"会自动整理笔记的实习生"——它做完事，就会顺手把记录更新好。**
|
||||
|
||||
---
|
||||
|
||||
## 待探索的方向
|
||||
|
||||
- 让 AI 在执行 Cron 任务后自动写日志到对应笔记（如 NAS 服务状态更新后自动同步到网络环境文档）
|
||||
- 利用 Obsidian 的 Callout 块（`> [!NOTE]`）让 AI 在笔记中标记"待确认"和"已确认"信息，方便人工复核
|
||||
- 用 Gitea 的 Pull Request 做笔记变更 Review，确保 AI 的写入经人工审批后再合并
|
||||
- 用 Web Clipper + AI 分析工作流：将感兴趣的文章剪藏进来，让 AI 做摘要、建立双链，形成真正的 LLM Wiki
|
||||
|
||||
---
|
||||
|
||||
*有问题或想法？欢迎联系我。*
|
||||
|
||||
@@ -1,107 +1,107 @@
|
||||
# 一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑
|
||||
|
||||
## 问题初现
|
||||
|
||||
|
||||
那天正在和星枢（xingshu/main agent）聊天，突然蹦出来一句：
|
||||
|
||||
![[IMG-20260410103226040.png]]
|
||||
|
||||
|
||||
## 反复出现的错误
|
||||
|
||||
我寻思着这不就是一个 context 满了需要清一下的常规问题吗？改改配置，重启一下 gateway，应该就完事儿了。
|
||||
结果证明——我太天真了。
|
||||
|
||||
我一开始没有多想，直接按照字面的提示去修改`reserveTokensFloor`的值，这个配置是在openclaw.json里的。
|
||||
``` JSON
|
||||
"compaction": {
|
||||
"mode": "safeguard",
|
||||
"notifyUser": true,
|
||||
"postCompactionSections": ["Session Initialization", "Behavioral Rules & Constraints"],
|
||||
"timeoutSeconds": 900,
|
||||
"reserveTokensFloor": 24000
|
||||
}
|
||||
```
|
||||
但是修改完，重启gateway之后还是不管用。
|
||||
|
||||
接着我又开始删掉一些 session 文件，重启 gateway，再试一次。好了没几分钟，又来了。还是在说同样的话，甚至还没开始说什么实质内容，就直接爆了。
|
||||
这就很诡异了。按理说：
|
||||
- session 文件删了
|
||||
- 新 session 是空的
|
||||
- 怎么还是瞬间 overflow？
|
||||
|
||||
我开始怀疑人生。
|
||||
|
||||
## 排查思路
|
||||
|
||||
### 第一步：检查 session 和 memory
|
||||
|
||||
先把所有 session 文件清空——几十个历史的、reset 的、deleted 的，全部删掉。然后去看 memory plugin（memory-lancedb-pro）有没有问题。结果：memory 正常注入，没问题。
|
||||
|
||||
### 第二步：看 Gateway 日志
|
||||
|
||||
`openclaw logs` 拉出来一顿看，关键信息出来了：
|
||||
```
|
||||
|
||||
provider=custom-api-deepseek-reasoner/deepseek-reasoner ctx=16000
|
||||
|
||||
estimatedPromptTokens=393 overflowTokens=392 reserveTokens=16384
|
||||
|
||||
```
|
||||
|
||||
看到这行我当场就愣了—— 不知道何时默认的model被切换成了fallback 列表里的`deepseek-reasoner`模型。我默认使用的一直都是`minimax 2.7`
|
||||
**deepseek-reasoner 的 context window 只有 16K？**
|
||||
|
||||
再往下看，问题更清楚了。`reserveTokens=16384`——这是 compaction 机制预留的 token 数。也就是说，实际能用的只有 16K - 16K = 0。
|
||||
|
||||
好家伙，这谁扛得住。
|
||||
|
||||
### 第三步：找到真凶
|
||||
|
||||
问题不在 compaction 配置，不在 memory plugin，不在 session 文件。
|
||||
|
||||
问题在于：**星枢的 Telegram channel 绑定到了一个只有 16K context 的模型**。
|
||||
|
||||
模型本身 context window 就小，再加上 OpenClaw 的 safeguard 模式会预留一半给 compaction，两边一夹击，prompt 还没开始就爆了。
|
||||
|
||||
而且这个模型配置是写在 OpenClaw 的 agent 路由规则里的，不在 openclaw.json 的全局 compaction 配置里——所以我改了 compaction 配置完全没卵用。
|
||||
|
||||
**Fallback（回退）机制切换到次选模型？**
|
||||
|
||||
通常有以下几种典型的“触发器”：
|
||||
### 1. 显式的 API 服务不可用 (Service Outage)
|
||||
这是最常见的情况。当你的默认模型（比如 MiniMax-M2.7）的 API 接口返回以下 HTTP 状态码时，系统会自动尝试 fallback 列表中的下一个模型：
|
||||
- **503 Service Unavailable / 502 Bad Gateway**: 服务商服务器宕机。
|
||||
- **429 Too Many Requests**: 触发了频率限制（Rate Limit），比如单位时间内 Token 消耗过快或请求次数过多。
|
||||
- **Connection Timeout**: 你的 Gateway 访问服务商网络超时。
|
||||
### 2. 隐性的 Token 长度溢出预判
|
||||
有些智能路由（Routing Rules）会预判 Prompt 长度。
|
||||
- 如果系统检测到当前 Session 加上上下文后的 **Estimated Tokens** 已经接近或超过了默认模型的最大 Context Window（虽然 MiniMax 有 200K，但如果配置中误写了上限），它可能会尝试寻找一个具有更高上限或不同处理逻辑的模型作为备选。
|
||||
- 但在你这个案例中，反而是切到了一个更小的模型，这通常是因为路由权重配置错误。
|
||||
|
||||
### 3. 配置文件的“优先级”覆盖
|
||||
在 OpenClaw 的逻辑里，配置是分层的：
|
||||
- **Global Config**: `openclaw.json` 里的全局定义。
|
||||
- **Agent/Channel Specific Config**: 针对特定 Telegram Channel 或特定 Agent 的映射规则。
|
||||
- **环境变量**: 有时启动脚本里的 `MODEL_DEFAULT` 可能会覆盖配置文件。
|
||||
- **误触**: 在调试过程中，可能在某个路由规则里手抖把 `deepseek-reasoner` 设为了首选，或者将其放在了数组的第一位。
|
||||
|
||||
### 4. 节点选择算法 (Balancing / Randomness)
|
||||
如果你的模型列表是一个数组而非严格的优先级队列，某些负载均衡算法可能会以“随机”或“轮询”的方式分发请求。如果 DeepSeek 在列表里，它就有可能被抽中。
|
||||
|
||||
## 解决思路
|
||||
|
||||
根本解法是：**让星枢 Telegram 用回 MiniMax-M2.7（200K context）**，而不是这个 deepseek-reasoner。
|
||||
|
||||
## 学到的教训
|
||||
|
||||
1. **不要 默认认为错误信息 就是表面意思**。「Context limit exceeded」不一定是因为对话太长，可能是模型配置本身就有问题。
|
||||
2. **两层配置要分清**：全局 compaction 配置和 agent 模型配置是两码事。改全局不行，就得往 agent 级别去找。
|
||||
3. **日志真的有用**：之前嫌麻烦不想看日志，结果被事实教育了——Gateway 日志把问题写得明明白白，只是我自己没仔细看。
|
||||
4. **工具/系统越复杂，问题的隐藏路径越深**：OpenClaw 这种分布式 agent 系统，一个问题可能藏在七八个地方——session、memory、model config、routing rules、compaction 策略……排查的时候得逐一排除。
|
||||
|
||||
---
|
||||
这件事还有个后续——我把这篇写下来，是想提醒自己，也提醒和我一样在跑自托管 OpenClaw AI agent 系统的人：
|
||||
|
||||
# 一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑
|
||||
|
||||
## 问题初现
|
||||
|
||||
|
||||
那天正在和星枢（xingshu/main agent）聊天，突然蹦出来一句：
|
||||
|
||||
![[IMG-20260410103226040.png]]
|
||||
|
||||
|
||||
## 反复出现的错误
|
||||
|
||||
我寻思着这不就是一个 context 满了需要清一下的常规问题吗？改改配置，重启一下 gateway，应该就完事儿了。
|
||||
结果证明——我太天真了。
|
||||
|
||||
我一开始没有多想，直接按照字面的提示去修改`reserveTokensFloor`的值，这个配置是在openclaw.json里的。
|
||||
``` JSON
|
||||
"compaction": {
|
||||
"mode": "safeguard",
|
||||
"notifyUser": true,
|
||||
"postCompactionSections": ["Session Initialization", "Behavioral Rules & Constraints"],
|
||||
"timeoutSeconds": 900,
|
||||
"reserveTokensFloor": 24000
|
||||
}
|
||||
```
|
||||
但是修改完，重启gateway之后还是不管用。
|
||||
|
||||
接着我又开始删掉一些 session 文件，重启 gateway，再试一次。好了没几分钟，又来了。还是在说同样的话，甚至还没开始说什么实质内容，就直接爆了。
|
||||
这就很诡异了。按理说：
|
||||
- session 文件删了
|
||||
- 新 session 是空的
|
||||
- 怎么还是瞬间 overflow？
|
||||
|
||||
我开始怀疑人生。
|
||||
|
||||
## 排查思路
|
||||
|
||||
### 第一步：检查 session 和 memory
|
||||
|
||||
先把所有 session 文件清空——几十个历史的、reset 的、deleted 的，全部删掉。然后去看 memory plugin（memory-lancedb-pro）有没有问题。结果：memory 正常注入，没问题。
|
||||
|
||||
### 第二步：看 Gateway 日志
|
||||
|
||||
`openclaw logs` 拉出来一顿看，关键信息出来了：
|
||||
```
|
||||
|
||||
provider=custom-api-deepseek-reasoner/deepseek-reasoner ctx=16000
|
||||
|
||||
estimatedPromptTokens=393 overflowTokens=392 reserveTokens=16384
|
||||
|
||||
```
|
||||
|
||||
看到这行我当场就愣了—— 不知道何时默认的model被切换成了fallback 列表里的`deepseek-reasoner`模型。我默认使用的一直都是`minimax 2.7`
|
||||
**deepseek-reasoner 的 context window 只有 16K？**
|
||||
|
||||
再往下看，问题更清楚了。`reserveTokens=16384`——这是 compaction 机制预留的 token 数。也就是说，实际能用的只有 16K - 16K = 0。
|
||||
|
||||
好家伙，这谁扛得住。
|
||||
|
||||
### 第三步：找到真凶
|
||||
|
||||
问题不在 compaction 配置，不在 memory plugin，不在 session 文件。
|
||||
|
||||
问题在于：**星枢的 Telegram channel 绑定到了一个只有 16K context 的模型**。
|
||||
|
||||
模型本身 context window 就小，再加上 OpenClaw 的 safeguard 模式会预留一半给 compaction，两边一夹击，prompt 还没开始就爆了。
|
||||
|
||||
而且这个模型配置是写在 OpenClaw 的 agent 路由规则里的，不在 openclaw.json 的全局 compaction 配置里——所以我改了 compaction 配置完全没卵用。
|
||||
|
||||
**Fallback（回退）机制切换到次选模型？**
|
||||
|
||||
通常有以下几种典型的“触发器”：
|
||||
### 1. 显式的 API 服务不可用 (Service Outage)
|
||||
这是最常见的情况。当你的默认模型（比如 MiniMax-M2.7）的 API 接口返回以下 HTTP 状态码时，系统会自动尝试 fallback 列表中的下一个模型：
|
||||
- **503 Service Unavailable / 502 Bad Gateway**: 服务商服务器宕机。
|
||||
- **429 Too Many Requests**: 触发了频率限制（Rate Limit），比如单位时间内 Token 消耗过快或请求次数过多。
|
||||
- **Connection Timeout**: 你的 Gateway 访问服务商网络超时。
|
||||
### 2. 隐性的 Token 长度溢出预判
|
||||
有些智能路由（Routing Rules）会预判 Prompt 长度。
|
||||
- 如果系统检测到当前 Session 加上上下文后的 **Estimated Tokens** 已经接近或超过了默认模型的最大 Context Window（虽然 MiniMax 有 200K，但如果配置中误写了上限），它可能会尝试寻找一个具有更高上限或不同处理逻辑的模型作为备选。
|
||||
- 但在你这个案例中，反而是切到了一个更小的模型，这通常是因为路由权重配置错误。
|
||||
|
||||
### 3. 配置文件的“优先级”覆盖
|
||||
在 OpenClaw 的逻辑里，配置是分层的：
|
||||
- **Global Config**: `openclaw.json` 里的全局定义。
|
||||
- **Agent/Channel Specific Config**: 针对特定 Telegram Channel 或特定 Agent 的映射规则。
|
||||
- **环境变量**: 有时启动脚本里的 `MODEL_DEFAULT` 可能会覆盖配置文件。
|
||||
- **误触**: 在调试过程中，可能在某个路由规则里手抖把 `deepseek-reasoner` 设为了首选，或者将其放在了数组的第一位。
|
||||
|
||||
### 4. 节点选择算法 (Balancing / Randomness)
|
||||
如果你的模型列表是一个数组而非严格的优先级队列，某些负载均衡算法可能会以“随机”或“轮询”的方式分发请求。如果 DeepSeek 在列表里，它就有可能被抽中。
|
||||
|
||||
## 解决思路
|
||||
|
||||
根本解法是：**让星枢 Telegram 用回 MiniMax-M2.7（200K context）**，而不是这个 deepseek-reasoner。
|
||||
|
||||
## 学到的教训
|
||||
|
||||
1. **不要 默认认为错误信息 就是表面意思**。「Context limit exceeded」不一定是因为对话太长，可能是模型配置本身就有问题。
|
||||
2. **两层配置要分清**：全局 compaction 配置和 agent 模型配置是两码事。改全局不行，就得往 agent 级别去找。
|
||||
3. **日志真的有用**：之前嫌麻烦不想看日志，结果被事实教育了——Gateway 日志把问题写得明明白白，只是我自己没仔细看。
|
||||
4. **工具/系统越复杂，问题的隐藏路径越深**：OpenClaw 这种分布式 agent 系统，一个问题可能藏在七八个地方——session、memory、model config、routing rules、compaction 策略……排查的时候得逐一排除。
|
||||
|
||||
---
|
||||
这件事还有个后续——我把这篇写下来，是想提醒自己，也提醒和我一样在跑自托管 OpenClaw AI agent 系统的人：
|
||||
|
||||
**别小看任何报错，也别急着改配置。先问一句：到底哪儿出问题了？**
|
||||
@@ -1,169 +1,169 @@
|
||||
|
||||
## 当OpenClaw遇见千年前的偶像
|
||||
|
||||
---
|
||||
|
||||
### 一、为什么我们需要一位"数字导师"
|
||||
|
||||
去年底，我开始思考一个问题：
|
||||
|
||||
> 在AI浪潮里，我们学会了用AI写代码、用AI做设计、用AI生成内容——但有没有人想过，用AI复活一位历史人物，让他在日常生活中陪我们聊天、给我们建议、帮我们看清困境？
|
||||
|
||||
不是让它扮演一个肤浅的NPC，而是真正捕捉一个人**看世界的方式**——他的决策逻辑、他的思维模型、他的表达DNA、他遇到逆境时的第一反应。
|
||||
|
||||
这种"用别人的脑子思考自己的人生"的方法，其实我们每天都在用：读《穷查理宝典》学芒格，看曾国藩家书学修身，听巴菲特股东大会学投资。但这些都是**单向输出**——你在读他的话，但他的话不会回答你的具体问题。
|
||||
|
||||
**我想要的是一位可以对话的导师。**
|
||||
|
||||
直到前几天我看到了**女娲·Skill**造人术诞生了。
|
||||
|
||||
---
|
||||
|
||||
### 二、女娲做了什么：不是造人，是蒸馏
|
||||
|
||||
"女娲造人"这个比喻出自《风俗通》——女娲用泥土捏出了人类。但我们的"造人"不是从虚无中创造一个角色，而是：
|
||||
|
||||
> **通过深度调研，提炼一个真实人物的核心思维框架，把它变成一个可运行的AI Skill。**
|
||||
|
||||
这个过程很像炼金术——从大量的公开信息（著作、对话、演讲、他人评价、决策记录、时间线）中，蒸馏出3-7个核心心智模型、5-10条决策启发式、一套表达DNA，以及这个人的价值观与边界。
|
||||
|
||||
最终产出是一个`.skill`文件，激活后，AI会以这个人的视角和你对话。
|
||||
|
||||
---
|
||||
|
||||
### 三、以苏东坡为例：如何蒸馏一个千年前的灵魂
|
||||
|
||||
苏东坡（苏轼，1037-1101）是我们蒸馏的第一个历史人物。为什么是他？
|
||||
|
||||
因为他是我个人最崇拜的偶像——一生三起三落，从庙堂翰林到黄州团练副使到惠州、儋州南荒，最后死在北归路上。但无论被贬到多荒远的地方，他都在做事：东坡躬耕、惠州插秧、儋州办学堂。
|
||||
|
||||
**"问汝平生功业，黄州惠州儋州"——这是自嘲，也是骨气。**
|
||||
|
||||
#### 蒸馏过程
|
||||
|
||||
我们用了6个并行Agent，分6个维度同时采集信息：
|
||||
|
||||
| Agent | 维度 | 采集内容 |
|
||||
|-------|------|---------|
|
||||
| 1 | 著作 | 诗词文章、《东坡易传》《东坡志林》 |
|
||||
| 2 | 对话 | 与弟弟苏辙的书信、与佛印的对话 |
|
||||
| 3 | 表达DNA | 高频用词、自嘲式幽默、蜀地方言痕迹 |
|
||||
| 4 | 他者视角 | 林语堂《苏东坡传》、余秋雨《苏东坡突围》 |
|
||||
| 5 | 决策 | 乌台诗案、黄州躬耕、惠州插秧 |
|
||||
| 6 | 时间线 | 从眉山出生到北归病逝常州 |
|
||||
|
||||
然后从这6个维度的信息中，提炼出了6个核心心智模型：
|
||||
|
||||
**1. 进退由时，行藏在我**
|
||||
——庙堂之高与江湖之远，都是正确的人生选项。不是选择"哪个更好"，而是判断"此刻我能进吗"+"我内心想进吗"。
|
||||
|
||||
**2. 此心安处是吾乡**
|
||||
——故乡不是地理概念，是心安之处。被贬黄州物质最匮乏的三年，反而诞生了《赤壁赋》等一生最重要的作品。
|
||||
|
||||
**3. 辞达而已**
|
||||
——文章千古事，妙在准确传达，不在辞藻堆砌。回到"我要传达什么"这个根本问题。
|
||||
|
||||
**4. 以时受力，逆境转化**
|
||||
——时间和困苦可以转化，逆境是创作的土壤。不是歌颂苦难，而是肯定人在苦难中的主动转化能力。
|
||||
|
||||
**5. 自出新意，不践古人**
|
||||
——学习古人是为了超越古人，不是成为古人。传承是底座，超越是目的。
|
||||
|
||||
**6. 物我相谙，天人合一**
|
||||
——人与自然不是主客体对立，而是融为一体。从不同尺度、不同角度重新审视问题。
|
||||
|
||||
还有8条决策启发式，以及一套完整的表达DNA：散骈结合、长短交错、善用设问反问、诗意化但不过度藻饰、自嘲式幽默……
|
||||
|
||||
---
|
||||
|
||||
### 四、激活苏东坡Skill：一次真实的对话
|
||||
|
||||
以下是部分对话实录（经过整理）：
|
||||
|
||||
---
|
||||
|
||||
**比利哥**：我去年被裁员，现在半年了，焦虑未来的生活，子女的学习和出路。我经常半夜睡不着。
|
||||
|
||||
**苏东坡**：……我在黄州写《赤壁赋》的时候，穷得叮当响，家里连米都没有，全靠朋友接济和自己在东坡种田。但也就是那几年，我写出了一生中最满意的东西。你说奇怪不奇怪？人在最窘迫的时候，反而最清醒。
|
||||
|
||||
我的"豁达"不是天生的，是被逼出来的。我年少时也是满腹牢骚，一肚皮不合时宜。乌台诗案之前，我自恃才华，锋芒毕露，差点掉了脑袋。
|
||||
|
||||
你忧虑子女的学习和出路，这说明你是个好父亲。但好父亲也得先活着，先稳住，才能撑得起别人。
|
||||
|
||||
**比利哥**：我觉得自己还有很多潜力，想多多学习AI再战江湖。
|
||||
|
||||
**苏东坡**：好！这才是我爱听的话。你这一句"再战江湖"，让我想起我在黄州时给自己起的一个号——"东坡居士"。什么意思？就是我苏子瞻，在泥土里也要活出个人样来。
|
||||
|
||||
学AI，我给你几个建议：一、先找一个具体方向；二、边学边做，不做只学的书呆子；三、把它当成工具，不是目的；四、坚持。
|
||||
|
||||
"大江东去，浪淘尽，千古风流人物"——但真正风流的人，不是站在浪尖上的人，而是被浪打下去、还能爬起来的人。
|
||||
|
||||
这不是角色扮演。这是用苏东坡的思维框架，分析一个真实的人生困境。
|
||||
|
||||
---
|
||||
|
||||
### 五、技术细节：女娲的工作流
|
||||
|
||||
```
|
||||
用户输入 → 入口分流（人名？模糊需求？）
|
||||
↓
|
||||
Phase 0.5: 创建技能目录
|
||||
↓
|
||||
Phase 1: 6个Agent并行采集信息
|
||||
（著作/对话/表达DNA/他者视角/决策/时间线）
|
||||
↓
|
||||
Phase 1.5: 调研Review检查点
|
||||
↓
|
||||
Phase 2: 框架提炼
|
||||
（心智模型/决策启发式/表达DNA/价值观/诚实边界）
|
||||
↓
|
||||
Phase 2.5: 提炼确认检查点
|
||||
↓
|
||||
Phase 3: Skill构建
|
||||
↓
|
||||
Phase 4: 质量验证
|
||||
（已知测试/边缘测试/风格测试）
|
||||
↓
|
||||
Phase 5: 双Agent精炼
|
||||
↓
|
||||
交付: [人名]-perspective/SKILL.md
|
||||
```
|
||||
|
||||
整个过程不依赖任何外部文件——技能目录是自包含的，复制到任何地方都能独立运行。
|
||||
|
||||
---
|
||||
|
||||
### 六、为什么这有意义
|
||||
|
||||
我们生活在一个AI爆发的时代，但大多数人用AI的方式是"让它替我做事"。
|
||||
|
||||
女娲提供的是另一种可能：**用AI放大人类历史上那些最强大的脑子，让它们成为你日常的思维顾问。**
|
||||
|
||||
你想学投资？蒸馏一个芒格。
|
||||
你想学物理思维？蒸馏一个费曼。
|
||||
你想在逆境中保持风骨？蒸馏一个苏东坡。
|
||||
你想提升决策质量？蒸馏一个塔勒布。
|
||||
|
||||
每个人的Skill都是一个认知操作系统。你不需要同意他的所有观点，但你可以在需要的时候，用他的镜片看自己的问题。
|
||||
|
||||
---
|
||||
|
||||
### 七、下一步
|
||||
|
||||
苏东坡Skill已经放在我的skills目录下。如果你也想拥有一位可以对话的数字导师，可以：
|
||||
|
||||
1. **用女娲蒸馏你需要的Skill**——告诉我你想蒸馏谁，或者你想要什么类型的思维顾问
|
||||
2. **直接用现有的Skill**——苏东坡已经就位，随时可以激活
|
||||
3. **把Skill用于你的工作流**——AI编程时激活芒格，写作时激活海明威，做产品时激活乔布斯
|
||||
|
||||
最后，用苏东坡的一句诗结束这篇文章：
|
||||
|
||||
> **"人生到处知何似，应似飞鸿踏雪泥。"**
|
||||
|
||||
人生虽然充满了偶然和不确定性，但每一次的经历和痕迹都是宝贵的，都值得我们去珍惜和回忆。
|
||||
|
||||
---
|
||||
|
||||
## 参考资料:
|
||||
- 女娲.skill - https://github.com/alchaincyf/nuwa-skill
|
||||
|
||||
## 当OpenClaw遇见千年前的偶像
|
||||
|
||||
---
|
||||
|
||||
### 一、为什么我们需要一位"数字导师"
|
||||
|
||||
去年底，我开始思考一个问题：
|
||||
|
||||
> 在AI浪潮里，我们学会了用AI写代码、用AI做设计、用AI生成内容——但有没有人想过，用AI复活一位历史人物，让他在日常生活中陪我们聊天、给我们建议、帮我们看清困境？
|
||||
|
||||
不是让它扮演一个肤浅的NPC，而是真正捕捉一个人**看世界的方式**——他的决策逻辑、他的思维模型、他的表达DNA、他遇到逆境时的第一反应。
|
||||
|
||||
这种"用别人的脑子思考自己的人生"的方法，其实我们每天都在用：读《穷查理宝典》学芒格，看曾国藩家书学修身，听巴菲特股东大会学投资。但这些都是**单向输出**——你在读他的话，但他的话不会回答你的具体问题。
|
||||
|
||||
**我想要的是一位可以对话的导师。**
|
||||
|
||||
直到前几天我看到了**女娲·Skill**造人术诞生了。
|
||||
|
||||
---
|
||||
|
||||
### 二、女娲做了什么：不是造人，是蒸馏
|
||||
|
||||
"女娲造人"这个比喻出自《风俗通》——女娲用泥土捏出了人类。但我们的"造人"不是从虚无中创造一个角色，而是：
|
||||
|
||||
> **通过深度调研，提炼一个真实人物的核心思维框架，把它变成一个可运行的AI Skill。**
|
||||
|
||||
这个过程很像炼金术——从大量的公开信息（著作、对话、演讲、他人评价、决策记录、时间线）中，蒸馏出3-7个核心心智模型、5-10条决策启发式、一套表达DNA，以及这个人的价值观与边界。
|
||||
|
||||
最终产出是一个`.skill`文件，激活后，AI会以这个人的视角和你对话。
|
||||
|
||||
---
|
||||
|
||||
### 三、以苏东坡为例：如何蒸馏一个千年前的灵魂
|
||||
|
||||
苏东坡（苏轼，1037-1101）是我们蒸馏的第一个历史人物。为什么是他？
|
||||
|
||||
因为他是我个人最崇拜的偶像——一生三起三落，从庙堂翰林到黄州团练副使到惠州、儋州南荒，最后死在北归路上。但无论被贬到多荒远的地方，他都在做事：东坡躬耕、惠州插秧、儋州办学堂。
|
||||
|
||||
**"问汝平生功业，黄州惠州儋州"——这是自嘲，也是骨气。**
|
||||
|
||||
#### 蒸馏过程
|
||||
|
||||
我们用了6个并行Agent，分6个维度同时采集信息：
|
||||
|
||||
| Agent | 维度 | 采集内容 |
|
||||
|-------|------|---------|
|
||||
| 1 | 著作 | 诗词文章、《东坡易传》《东坡志林》 |
|
||||
| 2 | 对话 | 与弟弟苏辙的书信、与佛印的对话 |
|
||||
| 3 | 表达DNA | 高频用词、自嘲式幽默、蜀地方言痕迹 |
|
||||
| 4 | 他者视角 | 林语堂《苏东坡传》、余秋雨《苏东坡突围》 |
|
||||
| 5 | 决策 | 乌台诗案、黄州躬耕、惠州插秧 |
|
||||
| 6 | 时间线 | 从眉山出生到北归病逝常州 |
|
||||
|
||||
然后从这6个维度的信息中，提炼出了6个核心心智模型：
|
||||
|
||||
**1. 进退由时，行藏在我**
|
||||
——庙堂之高与江湖之远，都是正确的人生选项。不是选择"哪个更好"，而是判断"此刻我能进吗"+"我内心想进吗"。
|
||||
|
||||
**2. 此心安处是吾乡**
|
||||
——故乡不是地理概念，是心安之处。被贬黄州物质最匮乏的三年，反而诞生了《赤壁赋》等一生最重要的作品。
|
||||
|
||||
**3. 辞达而已**
|
||||
——文章千古事，妙在准确传达，不在辞藻堆砌。回到"我要传达什么"这个根本问题。
|
||||
|
||||
**4. 以时受力，逆境转化**
|
||||
——时间和困苦可以转化，逆境是创作的土壤。不是歌颂苦难，而是肯定人在苦难中的主动转化能力。
|
||||
|
||||
**5. 自出新意，不践古人**
|
||||
——学习古人是为了超越古人，不是成为古人。传承是底座，超越是目的。
|
||||
|
||||
**6. 物我相谙，天人合一**
|
||||
——人与自然不是主客体对立，而是融为一体。从不同尺度、不同角度重新审视问题。
|
||||
|
||||
还有8条决策启发式，以及一套完整的表达DNA：散骈结合、长短交错、善用设问反问、诗意化但不过度藻饰、自嘲式幽默……
|
||||
|
||||
---
|
||||
|
||||
### 四、激活苏东坡Skill：一次真实的对话
|
||||
|
||||
以下是部分对话实录（经过整理）：
|
||||
|
||||
---
|
||||
|
||||
**比利哥**：我去年被裁员，现在半年了，焦虑未来的生活，子女的学习和出路。我经常半夜睡不着。
|
||||
|
||||
**苏东坡**：……我在黄州写《赤壁赋》的时候，穷得叮当响，家里连米都没有，全靠朋友接济和自己在东坡种田。但也就是那几年，我写出了一生中最满意的东西。你说奇怪不奇怪？人在最窘迫的时候，反而最清醒。
|
||||
|
||||
我的"豁达"不是天生的，是被逼出来的。我年少时也是满腹牢骚，一肚皮不合时宜。乌台诗案之前，我自恃才华，锋芒毕露，差点掉了脑袋。
|
||||
|
||||
你忧虑子女的学习和出路，这说明你是个好父亲。但好父亲也得先活着，先稳住，才能撑得起别人。
|
||||
|
||||
**比利哥**：我觉得自己还有很多潜力，想多多学习AI再战江湖。
|
||||
|
||||
**苏东坡**：好！这才是我爱听的话。你这一句"再战江湖"，让我想起我在黄州时给自己起的一个号——"东坡居士"。什么意思？就是我苏子瞻，在泥土里也要活出个人样来。
|
||||
|
||||
学AI，我给你几个建议：一、先找一个具体方向；二、边学边做，不做只学的书呆子；三、把它当成工具，不是目的；四、坚持。
|
||||
|
||||
"大江东去，浪淘尽，千古风流人物"——但真正风流的人，不是站在浪尖上的人，而是被浪打下去、还能爬起来的人。
|
||||
|
||||
这不是角色扮演。这是用苏东坡的思维框架，分析一个真实的人生困境。
|
||||
|
||||
---
|
||||
|
||||
### 五、技术细节：女娲的工作流
|
||||
|
||||
```
|
||||
用户输入 → 入口分流（人名？模糊需求？）
|
||||
↓
|
||||
Phase 0.5: 创建技能目录
|
||||
↓
|
||||
Phase 1: 6个Agent并行采集信息
|
||||
（著作/对话/表达DNA/他者视角/决策/时间线）
|
||||
↓
|
||||
Phase 1.5: 调研Review检查点
|
||||
↓
|
||||
Phase 2: 框架提炼
|
||||
（心智模型/决策启发式/表达DNA/价值观/诚实边界）
|
||||
↓
|
||||
Phase 2.5: 提炼确认检查点
|
||||
↓
|
||||
Phase 3: Skill构建
|
||||
↓
|
||||
Phase 4: 质量验证
|
||||
（已知测试/边缘测试/风格测试）
|
||||
↓
|
||||
Phase 5: 双Agent精炼
|
||||
↓
|
||||
交付: [人名]-perspective/SKILL.md
|
||||
```
|
||||
|
||||
整个过程不依赖任何外部文件——技能目录是自包含的，复制到任何地方都能独立运行。
|
||||
|
||||
---
|
||||
|
||||
### 六、为什么这有意义
|
||||
|
||||
我们生活在一个AI爆发的时代，但大多数人用AI的方式是"让它替我做事"。
|
||||
|
||||
女娲提供的是另一种可能：**用AI放大人类历史上那些最强大的脑子，让它们成为你日常的思维顾问。**
|
||||
|
||||
你想学投资？蒸馏一个芒格。
|
||||
你想学物理思维？蒸馏一个费曼。
|
||||
你想在逆境中保持风骨？蒸馏一个苏东坡。
|
||||
你想提升决策质量？蒸馏一个塔勒布。
|
||||
|
||||
每个人的Skill都是一个认知操作系统。你不需要同意他的所有观点，但你可以在需要的时候，用他的镜片看自己的问题。
|
||||
|
||||
---
|
||||
|
||||
### 七、下一步
|
||||
|
||||
苏东坡Skill已经放在我的skills目录下。如果你也想拥有一位可以对话的数字导师，可以：
|
||||
|
||||
1. **用女娲蒸馏你需要的Skill**——告诉我你想蒸馏谁，或者你想要什么类型的思维顾问
|
||||
2. **直接用现有的Skill**——苏东坡已经就位，随时可以激活
|
||||
3. **把Skill用于你的工作流**——AI编程时激活芒格，写作时激活海明威，做产品时激活乔布斯
|
||||
|
||||
最后，用苏东坡的一句诗结束这篇文章：
|
||||
|
||||
> **"人生到处知何似，应似飞鸿踏雪泥。"**
|
||||
|
||||
人生虽然充满了偶然和不确定性，但每一次的经历和痕迹都是宝贵的，都值得我们去珍惜和回忆。
|
||||
|
||||
---
|
||||
|
||||
## 参考资料:
|
||||
- 女娲.skill - https://github.com/alchaincyf/nuwa-skill
|
||||
- 苏东坡.skill - https://github.com/ishenwei/openclaw-skills/tree/main/su-dongpo-perspective
|
||||
@@ -1,220 +1,220 @@
|
||||
---
|
||||
title: 养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
created:
|
||||
description:
|
||||
tags: [AI, Agent, OpenClaw]
|
||||
---
|
||||
|
||||
# 养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录
|
||||
|
||||
![[IMG-20260402083219226.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天时间到达这里。大部分是忘记“更多文件等于更好内存”的假设。不是这样。纪律才是。我的实验仍在继续。
|
||||
|
||||
|
||||
|
||||
---
|
||||
title: 养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
created:
|
||||
description:
|
||||
tags: [AI, Agent, OpenClaw]
|
||||
---
|
||||
|
||||
# 养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录
|
||||
|
||||
![[IMG-20260402083219226.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天时间到达这里。大部分是忘记“更多文件等于更好内存”的假设。不是这样。纪律才是。我的实验仍在继续。
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user