金句开头：真正毁掉一个好工具的，往往不是功能不够强，而是你在没打地基的情况下，把它当「生产系统」在用。
一、120 小时之后，我才明白什么叫「别把玩具当生产」
很多人用 OpenClaw 的路径，都差不多：
- 一开始只是本地玩玩：跑个 demo、试试 Agent、写点小脚本；
- 觉得「好像挺稳的」；
- 某一天，你开始让它连夜跑任务、跑批处理、管一堆 Skills；
- 结果第二天一看：
- 磁盘快满了；
- 内存报警；
- 日志乱成一锅粥；
- 有的任务跑了一半挂了，连错在哪都懒得告诉你。
那一刻你会突然醒悟：
「它不是不行，是我压根没当系统来对待它。」
120 小时之后，我把那些「早知道一开始就该做」的事情，粗暴总结成 5 条。 你可以把它当成一份「OpenClaw 上生产前的体检清单」。
二、第 1 条：一定要有「专用工作目录」和「专用日志目录」
最容易被忽略的坑，就是「一切都默认」：
- 默认当前目录；
- 默认日志路径；
- 默认临时文件位置。
结果就是：
- 日志和缓存散落在项目里，想清理不敢删；
- 真出问题时，你连「它到底写到哪去了」都不知道。
正确的做法，是一开始就给 OpenClaw 规划一块「地盘」：
/opt/openclaw或你习惯的任何路径；- 里面统一划分：
logs/、tmp/、agents/、skills/、runs/； - 所有任务都在这个「沙盒」里活动。
这样一来：
- 出问题时，你知道去哪里找日志；
- 想清理时，可以放心地清掉整个
tmp/或单次run/目录； - 备份和迁移也有了清晰边界。
三、第 2 条：资源「限死一点」比「放飞一点」更安全
很多人对自己的机器有一种迷之自信：
「我这 32G 内存，开点并发算啥事。」
但你要意识到，OpenClaw 背后调的可能是：
- 本地大模型；
- 多个外部 API；
- 一堆工具/脚本/子进程。
任何一个环节出事，最后都要算在你这台机器头上。
你至少要做几件事：
- 给运行 OpenClaw 的用户单独设定
ulimit（最大打开文件 / 最大进程数）； - 给日志文件设定
logrotate，防止一夜之间几 G； - 对某些「重任务」设定单次运行超时和最大重试次数。
一句话：
别等资源打满了，才想起「要不限制一下」——那已经晚了。
四、第 3 条：没监控 = 白跑，别指望第二天还能复盘
很多人以为「跑得好不好」可以靠感觉：
- CPU 风扇声音大了点；
- 桌面卡了两下；
- 日志文件长了一截。
但当你想认真回答几个问题时，就会发现完全抓不住：
- 哪个任务最耗时、最费资源？
- 错误率最高的是哪个 Skill / Agent？
- 哪个时间段最容易出问题？
没有最基本的监控和统计，一切只是「印象」，不是「数据」。
你不需要一上来就搞 Prometheus + Grafana， 但至少可以：
- 定期记录 CPU / 内存 / 磁盘占用（哪怕是简单的 cron + shell）；
- 针对关键任务，打点起止时间、输入规模、输出大小；
- 把错误信息统一进一份「错误日志」，而不是散落各处。
这样当你跑完 120 小时再回头看时， 你手里至少有一份「可以学习的样本」，而不是一片混乱的黑盒。
五、第 4 条：日志不是「写给系统看」的，是写给未来的你看的
刚开始写日志的时候，我们都在用技术人的视角：
- 打一堆 debug；
- 输出各种变量；
- 记录很底层的信息。
但 120 小时之后，你会非常想揍当时的自己一顿：
- 这些日志告诉了你一堆「事实」，却很少告诉你「故事」；
- 你知道发生了什么，却不知道「为什么会这样」。
真正好用的日志，应该至少包括三层：
- 事件层：什么时候、谁、干了什么（哪一个 Agent / Skill 被触发、输入是什么）；
- 结果层：成功/失败、耗时多少、消耗了多少资源（Token/调用次数）；
- 决策层：关键分支是怎么选的（走了哪条策略、为什么走这条）。
你不需要把每一条都写得很重，但一定要给未来的自己留一点「可读性」：
让 3 天后的你，看一眼日志就能接上当时的思路，而不是从头猜。
六、第 5 条：永远准备一个「一键刹车」的开关
最后一个，也是最重要的：
请务必给自己留一个「紧急刹车」的开关。
无论这个开关是：
- 一个简单的「暂停标志文件」（存在就不再接新任务）；
- 一个面板上的开关按钮；
- 甚至只是一个约定俗成的「Kill 某个进程组」脚本；
关键在于——
当你发现事情不对劲的时候，要有办法 马上停下来，而不是眼睁睁看着它「继续作死」。
这个开关的存在，会极大提升你「敢于让它自动跑」的心理安全感。
七、小结：从「玩具心态」切换到「系统心态」
如果用一句话概括这 120 小时的教训：
你对 OpenClaw 的态度，决定了它是玩具，还是系统。
当你只是抱着「玩玩看」的心态去用：
- 默认配置就够了；
- 出问题重启就好；
- 日志乱点也无所谓。
可一旦你开始让它：
- 接外部请求；
- 帮你跑重要任务；
- 成为你生产力的一部分；
那你就必须像对待任何一套在线服务那样，对待它：
- 有界的目录；
- 有限的资源；
- 可观测的行为；
- 有故事性的日志；
- 可随时拉下的刹车。
只要你在一开始，花半天时间把这 5 条都「真正做一遍」， 后面那 120 小时，不仅不会是噩梦，反而会成为你为数不多「值得骄傲的工程实践」之一。
AI 解读
1. 问题本质拆解
- 表面是在分享「OpenClaw 120 小时踩坑经验」，
- 本质是在回答一个更底层的问题：「如何把一个实验性工具，提升到生产可用的系统级别？」
文章用「5 条必做」的方式，把抽象的「系统心态」拆成可以执行的动作：
- 目录 & 日志规范；
- 资源限制；
- 轻量监控；
- 可读日志；
- 紧急刹车。
2. 与 Skill 体系的映射 这篇文章可直接映射到你 SKILL-DIRECTORY.md 里的两个关键 Skill：
skill.openclaw.sandbox.setup：- 专注环境、目录、权限、日志基础配置；
skill.openclaw.runtime.guard：- 专注监控、资源控制、错误率、刹车策略。
文章可以看作这两个 Skill 的「经验故事版实现」：
- 输入：一套「玩具心态」的 OpenClaw 部署；
- 输出：一个「至少能跑 120 小时不崩」的系统。
3. 可扩展方向
- 你可以在
api.xyxbot.com下继续补一个skill.openclaw.setup.safe-runtime，把文中 5 条动作编码成一个统一的初始化流程； - 也可以为这篇文章配一份
checklist.md，每次新部署直接照单核查。
分类：AI 工具与编排
关键词：OpenClaw,长时间运行,踩坑总结,资源限制,日志系统,监控,守护进程,系统心态,安全运行
来源： 专栏文章：OpenClaw跑了120小时，踩了无数坑总结出的5条必做，这些坑你千万别再踩！ https://zhuanlan.zhihu.com/p/2001031113431335425