章节主旨
把此前只能在本地 IDE 里由你亲自 prompt 触发的工作流,搬到云上——具体做法是只上传确定性的 execution scripts(不上传 orchestrator),用 Modal 等 serverless 平台把它们变成可被 Webhook 或 Cron 触发的独立云函数,并配上密钥管理与日志监控。
核心论点
- 上云只上传 execution scripts,orchestrator 留在本地——云端跑的是确定性部分,等于把 agentic 工作流退回传统 procedural 工作流。(→ 详解1)
- 无人值守场景要把 LLM 移出循环——模型的概率发散在有人盯着时可纠偏,凌晨 3 点全权限自动跑时就是隐患。(→ 详解2)
- Modal 把 serverless 部署降成一句自然语言——pay-per-use、自动 spin down、给你 webhook URL,agent 读文档自己搭。(→ 详解3)
- Webhook 本质是「URL + 一段逻辑」——外部系统访问这个 URL 就唤醒你的工作流,像门铃。(→ 详解4)
- 定时用 cron,判断该不该上云看两条线——scheduled 或 event-triggered 才上云,否则留本地更安全。(→ 详解5)
- 密钥加密存储 + 主动埋日志——云端没有 IDE 的 reasoning window,可观测性得自己在代码里显式加。(→ 详解6)
知识点详解
1. 上云=只上传确定性的 execution scripts 4:29:19
回忆 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
原因是 stochasticity——模型天然带随机性,时间步一长就倾向于偏离你的本意,向各个方向发散。在 IDE 里你多半在场,就算此刻没盯着,一小时内也会瞥一眼,出问题能纠偏;可一旦是凌晨 3 点、全系统权限、无人值守地跑,这种波动就是纯粹的 liability。
Nick 给的类比:agent 是建筑师,云工作流是建筑。建筑师设计楼,但很少住进自己设计的楼里。所以让 agent 负责「架构」出这栋楼,再放确定性的 execution scripts 进去「住」。
他坦言也试过把 orchestrator 直接塞进云环境、让 agent 常驻监听并实时改东西——听着很酷、能通过 webhook 让云端 LLM 干任何事,但在几家真实业务里试下来,现在还不到时候,误差范围太大,过两年也许可以,当下就完全把 orchestrator 排除在外。
3. Modal:把 serverless 部署降成一句话 4:33:24
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
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
若想让触发方式从 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
密钥风险:把工作流做成云可访问,就是在互联网上开了台服务器,任何知道你凭据的人理论上都能访问。连接平台不可避免要上传 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 Nick 自己的设置是建一个专属 Slack 频道 Agentic-Cloud-LOG,每次工作流跑完自动推成功/失败通知——一种粗粒度但够用的可观测性:成了知道成、没成知道没成,再让 agent 去自查修复。
至于「把 error 自动丢给另一个云端 LLM 让它全自主修」的 self-fixing loop,他态度保留:多数人一天不会建几千个 webhook,瓶颈根本不在这;且它不引入新错误就修好的概率也低,不想误导人去建华而不实的自愈环。
实操 demo:4:47:51 他对 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(可观测性):系统运行状态的可见程度;云端需在代码里主动埋日志。
自检问题
- 上云时哪一层不上传,为什么? 答案:不上传 orchestrator(编排器),只上传确定性的 execution scripts。因为云端无人值守、全权限自动跑时,LLM 的概率发散(stochasticity)是隐患,把 LLM 移出循环、用 server side logic 强制固定路由才安全。见详解1、2 4:29:19
- Webhook 用一句话怎么解释?两类适合上云的工作流是什么? 答案:Webhook 是「被访问就触发你工作流的 URL + 一段逻辑」,像门铃。适合上云的两类:scheduled(日报/周报/定期抓取)用 cron,event-triggered(时效强、需几秒内响应)用 webhook;两者之外留本地更稳。见详解4、5 4:35:10
- 云端 debug 为什么比 IDE 难,Nick 怎么补救? 答案:IDE 有 reasoning window 可翻查,云端开箱即无这类日志。补救是让 agent 在代码里显式强制打日志(建 observability),Nick 自己用专属 Slack 频道 Agentic-Cloud-LOG 接收每次运行的成功/失败通知。见详解6 4:42:26