定时任务不是提醒器

更新时间：2026-03-23

这篇文章不是功能说明，也不是需求文档。

它想认真回答一个很容易被低估的问题：

AI 产品里的定时任务，到底应该是什么？

这个问题表面看像是一个边角能力问题，实际上会直接影响产品站位。

因为一旦你认真做定时任务，你就已经不再只是一个“用户来问一句，你答一句”的聊天产品了。
你开始进入另一个领域：

让系统在用户不在线时，继续代表用户处理工作。

这件事一旦成立，定时任务就不再只是个小功能，而会变成产品哲学的一部分。

一句话结论

OpenCrab 里的定时任务，不应该被设计成“定时发送一条 prompt”。

它更合适的定位是：

一个按时间或周期触发的后台执行单元。

但这里还有一个更重要的判断：

它既不应该退化成“高级提醒器”，也不应该异化成“只有高级用户才会配置的调度系统”。

OpenCrab 想做的，是介于两者之间，但产品层级更高的一种东西：

它有调度系统的稳定性
有工作台的上下文连续性
有对话产品的可理解性
也有团队产品的持续推进能力

换句话说：

OpenCrab 的定时任务，最终不该是一个独立的 automation 面板，而应该是一个能按节奏唤醒工作上下文继续运行的系统能力。

一、为什么很多 AI 产品的定时任务，总让人感觉“不太对”

现在越来越多 AI 产品都在做：

tasks
scheduled actions
alerts
automations
recurring jobs

但很多产品做出来以后，会让人有一种奇怪的感觉：

它明明能定时执行，但你不太想把真实工作交给它
它明明功能很多，但不像产品的一部分，更像后台工具
它明明能跑起来，但和聊天、项目、团队之间的关系不自然

我觉得问题不在于“技术做不到”，而在于很多产品一开始就把定时任务理解错了。

最常见的两个误区是：

误区一：把定时任务理解成提醒器升级版

这种理解会把定时任务做成：

到点提醒我
到点发我一句话
到点给我一份摘要

这类功能当然有用，但它只覆盖了很小一部分真实需求。

误区二：把定时任务理解成调度器外露

这种理解会把产品做成：

schedule
session
webhook
route
delivery mode
cron expression

它很强，但普通用户不会自然地认为“这就是我想用的 AI 工作能力”。

从系统角度看，这类设计可能很成熟；但从产品角度看，它只是把基础设施直接暴露给了用户。

二、定时任务的真实需求，到底是什么

如果只从用户价值看，而不是从技术实现看，我现在更倾向于把定时任务分成四类。

1. 提醒型

这是最直观的一类：

明天下午提醒我
每周提醒我做某件事
某个时间点不要忘了

这类需求的核心不是 AI 推理能力，而是：

别让我忘记。

它最重要的是：

简单
准时
通知可靠

2. 情报 / 监控型

比如：

每天给我 AI 新闻摘要
每周盯一下竞品变化
定时看看某个项目有没有新进展

这类需求不是 reminder，而是：

持续观察外部世界，并生成有价值的更新。

它节省的是用户的持续注意力，而不是一次性的记忆负担。

3. 周期性产出型

比如：

每周生成周报草稿
每月生成复盘框架
每周生成一次例会纪要模板

这类任务已经不只是“通知”，而是：

按节奏生成工作成果。

这时，系统更像一个后台文员。

4. 持续推进型

这是我认为最容易被低估、但对 OpenCrab 最关键的一类。

比如：

每周继续推进一次某个客户方案
每天把某个研究项目往前整理一步
每周唤醒一个 Team Room 继续处理 backlog

这类需求的重点不是创造一个新的独立结果，而是：

在既有上下文里，继续把某件事往前推。

到了这里，定时任务已经不像提醒器，也不像订阅器，而更像：

一个有节奏运行的后台 teammate。

三、真正统一这四类需求的，不是“提醒”，而是“后台执行单元”

如果把上面四类需求放在一起，你会发现：

定时任务 真正统一的抽象，不是 reminder，不是 alert，也不是 cron。

而是：

后台执行单元。

这个执行单元至少应该包含这些要素：

有明确目标
有触发节奏
有上下文来源
有运行记录
有结果出口

一旦这样定义，很多产品争论就会变得清楚。

比如：

它是不是一条消息，不重要
它是不是一个按钮，也不重要
它最关键的问题只有两个：
- 触发后做什么
- 结果落到哪里

四、OpenClaw 的路线：强调度、强投递、强 runtime，但它不是最终的产品答案

