Workflow SDK 与 Nitro v3：持久化后端正在进入应用运行时

Tech

需要等待、恢复或重试的后端流程通常会引入队列、worker、状态表和监控。Workflow SDK 的 Nitro v3 集成把这种持久化执行模型拉回到应用代码附近。

Nitro v3 应用中 API route 启动 Workflow SDK，并连接 use workflow、use step、Nitro storage、retry 和 observability 的架构图
Nitro v3 集成让 workflow step 更接近应用运行时，而不是单独的 worker bundle。

发生了什么

Vercel 在 2026 年 6 月 13 日宣布 Workflow SDK 的 Nitro v3 原生集成进入 beta。step 在与应用相同的 bundled runtime 中运行，workflow route 会成为 Nitro build 的一部分，useStorage 等 server-side API 可以在 "use step" 函数中直接使用。

为什么重要

对 Nuxt/Nitro 团队来说，这改变了长时间后端任务的位置。API route 可以启动 workflow，"use workflow" 负责编排，step 负责可重试的业务副作用。团队可以先在应用运行时附近建模，再决定是否拆出独立 worker。

社区信号

真正的重点是运维边界：外部写入需要 idempotency key，错误要区分 FatalError 与 RetryableError，运行中的 run 会固定在启动它的 deployment 上，观测性要从第一天开始设计。

对开发和运维的影响

采用路径应当循序渐进。先从 onboarding email、报表生成、延迟通知、需要人工确认的 AI agent flow 等可观测、可回滚的流程开始。支付、库存、账号删除等不可逆流程，应在 rollback step、幂等键和 runbook 都稳定后再迁移。

实用检查清单

• Classify candidates into work that should finish inside a request, work that needs a queue, and work that needs human intervention.

• Keep the input and output shapes of `"use workflow"` and `"use step"` functions backward-compatible across deployments.

• Attach stable idempotency keys, preferably based on stepId, to payments, emails, external writes, and queue publishes.

• Separate non-retryable validation failures with FatalError and handle rate limits or transient outages with RetryableError plus retryAfter.

• Document how in-flight runs stay pinned to deployments and how affected runs are cancelled or rerun after a fix.

• When steps use Nitro useStorage, server APIs, or route handlers directly, test local and production backend differences.

• Verify that runId, stepId, input class, retry count, failure code, latency, and cost are visible in the CLI or Web UI.

风险与反方观点

该集成仍处于 beta，并不意味着所有 job 都应该改写成 workflow。短缓存刷新或简单 webhook 转发，可能仍然适合普通 request/response 或小型队列。同一 runtime 的便利性不应模糊可重试代码与绝不能重复执行代码之间的边界。

来源

다른 글