WorkBuddy 的自动任务和 CodeBuddy CLI 的定时任务不是一回事

同一家的两个产品都有「定时跑任务」的能力，但机制差得很远——差到不能互相替代。

最关键的一条差异：CodeBuddy CLI 的定时任务是会话级的，退出就没了。

依据：WorkBuddy 官方文档《自动化》（Function-Description/Automation-Guide）与国内定价页；CodeBuddy 官方中文文档 cli/scheduled-tasks。核对日均为 2026-08-16。本文只并列官方事实，不做优劣判断。

一、形态前提

	WorkBuddy 自动化	CodeBuddy CLI 定时任务
载体	桌面客户端的一个功能页	会话内的能力（/loop 等）
官方定位	适用于周期性、重复性任务（每日简报、周报汇总、定时数据整理）	按设定时间表重复执行指令，或在未来某个时间点触发一次性操作
官方举的用途	每日简报、周报汇总、定时数据整理	定期检查构建状态、轮询任务完成情况、在特定时间点提醒自己

从举例就能看出面向的场景不同：一个是办公产出，一个是开发过程中的轮询与提醒。

二、最关键的差异：生命周期

CodeBuddy CLI（官方原文标了「注意」）：

定时任务是会话级别的。任务只在 CodeBuddy Code 运行期间有效，退出后自动清除。

官方在注意事项里还列了几条硬规则：

事项	官方说明
会话绑定	任务随会话存在，退出后任务消失，不会写入磁盘
循环任务上限	每个会话最多同时存在 50 个定时任务
最小间隔	1 分钟（秒级设置会被自动向上取整）
任务过期	循环任务 3 天后自动清除，过期前会最后触发一次
不补跑	会话中断期间错过的任务不会补发执行

WorkBuddy 侧：官方文档描述的是在自动化页面创建任务、可查看已安排的任务及历史执行记录，配置项包含名称、工作空间、提示词、模型与技能、定时规则（含生效日期区间）、推送到小程序。

数量限制来自定价页的档位权益（核对日 2026-08-16）：体验版 3 个、标准版 15 个、高级版 30 个、旗舰版 99 个（页面另标「限免 99 个」，那是活动态）。

并列陈述：一个是会话内临时的、3 天自动过期、每会话 50 个上限；一个是在客户端里持久配置的、按订阅档位限数量。

三、创建方式

CLI 提供了几种写法（官方给的示例）：

/loop 3m 检查一下流水线是否跑完，把结果告诉我
/loop 30m 帮我运行一次单元测试，如果有失败的用例告诉我
/loop 1h 看一下有没有新的 PR 需要我审查
/loop 10m /check-build

时间间隔支持 s（秒）、m（分钟）、h（小时）、d（天），省略时默认 10 分钟。

也支持自然语言（结尾加 every）：帮我监控接口响应时间 every 8m、每隔 25m 检查一下部署状态。

一次性提醒直接用自然语言：下午四点半提醒我同步一下今天的进展、明天早上 9 点帮我生成一份昨天的工作日报——这类执行完毕后自动删除。

需要精确时间的（每周一早上 10 点、每月 1 号），官方说明直接告诉 AI 需求，它会自动转成 cron 表达式并在回复时告诉你实际使用的表达式和执行频率。

WorkBuddy 侧是表单式配置：在自动化页面点右上角「添加」，逐项填名称、工作空间、提示词、模型和技能、定时规则、推送到小程序。官方还提供任务模板，覆盖新闻推送、周报生成、体检预约以及学习计划等常见场景。

四、CLI 独有的两个机制

一、每轮自主调整下一轮间隔。

官方原文：/loop 任务每次触发执行完毕后，AI 会根据本轮结果自主判断下一轮应该：提前触发、延后触发、维持原定间隔，或者直接结束循环。

官方举的例子挺形象：「检查一下流水线是否跑完」这类任务，如果流水线还在跑，AI 可能缩短下一轮间隔；如果跑完了，可能直接结束循环。

