TS
TaskScheduler 定时任务系统主页与 API 参数说明
Task.xizhenhua.top

让业务系统只关心任务内容,让调度系统稳定负责“何时触发”与“如何回调”

这里是 TaskScheduler 的服务首页。访问根域名先看系统定位、接入方式、参数结构和 API 文档; 正式对接时,统一使用 这一组 HTTP 接口创建、更新、启停和删除定时任务。 任务到点后,系统会按照你提供的 notifyHTTPParam 回调业务服务,再由业务服务完成 AI 执行、 知识库检索、通知下发或结果回写。

  • 统一调度入口 所有定时任务都通过同一组 API 建模,业务系统不用自己维护触发计划。
  • 业务执行留在你自己的服务里 调度器负责触发,不承载业务语义本身,降低耦合和迁移成本。
  • 支持单次与循环任务 可直接传 executeAt,也可传 5 段、6 段、7 段 cron
  • 适合 AI 与自动化场景 可以作为 go-ai-office 这类系统的定时执行入口与结果回写中枢。
System Positioning

这个系统最适合承担什么角色

TaskScheduler 不是业务工作流编排平台,也不是 AI 执行引擎。 它更适合做你系统里的“定时任务基础设施层”:统一接收任务定义、维护未来执行计划、定时回调业务服务,并记录调度过程中的关键结果。

调度内核

统一管理任务定义

通过 HTTP 统一创建、修改、启用、停用和删除定时任务,不同业务系统只需要维护自己的 app 名称与回调协议。

时间引擎

负责时间计算与未来计划

把单次时间戳或 cron 表达式展开为未来执行计划,避免业务侧自己处理多种调度语法和迁移逻辑。

执行回调

把执行权交回业务系统

到点后按照 notifyHTTPParam 发起回调,真正的 AI 生成、知识检索、机器人通知都由你的业务服务完成。

结果回写

补齐业务闭环与追踪

适合和 AI 助手、自动化工作台、通知系统联动,把执行状态、错误原因和响应内容再次回写到业务侧。

Integration Flow

一条完整的调度闭环是怎么跑起来的

下面这条链路就是系统的标准用法:业务系统负责创建与承接回调,TaskScheduler 负责稳定触发与调度基础能力。

01

创建任务

业务系统调用 /create_timer,提交 app、调度时间和 notifyHTTPParam

02

生成计划

调度器解析 executeAtcron,生成未来执行计划,并可通过 enable/disable 接口控制是否生效。

03

到点回调

任务到期后,系统会用你提供的方法、请求头和请求体向业务服务发起 HTTP 回调,真正执行业务动作。

04

结果回写

业务系统可结合 reportUrl 回写执行结果,把状态、错误原因、请求体和响应体收敛回自己的业务链路。

Routing

访问方式与域名分工

根域名用于人工查看说明页,正式 API 使用统一前缀;而真正的业务执行 URL 由调用方在创建任务时自行提供。

根域名主页

浏览器先看这里

适合查看系统定位、API 列表、字段说明、接入建议和示例请求。
正式接口

业务系统统一调用这组路径

所有创建、更新、启停、删除和联调测试接口,都以这个 API Base 为前缀。
业务回调

真正被执行的是你的业务 URL

https://your-business.example.com/v1/schedule/execute
这个地址不是 TaskScheduler 自己的路由,而是你在 notifyHTTPParam.url 里提交给调度器的业务入口。
Payload Schema

字段含义与接入约定

如果你是第一次接入,这一节最关键。核心要理解三个对象:任务本身、业务回调参数,以及业务侧回写结果时的约定字段。

Timer Fields

任务基础字段

app业务系统标识,用来隔离不同调用方的任务空间。
name任务名称,建议写成业务可读文本,方便排查和审计。
executeAt单次任务时间戳;传这个时,服务端会自动标准化为一次性 cron。
cron推荐的正式调度字段,支持 5 段、6 段和 7 段格式。
timerId更新、启用、停用、删除时使用的主键 ID。
notifyHTTPParam

回调参数结构

method当前主要按 POST 使用,便于传 JSON 负载。
url到点后真正要被调用的业务接口地址。
header回调时附带的请求头,例如 Content-Type、签名头、业务密钥头。
body回调请求体,通常是业务系统预先序列化好的 JSON 字符串。
调度规则

