WorkBuddy 的自动化和 OpenClaw 的 Cron 怎么比？一个图形配置，一个网关调度器

2026-08-16

「让它定时自动干活」这件事，两边都能做，但从怎么创建到怎么保存，几乎每一环都不一样。

先把形态前提摆清楚：WorkBuddy 是商业闭源桌面客户端，OpenClaw 是 MIT 开源的自托管 Gateway 网关。形态不同，自动化的实现方式自然不同。

依据：WorkBuddy 官方文档《自动化》（Function-Description/Automation-Guide）与国内定价页；OpenClaw 官方中文文档 zh-CN/automation/cron-jobs。核对日均为 2026-08-16。本文只并列官方事实，不做优劣判断、不做性能对比——我们没有安装任何一方。

一、创建方式

	WorkBuddy 自动化	OpenClaw Cron
创建方式	自动化页面点右上角「添加」，表单填六项	命令行：`openclaw cron create ...`
管理方式	页面上查看已安排的任务及历史执行记录	`openclaw cron list` / `get` / `show` / `runs --id <job-id>`
有没有模板	有：新闻推送、周报生成、体检预约、学习计划等	官方这一页未提模板

WorkBuddy 的六个配置项：名称、工作空间（默认自动分配 automation-xxxx）、提示词、选择模型和技能、定时规则（含生效日期区间）、推送到小程序。

OpenClaw 的创建示例（官方原文给的一次性提醒）：

openclaw cron create "2027-02-01T16:00:00Z" \
  --name "Reminder" \
  --session main \
  --system-event "Reminder: check the cron docs draft" \
  --wake now \
  --delete-after-run

从这两个例子就能看出受众差异：一个是填表单，一个是敲命令带参数。

二、任务存在哪、活多久

这是两边最实质的差异之一。

OpenClaw（官方原文）：

Cron 在 Gateway 网关进程内部运行，而不是在模型内部。Gateway 网关必须处于运行状态，调度才能触发。 任务定义、运行时状态和运行历史会持久化到 OpenClaw 的共享 SQLite 状态数据库中，因此重启不会丢失调度。

还有两条机制说明：

每次 Cron 执行都会创建一条后台任务记录；
一次性任务（--at）默认在成功后自动删除；传入 --keep-after-run 可保留；
Gateway 网关启动时，逾期的隔离式智能体轮次任务会被重新调度，而不是立即重放——官方给的理由是避免模型/工具的引导工作占用渠道连接窗口。

WorkBuddy：官方文档说明可在自动化页面查看已安排的任务及历史执行记录；配置项里有生效日期区间。任务是否持久化、存在哪里、重启后是否保留——官方文档没有对应的机制说明，我们不推断。

三、数量限制

	限制方式
WorkBuddy	按订阅档位：体验版 3 个、标准版 15 个、高级版 30 个、旗舰版 99 个（定价页另标「限免 99 个」，是活动态）
OpenClaw	官方 `cron-jobs` 这一页未给数量上限说明

WorkBuddy 侧的这个限制很实际：如果自动化是你的核心用法，规划要按不带括号的常规值算——按限免的 99 个规划，活动一结束回到 3 个，流程就塌了。

四、超时机制

OpenClaw 这边官方给得很细：

每次运行的实际时间预算：设置后使用 --timeout-seconds。否则——

隔离式/分离式智能体轮次任务受 Cron 自身的 60 分钟看门狗限制（该限制会在底层智能体轮次超时 agents.defaults.timeoutSeconds、默认 48 小时生效前触发）；

命令任务默认为 10 分钟；

脚本载荷默认为 5 分钟。

WorkBuddy 侧官方文档没有超时机制的说明，我们不推断。

五、两边共同的一个前提

都要求「宿主活着」。

OpenClaw：官方明写 Gateway 网关必须处于运行状态，调度才能触发；
WorkBuddy：官方在助理功能说明的「注意事项」里明写——使用助理时，电脑需要保持开机并运行 Tencent WorkBuddy。

两边都不是「云端托管的定时器」。区别在于宿主的形态：一个是你自己跑的 Gateway 进程（可以在服务器、容器、树莓派上），一个是你桌面上的客户端。

