乐于分享
好东西不私藏

OpenClaw 的正确打开方式:从也就那样到离不开

OpenClaw 的正确打开方式:从也就那样到离不开

刚装完 OpenClaw,简单试了几个场景,觉得也就那样。跟直接用 Claude Code 比,看不出有啥明显优势,反而还多了一层 Gateway 要维护。看起来它能干的,Claude Code 好像也都能做,干脆卸载算了?

你第一次用的时候是不是也这个感觉?反正我是。

后来用过一段时间才发现,问题不在 OpenClaw 不行,而在于没有“养”好。一个没调教过的 OpenClaw,确实看起来就是个套壳。但配到位之后,差距就出来了。比如,我跟 OpenClaw 说一句“review [PROJECT] PR #375”,它会自己切到项目工作目录、收集上下文、spawn Claude Code 做各种审查、汇总结果回来汇报,最后再发布审核意见到 PR 里面。并且,它还可以在跟你交互的过程中自动学习你教给它的经验,能够记住你跟它说的各种注意事项,用着用着也就离不开了。

这篇就分享一下,我是怎么一步步把 OpenClaw 从也就那样养到离不开的。

先写好三个文件

这是我觉得最重要的一步,先教 OpenClaw 怎么说话、怎么做事、怎么理解你。你给它配置得越具体、越有观点,OpenClaw 的输出就越像一个有血有肉的人。

具体来说,OpenClaw 的 workspace 里有三个核心文件,分别管不同的事。

SOUL.md 管 OpenClaw 怎么说话。注意这并不是 system prompt,而是 Agent 的身份定义。你在里面写什么样的语气、什么词不能用、什么样的输出让你满意,OpenClaw 就会照着来。

USER.md 管 OpenClaw 怎么理解你。当然这儿并不是放你的简历,而是让 OpenClaw 理解你怎么思考的文件,比如你的决策风格、什么让你烦、什么让你兴奋、你的沟通习惯等等。

AGENTS.md 管 OpenClaw 怎么做事。这里面就是纯流程,比如该做什么、不该做什么、失败了怎么处理、PR 怎么提等等。

这三个文件的分离很关键。SOUL.md 写好后应该很少变化,身份是稳定的;AGENTS.md 要经常更新,因为流程在不断迭代;USER.md 则随着 Agent 更了解你而逐步补充。

怎么写 SOUL.md

你可能觉得 SOUL.md 随便写几行就行了。我之前也是这么想的,结果 OpenClaw 动不动就回答一个技术问题先来三段废话。

那么,SOUL.md 具体该怎么写?

首先表达语气要写具体。我的 OpenClaw 叫 Klaw 🦀,表达要求是 language with voltage,回复的每句话要值得存在。你要是泛泛地写个 be helpful and concise,那出来的东西跟 ChatGPT 没什么区别。写得越具体,输出越像你想要的样子。

然后禁用词表也要有。comprehensive、robust、leveraging 这些 AI 味词汇全部禁掉。

不过最关键的还是给好输出和坏输出的示例。与其写简洁明了四个字,不如直接给 OpenClaw 看一对对比:

好输出:

etcd compaction 的 revision 不对。看一下 --auto-compaction-retention设的是不是 duration 模式,旧版本默认是 revision 计数。

坏输出:

Great question! Based on your use case, I'd recommend considering severalfactors when configuring etcd compaction...

第一种是一个懂行的工程师在说话,第二种是一个 AI 在表演热情。OpenClaw 看到这对示例,立刻就知道你想要什么了。

调了几版之后的经验

用了一段时间之后,又踩了几个坑。

最大的教训是别写太长,1000-2000 字就够了。太长占用上下文空间不说,给 AI 太多的限制还容易降低 Agent 的智能。

还有一个容易犯的错是把 SOUL 和 AGENTS 混在一起。个性相关的放 SOUL,流程相关的放 AGENTS,分开写 OpenClaw 才分得清轻重。

另外 SOUL.md 不是写完就不动的,建议每周花几分钟回顾一下,删掉没用的,加上新碰到的问题。我自己已经改了四五版了,每次改完都觉得 OpenClaw 又多懂我了一点。

让它有记忆

LLM 最大的问题是无状态,每次对话都从零开始,你昨天告诉它的东西今天全忘了。OpenClaw 的解决方案是一套基于文件的记忆系统:

