Trigger.dev

Trigger.dev 是一个开源的后台任务和 AI 工作流平台，由 Matt Aitken 和 Eric Allam 构建，这支位于都柏林的团队获得了 Y Combinator 以及包括 Standard Capital 在内的 A 轮投资者的支持。它解决了一个特定且长期存在的问题：像 AWS Lambda 和 Vercel 这样的无服务器函数具有几秒或几分钟的严格超时限制，但 AI 管道、文档处理任务和多步代理工作流通常需要运行几分钟甚至几小时。Trigger.dev 允许开发者将任务定义为普通的异步 TypeScript 函数，并在托管云基础设施或通过 Docker 或 Kubernetes 在自己的服务器上运行，完全不受此限制。

该平台以 TypeScript SDK 的形式发布，可与 Node.js、Bun、Next.js、NestJS 以及大多数其他 TypeScript 服务器环境集成。核心功能包括带有检查点恢复的持久化执行（任务在 await 点暂停并在不丢失状态的情况下恢复）、具有可配置退避策略的自动重试、带有优先级控制的并发队列、cron 调度，以及将实时任务进度流式传输到前端 React 应用的 Realtime API。它集成了 Vercel AI SDK、OpenAI Agents SDK、LangChain、LangGraph、LlamaIndex，以及来自 Anthropic、OpenAI、Google、Cohere 和 Mistral 的直接模型 API。对于特定于 AI 的用例，Trigger.dev 还支持人在回路（human-in-the-loop）等待点，任务会暂停以等待人工审批或输入，然后准确地从中断处恢复，且不消耗空闲计算时间。当前稳定版本为 v4，拥有 14,800+ GitHub stars，采用 Apache 2.0 许可。

Trigger.dev 在 2026 年 5 月的实际表现

Trigger.dev 的核心机制是检查点恢复（checkpoint-restore）执行。当任务到达 await 点（等待另一个任务、外部事件、计时器或人工）时，平台会使用 CRIU（用户空间中的检查点/恢复）序列化任务状态并挂起容器。在此暂停期间，任务不会产生计费。当等待的条件解决时，任务会准确地从序列化状态恢复。这与传统的无服务器架构有着根本的不同，在传统架构中，函数要么在超时时间内完成，要么失败。

任务在基于 Bun 的 worker（长期运行的容器，而不是短暂的 Lambda 风格调用）中运行。每个任务都可以指定自己的机器配置：CPU 核心数、RAM，以及可选的系统级包（如 FFmpeg、Puppeteer，或通过构建扩展自定义的 Python 环境）。这意味着视频转码任务和轻量级电子邮件任务可以共享同一个项目，同时在大小合适的机器上运行。

Realtime API 于 2024 年 12 月正式发布（GA），基于 Electric SQL（一个开源的 PostgreSQL 同步引擎）构建，支持像 useRealtimeRun 和 useRealtimeBatch 这样的 React hooks，将实时任务状态流式传输到浏览器 UI。文档处理管道可以向用户显示实时进度：“正在提取文本.. 正在总结第 3 章（共 8 章）..”，而无需轮询。在 GA 发布后的几天内，包括 Midday.ai 和 Papermark.io 在内的 60 多家组织采用了 Realtime API。

调度通过 cron 表达式或基于间隔的触发器原生处理，任务支持扇出（fan-out）模式：一个父任务可以并发生成数百个子任务，所有子任务都在具有统一可观测性的单个运行树中进行跟踪。由 OpenTelemetry 驱动的仪表板显示每次运行的完整追踪树、日志、重试历史记录和性能指标。

“我们决定使用 Trigger.dev 而不是 Inngest 或建立我们自己的专用解决方案.. [为了] 工作流自动化、可扩展性、开发速度、成本效益和面向未来。” - Sohrab Fadai，Product Hunt，2024

Trigger.dev 与 Inngest 和 Temporal 的定位对比

在开发者优先的持久化执行领域，最常被比较的三个工具是 Trigger.dev、Inngest 和 Temporal。它们各自采用了根本不同的架构方法。