如果只看今天公开资料里，谁在“定时任务 runtime”这件事上做得最完整，OpenClaw 确实很值得研究。

它的 cron jobs 设计相当成熟。官方文档里明确说：

cron 是 Gateway 内建 scheduler
job 会持久化
可以在正确时间唤醒 agent
可以把结果投递回聊天
也可以走 webhook

更重要的是，它区分了两种不同执行方式：

main session
isolated session

前者更像：

把一个 system event 注入主上下文
让主会话在下一个 heartbeat 里继续工作

后者更像：

单独跑一个独立 agent turn
结束后再决定怎么投递结果

这套设计非常成熟，因为它已经不是“会不会定时跑”，而是把这些关键问题都回答了：

任务是否持久化
任务在哪里运行
结果如何投递
是否应该污染主线程
后台 run 怎么记录
多 agent 情况下 job 绑定谁
isolated job 是否可以覆盖 model / thinking

从 runtime 角度看，这套系统很强。
而且很理性。

参考：

五、我对 OpenClaw 定时任务路线的评价

我对它的评价是：

系统设计非常成熟，但它更像调度系统，而不是最终的前台产品体验。

我觉得它做得很对的地方

1. 它清楚地知道：定时任务首先是 runtime 问题

很多产品一上来就在讨论 UI、按钮、提醒文案，但 OpenClaw 先把最关键的系统问题想清楚了：

任务存哪
什么时候执行
谁来执行
怎么投递
主线程和隔离线程怎么区分

这非常重要。

2. 它把 “main vs isolated” 说清楚了

这几乎是所有 AI 定时任务系统都应该有，但很多产品没有抽象清楚的一点。

不是所有定时任务都应该进入主对话。

有些任务天然适合：

留在当前工作上下文里继续

有些任务则天然适合：

在后台单独跑完，再把结果投递回来

OpenClaw 把这点做成第一性概念，这是它最大的优点之一。

3. 它把 delivery 当成正式能力，而不是附属细节

很多系统只关心“跑完了”，但现实里更关键的是：

跑完之后发到哪
用什么形式发
是发回聊天，还是发 webhook，还是内部消化

OpenClaw 在这件事上比很多产品成熟。

但我也觉得它有明确边界

1. 它更像基础设施，而不是工作台产品语言

从用户心智看，cron、heartbeat、announce、webhook、last route 这些概念都很系统化。

这套设计对工程型产品很好，对普通用户不够自然。

2. 它强调的是“调度与投递”，不是“任务与工作对象的关系”

OpenClaw 会非常清楚地告诉你：

任务怎么跑
跑在哪
跑完发哪

但它并不天然强调这些更偏产品的问题：

这个任务属于哪个工作上下文
这个任务是在继续推进某件事，还是只是在发一个结果
用户应该把它当成提醒、订阅、后台 job，还是团队节奏器

3. 它更偏 gateway-first，而不是 workspace-first

这意味着它的强项在：

always-on
channels
routing
automation

而不是：

对话连续性
项目上下文
团队推进叙事
任务与工作空间的关系

所以我会说：

OpenClaw 解决了“任务如何稳定运行”的大问题，但没有把“任务作为工作台产品对象”的问题讲到最前面。

六、OpenCrab 从 OpenClaw 应该借什么，不该借什么

这是最重要的一部分。

因为我们不是在评判谁好谁坏，而是在判断：

对 OpenCrab 来说，什么值得借，什么不能照搬。

1. 值得借的

借鉴一：把定时任务当作系统级能力，而不是页面级功能

这一点我非常认同 OpenClaw。

定时任务不是 tasks 页面上的一个小卡片功能，而应该是 runtime 层的能力。

它应该天然能接：

conversation
team room
channels
webhook
future inbox

借鉴二：明确区分“在原上下文继续”与“独立后台运行”

这在 OpenCrab 里也必须成为正式概念。

我更愿意用更产品化的语言来表达：

继续当前工作空间
后台独立运行

但底层抽象，本质上就是 OpenClaw 的 main session vs isolated session。

借鉴三：run history 和 delivery 必须是正式能力

任务不是只有 schedule 和 prompt。

一个成熟的任务对象还必须有：

run history
status
result target
delivery policy
failure behavior

借鉴四：多 agent / 多模型任务绑定应该是正式支持的

这对 OpenCrab 的 Team Mode 很重要。

以后任务不应该只知道：

什么时候跑

还应该知道：

由哪个工作上下文来跑
由哪个 team / agent profile 来跑

2. 不该照搬的

不要把系统术语直接暴露给普通用户

