这是 OpenClaw 教学系列的第二篇，核心议题只有一个：如何让「能跑」真正变成「好用」。
很多人在刚装上 OpenClaw 后的第一个念头往往是：怎么这么难用？跟别人说的完全不一样。
这背后的原因并不复杂：
不是模型的问题，也不是 Prompt 写得太差——从「能用」到「好用」，中间差了三个关键环节：记得住、找得到、断不了。
下面我就把踩过的所有坑总结成一套可复用的方法论，一件一件说清楚。
一、记得住——构建持久记忆体系
你让 Agent 帮你学习 React，聊了一下午，它记住了你的进度、踩过的坑、下一步该学什么。过几天你再问它，全忘了——你是谁、学到哪了、昨天聊了什么，都要从零开始。每天花 10 分钟重复教 Agent，一个月就是 5 个小时，全浪费了。
怎么解决？
这里有一套实践中总结出的三层记忆模型：
Tier 1 信息层
原始记录——学习笔记、对话记录，直接存在 memory/learning/ 目录下，只追加不删除，按需检索。
Tier 2 知识层
每日提炼——工作日志、重要决策、提炼后的知识点，每天一个文件 memory/YYYY-MM-DD.md（这是 OpenClaw 自带的机制）。
Tier 3 智慧层
长期记忆——跨领域洞察、底层规律、核心方法论，存放在 MEMORY.md 里，控制在 100 行以内，每次 Session 都加载。
这个模型灵感来自人类的记忆方式——你不会记住每天看过的所有文字，但会记住提炼后的知识点，最终形成底层的思维模式。
然后是 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 覆盖。这条规则现在写在每个 Agent 的 ERRORS.md 和 SHARED.md 里，所有 Agent 启动就知道。
再简单说一下 Heartbeat——这是 OpenClaw 的定时触发机制，默认每 30 分钟执行一次。之所以要介绍它，是因为光有记忆的存储架构还不够，记忆的动态吸纳不能只靠 OpenClaw 自带的机制——那样还是太弱。
如何解决动态吸纳问题？答案就是 Heartbeat 机制。可以设置每 6 小时进行一次记忆深化整理，一天 4 次刚好覆盖工作时段。整理流程：读取最近的日志文件 → 提炼到 MEMORY.md / USER.md / ERRORS.md / 每日记忆 → 清理过时信息。
搭好这套记忆体系之后，Agent 能做到什么？
- 学习场景：你昨天学到 React Hooks 第三章，今天 Agent 自动知道，接着第四章学习。
- 工作场景：你的代码风格偏好、项目架构约定，Agent 永远记得，不用每次重复说。
- 团队场景：新建一个 Agent，它自动读取
ERRORS.md，第一秒就知道团队所有规矩和踩过的坑。
不是 Agent 变聪明了，是你给了它一个不会丢的大脑——这才是 OpenClaw 的灵魂。
OpenClaw 确实很厉害，但不会搭 Agent 框架的人用这个，就像小孩拿激光枪，威力巨大，却用不明白。
二、找得到——建立搜索决策树
记忆搭好了，但 Agent 还是会在搜索上反复栽跟头。
当时有多混乱——OpenClaw 里搜索工具一大堆：web_fetch、curl、browser，还有各种第三方的。每次让 Agent 抓个网页，它就开始乱试：用 web_fetch → 失败（SSRF 拦截了）→ 试图改配置绕过 → 系统异常 → 换 curl → 才成功。同一个坑，Agent A 踩了，Agent B 还会再踩一遍。每次搜索任务光试错就要花 5-10 分钟，浪费 30-50% 的 Token。
更要命的是——当时试图在 openclaw.json 里加 dangerouslyAllowPrivateNetwork 来绕 SSRF，不但没用，还搞出了系统异常。后来才知道 SSRF 保护是硬编码的，配置根本改不了。这是第一个关键认知：不要试图改底层配置，要建备用方案。
转折点来自一个免费的全网搜索工具，装上之后自动变成 OpenClaw Skill，所有 Agent 直接可用——全网语义搜索、网页阅读、YouTube 字幕提取，全免费，不需要 API Key。当然，这个工具本身不重要，重要的是要学会去找别人造好的轮子。
测完之后发现它能覆盖 80% 的搜索场景，剩下 20% 的特殊情况各有各的解法。于是建了一套统一的搜索决策树：
- 第一步判断：是否需要 JS 渲染或登录态？
- 需要 → 直接用
browser - 不需要 → 用指定的免费工具
- 该工具也失败 → 按错误类型切：SSRF 拦截用
curl，其他错误用web_fetch，都失败才上browser
- 需要 → 直接用
特殊规则也得文档化：GitHub 搜索只能用 browser、B 站 IP 被封只能用 browser、自己的仓库用 gh CLI。
效果：搜索任务从 5-10 分钟试错变成不到 1 分钟直接命中，Token 开销砍了一半。
但这套方案最有价值的不是决策树本身，而是背后的思路——把它写进了 SHARED.md。所有 Agent 启动时自动读取，一个人踩过的坑，新建的 Agent 第一秒就知道。中控 Agent 负责维护 SHARED.md，有更新就广播通知所有 Agent。
这个思路不只是搜索能用——任何工具选择的场景都能这么干：识别重复问题 → 调研工具 → 建决策树 → 文档化 → 写入共享文件 → 全 Team 受益。从个人经验到团队知识，这是一次升维。在 AI 时代，最重要的就是：不要单干，Agent 就是你的员工，你要学的是管理。
三、断不了——采用计划文件模式
记得住、找得到，但还有一个几乎没人提过的隐蔽问题。
有没有遇到过这种情况：Agent 在做一个复杂任务，做到一半突然问你——你让我做什么来着？你以为是 Bug，重启了 Session，让它重新开始。又做到一半，又忘了。不是 Bug，是 OpenClaw 的正常机制——Context 窗口有限，对话太长就会自动压缩，删掉旧的对话和工具结果来释放 Token。如果你的任务状态只存在对话里，压缩一次就全丢了。
大部分人遇到这个问题会觉得是 OpenClaw 不好用，其实是不知道这个机制存在。知道了原因，解法就清楚了——既然 Context 会消失，那就别把关键状态只存在 Context 里。
做法：收到复杂任务时，先创建一个计划文件 temp/任务名-plan.md。文件结构很简单：目标（一句话）+ 步骤列表（带 Checkbox）+ 当前进度 + 遇到的问题 + 下一步。每完成一步就更新文件、打勾。
Context 被压缩时，文件不受影响——新 Session 开始读取计划文件，接着上次的进度继续。任务完成后删除或移到归档任务中，作为外部知识库的一部分。而且 Heartbeat 检查时也能发现进行中的任务，主动向人汇报进度。
效果有多夸张？晚上睡觉，Agent 在跑一个 20 步的任务。中间 Context 压缩了 3 次，跨了 2 个 Session。早上起来，它读完计划文件，接着昨天的第 15 步继续干，中间没丢任何进度。你睡了一觉，Agent 帮你干了一夜的活。如果不加这个机制，效果就难说了。
本质上，这就是把短期记忆（Context）里的关键状态，外化到长期存储（文件）里。和前面三层记忆模型的逻辑一样：重要的东西不能只存在会消失的地方。
三个模块讲的是三件事，但底层是同一个道理。
以上是框架层面的解法。
