---
title: '33 定时部署'
video_id: MxyRjL7NG18
part: 33
---

> 章节 33 / 37 · [[00-总览|课程总览]] · 起始 [4:50:51](https://youtu.be/MxyRjL7NG18?t=17451)


## 章节主旨

在上一章 webhook 部署的基础上,演示如何在 Modal 上用 **cron 定时触发器**让一个工作流按固定时间间隔(如每 5 分钟)自动跑起来,并说明它与事件触发(webhook)的分工。

## 核心论点

1. **定时触发解决「按时间」跑,webhook 解决「按事件」跑,二者互补。**([[#1-定时触发-vs-webhook-触发-45057|→ 详解1]])
2. **建定时函数无需手写 cron,把要跑什么、多久跑一次用自然语言交给 agent,系统提示里已内置生成 cron 表达式的能力。**([[#2-用自然语言让-agent-生成-cron-定时函数-45122|→ 详解2]])
3. **上云后跑的是纯 Python 脚本、不再走 directive,所以执行近乎瞬时,可靠性也更高。**([[#3-modal-面板时钟触发器与立即运行-45218|→ 详解3]])
4. **触发器只是接口,真正的价值在把定时/webhook 串成端到端自动流,接进 CRM 等业务系统。**([[#4-触发器串成端到端自动流-45411|→ 详解4]])

## 知识点详解

### 1. 定时触发 vs webhook 触发 [4:50:57](https://youtu.be/MxyRjL7NG18?t=17457)

上一章用 Webhook 部署工作流,那是**事件驱动**——外部系统发来一个请求才触发一次。本章换成 **schedule 触发**:不等事件,而是按预定的时间节奏自己跑。

典型场景是那种「无论有没有事,都该定期做一遍」的活儿,例如每 5 分钟跑一次 lead scraper(线索抓取)去拉新线索。两种触发器不是替代关系,而是覆盖不同的启动条件。

### 2. 用自然语言让 agent 生成 cron 定时函数 [4:51:22](https://youtu.be/MxyRjL7NG18?t=17482)

不必手写 cron 表达式。你只需告诉 agent 两件事:**要跑哪个东西**、**多久跑一次**,剩下的由系统提示里内置的逻辑翻译成 cron,再让 Modal 按这个节奏调度。(Cron 是 Unix 里用一串字段描述「每隔多久执行」的定时约定。)

演示里 Nick 直接下指令:「每 5 分钟给某邮箱发一封欢迎邮件,帮我在 Modal 上建一个云端定时触发器自动做这件事。」([4:51:33](https://youtu.be/MxyRjL7NG18?t=17493))

agent 先检查已有的 schedule function 模式,发现没有,于是新建一个定时发欢迎邮件的函数,部署完成后这个定时任务即刻上线,cron 里就写成「每 5 分钟(UTC)」。

### 3. Modal 面板:时钟触发器与「立即运行」 [4:52:18](https://youtu.be/MxyRjL7NG18?t=17538)

在 Modal 面板里,每个定时触发器带一个小时钟图标,标着「every 5 minutes UTC」。点进去能看到还没有已发出的调度调用,但显示「下一次在 1 分 9 秒后」([4:52:11](https://youtu.be/MxyRjL7NG18?t=17531))。

Modal 允许在两次定时之间**手动插一脚**:点「Run now」就立刻执行一次。演示里这一次冷启动约 3 秒起服务器 + 1.47 秒发送,邮件随即到达指定邮箱。

关键观察是执行极快:上云后不再使用 directive,跑的就是一段 Python 脚本,几乎瞬时完成 ([4:53:00](https://youtu.be/MxyRjL7NG18?t=17580))。因为紧接着上一次查询、服务器还热着,这次连冷启动都省了——0 毫秒启动、执行不到 1 秒,整件事一秒内跑完。相比之下,若每次都要冷启动、或要与模型来回通信,就慢且不确定「到底发没发出去」。

### 4. 触发器串成端到端自动流 [4:54:11](https://youtu.be/MxyRjL7NG18?t=17651)

拿到一个 webhook URL 后,它就是一个可以接进任何服务的接口。Nick 举的例子:当某个潜在客户在 ClickUp CRM 里被移动到「send proposal(发提案)」阶段时,自动触发这个 webhook,后续动作也随之自动跑。

而那个 CRM 阶段的推进,本身又可以由前面章节搭的 agentic 工作流来完成。这样一层套一层,就拼出一条**从事件到动作全自动**的端到端链路,这个 webhook URL 还能在团队内共享或交给别人复用。

对比早年的 no-code 平台(Zapier / n8n / make.com),那时要精确配置每一步;现在只要拿到 URL,就能自由连接想接的服务。

## 术语

- schedule trigger(定时触发器,按预定时间间隔自动执行工作流)
- webhook trigger(事件触发器,收到外部请求才执行一次)
- cron(Unix 定时约定,用字段串描述执行节奏,如「每 5 分钟」)
- Modal(把工作流部署上云、提供定时/webhook 调度与面板的云平台)
- run now(在两次定时调度之间手动立即执行一次的按钮)
- send proposal stage(CRM 里的「发提案」阶段,可作为触发条件)

## 自检问题

1. 定时触发器和 webhook 触发器分别解决什么问题?为什么说它们互补而非替代?
   **答案**:webhook 是事件驱动——外部请求来了才跑一次;schedule 是时间驱动——按固定间隔(如每 5 分钟)自动跑。前者覆盖「有事才做」,后者覆盖「定期都要做一遍」(如定时跑 lead scraper),启动条件不同故互补。见详解1 [4:50:57](https://youtu.be/MxyRjL7NG18?t=17457)
2. 建一个每 5 分钟跑的定时任务,用户需要手写 cron 表达式吗?流程是怎样的?
   **答案**:不需要。只告诉 agent「跑什么」和「多久一次」,系统提示内置逻辑会把它翻成 cron,再让 Modal 调度。agent 会先检查有无现成 schedule 模式,没有就新建并部署上线。见详解2 [4:51:22](https://youtu.be/MxyRjL7NG18?t=17482)
3. 为什么上云部署后执行会「近乎瞬时」?
   **答案**:因为云端跑的是纯 Python 脚本、不再走 directive,少了与模型来回通信;服务器若还热着连冷启动都省(0 毫秒启动、1 秒内完成),既快又不用担心「到底发没发出去」。见详解3 [4:53:00](https://youtu.be/MxyRjL7NG18?t=17580)