Inngest 在功能上与 Trigger.dev 的重叠度最高，但架构在一个关键方面有所不同：Inngest 不运行你的计算。它是一个纯 API 的编排层，通过 HTTP 调用你的无服务器端点并传递事件。开发者必须将工作划分为离散的 step.run() 函数，每个函数在步骤边界独立重试和设置检查点。这意味着 Inngest 任务仍然受限于每个步骤的无服务器执行限制（每次步骤函数调用大约 15 分钟）。Trigger.dev 直接在其托管基础设施（或自托管 worker）的长期运行容器中运行你的代码，没有步骤划分要求。一个连续的异步函数可以运行数小时。Trigger.dev 的 Hobby 付费层起价为 $10/mo；Inngest 的付费层起价为 $75/mo。Trigger.dev 采用 Apache 2.0 许可，可以完全自托管且没有功能限制。Inngest 的自托管条款则更为受限。在 npm 每周下载量方面，Inngest 每周大约有 85,000 次下载，而 Trigger.dev 为 45,000 次，这反映了 Inngest 在市场上存在的时间更长，尽管从 GitHub star 轨迹来看 Trigger 的增长速度更快。

Temporal 则完全处于另一个层级：面向极其复杂、长期运行、多语言工作流的企业级持久化执行。Temporal 使用事件溯源的确定性重放。每个工作流操作都记录在仅追加的历史日志中；在恢复时，工作流从头开始重放，重新执行所有活动直到当前点。这需要确定性的工作流代码：在工作流函数内不能有 Date.now()、不能有随机数、不能有直接 I/O。学习曲线要陡峭得多，要求开发者在发布第一个任务之前理解 Workflows、Activities、Workers、Task Queues、Namespaces 和 Signals。Temporal 支持多语言（Go、Java、Python、TypeScript、PHP、.NET）；Trigger.dev 则是 TypeScript 优先，仅将 Python 支持作为扩展变通方案。对于需要多年工作流历史记录、完整审计跟踪或 Java/Go worker 集群的企业来说，Temporal 是正确的选择。对于需要可靠后台任务且基础设施开销最小的 TypeScript AI 应用团队来说，Trigger.dev 的运行速度更快、成本更低。正如一位开发者在 Trigger.dev 与 Temporal 的对比页面上总结的那样：“将后台任务迁移到 Trigger 更可靠、更便宜、也更容易。”

构建 Python 优先的 ML 管道的开发者也应该评估 Modal，它提供 GPU 加速的无服务器计算和出色的 Python 工具。对于已经使用 n8n 或 Activepieces 进行可视化工作流自动化的团队来说，Trigger.dev 不是可视化工具的替代品，而是针对需要持久性和长期运行执行的任务的代码层补充。

代理循环在日常开发中的真实体验

开发体验从安装 @trigger.dev/sdk 包并添加 trigger.config.ts 文件以指定项目设置开始。任务是使用 task() 装饰的导出函数。Trigger.dev CLI 运行一个本地开发服务器，连接到 Trigger.dev Cloud（或自托管）仪表板，在开发过程中运行情况会实时显示。本地无需配置或管理单独的队列基础设施。

对于 AI 代理工作流，其模式是定义一个编排子任务的根任务。每个子任务都可以调用 LLM API、写入数据库、发送 HTTP 请求，并调用 wait.forEvent() 暂停直到外部信号到达。人在回路工作流添加了一个 waitpoint 调用，该调用序列化代理的状态并发送通知，然后在人工通过 Trigger.dev 仪表板或自定义 API 调用提交审批时恢复。

部署到生产环境只需一个 CLI 命令：npx trigger deploy。CLI 会构建一个 Docker 镜像，将其推送到 Trigger.dev Cloud（或自托管注册表），并创建一个不可变的带版本部署。已经在运行的任务继续在其部署的版本上运行；新任务则采用最新版本。这种原子版本控制可防止运行中的任务被新代码部署破坏，这是基于队列的系统常见的故障模式。

