结构变化

raw/微信公众号/养虾日记2：让Agent更懂你：OpenClaw + Self-Improving 复盘实战案例分享.md

@@ -0,0 +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，欢迎交流。*