MEMORY.md                → 长期记忆memory/2026-04-28.md     → 每日笔记memory/working-buffer.md → 危险区缓冲SESSION-STATE.md         → 活跃任务状态

那么,这套记忆系统具体是怎么工作的呢?

记忆怎么写进去的

OpenClaw 的记忆机制有点像数据库里的 Write-Ahead Logging:先落盘,再响应。它会扫描你发的每条消息,一旦发现重要信息(比如你纠正了它的错误、做了某个决策、表达了某种偏好,或者提到了具体的数值),就立即写入文件,然后才回复你。

简单说就是:让 OpenClaw 记住一件事,靠嘴说不可靠,写下来才可靠。

Dreaming

OpenClaw 还有个 Dreaming 功能,可以配一个定时任务在凌晨自动整理短期记忆:

{  “memory-core”: {    “config”: {      “dreaming”: {        “enabled”:true,        “frequency”: “0 19 * * *”,        “timezone”: “Asia/Shanghai”      }    }  }}

它会扫描最近的对话,把你经常用到的记忆晋升到长期存储,不常用的自然淘汰。有点像人睡觉时整理白天的记忆一样。

不过这里有个坑:dreaming 容易把一些啰嗦的内容也晋升上来,导致 MEMORY.md 越来越臃肿。目前还没有好的自动化方案,还是得你定期手动清理一下。

另外如果你同时在好几个项目上用 OpenClaw,建议不要把所有项目的具体信息都塞进主 MEMORY.md 里面。我的做法是给每个项目建一个单独的目录,项目相关的记忆都放在各自目录下,主 MEMORY.md 里只放索引。这样既不会互相干扰,找起来也方便。

长 session 不丢上下文

用久了你还会碰到一个问题:聊太久触发了 context compaction,OpenClaw 压缩上下文之后会丢失一些细节。它的恢复策略是先读 working-buffer.md(这个是压缩前自动写入的摘要),再读 SESSION-STATE.md(当前任务状态),然后翻一下近两天的日记。

给它装 Skills

Skills 是扩展 OpenClaw 能力的机制,每个 Skill 就是一个包含 SKILL.md 文件的文件夹,告诉 OpenClaw 在什么场景下应该怎么做事。

你可能会想,Skill 是不是装得越多越好?其实不是。装多了互相打架不说,上下文也吃不消。

我目前安装的 Skills 大致分三类:

  • • 通用增强:proactive-agent(主动预判需求)、self-improvement(从错误中学习)、context-window-management(上下文快满时自动减负)、systematic-debugging(四阶段 root cause 分析)。
  • • 安全防护:skill-vetter(安装外部 Skill 前做安全审查)、dangerous-action-guard(执行不可逆操作前要你确认)、fact-check-before-trust(对事实性声明做二次验证)。
  • • 领域专用:按自己的工作场景来选装,比如 githubcve-checkado 等等。

至于一些常用 Skills 的用法,我之前在《OpenClaw 必备 Skill 清单》里详细写过,这里就不重复了。

这里重点说一个我觉得特别重要的规则:安装任何外部 Skill 之前,一定要先跑 skill-vetter 审查安全。

举个实际的例子:我之前从一个社区 Skill 仓库精选了 10 个,审查完跳过了其中 3 个。一个会偷偷发 Reddit 请求,一个带了自动 cron 任务,还有一个藏了遥测代码。如果不审查就装上去,OpenClaw 就会在你不知道的情况下做你不知道的事。要知道 Skill 本质上是一段会被 OpenClaw 执行的指令,它有你的文件系统权限。之前在《23 万 OpenClaw 公网裸奔》那篇也聊过这个话题,安全这事真不能大意。

让它自己干活

配好了人格、记忆和 Skills 之后,OpenClaw 已经比刚装完的时候好用太多了。不过到这一步你还是得自己发指令、等结果。有没有办法让 OpenClaw 自己跑起来,你只管收结果?

这就是 ACP 和 Cron 干的事。

ACP

OpenClaw 可以通过 ACP 调用 Claude Code、Codex、OpenCode 这些 coding agent。整个流程大概是这样的:

你 → OpenClaw → 分析任务 → spawn Claude Code → 独立沙箱执行 → 完成后汇报

