Inngest 对比 Diagrid Catalyst：企业级 Agent 平台选型

五人的团队通常会选择一套无需操心基础设施的方案，这是正确的选择。但当第一个企业客户问起 Agent 在哪里运行、谁有权授权其工具时，这套方案就开始变得不那么正确了。

在原型阶段，Inngest 很容易理解。你用 TypeScript、Python 或 Go 编写函数，将持久化工作拆分为多个步骤，让平台处理状态、重试、流量控制和可观测性。它目前的持久化 Agent 模型使用步骤级记忆化，因此在回放期间不会重复已完成的 LLM 调用和工具调用。它还可以等待事件并调用子 Agent。

这非常适合将后台任务扩展为更长的 AI 工作流的 Web 团队。Agent 紧邻应用代码运行，不需要运行太多基础设施。

决策改变的时刻

架构对话通常会分阶段转变。

首先你交付功能。一个 TypeScript 工作流调用 LLM，丰富一些数据，然后写入结果。开发者体验决定了成败。

然后你必须应对故障。工具调用需要在正确的步骤恢复。Inngest 和 Catalyst 都通过不同的执行模型来处理这个问题。

接着第二和第三个 Agent 技术栈出现了。一个 Python 团队选择 LangGraph，一个 .NET 团队选择 Microsoft Agent Framework，另一个团队使用 Google ADK。Catalyst 的 bring-your-own-framework 模式开始变得重要，因为平台标准可以位于这些框架选择之下，而不是与它们竞争。

然后你进入企业评审阶段。客户要求工作负载身份、默认拒绝的访问控制、私有部署、MCP 治理，以及每个 Agent 行为的证据。这就是 Catalyst 更广泛的治理模型可以证明运行更大平台合理性的地方。

重试和仪表板是这次比较中最不有趣的部分。我会关注：

• 支持哪些语言和 Agent 框架
• 恢复期间已完成步骤和副作用会发生什么
• 谁来操作 worker、状态和执行平面
• Agent 到工具的访问如何进行认证和授权
• 存在哪些自托管、私有或气隙隔离的拓扑
• 多个团队如何共享一个平台而不共享权限

只要其语言和部署模式适合团队，Inngest 可以继续作为开发者优先的持久化函数、后台任务和 AI 工作流的最佳选择。一旦需求从"让这个函数持久化"扩展到"在整个企业范围内运行和治理多种类型的 Agent"，Catalyst 就更合适了。

两种错误都很常见，而且它们是同一错误指向相反方向的表现：在仍处于第一阶段时就购买了第四阶段的平台，以及在组织已经改变后拒绝重新审视第一阶段的决策。让架构跟随你实际承担的风险。

Diagrid Catalyst 快速入门

Inngest 持久化 Agent