Schedule Ops Skill

任务操作技能

工具清单

加载：全部为 deferred 工具，调用前须先 ToolSearch(names: "ScheduledTaskManage,ScheduledTaskStatus,ScheduledTaskWait") 激活 schema。

什么时候用哪个工具

• 用户在问任务情况（"有什么任务"、"进度怎么样"、"哪些待审批"）→ ScheduledTaskStatus
• 用户要创建、取消、删除任务 → ScheduledTaskManage（create / cancel / delete / archive 等）
• 用户要审批或打回某个任务 → ScheduledTaskManage 的 resolve 动作（approve / reject / rework）
• 用户要"立刻做某事"且希望看到结果（"跑这个脚本"、"现在生成报告"）→ ScheduledTaskManage(create, skipPlanConfirm:true) + 紧接着 ScheduledTaskWait
• 用户既问又改（"看看有什么任务，把过期的都取消掉"）→ 先 ScheduledTaskStatus 拿列表，再逐一 ScheduledTaskManage

立即任务 vs 定时任务：什么时候用 ScheduledTaskWait

这是本技能最关键的决策点。任务完成不会自动出现在对话里——Agent 不会收到任何异步通知。 要想知道任务结果，只能主动调工具去取（类似 Claude Code 的 Sleep 工具语义）。

立即任务：create + ScheduledTaskWait

用户描述当下就要做的事（"跑一下这个脚本"、"检查系统状态"、"生成一份报告"、"现在帮我 X"）：

1. ScheduledTaskManage(action:'create', skipPlanConfirm:true, ...) 启动
2. 紧接着调 ScheduledTaskWait({taskId, timeoutSec:60}) 阻塞等待完成
3. 根据 ScheduledTaskWait 返回的 tool_result 告知用户最终结果，然后 end_turn

ScheduledTaskWait 返回字段：

• status: done — 任务成功，读 summary（executionSummary）
• status: cancelled — 任务被取消或连续失败过阈值，读 error（lastError）
• status: timeout — 60 秒没完成，读 currentStatus（通常仍是 running）

定时任务：create + 直接回复，禁止 ScheduledTaskWait

用户描述未来/周期性的事（"每天 8 点"、"5 分钟后"、"每周一"、"明天早上"）：

1. ScheduledTaskManage(action:'create', schedule:{...}) 创建定时任务
2. 直接回复用户"已安排，将在 X 执行"
3. end_turn

严禁对定时任务调 ScheduledTaskWait——定时任务要等到未来某个时间点才跑，调 ScheduledTaskWait 只会白白卡住当前 turn 直到超时（最多 300 秒），浪费模型 token 和用户等待时间。

ScheduledTaskWait 超时后怎么办

ScheduledTaskWait 60 秒超时返回时，task 仍在后台运行。决策：

• 方案 A：如果预计再等一会就能完成 → 再调一次 ScheduledTaskWait({taskId, timeoutSec:120}) 继续等
• 方案 B：如果任务明显耗时更长 → 告诉用户"任务在后台继续执行，完成后可在任务中心查看"并 end_turn
• 不要无限连续调 ScheduledTaskWait，最多两次，之后应当移交后台

反模式：禁止 Bash sleep + ScheduledTaskStatus 轮询

错误做法（浪费 token、低效、和 ScheduledTaskWait 功能重复）：

Bash(sleep 5)
ScheduledTaskStatus(taskId)   → 还在 running
Bash(sleep 5)
ScheduledTaskStatus(taskId)   → 还在 running
...

正确做法：

ScheduledTaskWait({taskId, timeoutSec: 60})   → 一次调用，事件驱动，零无效往返

ScheduledTaskWait 内部订阅任务完成事件，一到达终态立即返回；没必要用 Bash 睡眠+轮询模拟同样的行为。

歧义消解

用户说"我有什么要处理的"、"what's on my plate"、"今天有什么事"——可能指任务、日历日程或未读邮件。优先用 ScheduledTaskStatus 检查任务，但同时告知用户你只查了任务维度。如果上下文暗示日程或邮件（如"今天有什么会"），应建议调用对应技能而非猜测。

为什么需要两阶段执行

任务默认采用「计划 → 审批 → 执行」两阶段模式。原因很简单：有些操作一旦执行就无法撤回——文件被修改、邮件被发送、数据被删除。两阶段让用户在不可逆操作发生前看到 Agent 的执行计划，决定是否继续。

流程如下：Agent 接到任务后先生成执行计划，任务进入 review 状态等待用户审阅。用户看到计划后可以批准（approve）、拒绝（reject）、或要求修改（rework 并附上修改意见）。批准后 Agent 才真正执行，执行结果再次进入 review 供用户确认，最终标记为 done。

状态流转全貌：todo → running(plan) → review(plan) → approve → running(execute) → review(result) → done

什么时候跳过审批

设置 skipPlanConfirm: true，任务直接执行，状态流转简化为：todo → running → done。

适用于只读、无副作用的操作——检查服务器状态、获取天气、汇总信息、生成报告摘要。这类任务即使出错也不会造成损失，额外的审批环节反而拖慢效率。

判断标准：如果执行结果不满意，用户能否简单地忽略它？ 能忽略的用 skipPlanConfirm: true，不能忽略的保持默认两阶段。

具体示例：

• 「每小时检查服务器状态」→ skipPlanConfirm: true（只读查询，无副作用）
• 「每天自动整理收件箱并归档」→ skipPlanConfirm: false（移动邮件是不可逆操作）
• 「定时发送日报」→ skipPlanConfirm: false（发送邮件无法撤回）
• 「每天早上生成待办摘要」→ skipPlanConfirm: true（只是读取和汇总信息）

注意：定时任务（带 schedule）默认 skipPlanConfirm: true，因为定时触发时用户通常不在线审批。如果定时任务包含不可逆操作，需显式设置 skipPlanConfirm: false。

调度类型决策

创建任务时先判断调度需求。不带 schedule 的任务立即执行，不进入调度系统。

用户只需要做一次？→ once 提供 scheduleAt（ISO 8601 时间字符串，必须是未来时间）。适合「周五下午五点发周报」「明天上午提醒我开会」这类一次性定时需求。

用户需要固定间隔重复？→ interval 提供 intervalMs（毫秒），最小值 60000（1 分钟）。适合「每 30 分钟检查一次服务器」（intervalMs: 1800000）、「每 2 小时同步数据」（intervalMs: 7200000）。

用户需要复杂时间规则？→ cron 提供 cronExpr（5 段格式：分 时 日 月 周）加 timezone。适合「工作日早上 9 点检查邮件」（cronExpr: "0 9 * * 1-5"）、「每月 1 号生成报告」（cronExpr: "0 10 1 * *"）。

常用 cron 示例：0 9 * * *（每天 9 点）· 0 9 * * 1-5（工作日 9 点）· 0 * * * *（每小时整点）· 0 10 1 * *（每月 1 号 10 点）· 0 8 * * 1（每周一 8 点）