Dify 定时触发（trigger-schedule）实测：工作流到点自动跑，和三个必须知道的坑

📖 摘要：日报自动生成、看板定时刷新、巡检定时告警——这些「到点自动跑」的需求，Dify 用 trigger-schedule 节点实现：它是工作流的「闹钟」入口（替代开始节点），发布后按配置的时间自动启动工作流。本文实测验证了真实定时触发（cron 每分钟连续运行全部成功）、时区行为、失败处理——以及三个交付前必须知道的坑：定时任务失败是静默的、首次发布可能不生效、时间格式只认 12 小时制。

1. 业务场景：工作流需要一个「闹钟」

给客户做数据看板、日报系统时，最常听到的需求是：

每天早上 9 点自动生成昨天的销售日报；每周一自动刷新周报看板；每个整点自动巡检一次服务状态。

人工触发不现实——凌晨的日报没人守着点按钮。工作流需要的是一个「闹钟」：到点自动启动，跑完自动结束，结果落库。

2. 方案：trigger-schedule 节点

Dify 的定时触发是一个入口节点（trigger-schedule，替代 start 作为工作流起点）：

• 两种配置模式：

  • visual（可视化）：按频率选——每小时（指定分钟）、每天（固定时间）、每周（指定星期几）、每月（指定日期）

  • cron（表达式）：标准 5 段 cron 表达式 + 时区——最灵活，支持「每分钟」级别的细粒度

• 触发机制：工作流发布后，调度器（celery beat）每分钟轮询一次到期的定时计划，到点自动启动工作流运行

• 入口语义：整个工作流从定时节点开始，跑完正常到结束节点——和手动触发的区别只是「谁按了开始键」

3. 整体架构

发布后：计划写入数据库（含下一次运行时间 next_run_at）→ 调度器轮询发现到期 → 启动运行 → 运行完成后自动推进到下一周期。

4. 实测验证（真实定时触发）

实验载体：最小定时工作流（trigger-schedule cron */1 * * * * 每分钟 → LLM 生成一句话 → 结束），时区 Asia/Shanghai，云端 Dify 1.16.1 实测。

结果：连续 4 分钟每分钟自动运行，全部成功，输出正常：

• ✅ 真实定时触发：到点自动启动，无需人工

• ✅ 时区生效：next_run_at 按 Asia/Shanghai 计算（北京时间 15:00 触发 = UTC 07:00）

• ✅ 周期推进：每次运行后自动计算下一次运行时间

5. 关键配置（DSL 结构）

data:

  type: trigger-schedule      # 入口节点（替代 start）

  title: 定时触发器

  mode: cron                  # visual | cron

  cron_expression: "*/1 * * * *"   # cron 模式：标准 5 段

  timezone: Asia/Shanghai     # 时区——⚠️ 默认 UTC，国内必须显式设置

  desc: 工作流的闹钟

visual 模式（每天 9:00 触发）：

mode: visual

frequency: daily

visual_config:

  time: "9:00 AM"             # ⚠️ 12 小时制，不支持 "09:00"

timezone: Asia/Shanghai

发布流程（⚠️ 两个关键点）：

1. 定时计划在发布时写入——首次发布可能不生效（实测第一次发布后计划表为空，重新发布一次才注册成功）——发布后务必验证

2. 发布后 1-2 个周期内观察首轮触发（cron 分钟级验证最快）

6. 实测坑（三个必须知道）

另外两个容易踩的：

• 时区默认 UTC——不设置会按 UTC 触发（国内差 8 小时）

• 运行记录不显示在常规运行列表——定时触发的运行在数据库里有记录，但 Console 的常规运行列表可能看不到，排查要走数据库或日志

7. 总结

定时触发把「到点自动跑」做成了平台原生能力：cron/visual 双模式、时区支持、周期自动推进，真实触发实测通过。但坑 1（失败静默）是交付红线——定时任务没有人工盯着，失败不可见等于「任务悄悄没跑」，方案里必须设计失败告警。

适合的场景：日报/周报自动生成、数据看板定时刷新、定时巡检与告警、定时拉取外部数据。不适合：对「必须跑成功」有硬性要求的任务（先解决失败可见性再说）。

本文为 Dify 功能实测记录，基于 2026-08 云端 1.16.1 环境，实验数据全部来自真实运行结果。