你写了个 skill，写了个 agent。然后你坐在终端前看它跑。
有 3 种主流方式让 Claude Code skill 和 agent 脱离你的控制自动跑。每种 trade-off 不同，没有最好，只有最合适。
Nate Herk 给出了完整的 3 方式拆解。
部署 agent 的两个轴
每个部署方案落在两个轴上：
轴 1：跑在哪
- 本机——你的 MacBook / Linux 机器
- 云——Anthropic cloud、Modal、Trigger.dev、VPS、AWS Lambda
关键问题：你的笔记本要一直开着吗？
- 要 → 本机
- 不要 → 云
轴 2：多 agentic
- 完全自主 loop——agent + skills + tools 全栈，能推理、能决策
- 确定性脚本——跑同样的逻辑，每次都一样的输出
关键问题：你的 task **需要"判断"**吗？
- 要 → agentic
- 不要 → 脚本
WAT 框架
Nate 用 WAT 框架来理解每个部署的覆盖范围：
- W = Workflow（流程）——"该做什么、按什么顺序"
- A = Agent（自主推理层）——"下一步该做什么的判断"
- T = Tools（工具）——"能调用的能力"
Skills 通常落在 W 和 T：
- 纯 workflow 的 skill（"按这个模板写 LinkedIn 帖"）= W
- chain workflow + tools 的 skill（"写 LinkedIn 帖 + 调 image API 生成配图"）= W + T
- Agent 是 A——它决定"下一步调哪个 tool、按什么顺序"
3 种部署方式覆盖不同 WAT：
| 方式 | W | A | T |
|---|---|---|---|
| 本机 loop | ✅ | ✅ | ✅ |
| Modal | ✅ | ⚠️ | ✅ |
| Trigger.dev | ✅ | ❌ | ✅ |
方式 1：本机跑 loop
最简单。零配置。
# 打开 Claude Code
> set up a loop every 10 minutes to read the new comments on my latest YouTube upload and reply using the transcript
Claude Code 内部跑 cron 式的循环。它读取你给的指令，设个 timer，循环执行。
适合
- 个人临时自动化（"每 10 分钟查评论区"）
- 数据备份（"每晚 22 点把 working dir 备份到 S3"）
- 监控告警（"每次 GitHub issues 有新 high-priority tag，给我发通知"）
- 临时探索（"今晚 2 小时内把 Reddit r/LocalLLaMA top 帖子分类到 Notion"）
代价
- 笔记本要开——关掉就停
- 没 observability——出错你看 console
- 没 retry——挂了人工重启
- 不 scale——只能跑你能想到的几个
方式 2：Modal（云 serverless）
Modal 是 cloud-hosted 的 Claude Code 部署平台。你的 agent / skill 跑在 Modal 的 serverless 容器里，按调用计费，auto-scale。
适合
- Cloud-hosted agent——不依赖本机
- Auto-scale 场景——流量波动大（白天高、夜里低）
- 轻量 task（< 10 分钟跑完）
- 不想管基础设施
代价
- 冷启动延迟——首次调用 5-30 秒
- agent loop 能力受限——Modal 适合确定性脚本（W + T），**agent 推理（A）**在 Modal 上不友好
- per-call 计费——长 task 成本高
- 数据本地性——agent 跑在云，本地文件需要 upload
方式 3：Trigger.dev
Trigger.dev 是长任务 + observability 平台。你的 workflow 跑在 Trigger.dev 的 worker 上，支持重试、日志、dashboard、webhook 触发。
适合
- 长任务（小时级、跨天）——本机 loop 跑不动、Modal 太贵
- 需要 observability——任务跑哪了、错哪了、retry 几次
- webhook 触发——GitHub push 后跑测试、Stripe 收到大额后跑报告
- 重试 + 失败恢复——长任务中间挂掉能 resume
代价
- 配置复杂——比本机 loop 多 5-10 倍 setup 时间
- agent 推理能力弱——Trigger.dev 是 W 重的，不适合 A 重的 agent
- 按 task 计费——大量小 task 不划算
- vendor lock-in——迁移成本高
3 种方式的对比
| 维度 | 本机 loop | Modal | Trigger.dev |
|---|---|---|---|
| 笔记本要开？ | ✅ 是 | ❌ 否 | ❌ 否 |
| Auto-scale？ | ❌ 否 | ✅ 是 | ⚠️ 半自动 |
| 长任务？ | ⚠️ 几小时 | ❌ < 10 分钟 | ✅ 跨天 |
| Observability？ | ❌ 弱 | ⚠️ 中 | ✅ 强 |
| Retry？ | ❌ 无 | ⚠️ 基础 | ✅ 强 |
| Setup 成本 | 5 分钟 | 1-2 小时 | 1-2 天 |
| 单 task 成本 | $0 | $0.001-0.01 | $0.01-0.1 |
| Agent 推理 | ✅ 强 | ⚠️ 弱 | ❌ 不支持 |
| 适合 WAT | 全 WAT | W + T | W |
选择决策树
我需要 agent 跑 24/7 吗？
│
├─ 否（只是个人临时自动化）→ 本机 loop
│
└─ 是
│
任务长吗（> 30 分钟）？
│
├─ 否（短 task、scale 重要）→ Modal
│
└─ 是（长 task、需要重试 + observability）→ Trigger.dev
Nate 没说的两件事
1. Hybrid 模式。实际生产中很少只用一种方式。典型 hybrid：
- 触发：Trigger.dev（webhook 接 GitHub push）
- 执行：Modal（短 task 跑 build/test）
- 长任务：Trigger.dev worker
- 监控：本机 agent（看 dashboard、临时修复）
3 种方式不是互斥，是组合。Nate 的"3 方式"是纯净架构，实操是 mix。
2. Agent 推理层的云部署。Modal 和 Trigger.dev 对"agent 推理"（A）支持都弱——它们假设"workflow 写好，agent 跑流程"。但 Claude Code 的核心价值是agent 实时判断——遇到 spec 模糊就停下问人。这个能力在云部署里基本用不了——因为没人值班。云部署的 agent 是"白天版本"，本机部署的 agent 是"24/7 陪人版"。这是云 agent 的结构性局限。
结论
3 种部署方式的核心 trade-off：
- 本机 loop = 简单 + 零成本，但笔记本要开
- Modal = cloud + auto-scale，但 agent 推理弱
- Trigger.dev = 长任务 + observability，但 setup 重
第一性问题：你的 task 需要 agent 推理吗？
- 是 → 本机 loop 是最友好选择
- 否 → Modal / Trigger.dev 都行，按时长 + scale 选
SOTA Sync 的判断：未来 12 个月，"agent 部署"会从"个人玩具"变成"团队基建"——Ops 角色（管理 agent deployment、监控、retry、cost control）会变成 AI 团队标配。这是 AI 时代的新工种——不是写 agent 的人，是养 agent 的人。
但 agent 推理层的云部署仍是空白——没人值班时，agent 怎么"判断"？ 这是云 agent 平台的下一道关卡。未来 12 个月会有"agent 值班"产品出现——让 agent 在云上也能"问人"。