定时运行的 AI Agent：如何自动执行工作流
并非所有 Agent 都需要等待事件到达。一些最实用的 Agent 按计划运行——在设定时间醒来，处理数据、生成报告、检查系统或执行维护任务。
定时 AI Agent 按预定间隔执行工作流。它运行、完成工作、等待下一次触发。这种模式非常适合那些需要定期发生但不需要常在线基础设施的任务。定时 Agent 将重复的手动工作转化为可靠的自动化流程。
何时使用定时 Agent
定时 Agent 擅长重复的、可预测的工作。它们对于时间已知且能在单次执行窗口内完成的任务特别有效。
常见使用场景
每日报告生成。 Agent 每天早晨运行，汇总前一天的指标、日志或分析数据。它从多个来源收集数据，通过语言模型处理以识别趋势和异常，将结果格式化为报告，分发给相关人员。
定期数据清理。 数据会随时间积累不一致、重复和过期记录。定时 Agent 每周运行，扫描数据库、识别和合并重复记录、验证数据完整性、归档已超过保留期限的记录。
定时内容发布。 内容 Agent 起草文章、检查是否符合规范、在最佳时间发布。它还可以重新利用现有内容——例如将博客文章转为社交媒体更新——并计划发布。
系统健康监控。 Agent 定期检查基础设施指标，运行诊断测试，将结果与基线对比，在检测到异常时通知团队。更高级的 Agent 可以采取纠正措施——重启服务、清除缓存或扩缩容资源。
批量数据处理。 运行之间积累的数据——API 响应、用户活动日志、排队的事务——在非高峰时段批量处理。Agent 加载、处理、存储结果，然后等待下一个窗口。
跨系统同步。 需要定期数据同步的系统——例如在 CRM 和计费系统之间同步用户记录——是定时 Agent 的自然候选。Agent 按间隔运行，识别自上次同步以来的变更，传播更新。
定时 Agent 如何工作
定时 Agent 的核心架构很直接，但几个设计决策会影响可靠性和可维护性。
计划定义
计划定义 Agent 何时运行。常见格式包括：
- Cron 表达式。 标准的 Unix 格式，用于指定基于时间的计划：
0 9 * * 1表示"每周一上午 9:00"。Cron 提供对分钟、小时、月日、月份和周日的细粒度控制。 - 基于间隔。 比 cron 更简单："每 15 分钟"、"每小时"、"每天"。间隔计划更容易配置，但对复杂时间的灵活性较差。
- 基于日历。 绝对日期和时间："每季度第一天运行"、"12 月 1 日运行"。适用于业务特定的计划。
Agent 工作流
工作流是 Agent 每次运行时执行的一系列步骤。典型的定时 Agent 工作流遵循这个模式：
[定时触发]
↓
[Agent 开始执行]
↓
[加载上下文：确定"自上次运行以来"的边界]
↓
[获取自上次运行以来积累的数据或状态]
↓
[用语言模型处理数据]
↓
[需要时执行工具：写入数据库、调用 API、发送消息]
↓
[存储结果并更新"上次运行"时间戳]
↓
[如果配置了通知，发送（成功、失败或摘要）]
↓
[Agent 完成；资源释放]
跨运行状态管理
定时 Agent 需要跟踪跨执行次数的进度。最重要的状态是："哪些工作已经完成？"通常通过以下方式管理：
- 上次运行时间戳。 数据库记录存储上次执行时间。每次运行时，Agent 查询自该时间戳以来创建或修改的数据，完成后更新。
- 游标或偏移量跟踪。 对于分页数据源，Agent 维护一个随数据处理前进的游标。每次运行时，从中断处继续。
- 长任务的检查点。 如果定时任务需要多次运行才能完成，Agent 增量保存进度，从最后一个检查点恢复。
输出处理
定时 Agent 运行的结果需要一个去处。常见的输出模式包括：
- 存储。 结果写入数据库、数据仓库或文件存储。
- 分发。 结果通过邮件、消息平台或仪表盘发送。
- 下游触发。 定时 Agent 发出事件触发其他 Agent 或系统。这创建了定时和事件驱动 Agent 协同工作的混合模式。
为可靠性设计
定时 Agent 在无人监督下运行，因此必须优雅处理故障。
幂等性
运行同一个定时任务两次应产生与运行一次相同的结果。如果 Agent 发送每日摘要邮件，运行两次不应发送重复邮件。幂等性通过以下方式实现：
- 在执行前检查工作是否已完成。
- 对数据库写入使用 upsert 操作而不是仅插入。
- 设计通知逻辑为替换而不是追加。
重叠保护
如果定时运行时间超过间隔，可能出现两个实例同时执行。常见缓解措施包括：
- 锁定：执行前获取分布式锁，使后续实例等待或跳过。
- 单实例强制：调度器在启动新运行前检查是否有运行进行中。
- 队列式执行：不直接触发，而是将计划事件放入队列，Agent 逐一处理。
故障通知
定时 Agent 的静默故障比不运行更糟糕——你以为工作已完成，实际上没有。在关键定时 Agent 中构建检测和通知：
- 记录运行状态、持续时间和任何错误。
- 在失败或异常情况时发送告警。
- 对瞬时故障实施带退避的重试逻辑。
监控运行历史
跟踪每次执行——开始时间、结束时间、持续时间、状态、处理的记录数、任何错误。运行历史有助于识别模式：始终比预期耗时更长的任务、在特定条件下集中失败的 Agent、以及随着数据量增长而性能下降的 Agent。
定时 vs. 事件驱动：互补模式
定时和事件驱动 Agent 是互补而非竞争的。许多生产系统两者并用。
| 特征 | 定时 Agent | 事件驱动 Agent |
|---|---|---|
| 触发 | 基于时间 | 外部信号 |
| 成本模式 | 可预测，固定 | 可变，基于使用 |
| 延迟 | 最多一个间隔 | 即时 |
| 覆盖范围 | 保证运行 | 如果没有事件则错过 |
| 典型间隔 | 分钟到月 | 毫秒到秒 |
常见混合模式：事件驱动 Agent 处理实时用户交互并记录到数据库。定时 Agent 每天运行，将积累的记录处理为摘要报告。事件驱动 Agent 提供响应性；定时 Agent 提供完整覆盖和分析处理。
实践实施指南
第一步：定义任务
确定一个你目前手动处理的重现任务。定义一次完整运行包括什么、需要什么数据、发生什么处理、输出应该是什么样子。
第二步：定义计划
根据时效性要求选择间隔。监控 Agent 可能每 5 分钟运行一次。报告 Agent 可能每天运行一次。清理 Agent 可能每周运行一次。正确的间隔是仍能满足业务需求的最长间隔。
第三步：构建工作流
实现 Agent 工作流，每一步有清晰边界。如果任务可能超过执行时间限制，使用检查点。外部存储状态，使进度在重启后存活。
第四步：添加错误处理
定义某步失败时发生什么。应该重试？跳过失败项继续？停止并告警？不同步骤可能需要不同的错误策略。
第五步：测试和监控
手动运行 Agent 多个周期。验证状态是否正确跟踪、幂等性是否工作、故障模式是否处理。然后设置监控仪表盘和告警。
OpenClaw 中的定时 Agent
在 OpenClaw 技能架构中，定时能力可以作为带时间触发器的技能实现。技能定义其计划——通过 cron 表达式或间隔——以及每次触发时执行的处理逻辑。多个定时技能可以独立运行，每个处理其特定的重复任务。
定时技能也可以发出事件供其他技能使用，创建混合模式。例如，每日清理技能运行其维护任务，然后发出"维护完成"事件触发报告技能。这使每个技能专注于其职责，同时允许它们通过事件协调。
了解更多：事件驱动 AI Agent 以及定时模式如何与事件驱动设计在生产系统中互补。
常见错误
依赖内存中状态。 如果 Agent 进程在运行之间重启，内存中的进度丢失。始终将进度和状态存储在持久存储中。
没有重叠保护。 没有锁定或单实例强制，频繁调度的 Agent 可能冲突，导致重复处理或数据损坏。
忽略时区。 "每天上午 9 点"不指定时区是有歧义的。明确指定时区，特别是为跨区域用户服务的 Agent。
静默故障。 运行失败时不记录日志或发出告警。一个故障的定时 Agent 可能几天不被发现，积累未处理工作的积压。
下一步
从你目前在手动操作的简单重复任务开始——检查仪表盘、发送摘要、清理旧数据。定义计划，编写 Agent 工作流，让它运行。然后添加监控和错误处理。
查看教程页获取实践示例。