二、时间偏移（Jitter）。

官方说明系统会对触发时间添加少量随机偏移，避免大量任务同时执行带来的拥堵：循环任务最多延迟周期时长的 10%（上限 15 分钟）；一次性任务对于整点和半点任务最多提前 90 秒执行。

所以设置「每小时」执行的任务，实际触发时间可能在整点后的 0–6 分钟内随机分布。

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

五、WorkBuddy 独有的几项配置

对照 CLI 的清单，WorkBuddy 的配置项里有几项是 CLI 那边没有对应说明的：

• 工作空间：指定任务执行目录及文件保存位置，默认自动分配 automation-xxxx 工作空间；
• 选择模型和技能：指定执行任务的模型和技能；
• 生效日期区间：定时规则里可以设起止；
• 推送到小程序：开启后推送会通过安全链路把文件同步到云端，以便在小程序端接收；
• 任务模板：四个现成方向。

这几项体现的是「产出物导向」——结果要存到哪、用什么模型、怎么送到你手上。而 CLI 那边的定时任务更偏「过程轮询」。

六、两边共同的一个前提

都跑在你自己的机器上。

• CLI：任务随会话存在，会话在你的终端里；
• WorkBuddy：官方在助理功能说明的「注意事项」里明写——使用助理时，电脑需要保持开机并运行 Tencent WorkBuddy。

两边都不是云端定时器。 电脑关机、休眠，任务都不会跑。CLI 那边还多一条——不补跑（会话中断期间错过的任务不会补发执行）。

七、CLI 侧有一个开关值得知道

官方说明可以通过环境变量完全关闭定时任务功能：

CODEBUDDY_DISABLE_CRON=1 codebuddy

启用后 /loop 技能不再可用，CronCreate、CronList、CronDelete 工具也会被禁用。

WorkBuddy 侧官方文档没有对应的整体开关说明。

八、什么情况用哪个（按官方自述定位归因）

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

• 需要每天/每周产出一份文件（简报、周报、数据整理），并且要长期跑下去 → WorkBuddy 的自动化是按这个设计的（持久配置、指定工作空间与输出、可推送）；
• 需要在一次开发会话期间轮询某个状态（等流水线、等构建、等 PR） → CLI 的 /loop 是按这个设计的（会话级、AI 自主调整间隔、3 天过期）；
• 需要超过 3 天的持续调度 → CLI 官方直接给了建议：在过期后重新创建，或者改用外部调度方案（如 GitHub Actions 等）；
• 需要在手机上看到结果 → WorkBuddy 有「推送到小程序」这一项。

九、我们不写的东西

• 不写谁的定时能力更强——两者面向的场景不同，比较没有意义；
• 不做「一个 /loop 约等于一个自动任务」这类换算；
• 不写 WorkBuddy 侧的任务是否有过期机制——官方文档未说明，不推断；
• 不写单个任务的积分消耗——官方未公布。

小结

• 最关键差异：CLI 的定时任务是会话级的（退出即清除、不写入磁盘、3 天自动过期、每会话最多 50 个、最小间隔 1 分钟、不补跑）；WorkBuddy 的自动化是持久配置，数量按订阅档位（3 / 15 / 30 / 99）。
• 创建方式：CLI 用 /loop [间隔] 指令（省略间隔默认 10 分钟）或自然语言，需要精确时间时 AI 自动转 cron 并告诉你表达式；WorkBuddy 是表单式六项配置 + 任务模板。
• CLI 独有：每轮 AI 自主调整下一轮间隔、时间偏移 Jitter（循环最多延迟周期 10%、上限 15 分钟）。
• WorkBuddy 独有的配置项：工作空间（默认 automation-xxxx）、模型与技能、生效日期区间、推送到小程序、任务模板。
• 共同前提：都跑在你自己的机器上，不是云端定时器。
• 超过 3 天的持续调度，CLI 官方直接建议过期后重建，或改用 GitHub Actions 等外部调度。

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