刚装完 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 several
factors 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”:“019***”,“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（对事实性声明做二次验证）。
• 领域专用：按自己的工作场景来选装，比如github、cve-check、ado 等等。

至于一些常用 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.4”] }}

另外 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、Slack 这些 IM 渠道随时跟你交互，记忆系统让它不再每次从零开始，Skills 给它装上了模块化的能力扩展，ACP 让它可以调度 Claude Code 和 Codex 帮你干活，而 Cron 让它在你睡觉的时候自己把活干了。

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

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。