AI Agent 一跑就是几小时？Trigger.dev 专治长任务超时和中断

你写了一个 AI Agent，本地跑得挺好。部署上线之后问题来了：任务跑了一个多小时，平台超时把它杀了；或者服务器重启，跑到一半的任务就那么没了，没有任何恢复机制。

这类"长时间运行的后台任务"是 AI 应用落地最常被低估的坑。传统的 Serverless 函数有执行时间上限（通常几分钟），而一个真正干活的 Agent 花几十分钟甚至几小时是常态。

Trigger.dev 就是专门解决这个的。它在 GitHub 上有 1.6 万 star，Apache-2.0 协议，可商用。官方定位是"构建和部署完全托管的 AI Agent 与工作流"，核心词是 durable——持久化的、可恢复的。

它到底是什么

Trigger.dev 是一个后台任务平台。你把任务写成普通的 TypeScript 函数，它负责让这个函数能可靠地跑完，不管跑多久、不管中间发生什么。

它和队列系统（BullMQ、Celery）的区别在于：队列给你"分发任务"的能力，Trigger.dev 给你"任务一定能跑完"的保证。后者包含前者，还多了持久化、自动重试、断点续传、可观测性。

核心概念很简单：

import { task } from "@trigger.dev/sdk/v3";

export const researchAgent = task({

id: "research-agent",

retry: { maxAttempts: 3 },

run: async (payload: { topic: string }) => {

const outline = await callLLM(payload.topic);

const sections = await Promise.all(outline.map(writeSection));

await saveReport(sections);

return { sections: sections.length };

},

});

你写的就是一个 async 函数。但这个函数运行在 Trigger.dev 的运行时里，它的每一步执行状态都被持久化了。

"可恢复"到底是什么意思

这是 Trigger.dev 最核心的能力，值得单独讲清楚。

普通函数如果服务器重启，上下文全丢，从头再来。Trigger.dev 的任务会记录执行进度——哪些步骤跑完了、结果是什么。如果任务中断（部署、机器故障、超时），恢复后会从断点继续，而不是从头开始。

对 AI 任务来说这个价值巨大。一个跑了 40 分钟、已经烧掉几十块钱 API 费用的 Agent，因为一次部署挂掉就要从头再烧一遍，这是真金白银的损失。

配合这个能力的还有几个特性：

• 自动重试：失败重试，带指数退避
• 并发与队列控制：限制同时跑的任务数，避免把下游 API 打挂
• 超时与延迟：任务可以延迟执行、可以设超时
• 生命周期钩子：任务开始、失败、成功的回调

什么场景非它不可

判断标准很简单——任务时长超过 Serverless 上限，或者不能容忍中断：

• AI Agent 的长链路推理（几分钟到几小时）
• 视频/音频处理、批量转码
• 大批量数据导入导出
• 需要跨小时等待的工作流（发邮件后等 24 小时再检查有没有回复）
• 定时爬虫、批量报告生成

反过来，如果你的任务都在几秒内完成，用个普通队列甚至直接同步执行就够了，上 Trigger.dev 属于过度设计。

自托管还是用云

Trigger.dev 是开源的，可以完全自托管。官方有完整的 self-hosting 文档，用 Docker Compose 部署，需要 Postgres 和 Redis。

选云服务的理由是省事——可观测性面板、自动扩缩容、告警都现成。选自托管的理由通常是数据合规和成本控制。

一个实用的判断：团队小、想快速验证 → 先用云；任务量大、有合规要求 → 自托管。因为它是开源的，这两条路之间迁移的成本不高，不用在选型时过度纠结。

上手的几个建议

任务要拆细。 一个任务里塞五十步，出问题定位困难。拆成多个小任务串联，每个任务职责单一，失败重跑的粒度也小。

幂等性必须保证。 任务可能被重试、可能断点续跑，同一个操作执行两次不能产生副作用。写数据库用 upsert，调外部 API 带幂等键。

payload 要小。 传给任务的是元数据，不是大数据。一个几百 MB 的文件别塞进 payload，传对象存储的路径。

设合理的并发上限。 AI 任务特别容易触发 API 限流。给对接 LLM 的任务设并发上限（比如同时最多 5 个），比事后处理 429 错误省心得多。

生产落地的四个要点

用 `run` 内的子任务做进度可视化。 长任务如果没有进度反馈，用户（和你自己）会觉得它挂了。Trigger.dev 支持在任务内部触发子任务并上报进度，UI 里能看到"第 3 步 / 共 10 步"，这个体验差别很大。

对外部调用全部包一层超时。 LLM 接口偶尔会挂住不返回，不设超时的话任务会一直挂着占着并发位。每个外部调用都设 timeout，失败走重试。

区分可重试与不可重试错误。 网络超时、限流（429）该重试；参数错误、数据格式不对不该重试——重试一百次也是失败，只会浪费时间和钱。在代码里显式区分这两类异常。

留好 dead letter 兜底。 重试耗尽仍然失败的任务，要有一个明确的去向（写进失败表、发告警），而不是静默消失。静默失败是后台任务最危险的失败模式。

成本怎么算

自托管本身没有授权费用，成本在服务器和数据库。Trigger.dev 会记录每一次运行的详细日志和状态，跑量大时数据库增长较快，需要配保留策略。

真正省钱的地方恰恰是它的核心能力：断点续跑。一个跑了 40 分钟、调用了几百次 LLM 的任务，因为一次部署中断就要从头再跑一遍，这个损失远大于平台本身的花费。对 AI 任务来说，可靠性就是成本。

我的判断

AI 应用从 demo 走到生产，卡住的地方往往不是模型能力，而是这些工程细节：任务跑一半挂了怎么办、重试会不会重复烧钱、出问题能不能看到是哪一步。Trigger.dev 把这些做成了默认能力，不用你自己造轮子。

如果你的 Agent 已经开始产生真实费用、或者已经有用户依赖它的产出，这套"任务不会莫名消失"的保证，值得认真考虑。

官方仓库在 github.com/triggerdotdev/trigger.dev。