蜂控定时任务怎么设才放心？别只看名称，要核对下次触发和执行结果

设了“每天检查一次”，是不是就可以不管了？先看一眼任务列表里的下次执行时间，再看它具体要交给哪个 AI 做什么。这两件事，比任务叫什么名字更重要。

在这次只读检查中，我们看到过任务说明与实际周期字段不一致的情况：描述里写的是一个频率，真正配置的是另一个间隔；也有描述为“每天某个时间”，配置却是“每隔 24 小时”的任务。因此，这篇不教你多建几个定时器，而是讲怎样确认它真的按预期工作。

以下说明基于蜂控 v1.2.105 的任务页面与对应调度逻辑。检查没有修改或触发任何现有任务，私人名称和业务内容未公开。

名称是备注，计划字段才决定时间

当前蜂控 AI 定时任务支持一次性、间隔与每周计划。对于“每天固定时刻”，应按界面提供的每周日期与时间配置来表达，例如选择一周七天，再设置目标时间；不要只在名称里写“每天”。

需求	要检查的配置
过一会儿提醒一次	一次性时间、次数和接收 AI
每隔一段时间检查	间隔分钟数、下次触发时间
每天固定时刻检查	所选日期、时刻及下次触发时间

“每 24 小时”按间隔推进，不保证对应你想要的每天早上某个时刻。当前每周时间计算还依赖运行服务所处的时区；如果运行环境换到了服务器，尤其要核对页面显示的下一次时间。

创建后让 AI 回读配置，比让它再说一句“已设置”更有用：

请核对任务的实际计划类型、间隔或日期时刻、下次触发时间、触发次数限制和接收对象。不要只复述任务名称。

定时器负责叫醒 AI，不替你验收业务

当前调度流程会把任务内容投递给对应 AI 会话。投递成功后，触发计数递增。因此，列表里的“已触发”不能直接当作“设备操作成功次数”。

可以把一次任务分成三个问题：

1. 有没有到点投递？ 看任务状态、触发记录和下次时间。
2. AI 有没有开始处理？ 看对应会话与工具调用情况。
3. 设备有没有完成？ 看执行结果、相关记录或目标页面。

例如“检查状态”已经投递，但设备暂时无法连接，业务就不算完成。反过来，AI 的文字总结也不应替代关键操作的结果核对。

第一个任务，建议只做一次只读检查

可以用下面这个示例表达需求，不涉及发送消息或修改内容：

五分钟后，仅检查指定测试设备的连接状态，不修改设备。只执行一次。报告在线、离线或无法确认，并说明查询结果。创建后告诉我实际触发时间和接收 AI。

然后亲自核对任务列表，等到时间后看对应记录。确认“时间正确、对象正确、结果可理解”，再改成周期需求。

蜂控本机任务依赖运行中的服务；把电脑关机或让服务停止，不应期待它仍像独立的云定时服务一样执行。设备任务还需要相应设备与执行环境可用。出现“异常停用”时，先查原因，不要反复新建同名任务。

周期任务里，把重复执行的后果写清楚

定时检查状态通常容易重复做；发送消息、创建内容、安装应用就不一样。如果上一次结果不明，下一次直接再做，可能造成重复。

可以补充：

开始前先确认上一轮结果；仍在执行或结果未知时，不重复提交。已完成的项目跳过，失败项单独报告。连续异常时停止自动处理，交给人工确认。

这段是设计要求，不代表所有蜂控任务已经自动具备这些保护。需要结合具体脚本或技能实现，并实际验证。

其他调度系统也强调类似原则。例如 Kubernetes 的 CronJob 文档提醒，调度存在特殊情况下重复或未创建任务的可能，应让任务具备可重复执行而不产生额外副作用的设计。这里引用的是工程思路，不表示蜂控使用 Kubernetes 调度。官方文档

最后看这四项就够了

计划是否符合需求；目标 AI 与设备是否正确；运行环境是否可用；结果怎样确认、失败怎样处理。

如果定时内容还很模糊，先按AI 任务描述技巧把它收窄。如果每次操作步骤都相同，可以先整理成可验证的小脚本，再安排周期执行。定时器的价值是按时发起一个已经说清楚的任务，而不是反复放大一个还没调好的流程。