这带来一个实际差异：OpenClaw 文档里列了 Docker、Kubernetes、各家云托管的部署方式，所以它的 Gateway 可以 7×24 跑在服务器上；WorkBuddy 的自动任务依赖你那台桌面电脑醒着——电源设置里的自动睡眠是最常见的杀手。

六、输出去哪

OpenClaw（官方原文）：Cron 可将输出发送到聊天渠道、Webhook，或不发送到任何位置。

WorkBuddy：结果保存到指定目录（工作空间）；另有一项「推送到小程序」——官方说明开启后推送会通过安全链路把文件同步到云端，以便在小程序端接收。

两边的思路不同：一个是「发到哪个渠道」，一个是「存到哪个目录 + 要不要推到手机」。

七、外部调度这条路

有意思的是，两边官方都提到了「用外部调度器」这个选项：

OpenClaw 官方给了详细的注意事项：如果你通过系统 Cron 或其他外部调度器驱动 openclaw agent，要用硬终止升级机制封装它；对 GNU timeout 应优先使用 timeout -k 60 600 openclaw agent ... 而不是普通的 timeout 600 ...；对 systemd 单元使用 SIGTERM 停止信号并设置 TimeoutStopSec。还说明了 --run-id 重复使用时的行为——如果原始 Gateway 网关运行仍处于活动状态时重复使用 --run-id，系统会将重复请求报告为正在运行，而不会启动第二次运行。
同门的 CodeBuddy CLI 那边（定时任务是会话级、3 天过期）官方直接建议：需要更长时间就改用外部调度方案（如 GitHub Actions 等）。

WorkBuddy 侧官方文档没有涉及外部调度——这符合它的定位：面向不碰命令行的办公用户。

八、按官方自述定位的场景归因

强调：这是按双方官方自述的定位与机制做的归因，不是评测结论。

你要每周产出一份文件（周报、简报、数据整理），不想碰命令行，还想在手机上看到结果 → WorkBuddy 的自动化是按这个设计的（表单配置、任务模板、推送到小程序）；
你要任务持久化、重启不丢、跑在服务器上 7×24 → OpenClaw 的 Cron 官方写明持久化到 SQLite、重启不丢调度，且文档列了容器与云托管路径；
你需要精确控制每次运行的超时 → OpenClaw 给了 --timeout-seconds 与多层默认值；
你需要把输出发到聊天渠道或 Webhook → OpenClaw 的 Cron 直接支持这三种去向；
你的电脑不能一直开着 → 这一条对 WorkBuddy 是硬约束（官方明写需保持开机运行）。

九、我们不写的东西

不写谁的自动化更强——形态不同（桌面客户端 vs 自托管网关），比较没有意义；
不做「一个自动任务约等于一个 cron job」这类换算；
不写 WorkBuddy 侧的持久化、超时、数量之外的机制——官方文档未说明，不推断；
不写 OpenClaw 的数量上限——官方这一页未给；
不写稳定性、准点率等表现——不在双方官方文档里，也无法在不安装的情况下验证。

小结

形态前提：WorkBuddy 是商业闭源桌面客户端，OpenClaw 是 MIT 开源自托管 Gateway 网关。
创建方式：WorkBuddy 表单六项 + 任务模板；OpenClaw 命令行 openclaw cron create ...。
★ 持久化：OpenClaw 官方明写任务定义、运行时状态与运行历史持久化到共享 SQLite，重启不会丢失调度；WorkBuddy 侧官方未说明，不推断。
数量：WorkBuddy 按订阅档位（3/15/30/99，另有限免活动态）；OpenClaw 官方这一页未给上限。
超时：OpenClaw 给了 --timeout-seconds 与默认值（60 分钟看门狗 / 命令任务 10 分钟 / 脚本载荷 5 分钟）；WorkBuddy 侧未说明。
共同前提：都要求宿主活着——OpenClaw 是 Gateway 网关必须运行，WorkBuddy 是电脑需保持开机并运行客户端。
输出去向：OpenClaw 可发聊天渠道 / Webhook / 不发送；WorkBuddy 是存到工作空间 + 可选推送到小程序。

双方功能与文档表述均以各自官方为准，核对日 2026-08-16。