计划任务

这页不只讲“怎么创建一个计划任务”。

这页更重要的是讲清楚：

• 计划任务适合做什么，不适合做什么
• 它和 Chat、Workflow、WorkPack、Runs、Inbox 是什么关系
• 用户表面看不到，但会直接影响结果的后台规则是什么
• 为什么有些任务明明“到点了”，却没有按你想象的方式执行

先用一句话理解

计划任务适合做的是：

在确定时间，用稳定输入，触发一条可控任务，然后把结果送回 Chat、Inbox 或指定渠道。

它不是“万能自动驾驶”。

如果一件事需要多步编排、分支、审批链、复杂重试，应该优先进入 工作流 或 WorkPack，而不是硬塞进计划任务。

它最适合什么场景

更适合的场景：

• 每天固定时间生成简报、清单、提醒或 handoff note
• 每周固定节奏做项目回顾、风险汇总、例会准备
• 每隔几小时做一次轻量 follow-up
• 让一个稳定的一步任务按时运行
• 让一个已验证的 workflow / WorkPack 在固定时间触发

不适合的场景：

• 需要很多分支判断的流程
• 需要多人审批串联的流程
• 一旦失败就必须自动恢复很多步的流程
• 第一次就直连真实外部发布、真实客户群、真实生产系统
• 你自己都还没手动跑顺的任务

入口

切换到完整工作台，在「推进处理」中打开「计划任务」。

如果你当前在浏览器只读模式，通常只能查看，不能创建、切换或手动触发计划任务。真正的创建、启停和运行，主要依赖桌面端。

计划任务和其他板块是什么关系

这是最容易混的地方。

一句话说：

计划任务是“什么时候触发”，不是“怎么执行”的全部答案。

你在界面里能看到什么

通常你会看到这几类信息：

• 任务名称
• 触发方式
• 执行模式
• 下一次运行时间
• 最近一次状态
• 最近运行记录
• 可选交付去向

表面上看很简单。

但真正决定它是否靠谱的，往往是下面这些“用户不一定第一眼能看到”的东西。

用户不一定看得到，但会直接影响结果的后台规则

这是这页最重要的部分。

1. 计划记录和执行方案不是一回事

如果你是从 Workflow 或 WorkPack 发起定时：

• 计划任务页面里保存的是“定时记录”
• 真正的执行逻辑仍然在 workflow / WorkPack 那边

也就是说，计划任务负责“到时间触发”，Workflow 负责“这次到底怎么跑”。

所以你改 schedule，不等于你改了流程本体。

反过来，你改了 workflow，也不代表所有历史计划记录都会自动变成你想象中的样子。

2. 某些上下文是“关联进去”，不是“整段复制进去”

当计划任务来自项目上下文或对话上下文时，Raydo 更倾向于把源内容作为 metadata 关联进去，而不是把原始上下文整段复制进任务里。

这会带来两个直接结果：

• 好处是更安全，减少原始内容被不必要扩散
• 代价是如果原上下文本身不完整，定时任务也不会凭空变完整

所以不要以为“我当时聊过一次，后面计划任务就永远什么都懂了”。

不一定。

3. 桌面端是否可用，会直接影响本地调度

Raydo 当前有明显的本地调度特征。

对用户来说最实用的理解是：

• 桌面端更像真正的计划任务执行主场
• 浏览器模式更偏只读查看
• 本地 Runtime、桌面调度可用性、应用在线状态，都会影响触发

所以“时间到了没跑”时，第一怀疑对象不该只是 prompt。

更应该先查：

• 桌面端当时是否可用
• 本地调度是否正常
• 设备是否休眠、断网或被系统中断

4. 到点触发，不一定只有一种原因

同一条计划任务的运行，后台可能来自不同触发原因，例如：

• 正常到点触发
• 你手动点了 Run
• 系统在恢复之前错过的触发

这会影响你怎么看一条 run。

比如你以为是“自动准点触发”，其实那次是人工补跑。

再比如你以为是“重复执行”，实际上可能是一条补偿运行和一条手动运行叠在了一起。

5. 结果交付成功，不等于执行全都没问题

计划任务可能有两层成功：

• 执行本身成功
• 结果交付成功

比如内容已经生成了，但发外部渠道失败了。

这时不是“什么都没做成”，而是：

• run 可能已经完成
• 只是 delivery 失败

这就是为什么你要同时看 run 状态和交付去向。

不能只看最后有没有发出去。

6. Raydo 会尽量保留红线，而不是默默帮你赌

对外部渠道、审批、授权、验证这类高风险链路，Raydo 更应该做的是：

• 阻塞
• 等审批
• 记录失败
• 送入 Inbox

而不是在结果不明确时偷偷重发。

这点很重要。

尤其是消息发送、表单提交、公开分发这类动作，宁可让你多看一眼，也不要让系统替你赌第二次。

什么时候该用计划任务，什么时候该升到 Workflow

这是实际使用里最值钱的判断。

用计划任务就够了

• 一步执行
• 输入稳定
• 输出稳定
• 没有复杂分支
• 不需要很多审批
• 失败后人工判断比自动恢复更安全

应该升到 Workflow / WorkPack

• 已经开始出现多步骤
• 已经开始出现“如果 A 失败走 B”
• 已经需要审批点
• 已经需要重试、分叉、留痕、交付链
• 已经不只是“定时提醒我做事”，而是“定时驱动一个完整工作过程”

如果你已经在计划任务里塞了太多补丁逻辑，通常就说明该升级了。

