定时任务设了跑没跑？WorkBuddy 定时任务集中管理全流程

摘要：

定时任务最怕"设了跑没跑"没人知道。本文以 WorkBuddy 定时任务为例，走完创建、运行、监控、异常处理到配额与 Credits 管理的全流程，说清去哪看运行记录与产物。

一、定时任务真正的焦虑：设了之后，心里没底

每天早上的数据简报、每周五的周报汇总、共享目录里新增文件的自动处理——这类重复劳动最适合交给定时任务。可真正用起来才发现，难点不在"设"，而在"确认"：任务到底跑没跑？几点跑的？产物放在哪？失败了有没有人知道？

靠人盯的方式，本质是把任务的确定性交给记忆力；靠自建脚本的方式，又要面对日志分散、异常无感知、排查靠猜的局面。任务在机器手里执行，人却对执行状态一无所知，这种信息不对称，才是"设了跑没跑"焦虑的根源。

一个真正可用的定时任务体系，需要回答三个问题：怎么设、怎么确认执行、失败了怎么处理。下文以 WorkBuddy 的定时任务能力为例，按"创建→运行→监控→异常处理→配额与 Credits"的顺序走一遍全流程，把这三个问题逐一落地。

二、创建：四步把一个重复劳动配成可管理的任务

WorkBuddy 把"定时任务"收进左侧边栏同一个入口，所有任务的创建、列表与运行记录都在这一处集中管理——这也是后文能"在一个地方看全"的前提。新建一个任务，核心是按顺序填好四个要素，每一步都有具体落点，而不是凭感觉配。

第一步：进入创建页。 在桌面客户端左侧边栏点击「定时任务」，再点「新建定时任务」，进入可视化配置界面。常用场景可以从内置模板快速起手，个性化需求则完全自定义；习惯用代码管理配置的人，还能切到高级模式，用 YAML 直接编写，方便纳入版本控制或在多台机器间复用。

第二步：定触发器，决定"何时跑"。 触发器有两种：定时触发用 Cron 表达式设定周期，比如"每天 9:00""每周五 17:00"，界面也提供常用周期的可视化选择，不必手写表达式；事件触发则监听某个动作，例如"指定目录下新增文件时"自动启动。配之前先想清楚这次是周期性的还是条件性的，避免建错类型导致任务不按预期启动。

第三步：定执行体，决定"做什么"。 执行体是任务真正干的事，用一段自然语言指令来描述，例如"汇总昨日工作生成简报"。指令之下可以挂载具体能力：要推送结果就接上企业微信等连接器；要做文件处理就调用对应技能；要套用专业方法论就召唤专家。把"指令 + 能力"配齐，任务才从一句描述变成无人值守的动作。

第四步：定工作空间，决定"在哪跑、产物落哪"。 指定任务在哪个工作空间执行，文件的读取与产物写入就会落在预期目录，不会出现"任务成功了却找不到产物在哪儿"的情况。对多项目并行的团队，这一步尤其关键——它保证每个任务的操作范围清晰、互不串扰。

四步填完保存，任务就出现在「定时任务」列表里，集中管理就此成立。建议在正式交给无人值守之前，先手动触发一次试运行：确认它按预期执行、产物落在正确目录、连接器推送到位。跑通一次再放手，比直接上线后"设了跑没跑"心里没底要稳得多。

三个高频场景可以直接对照套用：每天早上 9:00 自动生成昨日工作简报并推送到企业微信；每周五下午 5:00 自动汇总本周工作并生成周报；当指定目录下新增文件时，自动调用文件处理技能。这三类分别对应周期汇总、定期汇报、文件监听三种模式，本质都是上面四步的不同组合。

三、运行与监控：跑没跑、产物在哪，都有明确答案

任务创建之后，"确认执行"就有了固定的查看位置，不用再回到创建时的配置页里翻状态。定时任务页把模板、配置与运行记录集中到一处查看：汇总页按时间线依次展示历次运行，哪一次成功、哪一次失败、各自产出了什么，沿着时间线即可逐一核对；任务完成后还会以系统通知的形式提醒，产物不再藏在文件夹里等人发现。