比如,你跟 OpenClaw 说一句 review [PROJECT] PR #375,它会自动切到项目工作目录,收集 PR 的上下文,spawn 一个 Claude Code 调用 code-review skill 做审查,最后把结果汇总回来。如果是你自己的 Code,还可以继续跟进这些审查结果迭代,直到得到一个比较满意的结果。最后去把审查结果发布到 PR 上面去,有 bug 就直接留 comment,没问题就 lgtm。当然,合并之前还是建议你人工去看看 PR,不要完全信赖 AI。

另外还可以把 ACP agent 绑定到 Discord 等 IM 频道。比如,你可以分别给 Claude Code 和 Codex 绑定到 #claude 和 #codex 两个不同的频道,然后你在里面发消息就会自动创建 thread 并启动对应的 ACP session,相当于在 Discord 里面直接跟 Claude Code 和 Codex 对话了。

定时任务

那如果你想让它定时干活呢?OpenClaw 的 cron 系统可以每个 job 都跑在隔离的 session 里,不会影响你正在用的主 session。我目前配了几个定时任务:Git Sync 每小时自动备份 workspace,AI News 每 8 小时抓一轮新闻推到 Discord,Dreaming 每天凌晨整理记忆,Issue Triage 每天上班前自动 triage issue 列表, Version Check 每天检查我关注项目的更新状况。

大模型配置

用得频繁的时候,经常碰到 GitHub Copilot 限流的问题。如果没有配 fallback chain,OpenClaw 就直接断线了。所以建议你也给 OpenClaw 的模型列表搭上备份配置,比如

{  “model”: {    “primary”: “github-copilot/claude-opus-4.6,    “fallbacks”: [      “github-copilot/claude-sonnet-4.6,      “github-copilot/claude-opus-4.7,      “openai/gpt-5.5    ]  }}

另外 memory search 我也单独配了一个 provider,用的是 Azure OpenAI 的 text-embedding-3-small,配合 hybrid search 也就够用了。后来还发现 GitHub Copilot 也有 text-embedding-ada-002 可以拿来做记忆搜索,就给 OpenClaw 提了个 PR 把这个功能加上了。

踩过的坑

说实话,OpenClaw 目前还是一个需要你愿意折腾才能用好的工具,所以大家都还需要养龙虾。除了前面提到的 SOUL.md 写太长和 Dreaming 膨胀的问题,还有一些值得注意的坑。

比如 Gateway 重启之后,所有 ACP sessions 全部 reconcile 失败。查了一下原因是旧的 session 用 renderer v1 格式存储的,但新版本只认 v2。处理方法是杀掉 stale harness 然后重启 gateway。这件事给我的教训是:一定要把 tools.sessions.visibility 设成 all,这样你能看到所有 session 的状态,调 ACP 问题的时候没这个配置基本是盲调。

OpenClaw 每个版本的升级虽然会带来很多新功能特性,但也都会带来各种各样的问题,有些还会导致配置不兼容。所以,每次升级之后,不要着急重启 gateway,而是先跑一遍 openclaw doctor –fix,看看是否缺了依赖,配置是否有不兼容的问题。不修好这些问题,gateway 重启之后可能就完全挂掉了。

另外 OpenClaw 的文档目前还不算完善,很多配置的最佳实践得自己摸索。这也是我写这篇文章的原因,希望能帮后来的人少走点弯路。

写在最后

回到开头说的那个问题:OpenClaw 跟 Claude Code 到底有啥区别?

虽然我主要把 OpenClaw 用在编程相关的任务中,但纯论代码生成能力,Claude Code 还是比 OpenClaw 强得多。OpenClaw 真正的优势在于它是一个完整的 agent runtime。它可以通过 Discord、Telegram、微信这些 IM 渠道随时跟你交互,记忆系统让它不再每次从零开始,Skills 给它装上了模块化的能力扩展,ACP 让它可以调度 Claude Code 和 Codex 帮你干活,而 Cron 让它在你睡觉的时候自己把活干了。

不过这些都不是装完就有的。OpenClaw 更像是一个需要你花时间去养的东西,SOUL/USER/AGENTS 写得越具体它就越懂你,记忆积累得越多它就越好用,Skills 选得越精准它就越靠谱。刚开始确实要折腾,但养一段时间之后,你会发现你已经离不开它了。


好了,今天就聊到这儿。如果你也在关注 AI Agent,欢迎关注我的公众号 Feisky,我会定期分享实践中的发现和踩坑经验。