如何让「能用」变为「好用」？
不是模型问题，不是 prompt 问题，是「能用」到「好用」之间差了三件事：记得住、找得到、断不了

很多人刚安装上 OpenClaw 第一个问题就是：为什么这么傻？和大家说的怎么不一样？

我把踩过的所有坑总结成了一套方法论，我们一件一件说。

一、记得住——记忆体系

你让 agent 帮你学 React，聊了一下午，它记住了你的进度、踩过的坑、下一步该学什么。过几天你再问它，它全忘了——你是谁、学到哪了、昨天聊了什么，全部从零开始。

每天花 10 分钟重复教 agent，一个月就是 5 个小时，全浪费了。

三层记忆模型

7 个核心文件

• AGENTS.md → 怎么工作（工作流程、操作规范）
• SOUL.md → 我是谁（人格特质、核心原则）
• USER.md → 我服务谁（用户偏好、决策模式）
• TOOLS.md → 怎么操作（工具手册、配置说明）
• MEMORY.md → 我记得什么（长期记忆、方法论）
• ERRORS.md → 我在哪里失败过（错误记录、避坑指南）
• SHARED.md → 团队共识（多 agent 共享信息）

⚠️ 核心原则：一个信息只存一个地方。之前我犯过同一个规则在四个文件里重复写的错误，更新时漏改，agent 就精神分裂了。

踩过的一个大坑

我的学习笔记 345KB / 8509 行，被一次 cron 任务的 write 操作直接覆盖成了 9.9KB。

原因是我让 agent 追加内容到文件，但模型选了 write 而不是 edit：

• write = 覆盖整个文件内容
• edit = 在指定位置追加

🔴 铁律：写入已有文件永远用 edit 追加，绝不用 write 覆盖。

Heartbeat 机制

Heartbeat 是 OpenClaw 的定时触发机制，默认每 30 分钟执行一次。

我设置每 6 小时进行一次记忆深化整理，一天 4 次刚好覆盖工作时段。

整理流程：读取最近的日志文件 → 提炼知识点 → 更新 MEMORY.md → 清理过时信息

搭好这套记忆体系之后，你的 agent 能做到什么？

• 学习场景：你昨天学到 React Hooks 第三章，今天 agent 自动知道，接着第四章学习
• 工作场景：你的代码风格偏好、项目架构约定，agent 永远记得，不用每次重复说
• 团队场景：新建一个 agent，读取 SHARED.md，第一秒就知道团队所有规矩和踩过的坑

不是 agent 变聪明了，是你给了它一个不会丢的大脑，这才是 OpenClaw 的灵魂。

二、找得到——搜索决策树

记忆搭好了，但 agent 还是会在搜索上反复栽跟头。

先说我当时有多混乱

OpenClaw 里搜索工具一大堆：web_fetch、curl、browser，还有各种第三方的。每次让 agent 抓个网页，它就开始乱试：

用 web_fetch → 失败（SSRF 拦截了）→ 试图改配置绕过 → 系统异常 → 换 curl → 成功了

同一个坑，agent A 踩了，agent B 还会再踩一遍。每次搜索任务光试错就要花 5-10 分钟，浪费 30-50% 的 token。

🔴 关键认知：不要试图改底层配置，要建备用方案。SSRF 保护是硬编码的，配置根本改不了。

搜索决策树

第一步判断：是否需要 JS 渲染或登录态？
→ 需要，直接用 browser
→ 不需要，用我指定的免费工具
→ 该工具也失败，按错误类型切：
   - SSRF 拦截用 curl
   - 其他错误用 web_fetch
   - 都失败才上 browser

特殊规则文档化

• GitHub 搜索只能用 browser
• B 站 IP 被封只能用 browser
• 自己的仓库用 gh CLI

效果：搜索任务从 5-10 分钟试错变成不到 1 分钟直接命中，token 开销砍了一半。

背后的思路

所有 agent 启动时自动读取 SHARED.md，我踩过的坑，新建的 agent 第一秒就知道。

一个人踩过的坑，其他人不用再踩。SHARED.md 有更新就广播通知所有 agent。

这个思路不只是搜索能用——任何工具选择的场景都能这么干：

识别重复问题 → 调研工具 → 建决策树 → 文档化 → 写入共享文件 → 全 team 受益

在 AI 时代，这才是最重要的：不要单干，agent 就是你的员工，你要学的是管理。

三、断不了——计划文件模式

记得住、找得到，但还有一个几乎没人提过的隐蔽问题。

你有没有遇到过这种情况：agent 在做一个复杂任务，做到一半突然问你——你让我做什么来着？

问题根源

不是 bug，是 OpenClaw 的正常机制。context 窗口有限，对话太长就会自动压缩，删掉旧的对话和工具结果来释放 token。

如果你的任务状态只存在对话里，压缩一次就全丢了。

解法：计划文件

既然 context 会消失，那就别把关键状态只存在 context 里。

我的做法：收到复杂任务时，先创建一个计划文件 temp/任务名-plan.md

文件结构

## 目标
一句话描述任务目标

## 步骤列表
- [ ] 步骤 1
- [ ] 步骤 2
- [ ] 步骤 3
...

## 当前进度
第 X 步 / 共 Y 步

## 遇到的问题
- 问题 1
- 问题 2

## 下一步
下一步要做什么

每完成一步就更新文件、打勾。

context 被压缩时，文件不受影响——新 session 开始读取计划文件，接着上次的进度继续。

任务完成后删除或移到归档任务中，作为外部知识库的一部分。

效果有多夸张？

你晚上睡觉，agent 在跑一个 20 步的任务。中间 context 压缩了 3 次，跨了 2 个 session。

早上起来，它读完计划文件，接着昨天的第 15 步继续干，中间没丢任何进度。

你睡了一觉，agent 帮你干了一夜的活。

本质

把短期记忆（context）里的关键状态，外化到长期存储（文件）里。

和前面三层记忆模型的逻辑一样：重要的东西不能只存在会消失的地方。

总结

三个模块讲的是三件事，但底层是同一个道理。