任务生命周期

每次提交任务都会创建一个新任务，并立即返回 task_id。之后任务在服务端依次经历派发、排队、执行，最终停在一个终态。你通过查询任务读取它的最新状态。

状态一览

`status`	含义	终态	`credits`
`queued`	已受理并保存，等待派发		预占
`dispatching`	正在派发，或正在确认派发结果		预占
`pending`	已派发，在平台队列中排队		预占
`running`	正在向 AI 平台提问并抓取回答		预占
`succeeded`	拿到了回答	✓	扣除
`failed`	失败，原因见 `error_code`	✓	0（退回）
`canceled`	任务被取消	✓	0（退回）

只有 succeeded、failed、canceled 是终态，正常情况下到达后不再变化（极少数情况下，运维人工重跑会用更新的结果覆盖终态，对账以最新一次查询为准）。点数规则见计费与点数。

提交 ──▶ queued ──▶ dispatching ──▶ pending ⇄ running ──▶ succeeded
                                                      ──▶ failed
                                                      ──▶ canceled

几点需要注意：

任务可能在多个阶段失败。 派发前 API Key 已失效（queued → failed）、派发被拒绝（dispatching → failed）、平台抓取失败（running → failed）；排队或执行中的任务也可能被取消（→ canceled）。
pending 与 running 可能往返。 P2 任务遇到可重试的失败（网络、平台临时异常）会回到队列再执行一次，此时 started_at 会清零，重新开始执行时再记录。
dispatching 不是失败。 派发结果需要确认时，任务会停留在 dispatching，error_code 显示 dispatch_uncertain。服务端会自行确认，不会重复派发。判断成败只看 status，不要因为 error_code 非空就当作失败。
成功也可能内容很少。 succeeded 只表示拿到了平台的回答；引用来源为空、回答很短都可能是正常结果（有的问题平台不联网搜索）。

时间预期

抓取本身通常需要几十秒到两分钟，视平台和回答长度而定；开启思考模式后通常明显更慢。不同平台差异较大，可参考平台列表返回的 p50_duration_seconds（近 24 小时成功任务从提交到完成的中位耗时，含排队）。
排队时间没有上限，也不承诺 SLA。 平台繁忙或平台账号暂时不可用时，P2 任务会留在队列里等待恢复，可能等待较久；P1 先出队，但也不保证几秒内开始。两档的区别见平台、优先级与国家。
服务端不设执行截止时间。 任务不会因为等太久被自动判失败，也不会因为过了 monitor_date 当天而失效。

轮询：多久查一次

服务端每 15 秒左右与执行方同步一次未完成任务的进度，查询任务读取的是同步后保存的状态。所以：

建议每 15 秒查询一次。 查得更勤通常只会拿到同一个状态。
大量任务时，用一个定时循环批量查询各个未完成的 task_id，不必为每个任务单独起一个等待线程。
你可以设置自己的业务超时（例如 30 分钟后先不等了），但不要把超时当作失败：任务仍会继续执行，之后随时可以用 task_id 取回结果。
查询本身不消耗点数。

同步等待 `wait_seconds`

不想自己写轮询时，提交时可以传 wait_seconds（0–120 秒）。服务端会在这段时间内每 2 秒检查一次任务，任务到达终态或时间用完就返回当时的任务。

0（默认）：不等待，立即返回 queued。
等待到时间仍未结束，会返回非终态的任务，你仍需要按 task_id 继续轮询。
把客户端的 HTTP 超时设得比 wait_seconds 更长（例如再多留 15 秒）。实际能等多久还受网络链路上代理超时的限制；如果连接被中途断开，任务不受影响，按下一节的方法找回 task_id 继续查询即可。
同步等待只影响这次 HTTP 请求何时返回，不会延长或缩短任务的执行时间，也不影响计费。

避免重复提交

每次调用提交接口都会创建一个新任务，成功后各自计费；服务端不会按问题内容去重。所以当你不确定上一次提交是否成功时（例如请求超时、连接中断、进程崩溃），不要直接重试提交，而是：

调用任务列表，用 keyword 传入问题文本（最多 256 个字符，长问题取前 256 个字符），或用 start_time / end_time 限定提交时间，找出刚才那次提交的 task_id。
找到了就继续轮询它；确认没有，再重新提交。

在你自己的系统里，建议先落库「待提交」记录，拿到 task_id 后立刻回写，这样任何时候都能对上账。

`monitor_date` 是什么

monitor_date 是任务的业务日期（YYYY-MM-DD，北京时间），默认是提交当天。它用于给任务打上「属于哪一天的监控」的标签，便于你按天归档和对账：

它不是计划执行时间：任务提交后就会进入队列，不会等到那一天才执行。
它不是截止时间：过了那一天任务照常执行。
跨时区系统可以传带时区的 RFC 3339 时间（如 2026-10-26T09:30:00-07:00），服务端会换算成北京时间的日期。

没有回调

目前不提供 Webhook 回调，任务结果只能通过轮询获取。