支持的调度语法

  • 5 段 cron:0 9 * * *
  • 6 段 cron:0 0/5 * ? * *
  • 7 段 cron:15 30 9 19 3 ? 2026
  • 如果传 executeAt,调用方不需要自己生成一次性 cron。
统一响应

HTTP 返回结构

{
  "code": 0,
  "message": "ok",
  "data": {},
  "date_time": "2026-03-19T20:00:00+08:00"
}
创建成功时,data 中会带上 timerId;启停与删除成功时通常只返回状态确认。
回写建议

业务系统最好额外携带什么

建议你在 notifyHTTPParam.body 中预先放入业务系统自己的 scheduleTaskId、签名密钥和 reportUrl,这样回调和回写就能闭环关联到同一条业务任务。

边界说明

哪些逻辑不应该放在调度器里

复杂业务编排、AI Prompt 执行、知识库读取、机器人通知、业务鉴权等逻辑,建议都放在你自己的业务服务中,不要塞进调度系统本体。

Callback Design

回调怎么配,业务接口应该怎么接

这部分专门解释调度器真实会怎么调用你的业务服务。当前实现非常明确:按 notifyHTTPParam 原样发起 HTTP POST,请求头和请求体都由调用方提供;回调结束后,如果请求体里带有 scheduleTaskIdsecretreportUrl,系统还会自动补一轮结果回写。

调用方式

当前真实支持的回调行为

Method当前执行器按 POST 方式发起业务回调。
Header使用 notifyHTTPParam.header 中的键值对原样透传。
Body使用 notifyHTTPParam.body 作为请求体;通常建议传 JSON 字符串。
Timeout当前 HTTP 客户端默认超时约 5 秒,业务接口不宜做过长阻塞。
Response响应体会被按 JSON 解析,建议你的业务回调接口始终返回结构化 JSON。
Trace若 body 中带有 scheduleTaskId,会记录 callback_requestcallback_response 等追踪阶段。
当前实现不会帮你自动生成鉴权头、签名或业务参数,所以建议在 header 与 body 中显式带上业务侧需要的密钥与任务标识。
最小可用案例

普通业务回调配置

{
  "notifyHTTPParam": {
    "method": "POST",
    "url": "https://your-business.example.com/api/job/run",
    "header": {
      "Content-Type": "application/json",
      "X-App-Key": "your-app-key"
    },
    "body": "{\"jobType\":\"daily-summary\",\"tenantId\":\"team-a\"}"
  }
}
这种方式适合普通 WebHook 或内部服务触发。调度器只负责按时 POST 到你的业务地址,不自动发 report 回写。
闭环案例

带 reportUrl 的 AI / 自动化回调

{
  "notifyHTTPParam": {
    "method": "POST",
    "url": "https://ai.example.com/v1/workspace/schedule/execute",
    "header": {
      "Content-Type": "application/json",
      "X-Schedule-Secret": "demo-secret"
    },
    "body": "{\"scheduleTaskId\":\"abc123\",\"secret\":\"demo-secret\",\"reportUrl\":\"https://ai.example.com/v1/workspace/schedule/report\"}"
  }
}
当 body 里包含 scheduleTaskIdreportUrl 时,调度器会在回调结束后额外向 reportUrl POST 一份执行结果。
自动回写

调度器会回写什么 report 内容

{
  "scheduleTaskId": "abc123",
  "schedulerTimerId": 9527,
  "runAt": 1773925200,
  "status": "success",
  "reason": "",
  "requestBody": "{\"scheduleTaskId\":\"abc123\",\"secret\":\"demo-secret\",\"reportUrl\":\"https://ai.example.com/v1/workspace/schedule/report\"}",
  "responseBody": "{\"code\":0,\"message\":\"ok\"}",
  "secret": "demo-secret"
}
如果业务执行失败,status 会变成 failedreason 会带上错误原因,便于业务侧把执行结果落库。
业务承接建议