普通用户不该先理解：

cron
heartbeat
webhook
isolated session

他应该理解的是：

这个任务会在什么时候执行
它会继续哪个工作
结果会回到哪里
是否会通知我

不要把任务产品做成调度台

OpenCrab 不是要做一个通用 automation gateway dashboard。

OpenCrab 要做的是：

面向普通用户的 AI 工作台。

所以任务页不该优先展示“调度配置”，而应该优先展示：

这是什么任务
它在推进什么
最近做了什么
下次会做什么
如果我点进去，我会回到哪个工作空间

不要让任务脱离工作对象

这是我认为 OpenCrab 和 OpenClaw 最大的产品差别。

在 OpenCrab 里，任务不该只是“某个时间运行一次 agent”的记录。

它应该和这些对象有稳定关系：

对话
Team Room
Agent Room
future artifacts / inbox

也就是说，OpenCrab 里的任务必须是 workspace-aware 的。

七、回到 OpenCrab：定时任务到底该和对话如何关系化

这个问题我现在的答案比之前更明确：

任务本身应该独立，但结果目标必须显式。

我不赞成两个极端：

极端一：永远绑定原对话

问题是：

原对话可能会跑题
长期任务会把普通聊天刷乱
任务对象感很弱

极端二：永远新起一个对话

问题是：

会割裂本来连续的上下文
用户追问不自然
Team Mode 场景尤其别扭

所以更合理的方案是：

Task 是一等对象
Task 有自己的生命周期、状态、运行记录
Task 不从属于某条聊天
但 Task 每次执行都要有明确 result target

这个 target 可以是：

当前 conversation
当前 Team Room
专属 task-only space
未来的 channel / inbox / artifact board

八、OpenCrab 现在已经对了一半，但还不够

从当前实现看，OpenCrab 已经走在正确方向上了。

它现在已经具备这些特征：

任务是独立对象
任务可以绑定 conversationId
任务也可以绑定 projectId
没有绑定 conversation 时，可以创建专属任务对话
任务详情里已经把“结果回流”作为正式概念展示

这说明 OpenCrab 已经不是“消息里点一个 reminder 按钮”的思路了。

但它距离我理想中的状态还差几层关键语义：

1. 任务类型还没有显式分层

现在创建任务更像统一表单：

名称
prompt
时间

但从产品角度看，至少应该显式区分：

提醒型
情报 / 监控型
周期产出型
持续推进型

因为这四类任务的默认 target、默认通知方式、默认历史展示方式都应该不同。

2. 结果目标还没有成为创建时的核心问题

底层已经有 conversationId / projectId，这是好事。
但前台还没有把：

这条任务以后把结果回到哪里

做成用户可理解、可确认的核心步骤。

3. 通知层和回流层还没有分开

这会是后面很重要的一步。

因为：

结果落点
通知方式

不应该是一回事。

一个任务完全可以：

结果继续沉淀在 Team Room
但只在需要用户介入时发提醒

4. run history 还更像记录，而不是任务叙事主干

这是一个产品成熟度问题。

理想状态下，用户看任务时最想知道的是：

最近一次做了什么
和上次相比变了什么
有没有需要我接手
这次是在提醒、监控、产出还是推进

也就是说，run history 不该只是日志，而应该成为任务体验的主叙事。

5. 和 Team Mode 的结合还不够深

现在你已经支持 projectId，这方向完全正确。

但更进一步，定时任务在 OpenCrab 里的真正价值，应该是：

唤醒一个 Team Room
让这个团队在节奏点继续工作
在需要用户时回到 frontstage

这时任务就不再像“单独调一次 prompt”，而更像：

一个团队节奏器。

九、所以，OpenCrab 到底要做什么，为什么

说到底，OpenCrab 在定时任务这件事上，不想做两种东西：

1. 不想做纯提醒器

因为这太浅了。

它能解决“别忘了”，但解决不了：

持续观察
周期产出
背景推进

2. 也不想做纯调度器

因为那会把产品推向工程化配置面板。

它能解决“怎么稳定地跑”，但解决不了：

普通用户如何理解它
任务如何融入工作空间
定时任务如何成为产品主线，而不是后台功能

所以 OpenCrab 想做的，是第三条路：

把定时任务做成工作台中的后台执行能力。

这意味着它必须同时满足这四件事：

第一，任务要独立

它必须是一等对象，有自己的生命周期，而不是聊天里的附属动作。

第二，任务要有上下文归属

它必须知道：

它是在继续哪个 conversation / team / workspace

第三，任务要有结果出口