成功乐观者的必读秘籍：在放弃OpenClaw前你需要知道的事

调试 OpenClaw 的经历宛如驯服一只脾性古怪、力量无比的机械龙虾。它能够帮助你迅速提升工作效率，但有时也会失控，导致资源的浪费。初期的几天里，我几乎天天在想，是不是该放弃这项工具。一边看着 broker 一遍又一遍地输出相同的结果，一边感受到 token 像沙漏般迅速消逝。然而，经过几轮的折腾，它终于开始稳定运行，甚至让我感受到了一种“好用”的成就感。此时我才意识到，问题并不是出在它的能力上，而是在于我尚未掌握调试的要领。

首先，我的一个重要经验是进行模型分层。不要将最昂贵的模型用于日常心跳检查和那些无关紧要的任务，这就像用一辆豪华跑车去送外卖，虽然速度快，但成本极高。相对便宜的模型，如 Haiku、Gemini Flash 甚至本地的 Ollama，能够有效处理这些常规事务，而复杂的任务则应交给高端模型去完成。此外，你可以在流程中随时使用 `/model` 命令切换模型，没必要在一开始就耗尽所有资源。许多人抱怨输出不够好，实际上只是使用不当而已。

其次，需要为它设置“护栏”。即使是开箱即用的 OpenClaw，依然像一名聪明但情绪多变的学徒：它会进行循环、忘记上下文，甚至做出让人意想不到的决定。与其让其自由发挥，不如在 `workspace/skills/` 中清晰地编写 SKILL.md，把任务细分得明确具体，再加入反循环与压缩总结的规则，以及提问前的任务检查。高效的代理背后，往往是一整套经过打磨的指令集——你是指挥者，它则是演奏者。

第三，任务调度也至关重要。很多人以为只要开启一个代理会话，关闭聊天窗口后它就能继续工作。实际上，session 只有在互动时才会保持状态。后台任务需要与 cron job 配合，并设置独立的目标。如果涉及一次性延时任务，就必须使用一个队列（可以是 Notion、SQLite 或文本文件），然后用 cron 进行轮询。如果不理解这一点，往往会误以为系统“不稳定”。

第四，循序渐进是关键。一次性接入邮箱、日历、Telegram、爬虫和 cron，看似高效，其实是在增加故障风险。我学会了先建立一个简单的工作流，比如早报 cron，让其稳定到让我完全放心后，再逐步添加其他任务。别忘了运行 OpenClaw Doctor，它有时能在系统崩溃前及时救助。

第五，持久化状态也是一个重要环节。compacting 会逐渐丢失上下文，因此要将关键决策记录在持久文档中，如 USER.md、AGENTS.md 和 HEARTBEAT.md，减少 broker 的“重新学习”次数，这样整体表现会显著改善。许多人忽视这一点，结果只能抱怨“它怎么又忘了”。

最后，我必须强调，OpenClaw 目前还未完全成熟。那些号称“一夜之间生成完整 App”的演示，背后往往是数周的调试。尽管真实使用与展示之间的差距在缩小，但仍然存在。因此，如果你觉得调试过程异常艰难，请不要怀疑自己的能力——这正是它的常态。

希望这些经验能够帮助你减少资源浪费，降低怀疑自己能力的次数。如果你在某个具体问题上遇到困难，不妨交流一下，也许你会发现这只机械龙虾，实际上只需要一双懂得驯养的手。