你的回调接口最好满足这些约定

  • 始终返回 JSON,例如 {"code":0,"message":"ok"},避免响应体无法解析。
  • 在 header 或 body 中自行校验业务密钥,不要把调度器当成鉴权层。
  • scheduleTaskId 当成业务关联主键,便于和自己的执行日志串联。
  • 如果任务可能重复触发,建议业务接口自行做幂等控制。
  • 耗时任务建议异步落到自己的队列或工作流,不要让回调接口长时间阻塞。
API Reference

接口列表

下面展示当前首页建议对外公开的全部接口。页面中的路径全部按正式前缀 /api/xtimer/* 展示。

POST

Create Timer

/create_timer

创建一个新的定时器,适用于单次任务和循环任务。生产系统通常先创建,再立即启用。

app必填,业务系统名称。
name必填,定时器名称。
executeAt可选,单次任务时间戳。
cron可选,循环或一次性 cron。和 `executeAt` 至少传一个。
notifyHTTPParam必填,触发时要调用的业务回调信息。
POST

Update Timer

/update_timer

更新已有任务的名称、执行时间、cron 表达式或回调参数。适合编辑已存在的任务定义。

app必填,业务系统名称。
timerId必填,要更新的 timer ID。
name可选,更新后的名称。
executeAt可选,新的单次执行时间。
cron可选,新的 cron 表达式。
notifyHTTPParam可选,新的回调配置。
POST

Enable Timer

/enable_timer

重新启用一个已经停用的任务,并恢复未来执行计划。通常用于草稿发布或临时停用后的恢复。

app必填,业务系统名称。
timerId必填,要启用的 timer ID。
POST

Disable Timer

/disable_timer

停用一个已启用任务,并清理未来尚未执行的调度计划。适合暂停或下线业务任务。

app必填,业务系统名称。
timerId必填,要停用的 timer ID。
POST

Delete Timer

/delete_timer

删除任务主记录。若任务仍在运行中,系统会先执行停用与清理,再删除主记录。

app必填,业务系统名称。
timerId必填,要删除的 timer ID。
POST

Callback Test

/callback

用于联调或演示回调链路是否畅通。它不是生产业务闭环中的正式执行入口,正式执行仍然依赖业务系统自己的回调地址。

建议只在验收联通性、排查 header/body 透传问题时使用这个接口。
Examples

最常见的请求示例

这部分给的是最贴近业务接入的示例:一个循环 AI 任务,一个单次执行任务,再加一份结果回写字段示例。

循环任务

创建每日定时任务

curl -X POST '/create_timer' \
  -H 'Content-Type: application/json' \
  -d '{
    "app": "go-ai-office",
    "name": "每天早上汇总日报",
    "cron": "0 9 * * *",
    "notifyHTTPParam": {
      "method": "POST",
      "url": "https://ai.example.com/v1/workspace/schedule/execute",
      "header": {
        "Content-Type": "application/json",
        "X-Schedule-Secret": "demo-secret"
      },
      "body": "{\"scheduleTaskId\":\"abc123\",\"secret\":\"demo-secret\",\"reportUrl\":\"https://ai.example.com/v1/workspace/schedule/report\"}"
    }
  }'
单次任务

传 executeAt 创建一次性任务

{
  "app": "go-ai-office",
  "name": "2026-03-19 21:00 执行一次",
  "executeAt": 1773925200,
  "notifyHTTPParam": {
    "method": "POST",
    "url": "https://ai.example.com/v1/workspace/schedule/execute",
    "header": {
      "Content-Type": "application/json",
      "X-Schedule-Secret": "demo-secret"
    },
    "body": "{\"scheduleTaskId\":\"abc123\",\"secret\":\"demo-secret\",\"reportUrl\":\"https://ai.example.com/v1/workspace/schedule/report\"}"
  }
}
结果回写

业务系统可理解的 report 字段

{
  "scheduleTaskId": "abc123",
  "schedulerTimerId": 9527,
  "runAt": 1773925200,
  "status": "success",
  "reason": "",
  "requestBody": "...",
  "responseBody": "...",
  "secret": "demo-secret"
}
建议业务侧把这份 report 结果持久化,这样可以把调度执行记录和业务任务日志关联在一起。
接入建议

推荐的对接顺序

  • 先打通 /create_timer/enable_timer
  • 再验证业务回调地址、签名头和请求体是否能完整透传。
  • 最后补齐业务侧的 report 回写,让整条链路具备可观测性和可追踪性。