§15 定时任务
DeerFlow 2.0 有定时任务 MVP——注意是 MVP，有明确边界，但已经能打。
它解决什么
之前仓库里有内部定时器，但用户没法从产品里「创建、查看、暂停、触发、删除」常驻后台任务。MVP 先把这些管理面做出来，自然语言建任务留到后面。
支持的形态
| 维度 | 支持 | 不支持 |
|---|---|---|
| 任务类型 | once（一次性）、cron（周期） |
interval（间隔） |
| 上下文模式 | fresh_thread_per_run（默认）、reuse_thread |
—— |
| 触发 | 定时 + 手动 trigger |
IM/Channel 派发 |
为什么不支持 interval？MVP 故意砍掉，因为它要多一套解析、多前端校验、多边界 case，而 once + cron 足以证明调度架构。
它靠 DB 租约保证安全
调度器默认关闭，要显式开：
scheduler:
enabled: false
poll_interval_seconds: 5
lease_seconds: 120
max_concurrent_runs: 3
min_interval_seconds: 60
核心保障是 DB 租约（lease）：每个轮询周期，调度器用一条 DB 事务原子地「认领」到期任务（设 lease_owner + lease_expires_at + 临时 running），避免多实例重复跑。任务 owner 隔离——别人的任务你列不到也改不了。
每次触发，都走和手动触发相同的 run-launch helper，不另搞一套运行时。重叠时按固定规则 skip，错过按 run_once 补最新一次。
REST 端点集中在 /api/scheduled-tasks：GET / POST / PATCH、/pause /resume /trigger、/runs 历史。
标叔的结论：定时任务的「工程克制」值得学——先管理面、后自然语言；先 once/cron、后 interval；默认关、显式开。每一刀都为了「第一个 PR 能被审、能被安全运维」。你做功能，也该这么切。
上下文会膨胀。下一章讲怎么管。