2026年3月 · 基于官方源码与文档整理 · 阅读约12分钟

开场：为什么大部分人做不到？

“我的OpenClaw Agent可以24小时不间断工作！”

Reddit上、Twitter上、各种教程里，这句话你肯定见过。但事实是：大多数人的代理跑不到2小时就挂了。

• 令牌爆了，对话卡死
• 网关进程挂了，所有Agent全部停
• 任务执行到一半断了，不知道从哪继续
• API速率限制，直接报错
• 成本失控，一天烧掉几十块

社区里确实有人实现了 24/7 运行：有团队用 OpenClaw 处理 WhatsApp、Telegram、任务管理，月成本 $150–300 跑跑；也有人做了几十个 cron 定时任务，实现了理论上次自动恢复。

提示：这篇文章基于官方源码和文档，直接告诉你：要让OpenClaw Agent真正24小时持续工作，需要对哪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 精简

在 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在自我进化，同类问题下降率持续下降

行动清单：立即对照检查

网关与平台

• VPS用户：openclaw gateway install 已安装守护进程，loginctl enable-linger 已执行
• 本机用户：PM2 监控进程已配置并设置开机自启动
• openclaw doctor
  
   无报错
• 手动杀掉网关后验证过自动重启
• 工作区已初始化为仓库 Git 仓库

代币管理

• reserveTokensFloor: 20000
  
  （不要设为0）
• memoryFlush.enabled: true
  
  ，softThresholdTokens: 4000
• session 每日自动重置已配置
• 发过 /status 确认代币用量在正常范围

内存系统

• MEMORY.md 已手动创建，写入基本长期记忆
• 发过 /context list 确认 MEMORY.md 被加载
• 长任务有对应的状态文件（memory/task-xxx.md）
• 验证过中断恢复：重启后代理能从断点继续

任务设计

• 任务拆成小步骤，每步不超过 1 小时
• 每步完成后保存中间结果到文件
• 关键操作有权力等性检查（服务员就跳过）

监控与自动化

• Heartbeat先设置 "0m" 关闭，测试稳定后改为 "30m"
• HEARTBEAT.md 专业版，写了具体检查任务和其他条件
• 定时任务用 Cron 管理，不用的及时删除

成本控制

• 默认模型设置俳句级别，核心任务指定 Sonnet
• SOUL.md控制在500行以内
• 所有工作区文件总计不超过 15 万字符
• 定期运行 openclaw status 观察 token 消耗趋势

总结：24/7运行不是神话，是工程

OpenClaw确实可以24小时持续工作，但不是装完就能跑的。

重点：最优先做的两件事：一是选对平台（VPS + systemd，或本地机 + PM2），二是慢慢配好内存刷新（防止压缩时丢失上下文）。这两件做好了，你的龙虾有了基本的生存能力。其余的（心跳、任务原子化、成本分级）可以加。

警告： OpenClaw 维护者明确表示：“如果你不知道怎么运行命令行，这个项目对你来说太危险了。”范围、低权限开始，在 SOUL.md 里明确限制边界，稳定之后逐步扩大。