创建前的准备

在你点击创建前，建议先完成这 5 件事：

创建时最关键的 5 个决定

1. 执行模式

计划任务当前通常会落到几类执行模式：

• Chat execution
• Role execution
• Workflow execution
• Work Pack execution
• Media capability execution

实用理解：

• 轻量单步任务，适合 Chat execution
• 需要角色路由，适合 Role execution
• 多步骤编排，适合 Workflow execution
• 要复用现成工作包，适合 Work Pack execution
• 直接图片 / 视频生成，适合稳定的 media capability execution

其中 direct capability 这一路，当前更适合稳定媒体能力，不建议把它理解成“所有能力都能直接定时调用”。

2. 触发方式

当前常见有 3 种：

如果你用 cron，当前更适合把它当成五段式 cron。

如果团队里不是每个人都熟 cron，优先用更直观的日 / 周 / 间隔表达，不要为了“技术上更灵活”把维护成本抬高。

3. 交付去向

结果通常可以送到：

• Chat
• Inbox
• Channel

实用建议：

• 想自己先看结果，优先送 Chat
• 想后续有人继续跟，优先送 Inbox
• 想发到外部渠道，才考虑 Channel

如果 Channel 没配好、没有默认目标，或者连通性本身有问题，结果可能保住了，但 delivery 会失败。

所以“交付去向”不是随便填一下就行。

4. 项目绑定

如果一条任务和某个项目明确相关，尽量绑到项目。

好处很直接：

• 回头更容易追 run
• 更容易看输出属于哪个工作上下文
• 更容易交给别人复盘

5. 名称和描述

计划任务特别容易在一个月后变成“这条到底是干什么的”。

命名建议直接写清：

• 对象
• 节奏
• 结果

比如：

• 工作日 AI 项目简报
• 每周五 handoff note
• 每 2 小时 focus check-in

而不是：

• 自动任务 1
• 运营计划
• daily run

运行状态怎么读

任务状态

任务本身常见状态：

• Active
• Paused
• Completed
• Disabled

实用理解：

• Active：会继续等下一次触发
• Paused：记录还在，但先别继续跑
• Completed：一次性任务跑完，生命周期自然结束
• Disabled：当前不参与触发

单次运行状态

单次 run 常见状态：

• Queued
• Running
• Success
• Failed
• Skipped

其中最容易误判的是：

• Failed 不是都一样，要继续看失败发生在执行还是交付
• Skipped 不一定是坏事，可能是因为条件不满足、预算收口或人为暂停策略

计划任务真正要看的，不只是“下一次运行时间”

很多人只看 next run。

其实更该一起看的是：

• next run 对不对
• last run 是什么状态
• failure count 有没有上涨
• 最近 run 的 output 在哪里
• 有没有送到 Chat / Inbox / Channel

如果只盯着“下一次时间没问题”，其实不够。

高风险任务应该怎么控

如果计划任务会碰下面这些动作：

• 外部发消息
• 发到群或频道
• 浏览器提交
• 写回外部系统
• 公开发布

建议至少做这几件事：

1. 第一轮只用测试目标
2. 保留审批或人工收口
3. 设置最小发送范围
4. 明确失败后不要自动赌重发
5. 首次成功后马上回看 run 与实际外部结果

如果你们团队后面会把计划任务接入更正式的外部分发，这一条尤其不能省。

一个更稳的使用顺序

推荐这样推进：

计划任务背后的“隐形检查”

用户不一定都能直接看到，但从产品设计上，你应该默认计划任务至少会被这些问题影响：

• 能力路由有没有真正解析出来
• 渠道目标有没有选中
• 本地调度是否可用
• 项目上下文是不是足够
• 执行预算和失败预算是否合理
• 停止条件和验证路径是否清楚

如果这些东西没有对齐，计划任务最容易出现的不是“完全不能创建”，而是“能创建，但跑起来不稳”。

这类问题最难排，因为表面看起来像是偶发。

实际上往往是建模阶段就没收口。

和 Inbox 的关系

Inbox 不只是“失败箱”。

它更像是计划任务的人工接力区。

典型情况包括：

• 结果需要你确认
• 交付失败需要你补处理
• 高风险动作不该静默继续
• 任务跑完了，但还需要人工下一步

所以如果你们团队真的开始用计划任务做实际工作，Inbox 要一起看，不要只看 Scheduled Tasks 页面。

和 CLI 的关系

如果你需要更精确地看本地调度状态，或者桌面 UI 看不够细，可以配合 CLI。

常见命令包括：

raydo scheduled-tasks list
raydo scheduled-tasks runs
raydo scheduled-tasks run-due
raydo scheduled-tasks daemon
raydo scheduled-tasks daemon-status
raydo scheduled-tasks daemon-repair
raydo scheduled-tasks daemon-stop

这组命令更适合：

• 查本地调度是不是活着
• 看到期任务有没有被捞到
• 手动触发 due run
• 修本地 daemon

如果你们后面要做更正式的运维文档，这块还可以继续拆一页 CLI 专题。

常见问题

成功标志

一条计划任务真正“成熟”的标志，不只是能创建成功。

而是同时满足这几件事：

• 下一次运行时间正确
• 首次自动触发按预期执行
• 运行结果回到正确位置
• 失败时能在 Runs 或 Inbox 被及时发现
• 不会因为重试、补跑或交付不确定而造成重复外部影响

做到这里，计划任务才算是真的能托付一点工作。