对于正在执行的任务，后台任务支持查看详情与终端输出，执行过程不再是个黑盒。如果人不在电脑前，微信小程序是另一个确认入口：在桌面客户端「设置」→「微信小程序」中扫码绑定后，小程序可以查看运行中的任务状态，并接收任务完成通知；移动端 App 同样支持对任务进行查看、追问与中断。

把这几处观察点连起来，"设了跑没跑"就有了闭环答案：汇总页看历史，系统通知看结果，小程序与 App 看实时状态，终端输出看执行细节。定时任务从"盲跑"变成"可查"，靠的不是记性，而是这些固定入口。

四、异常处理：让失败从黑洞变成可处理的事件

定时任务最怕的不是失败，而是失败了没人知道，知道了处理时又重复建会话、把现场冲掉。现在的重试机制会在当前会话继续处理失败的任务，避免生成新的重复会话；重试成功后的状态会准确显示，切换任务也不会再带上旧错误。

任务已经启动但执行异常时，对话框中可以点击「中止」按钮停止当前任务，再重新描述需求发起。日常排查可以沿四个方向入手：当前选中的模型负载较高时，切换其他模型；网络延迟较高或不稳定时，排查网络波动与代理设置；安全软件拦截或本地网络异常时，检查网络连接与放行情况；任务本身过重、Agent 需要多步执行时，拆成更小的步骤分次完成。定时任务多在无人值守时段执行，异常往往不会有人当场发现，因此排查更依赖运行记录与产物通知来暴露问题，而不是靠使用者撞见——排查思路本身与常规问答场景一致，区别只在触发方式。

五、配额与 Credits：放量之前，先把账算清

定时任务跑得越多，越要把两笔账算清楚：一是任务数量配额，二是每次执行消耗的 Credits。下面分两块说明，最后补一个容易混淆的边界。

5.1 任务数量配额

各版本每月可创建的自动任务额度不同，括号内为限免期间的额度：

• 体验版：每月 3 个（限免期间 99 个）
• 标准版：每月 15 个（限免期间 99 个）
• 高级版：每月 30 个（限免期间 99 个）
• 旗舰版：每月 99 个
• 企业版：不限制数量

需要同时跑几十个周期任务的团队，企业版在额度空间上更从容，不会因为额度见顶而被迫删旧任务。

5.2 Credits 消耗

Credits 是 WorkBuddy 计量模型调用、文件处理等操作的虚拟积分，定时任务每次执行都会消耗一定数量的 Credits。消耗多少取决于两件事：

• 调用的模型：不同模型消耗不同，推理模型消耗更多；
• 处理的内容：文件处理按文件大小消耗。

查看与管控方式分两类：个人可在「设置」→「积分」中查看当前余额与消耗明细；企业版则由管理员统一查看团队整体的消耗量，便于集中核算。

实操建议是先用消耗较低的档位把任务跑通、核对产物质量，再逐步调整执行频率与模型，避免一上来就按高频加推理模型的方式放量，导致 Credits 快速消耗却还没验证产物价值。

5.3 一个容易混淆的边界

项目内也可以配置定时执行的任务，但它与个人全局的定时任务是两套独立体系，放量前要先分清楚：

• 项目内定时任务：项目级能力，仅支持定时触发，且仅创建者本人可见、可管理；
• 个人全局定时任务：支持定时与事件两种触发方式，由创建者在全局范围内可见和管理。

团队推广时建议把两者边界讲清楚，避免成员找不到别人创建的定时任务、重复配置出功能相同的任务，白白占用额度。

六、总结

定时任务的价值不在于"设上去"，而在于"可确认"：创建时结构清晰，运行后记录可查，失败时有路径处理，放量前有账可算。五步走完，自动化才从"设了就跑"变成"跑了能验"，无人值守才真正立得住。

当定时任务需要调用更多外部能力时，技能生态决定了自动化的边界——执行体可以调用的技能与连接器越多，无人值守能覆盖的环节就越长。当前 WorkBuddy 官方活动页 汇总了企业专享版的活动信息：316 元/用户/月（100 人起购），提供腾讯云专享 VPC、独享运行环境、数据租户隔离与专属企业插件，自动任务数量不设限制，适合对运行环境与数据隔离有要求的团队；页面上的"云 Skills × WorkBuddy 最佳实践集"收录了 OCR、COS、EdgeOne、CloudBase、CLS 与 WorkBuddy 的联动案例，可作为扩展自动化边界的参考。