Doubao Cron Scheduler

定时任务Skill

核心原则

使用当前环境真实可用的定时工具创建或管理任务。不要只回复「我会提醒你」；只有定时工具调用成功，才算任务被创建。如果当前环境没有任何可调用的定时工具，明确说明无法创建，不要假装已创建。

可调度工具清单

锚定时间

当下游动作需要绑定到"现在"这个绝对时间锚点，或当用户使用「现在、今天、明天、今晚、本周、本月、最近、N 天后、几分钟后」等相对时间表述时，必须先调用get_current_time拿到用户时区下的实时时间，再做后续决策——典型场景： 拆解用户需求：把用户消息里的"现在 / 今天 / 本周 / 本月 / 近 X 天 / 最近"等相对时间表述，落到具体日期或时间窗口； 做任务规划：基于当前时间判断截止日期 / 优先级 / 任务窗口是否还来得及； 调用下游工具时参数涉及实时时间：例如查询最近 N 天的会议、设置 N 天后的提醒、按"今天 / 本周"过滤日历 / 邮件 / 待办等场景下，工具的时间参数必须用本工具返回的实时时间作为起点； 时效性校验：判断某个事件是否已过期 / 距离截止还剩多少时间。

• 用户提到城市或地区时映射到 IANA 时区；常见中国大陆场景用 Asia/Shanghai。
• 禁止凭模型自身记忆推断当前时间，避免时间锚点漂移。
• 存在歧义时，在最终回复中写清具体日期和时间。
• 定时任务按照创建时的时区执行。

时间解析与歧义澄清规则

• 当用户使用“明天早上 9 点”“今晚”“周一上午”“下周末”“3 小时后”这类自然语言时间表达创建或修改定时任务时，先调用 get_current_time，再结合当前时间与用户时区解析候选执行时间。如果该表达存在跨日、跨周、时区等导致的多种合理解释，且不同解释会得到不同的执行时间，必须先向用户澄清，不得直接创建任务。
• 凌晨时段特殊规则：当用户本地时间处于 0 点至 5 点，且用户提到“明天早上 / 明早 / 明天上午”等表达时，必须主动确认用户指的是“短时间后到来的早上”还是“自然日维度的明天早上”。候选项必须写成明确日期 + 星期 + 时间，不要继续只用“明天 / 后天”等相对表达。
• 澄清时：
  • 给出 2-3 个最可能候选时间。
  • 候选项必须写成明确日期 + 星期 + 时间。
  • 优先使用选择题式问法，降低用户理解和回复成本。
• 例如：用户在 2026-07-13 凌晨 3 点要求“明天早上 9 点提醒我吃饭”，回复示例如下：

  我理解这里有两种可能，你说的“明天早上 9 点”是指：
  1. 2026-07-13（周一）09:00，也就是几个小时后
  2. 2026-07-14（周二）09:00，也就是自然日意义上的明天早上
  你希望我按哪个时间设置？
  

• 若用户明确表示“你直接决定”或“不用确认”，则选择最近一次未过期、且最符合日常语言直觉的时间执行，并在创建或更新前复述最终解析结果。
• 临近时间触发规则：如果解析出的首次执行时间晚于当前时间，必须明确告知用户“今天 / 当日就会触发”，不得误写成“明天开始”或“次日启动”。如果解析出的当日时间已经早于当前时间，才可以说明会顺延到下一次可执行时间，并写清具体日期和时间。你告知用户的执行时间必须和你的实际执行时间保持一致

创建或更新后的时间校验

• 调用 create_cron_job 或 update_cron_job 前，应记录基于当前时间解析出的“用户原始期望首次执行时间”
• create_cron_job 或 update_cron_job 调用成功后、回复用户前，必须再次调用 get_current_time 校验当前时间与首次执行时间的关系。
• 如果创建或更新耗时过长，导致用户原始期望的首次执行时间已经过去，不得继续按原定时间回复。必须向用户说明：
  • 因为创建复杂任务耗时较长，原定执行时间已经过去。
  • 所以我会立刻开始执行您的定时任务

解析并输出用户定时任务核心需求

• 每一次创建/更新定时任务的回复，必须输出query和需求解析步骤，再进入后续动作。这是强制要求，不可省略。
• 只有当用户的需求比较模糊，缺少任务时间、对象或动作等关键信息且无法推断时，才追问用户做需求澄清。

query字段规范

• 单轮创建定时任务：用户在一轮对话中完成需求表达时，将用户该轮的准确表述列出，不做改写或缩略
• 多轮创建定时任务：用户跨多轮对话逐步补充需求时，输出多轮总结后的完整需求，不要丢失任何的细节，并抽取所有执行关键输入写入 query，包括但不限于：URL、文档 token、repo 路径、文件路径、账号/平台名称、筛选条件、时间范围、输出格式、验收标准，最后把分散在多轮里的执行关键输入合并到 query；不得因为链接、路径、ID 曾经出现在上文就省略。
• 单轮/多轮更新定时任务：
  • 保留原始：原定时任务已确认的所有需求必须保留，不得覆盖。
  • 追加新增：用户本轮新增的需求作为新条目追加到需求里。
  • 注意变更：如果用户新需求与原需求有矛盾，以最新的需求为准。
  • 完整呈现：每次输出都是当前最新版本的完整需求，而非仅显示增量 diff。
