从面向开发者的 Zapier 到驱动 90% 的 AI Agent

Trigger.dev 已经从“面向开发者的 Zapier”这一概念，演变为可直接嵌入软件产品内部的 AI 代理与长时运行工作流基础设施。其核心论点是：开发者希望获得一个简单的 SDK，同时将执行、可靠性、重试、队列以及长时任务管理外包出去。根据创始人的说法，只有在他们从帮助开发者定义异步工作，转向真正由 Trigger.dev 的基础设施来执行这些工作之后，产品市场契合才开始显现，而这一转变也恰好契合了 AI 需求的上升。这场访谈还传递出一种更广泛的软件开发观：AI 不仅改变了产品在运营层面的需求，也改变了工程团队应当如何工作、招聘、审查代码以及衡量生产力。

关键信息

1. 真正奏效的切入点并不是面向内部团队的自动化，而是嵌入客户面向终端用户产品中的基础设施： 早期用例更像是面向开发者的 Zapier 工作流，用于销售、市场营销或 GitHub 自动化等后台职能。更强的需求拉动力则来自客户将 Trigger.dev 用在自己的产品中，为终端用户执行工作——给出的例子包括文档处理、视频编码以及 AI 媒体生成工作流。

   为何重要： 这是一个重要的市场区分：内部自动化或许能够验证兴趣存在，但更深层的产品价值和更强的基础设施依赖，来自处于面向用户应用关键路径之中。

2. 据称，只有在 Trigger.dev 自己接管代码执行之后，产品市场契合才真正到来： 在第二版中，开发者使用 SDK，但仍在自己的基础设施上执行工作；在第三版中，Trigger.dev 同时提供 SDK、平台和执行层。创始人表示，这一变化之后增长立刻加速，而且许多客户此前其实已经默认 Trigger.dev 会负责执行这些任务。

   为何重要： 这表明客户的主要需求可能不只是编排 API，而是托管式责任承担。对于基础设施产品而言，降低运维负担的重要性，可能高于提供灵活的底层原语。

3. 无服务器架构制造了一个结构性缺口，而 AI 工作负载让这一缺口更加突出： 创始人认为，现代无服务器系统很适合短生命周期的请求/响应型工作负载，但并不适合长时间运行的任务。Trigger.dev 将自己定位为填补这一缺口的方案，提供队列、重试、幂等性和持久执行能力，而随着 AI 使用增长，这些能力变得尤其相关。

   为何重要： 这构成了公司时机判断背后的因果逻辑：AI 并没有制造这个基础设施缺口，但让这个缺口变得更痛、更频繁。

4. 创始人认为，早期增长乏力部分是因为以错误的形态在解决问题，而不是因为市场没有需求： 他们明确表示，第二版“表现还可以”，但并未达到产品市场契合，问题也不只是需求缺失。他们的解读是：市场本来就存在，只是产品在执行模型改变之前，与市场的匹配度还不够高。

   为何重要： 对创始人和投资人来说，这是一个有价值的模式：部分采用可能意味着问题真实存在，但抽象方式、责任边界或运营模型仍然不对。

5. 开发者体验被视为设计问题，而不只是界面打磨： 团队强调对 SDK 函数设计以及用户理解产品最初几秒钟体验的精心打磨，包括在落地页上以代码优先的方式展示。他们声称的目标是让开发者在使用产品时“非常、非常难以失败”。

   为何重要： 在开发者工具领域，这里将设计定位为防错机制和采用杠杆。其主张是，API/SDK 的易用性与代码可读性是战略性的产品决策，而不是营销层面的润色。

6. 其开源姿态较为宽松，但难以扩展的运营层仍然是差异化的托管服务： 他们将产品描述为基于 Apache 2.0 许可证的开源项目，大部分功能都可用，而未开源的部分实际上是用于管理和扩展基础设施的运营层。他们提到用户可以通过 Kubernetes/Helm 来运行它，但要把它扩展得足够好并不容易。

   为何重要： 这是一个典型的开放核心/托管基础设施模式：开放有助于采用，而运营复杂性则维持了商业化能力。

战略含义

• 如果创始人的说法准确，那么围绕 AI 代理的持久性机会，可能不太在于代理提示本身，而更多在于工作流执行、可靠性、上下文处理和托管基础设施。
• 开发者基础设施公司若能端到端地掌控运营结果，可能比仅仅提供仍需客户自行运行的模块化构件，获得更大收益。
• 当托管价值体现在扩展、编排和运营复杂性，而不是通过封闭核心 API 来实现时，开源采用与托管服务变现可以并存。
• 积极采用 AI 的工程组织，可能需要围绕验证与判断力，而不是围绕无辅助实现能力，来重新设计招聘、评审与测试流程。

值得关注的信号

• Trigger.dev 是否能在第三版首次拐点之后继续增长，因为访谈文字声称其月度收入环比增长强劲，但提供的当前指标有限。
• 市场是否会越来越标准化地转向 AI 工作流的托管执行，而非自托管的编排原语。
• AI 产品团队会多频繁地收敛到创始人提出的代理构建“两部分模型”：上下文组装加动作/生成。
• 开发者工具采购方是否会继续偏好宽松许可开源加付费托管基础设施，还是自托管需求会增强。

注意事项

• 文字记录似乎并不完整，并且包含尾部摘录标记，因此可能缺失部分上下文。
• 这场访谈由创始人陈述，带有宣传性质；其中关于产品市场契合、增长和客户使用情况的说法，并未在来源中得到独立验证。
• 标题/描述提到“支撑 90% 的 AI 代理”，但摘录的访谈内容并未提供对这一说法精确且可归因的解释或指标。