---
title: '32 把工作流放上云 & Webhook 部署'
video_id: MxyRjL7NG18
part: 32
---

> 章节 32 / 37 · [[00-总览|课程总览]] · 起始 [4:28:45](https://youtu.be/MxyRjL7NG18?t=16125)


## 章节主旨

把此前只能在本地 IDE 里由你亲自 prompt 触发的工作流,搬到云上——具体做法是**只上传确定性的 execution scripts(不上传 orchestrator)**,用 Modal 等 serverless 平台把它们变成可被 Webhook 或 Cron 触发的独立云函数,并配上密钥管理与日志监控。

## 核心论点

1. **上云只上传 execution scripts,orchestrator 留在本地**——云端跑的是确定性部分,等于把 agentic 工作流退回传统 procedural 工作流。([[#1-上云只上传确定性的-execution-scripts-42919|→ 详解1]])
2. **无人值守场景要把 LLM 移出循环**——模型的概率发散在有人盯着时可纠偏,凌晨 3 点全权限自动跑时就是隐患。([[#2-为什么把-llm-移出云端循环-43040|→ 详解2]])
3. **Modal 把 serverless 部署降成一句自然语言**——pay-per-use、自动 spin down、给你 webhook URL,agent 读文档自己搭。([[#3-modal把-serverless-部署降成一句话-43324|→ 详解3]])
4. **Webhook 本质是「URL + 一段逻辑」**——外部系统访问这个 URL 就唤醒你的工作流,像门铃。([[#4-webhook-是什么-43510|→ 详解4]])
5. **定时用 cron,判断该不该上云看两条线**——scheduled 或 event-triggered 才上云,否则留本地更安全。([[#5-cron-定时以及该不该上云的两条判据-43804|→ 详解5]])
6. **密钥加密存储 + 主动埋日志**——云端没有 IDE 的 reasoning window,可观测性得自己在代码里显式加。([[#6-密钥加密存储--日志与可观测性-43932|→ 详解6]])

## 知识点详解

### 1. 上云=只上传确定性的 execution scripts [4:29:19](https://youtu.be/MxyRjL7NG18?t=16159)

回忆 DOE 框架 的三层:directives、orchestration、executions。上云时**不上传 orchestrator**,只把 execution scripts(纯确定性脚本)部署成云函数。directives 可以选上传,给日后可能编辑它的模型留点上下文,但核心只需 execution scripts。

可以把每个 execution script 理解成「一个只可靠地做一件事的 API」。和本地相比,**根本差别是云端没有 LLM**——你只是用 LLM 快速搭出一个有明确输入输出的自建 API,然后让它按固定顺序执行:node 1 → node 2 → … → node n,靠 server side logic 强制成同一条路由,不再有每次略有不同的路由决策。

代价要认清:这一步把 agentic 工作流变回了传统 procedural 工作流,它**不能再临场适应意外、不能 self-anneal、不能反问澄清**,只会一丝不差地做你让它做的事。但一个部署上云的工作流本就该是在本地跑过几十遍、debug 干净的 battle-tested 版本,所以损失有限。

### 2. 为什么把 LLM 移出云端循环 [4:30:40](https://youtu.be/MxyRjL7NG18?t=16240)

原因是 stochasticity——模型天然带随机性,时间步一长就倾向于偏离你的本意,向各个方向发散。在 IDE 里你多半在场,就算此刻没盯着,一小时内也会瞥一眼,出问题能纠偏;可一旦是凌晨 3 点、全系统权限、无人值守地跑,这种波动就是纯粹的 liability。

Nick 给的类比:**agent 是建筑师,云工作流是建筑**。建筑师设计楼,但很少住进自己设计的楼里。所以让 agent 负责「架构」出这栋楼,再放确定性的 execution scripts 进去「住」。

他坦言也试过把 orchestrator 直接塞进云环境、让 agent 常驻监听并实时改东西——听着很酷、能通过 webhook 让云端 LLM 干任何事,但在几家真实业务里试下来,**现在还不到时候**,误差范围太大,过两年也许可以,当下就完全把 orchestrator 排除在外。

### 3. Modal:把 serverless 部署降成一句话 [4:33:24](https://youtu.be/MxyRjL7NG18?t=16404)

Nick 用的平台是 Modal(trigger.dev 等也能干同类事,他声明无利益关联)。Modal 是 serverless infrastructure:按需临时拉起虚拟服务器。传统 serverless 有两难——要么常在线一直计费,要么离线但每次要 cold start、等一两分钟才响应;Modal 两头都解掉,既能 spin down 到零成本,又能近乎瞬时响应。

用法极简:把一个 Python 脚本变成云函数,pay-per-use,不跑就不花钱,给你一个和 make/n8n 一样的 webhook URL。价格极低——月初给 5 美元额度,他两三周只用掉 4 美分。

最省事的是**你不需要懂这些平台**:它们为 agent 而建,文档极好,agent 能自己爬取并搭好。你实际只要对 agent 说「把这个变成云函数」,剩下它全包。拿到的 webhook URL 可被任何东西调用,包括别的 agent。

### 4. Webhook 是什么 [4:35:10](https://youtu.be/MxyRjL7NG18?t=16510)

**Webhook 就是一个「有东西撞上来就触发你工作流」的 URL**。CRM、网站表单、make、n8n 都能自动去 call 这个 URL。类比门铃:有人按,你的工作流就醒来跑,你不必在场。

它就是互联网上的一个目的地(一个 node),你把 URL 填进浏览器回车能触发,用 make/n8n 发 HTTP 请求能触发,terminal、agent 都能触发。访问时它跑一段逻辑,输入符合规格就继续、再去 call 你想要的任何服务。所以 webhook 无非是「URL + 附带的逻辑」,在任何自动化场景里都极常见。

agent 幕后怎么搭:它先读 `agents.md` / `claude.md` / `gemini.md` 了解你的设置(理想情况你在里面写清「你的工作之一是在 Modal 上搭云 webhook/定时工作流,方法如下」),再看目标工作流的 execution scripts,用 Modal 喜欢的 decorator 格式包好,遇到 prompt/API key 就问你,多数时候即插即用。请求体通常是 JSON——你不必会写,能认出花括号、把 webhook 文档里的样例复制粘贴给 agent 即可。不会连某个服务,就直接问 agent,它会一步步带你走 UI。

### 5. Cron 定时,以及该不该上云的两条判据 [4:38:04](https://youtu.be/MxyRjL7NG18?t=16684)

若想让触发方式从 webhook 改成定时,用 **cron**。Modal 和各家 agent 原生支持,你不用碰 cron 语法,只说「每天下午 5 点跑一次」它就配好——像设一个循环日历提醒,只不过对象是你的工作流。示例:「我要每周一早 9 点自动出周报」,agent 会替你写好 cron、部署到 Modal。

**判据一:该上云的两类**——① scheduled:日报、周报、定期抓取/HTTP 请求;② event-triggered:时效强、要在别的请求进来后几秒内响应,就上 webhook。

**判据二:两类之外的留本地**。如果一件事不需要在你不在时跑,那就该在你在场时跑,因为 agentic 工作流放大杠杆的同时也**放大误差边界**,你最好在旁边看着出没出岔子。何况你 3、4 小时的在场工作,用 agentic 工作流已相当于 30–40 小时产出,留本地并不真损失多少。

### 6. 密钥加密存储 + 日志与可观测性 [4:39:32](https://youtu.be/MxyRjL7NG18?t=16772)

**密钥风险**:把工作流做成云可访问,就是在互联网上开了台服务器,任何知道你凭据的人理论上都能访问。连接平台不可避免要上传 secret,这本身有风险。Modal 的做法是把凭据存成**与代码分离的 encrypted secret**,只在有人 call webhook 时才注入运行,不进 codebase——和 IDE 里代码与 `.env` 分离同理,是专业工程团队的常规做法。agent 会自然地问你「这脚本要 Apollo API key,用你 env 里那个吗?」,你答 yes/no/换这个即可。

**日志与 observability**:IDE 出错好查,因为有 reasoning window 能翻;云端开箱即无这类日志,所以**你的 agent 必须在代码里显式强制打日志**,否则 debug 会很久。从一开始就建观测性,后续就顺得多。[4:42:26](https://youtu.be/MxyRjL7NG18?t=16946) Nick 自己的设置是建一个专属 Slack 频道 `Agentic-Cloud-LOG`,每次工作流跑完自动推成功/失败通知——一种粗粒度但够用的可观测性:成了知道成、没成知道没成,再让 agent 去自查修复。

至于「把 error 自动丢给另一个云端 LLM 让它全自主修」的 self-fixing loop,他态度保留:多数人一天不会建几千个 webhook,瓶颈根本不在这;且它不引入新错误就修好的概率也低,不想误导人去建华而不实的自愈环。

**实操 demo**:[4:47:51](https://youtu.be/MxyRjL7NG18?t=17271) 他对 agent 说「给 `create_proposal.md` 建一个 modal webhook、拿回 URL」,系统提示里预设的 `webhooks.json`(原本为空)被自动填入新条目,部署成功即得到一条 webhook URL。跑一次示例生成了提案,再让 agent「加长段落、更真实」并更新文档重跑。全程只需在 Modal 点一下拿 API token 粘进去。

## 术语

- Execution scripts(执行脚本):DOE 三层里确定性的那部分,上云只上传它。
- Orchestrator(编排器):调度各执行脚本的 agent 层,**不上云**,留本地。
- Modal:pay-per-use 的 serverless 平台,一句话把脚本变云函数、给 webhook URL。
- Serverless / Cold start(无服务器 / 冷启动):按需拉起服务器;离线态首次唤醒的延迟即 cold start,Modal 规避了它。
- Webhook(网络钩子):被访问即触发工作流的「URL + 逻辑」,像门铃。
- Cron:描述「何时运行」的定时机制,agent 代你生成语法。
- Encrypted secret(加密密钥):与代码分离、调用时才注入的凭据存储方式。
- Observability(可观测性):系统运行状态的可见程度;云端需在代码里主动埋日志。

## 自检问题

1. 上云时哪一层不上传,为什么?
   **答案**:不上传 orchestrator(编排器),只上传确定性的 execution scripts。因为云端无人值守、全权限自动跑时,LLM 的概率发散(stochasticity)是隐患,把 LLM 移出循环、用 server side logic 强制固定路由才安全。见详解1、2 [4:29:19](https://youtu.be/MxyRjL7NG18?t=16159)
2. Webhook 用一句话怎么解释?两类适合上云的工作流是什么?
   **答案**:Webhook 是「被访问就触发你工作流的 URL + 一段逻辑」,像门铃。适合上云的两类:scheduled(日报/周报/定期抓取)用 cron,event-triggered(时效强、需几秒内响应)用 webhook;两者之外留本地更稳。见详解4、5 [4:35:10](https://youtu.be/MxyRjL7NG18?t=16510)
3. 云端 debug 为什么比 IDE 难,Nick 怎么补救?
   **答案**:IDE 有 reasoning window 可翻查,云端开箱即无这类日志。补救是让 agent 在代码里显式强制打日志(建 observability),Nick 自己用专属 Slack 频道 Agentic-Cloud-LOG 接收每次运行的成功/失败通知。见详解6 [4:42:26](https://youtu.be/MxyRjL7NG18?t=16946)