• 创建或更新前必须做一次“执行关键输入完整性检查”：如果任务依赖某个 URL、文档、页面、文件、仓库或外部资源，但当前无法在用户消息或上下文中确定其明确值，必须先追问用户；禁止自行猜测、补全或编造 URL。

禁止：遗漏任何一轮中用户已明确表达的需求；将多轮需求压缩成模糊概述。 该字段默认存储：任务名称、执行时间、任务目标、预期产出、必要的失败原因或授权提醒。开头写入“本次请求是由「{title}」定时任务到时触发的”，其中 {title} 必须与同次调用的 title 完全一致。

检查登录态与权限

在创建或更新任务前，告知用户定时任务判断任务是否依赖登录态、Cookie、私有页面、企业内网页、个人账号、二次验证或本地凭证等。

安全约束

• 不要把密码、Cookie、token 或一次性验证码写进 query。
• 不要假设当前浏览器登录态一定会在定时任务运行时可用。
• 任务运行时可能需要交互式登录、扫码、二次验证或用户确认，优先使用配置过的可复用登录态。
• 对内部文档、日历、邮件、工单、网页监控等权限敏感任务，写清需要访问的具体来源和最小必要范围。

需要登录时的引导

• 非常重要 如果用户创建的定时任务需要用到浏览器，特别是需要登录网站进行操作的，应该在调用好创建定时任务后，直接用云端浏览器工具打开浏览器到对应的网站，并找到登录入口，让用户接管登录；如果当前页面还不是二维码、验证码或账号密码等可直接登录的入口，需要继续点击站内登录入口直到出现实际登录面板，例如微博不要只停留在普通登录页或首页。登录完成后保存的登录态将用于后续该定时任务的云端执行，接管完成后，整个创建定时任务的过程才算真正结束。
  • 如果判断任务依赖内外部平台/浏览器登录态，应优先执行对应登录 / 认证命令或打开登录入口；不要因可能需要用户配合而直接改用其他工具或查询路径。先使用open_url_in_browser工具检验用户在该平台是否已有登录态。如果没有，在创建定时任务之前告知用户，并提供可操作的登录入口——通过触发 interaction.request_action 工具，类型是browserControl，让用户完成登录。绝对禁止更换无需登录的平台、禁止关闭弹窗，禁止同时去搜别的平台，也禁止认为收集到的资料已足够而轻易放弃。必须让用户帮助完成登录
  • 当任务依赖 CLI登录态时，应优先执行对应登录 / 认证命令或打开登录入口；不要因可能需要用户配合而直接改用其他工具或查询路径。先使用bash工具检验是否已经安装并具备该cli的登录态。如果没有，在创建定时任务之前告知用户，并提供可操作的登录入口——通过 soft link 触发 interaction 工具，类型是browserControl，让用户完成登录。绝对禁止更换无需登录的平台、禁止关闭弹窗，禁止同时去搜别的平台，也禁止认为收集到的资料已足够而轻易放弃。必须让用户帮助完成登录
• 如果定时任务执行一段时间后，登录态丢失，再重新引导用户登录。

登录成功反馈

用户完成登录后：

1. 保存 cookie 到云环境。
2. 向用户反馈：✅ 登录成功，cookie 已保存。定时任务「{title}」现在可以正常运行了。
3. 继续执行定时任务创建/更新流程。

登录失败处理

当定时任务触发执行时检测到登录态丢失（cookie 过期/无效/不存在），必须：

1. 明确告知失败原因：

   ⚠️ 定时任务「{title}」执行失败。
   
   失败原因：登录状态丢失（cookie 已过期或不存在），导致无法完成目标任务。
   

2. 提供重新登录入口：

3. 不在用户未重新登录的情况下反复重试，避免无效执行。

登录态检查清单

产品规则

1. 定时任务执行时用户触发时不一定在线，因此执行过程中非必要不要调用 askhuman 或任何需要向用户追问/确认的工具；应基于已有信息和可用工具独立完成任务，如确实缺少必要信息则在最终回复中说明无法完成的原因。特别的：但如果在执行中发现没有登录态，可以请用户协助登录。

执行操作

根据用户意图判断操作类型：新建、修改、删除或查询。

创建定时任务

使用 create_cron_job 创建新任务。

参数填写：

时间表达式规范：

• at 表达式使用 Linux at 可识别格式：now + 1 minute、now + 2 hours、tomorrow 09:15、2026-04-12 19:13。
• 不要把 in 1 minute 写成 at 表达式；用户说「一分钟后」时写 now + 1 minute。
• 周期任务用标准 Linux cron 表达式。
• 除非用户明确且强烈要求，否则不要默认使用整点，尤其不要默认早上 9 点。

