为什么很多人宣称的“OpenClaw Agent 24小时不停机”做不到？
Reddit、Twitter和各类教程里，这句话很常见，但现实是：大多数人的Agent跑不到2小时就崩了。常见坑包括：Token耗尽、对话卡死、Gateway进程挂掉、任务中断无法续跑、API限流报错，以及成本失控，一天烧掉几百。
但社区里确实有人实现24/7稳定运行：有人用它处理Whats App、Telegram与任务管理，月成本仅150–300美元；也有人用数十个cron任务实现自动恢复。
本文基于官方源码与文档，直接告诉你：要让OpenClaw Agent真正持续稳定工作，必须做对的6件事、具体配置与验证方法。
官方文档明确：追求24/7可靠性请用VPS；能接受休眠/重启中断，可在本地运行。本教程两种方案都讲，但强烈推荐VPS。
核心条件：6 个必备要素
1. Token 管理：防止对话"撑死"
问题： 每次对话都在消耗 token，超过模型的 context window（Claude 是 20 万 token），对话就会卡死或被迫压缩并丢失上下文。
解决方案：自动压缩 + 压缩前预存记忆
压缩（Compaction）的触发条件源自源码：
contextTokens > contextWindow - reserveTokens
在 ~/.openclaw/openclaw.json 中配置：
{
agents: {
defaults: {
compaction: {
reserveTokensFloor: 20000, // 安全缓冲区，不要设为 0
memoryFlush: {
enabled: true,
softThresholdTokens: 4000, // 提前 4000 token 触发预存（官方默认值）
systemPrompt: "Session nearing compaction. Store durable memories now.",
prompt: "Write any lasting notes to memory/YYYY-MM-DD.md; reply with NO_REPLY if nothing to store."
}
}
}
}
}
工作原理：达到软阈值时，OpenClaw 静默触发一次 Agent，让它把重要信息写进 memory/YYYY-MM-DD.md ，然后才压缩。Agent 用 NO_REPLY 响应，你看不见这次操作。
同时配置每日 session 自动重置，防止 token 无限累积：
session: {
reset: {
mode: "daily",
atHour: 4, // 每天凌晨 4 点自动重置
idleMinutes: 10080 // 或者 7 天不活跃也重置
}
}
验证方法： 在对话框发
/status或命令行运行openclaw status，查看当前 token 使用量和 compactionCount。
2. Memory 系统：断了能接上
问题： 网络断了、电脑重启、Gateway 挂了，任务执行到一半中断，Agent 不知道从哪继续。
解决方案：Memory 文件体系
官方文档原话：“模型只记得被写入磁盘的东西，文件是唯一的真相来源。” workspace 目录结构：
~/.openclaw/workspace/
├── MEMORY.md # 长期记忆（需手动创建，存在才加载）
├── memory/
│ ├── 2026-03-18.md # 每日日志（自动追加）
│ └── task-001.md # 长任务状态文件（手动维护）
MEMORY.md 不会自动创建 ，需要手动建：
touch ~/.openclaw/workspace/MEMORY.md
长任务的状态文件模板（memory/task-001.md ）：
# 任务：撰写 OpenClaw 教程
**状态：** 进行中
**最后更新：** 2026-03-18 14:30
## 已完成步骤
- [x] 调研社区案例
- [x] 整理 6 个核心条件
- [x] 撰写前 3 个章节
## 下一步
1. 完成第 4–6 章节
2. 排版 HTML 并发布
在 AGENTS.md 或 SOUL.md 里告诉 Agent 会话启动时先读 MEMORY.md，找到未完成任务，确认后从断点继续。想查看哪些文件被加载，发 /context list 。
验证方法： 手动重启 Gateway，重启后让 Agent 汇报当前任务状态，确认它能从 memory 文件中恢复。
3. Gateway 稳定性：进程挂了能自动重启
问题： Gateway 是核心进程，监听 ws://127.0.0.1:18789 ，它挂了所有 Agent 全停。系统不会自动重启它。
解决方案 A（VPS / Linux）：systemd 用户服务
官方推荐方式，一条命令搞定：
# 安装时直接带上 daemon
openclaw onboard --install-daemon
# 或者已装好后单独安装
openclaw gateway install
# 关键：让服务在你退出登录后继续跑
loginctl enable-linger $USER
警告： Linux systemd 用户服务默认在你退出 SSH 后停止。
loginctl enable-linger是 VPS 上实现真正 24/7 的关键一步，必须执行。
解决方案 B（macOS / 本地机）：PM2
npm install -g pm2
pm2 start "openclaw gateway --port 18789" --name "openclaw-gateway"
pm2 save
pm2 startup # 按提示执行输出的命令，实现开机自启
验证方法： 手动杀掉 Gateway 进程，观察是否在 5 秒内自动重启。运行
openclaw health --json确认恢复正常。
4. 任务设计：可中断可恢复
问题： 任务设计成"一口气做完"，中断后无法恢复。写到一半断了，下次只能重新开始。
解决方案：任务原子化 + 检查点
错误做法
给 AI：“帮我写一篇 5000 字的文章。”——中断后只能重来。
正确做法
拆成 8 个独立步骤，每步完成后保存结果：
步骤 1：调研资料 → 保存到 memory/research.md
步骤 2：整理大纲 → 保存到 memory/outline.md
步骤 3–5：分段写作 → 每段保存一个文件，更新任务状态
步骤 6：生成封面图
步骤 7：排版 HTML
步骤 8：发布到草稿箱
同时，关键操作要做到幂等 ——先检查是否已执行再操作，防止重启后重复执行（比如发邮件前先查是否已发送）。
验证方法： 执行多步骤任务时手动中断，恢复后 Agent 应从上次完成的步骤继续，而不是从头开始。
5. 监控与 Heartbeat：知道发生了什么
问题： Agent 在后台跑，出了问题你不知道。等发现时任务可能已经卡了好几小时。
解决方案：Heartbeat + Cron 定时任务
Heartbeat 是 OpenClaw 内置的主动探测机制：Gateway 每隔指定时间触发一次 Agent，Agent 读取 HEARTBEAT.md 执行检查。测试稳定后在 openclaw.json 里开启：
agent: {
heartbeat: { every: "30m" } // 先设 "0m" 关闭，测试稳定后再开
}
HEARTBEAT.md 示例：
# Heartbeat 检查清单
- 检查有没有紧急邮件
- 检查未来 2 小时的日历事件
- 查看是否有卡住超过 2 小时的任务
以下情况立即通知我（发消息到 Telegram）：
- API 调用连续失败 3 次
- 发现任何异常或错误
- 长任务完成
如果一切正常，回复 HEARTBEAT_OK，不要打扰我。
需要精确定时的任务用 Cron，它持久化存储在 ~/.openclaw/cron/jobs.json ，重启不丢失：
# 每天早 7 点发送早报
openclaw cron add \
--name "早报" \
--cron "0 7 * * *" \
--tz "Asia/Shanghai" \
--session isolated \
--message "发送今天的天气、日历和邮件摘要。" \
--announce
验证方法： 发一条消息触发 Heartbeat（或等 30 分钟），观察 Agent 是否正常汇报。手动触发一个错误，检查是否收到通知。
6. 成本控制：不能让账单失控
问题： 24 小时运行 token 一直在消耗。Heartbeat 每次触发都是一次完整的 Agent 运行，Cron 任务也同理，跑多了费用迅速累积。
解决方案：模型分级 + Context 精简
| 任务类型 | 推荐模型 | 理由 |
|---|---|---|
| Heartbeat、日志整理、简单问答 | claude-haiku-4-5 |
频率高，必须便宜 |
| 写作、分析、代码、核心任务 | claude-sonnet-4-6 |
质量与成本平衡 |
| 超复杂推理（极少数） | claude-opus-4-6 |
贵，谨慎使用 |
在 openclaw.json 里配置默认模型：
agent: {
model: "anthropic/claude-haiku-4-5" // 默认用便宜模型
}
另外三个省钱关键：
- 精简 Heartbeat 指令
——HEARTBEAT.md 越短，每次消耗越少；完全空白时 OpenClaw 自动跳过本次运行
- 控制 workspace 文件大小
——每次运行所有 bootstrap 文件都会注入上下文，单文件建议不超过 2 万字符，所有文件合计不超过 15 万字符
- 不用 Cron 的任务就关掉
——每个 Cron 触发都是一次 Agent 运行，不需要的任务及时删除：openclaw cron list 查看，openclaw cron remove <id> 删除
验证方法： 运行
openclaw status查看 token 消耗统计，观察每日用量趋势是否在预期范围内。
真实案例：他们是怎么做到的
案例 124/7 多渠道运营
做法： 主模型用订阅制（固定费用）处理日常任务，高峰溢出自动 fallback 到按量计费的便宜模型，月成本 $150–300
效果： 24/7 处理 WhatsApp、Telegram、任务管理，成本可控
关键： 订阅制 + 按量备用模型的组合，避免单纯按 token 计费的不可控性
案例 2多 Agent 编排 + 自动恢复
做法： 1 个编排 Agent 指挥多个专业 Agent 分工协作，配合大量 Cron 定时任务
效果： 凌晨自动备份到深夜反思全程自动化，Memory 系统做扎实后中断恢复成功率显著提升
关键： 每个步骤都有状态文件，Agent 在自我进化，同类问题复发率持续下降
行动清单：立即对照检查
Gateway 与平台
-
VPS 用户：
openclaw gateway install已安装 daemon，loginctl enable-linger已执行 -
本地机用户：PM2 守护进程已配置并设置开机自启
-
openclaw doctor
无报错
-
手动杀掉 Gateway 后验证过自动重启
-
workspace 已初始化为私有 Git 仓库
Token 管理
reserveTokensFloor: 20000
（不要设为 0）
memoryFlush.enabled: true
，softThresholdTokens: 4000
-
session 每日自动重置已配置
-
发过
/status确认 token 用量在正常范围
Memory 系统
-
MEMORY.md 已手动创建，写入基本长期记忆
-
发过
/context list确认 MEMORY.md 被加载 -
长任务有对应的状态文件（
memory/task-xxx.md） -
验证过中断恢复：重启后 Agent 能从断点继续
任务设计
-
任务拆成小步骤，每步不超过 1 小时
-
每步完成后保存中间结果到文件
-
关键操作有幂等性检查（做过就跳过）
监控与自动化
-
Heartbeat 先设
"0m"关闭，测试稳定后改为"30m" -
HEARTBEAT.md 精简，写了具体检查任务和告警条件
-
定时任务用 Cron 管理，不用的及时删除
成本控制
-
默认模型设为 Haiku 级别，核心任务指定 Sonnet
-
SOUL.md 控制在 500 行以内
-
所有 workspace 文件合计不超过 15 万字符
-
定期运行
openclaw status观察 token 消耗趋势
总结：24/7 运行不是神话，是工程
OpenClaw 确实可以 24 小时持续工作，但不是装完就能跑的。
重点： 最优先做的两件事：一是选对平台（VPS + systemd，或本地机 + PM2），二是配好 Memory Flush（防止压缩时丢失上下文）。这两件做好了，你的龙虾就有了基本的生存能力。其余的（Heartbeat、任务原子化、成本分级）可以慢慢加。
警告： OpenClaw 维护者明确说过："如果你不知道怎么运行命令行，这个项目对你来说太危险了。"从小范围、低权限开始，在 SOUL.md 里明确限制边界，稳定后再逐步扩大。