“能够使用 TypeScript 来定义工作流真是太棒了。” - Charlie，Product Hunt，2024

通过 OpenTelemetry 内置了可观测性。每次运行都会生成一个在仪表板中可见的追踪树：每个步骤、其持续时间、其输入和输出，以及任何嵌套的子任务调用。可配置的错误警报可以路由到 Slack 或 PagerDuty。日志保留期从 Free 层的 1 天到 Pro 层的 30 天不等，Enterprise 层支持自定义保留期。

Trigger.dev 是为谁构建的

Trigger.dev 专为构建 AI 驱动应用程序的 TypeScript 开发者而构建：具有 AI 功能的 Next.js 应用、处理文档的 NestJS 后端、任何调用 LLM API 并需要重试逻辑和可观测性的服务器端代码。当 AI 管道不断触及无服务器超时限制，或者当开发者发现自己需要手动编写脆弱的重试逻辑时，该工具尤为有价值。

处于早期阶段的初创公司会发现 $10/mo 的 Hobby 计划足以满足大多数生产工作负载，计算费用按实际使用量单独计费。处理大量 AI 推理任务的团队会发现 Pro 层的 200+ 并发运行和专属 Slack 支持绝对物超所值（$50/mo）。截至 v4 版本，Docker 上的自托管部署已有完善文档且非常成熟；Kubernetes 自托管也已可用，并在系列官方博客文章中进行了说明。

Trigger.dev 可以自然地集成到已经使用 Zapier 或 Make 进行无代码自动化的技术栈中，服务于不同的层级。这些平台在不编写代码的情况下处理跨应用事件路由，而 Trigger.dev 则处理当任务运行时间超过 Lambda 函数允许的时间时，代码层内部发生的事情。

对开源有重大承诺的团队会非常欣赏其 Apache 2.0 许可。整个平台可以自托管，没有功能限制，没有运行次数限制，除了 TypeScript SDK 本身之外没有供应商锁定。截至 2026 年 5 月，该代码库拥有 14,800+ GitHub stars、活跃的维护者和 617+ 个版本发布，表明其具有真正的持久生命力。

Trigger.dev 不是什么

它不是一个 Python 工具。 SDK 仅支持 TypeScript。虽然可以通过构建扩展在任务内部将 Python 脚本作为子进程调用，但没有原生的 Python SDK，没有 Python 任务定义，也没有对任务内 Python 包管理的一流支持。运行推理管道的 Python 优先 ML 团队应该改用 Modal、Prefect 或带有 Python worker 的 Temporal。

它不是一个无代码或低代码平台。 没有可视化工作流构建器、拖放节点或用于定义任务的 GUI。一切都是代码。如果没有开发者的参与，业务用户或非工程团队无法使用 Trigger.dev。有关可视化工作流自动化，请参阅 n8n 或 Activepieces。

它不是一个完整的可观测性技术栈。 虽然内置的 OpenTelemetry 追踪很有用，但拥有现有可观测性基础设施（Datadog、Grafana、Honeycomb）的团队需要将 Trigger.dev 的追踪集成到他们现有的工具中。内置仪表板功能齐全，但不能替代专用的可观测性平台。

它尚未达到 Temporal 规模的企业级强化。 在 2025 年 9 月的生产事故中，单个客户过大的错误消息级联导致了三次同时发生的云故障，这表明基础设施在快速增长下仍在稳定过程中。团队发布了详尽的公开事故报告并在 48 小时内发布了修复程序，这是一个积极的信号。但对于工作流故障属于业务关键型的团队来说，可能希望等待 MicroVM 迁移（计划用于减少对 Kubernetes 的依赖）完成后，再在企业规模上进行投入。

如果你的团队已经在使用基于步骤的工作流良好运行 Inngest 且没有超时问题，请跳过 Trigger.dev。迁移成本是真实存在的，功能差异可能不足以证明其合理性。如果你需要经过实战检验的多年工作流审计跟踪，也请跳过它：那是 Temporal 的领域，而不是 Trigger 的。