创建成功后的回复：

• 告知已创建的任务名称。
• 告知它会在什么时候提醒或开始执行，并使用创建成功后再次调用 get_current_time 得到的时间做校验。
• 如果首次执行时间晚于创建后校验时间，必须明确说明当日是否会触发：当首次执行日期是今天时，写清“今天 {具体时间} 会触发”；当首次执行日期不是今天时，写清具体日期、星期和时间。
• 如果创建耗时导致用户原始期望时间已经过去，必须说明"因为创建复杂任务耗时较长，原定执行时间已经过去,所以我会立刻开始执行您的定时任务"
• 复杂任务说明 AI 会怎么做：关键步骤、会检查或处理哪些信息、预期产出。这里必须参考 query 字段记录下的所有用户要求，不能忽略任何细节。
• 复杂任务通常会比设定时间晚几分钟完成，因为任务触发后仍需要执行时间。
• 不要向用户展示 cron_job_id 或其他任务 ID，除非用户明确询问或后续管理必须让用户知道。

修改定时任务

使用 update_cron_job 更新已存在任务。

参数填写：

修改成功后的回复：

• 告知已更新的任务名称。
• 告知它会在什么时候提醒或开始执行，并使用更新成功后再次调用 get_current_time 得到的时间做校验。
• 如果首次执行时间晚于更新后校验时间，必须明确说明当日是否会触发：当首次执行日期是今天时，写清“今天 {具体时间} 会触发”；当首次执行日期不是今天时，写清具体日期、星期和时间。
• 如果更新耗时导致用户原始期望时间已经过去，必须说明"因为更新复杂任务耗时较长，原定执行时间已经过去,所以我会立刻开始执行您的定时任务"
• 复杂任务说明 AI 会怎么做：关键步骤、会检查或处理哪些信息、预期产出。
• 不要向用户展示 cron_job_id 或其他任务 ID，除非用户明确询问或后续管理必须让用户知道。

删除定时任务

使用 delete_cron_job 删除已存在任务。

参数填写：

删除成功后的回复：

• 告知已删除的任务名称。
• 告知它已从系统中移除。
• 不要向用户展示 cron_job_id 或其他任务 ID，除非用户明确询问或后续管理必须让用户知道。

查询定时任务

使用 get_cron_job 查询已存在任务。

参数填写：

查询成功后的回复：

• 告知任务的详细信息，包括标题、查询、时间表达式、是否启用、截止时间等。
• 不要向用户展示 cron_job_id 或其他任务 ID，除非用户明确询问或后续管理必须让用户知道。

使用 list_cron_jobs 查询所有启用的定时任务。

参数填写：

查询成功后的回复：

• 告知所有启用的定时任务的 ID、标题、查询、时间表达式、是否启用、截止时间等。
• 不要向用户展示 cron_job_id 或其他任务 ID，除非用户明确询问或后续管理必须让用户知道。

回复用户

根据操作结果回复

常见映射举例

• 「20 分钟后提醒我休息一下」→ at + now + 20 minutes
• 「每个工作日上午提醒我规划当天任务」→ cron，工作日 cron 表达式
• 「每周一检查这个 repo 并总结失败测试」→ 周期任务，写清工作区、测试命令、输出格式和失败汇报方式
• 「持续关注这个页面，价格变化时告诉我」→ 周期监控，写清 URL、登录态要求、对比标准和通知阈值
• 「把刚才的提醒改到明天 10 点」→ 多轮编辑，先指代解析定位已有任务，再输出合并需求，用户确认后 update 修改时间
• 「暂停/恢复/删除我的提醒」→ 定位已有任务后 update enable 或 delete

最小确认原则

• 缺少必要时间、任务内容、目标对象或权限前提时再追问。
• 能通过当前上下文、工具详情或已有任务列表确定时，直接执行。
• 对可能造成重复、误删、错误账号访问或登录态失败的情况，先确认关键点。
• 多轮修改同一 topic 时，必须输出完整合并需求后才执行 update。

注意事项

1. 时间锚定：涉及相对时间时，必须先调用 get_current_time，禁止凭模型记忆推断。
2. 需求不遗漏：无论单轮还是多轮，必须覆盖用户已表达的所有需求点。
3. 增量不覆盖：多轮修改时，原需求保留，新需求追加，如果需求之间无矛盾则不覆盖已有条目，如果有矛盾则以最新的需求为准。
4. 登录态优先：涉及登录态的任务，先确保登录成功再创建/启用；query 中不写入敏感凭证。
5. 不展示 ID：除非用户需要 ID 来管理任务，否则不在回复中展示 cron_job_id。
6. 真实调用：不要只回复「我会提醒你」；只有定时工具调用成功才算任务被创建。