Workflow SDK 與 Nitro v3：耐久型後端正在進入應用程式 runtime

Tech

需要等待、恢復或重試的後端流程，常會帶來 queue、worker、狀態表與監控。Workflow SDK 的 Nitro v3 整合讓這種 durable execution 更靠近應用程式碼。

Nitro v3 應用中 API route 啟動 Workflow SDK，並連到 use workflow、use step、Nitro storage、retry 與 observability 的架構圖
Nitro v3 整合讓 workflow step 更接近應用程式 runtime，而不是分離的 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 負責可重試的業務 side effect。團隊可以先在應用程式 runtime 附近設計，再決定是否拆成 worker 服務。

社群訊號

重點仍是維運邊界：外部寫入需要 idempotency key，錯誤要分成 FatalError 與 RetryableError，執行中的 run 會固定在啟動它的 deployment，而 observability 必須一開始就納入。

對開發與維運的影響

導入路徑應該循序漸進。先從 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 forwarding，可能仍適合一般 request/response 或小型 queue。同一 runtime 的便利性，不應模糊可重試程式碼與絕不能重複執行程式碼之間的邊界。

來源

다른 글