跳到主要內容

Vercel Workflows:用 "use workflow" 和 "use step" 把 Durable Execution 寫進應用程式碼——100M 次 workflow run 後 GA

來源Vercel Blog

你在生產環境跑一個需要多個步驟的長時間任務——比如「用戶註冊後建立網站」:先抓用戶資料、再生成計劃、再建構站台。傳統做法是:Queue + Worker + Status DB + Retry Logic + 獨立的 Orchestrator 服務。五個基礎設施元件,各自有自己的 codebase 和維護成本。

Vercel Workflows 的答案是:全部消滅,直接寫在應用程式碼裡。


兩個 Directive,取代一整套 Infra

export async function createSite(input: { userId: string }) {
  "use workflow"
  const profile = await fetchUserProfile(input.userId)
  const plan = await generateSitePlan(profile)
  const site = await buildSite(plan)
  return site
}

async function fetchUserProfile(userId: string) {
  "use step"
  return db.user.findUnique({ where: { id: userId } })
}

"use workflow" 標記一個函數為持久化工作流程的入口點。"use step" 標記每個工作單元。其餘的——state persistence、retry、encryption、event log——全部自動處理。

Loading diagram...

每個 step 是獨立的 function invocation。失敗就只重試那個 step,不是整個 workflow。


底層架構:三個元件

Event Log(事件日誌):每個 step 的輸入、輸出、stream chunk、sleep、hook、錯誤都被記錄下來。這是整個執行狀態的唯一真相來源,讓 workflow 可以在任意點中斷後精確恢復。

Fluid Compute:每個 step 作為獨立的 function invocation 執行。平台負責出列(dequeueing)、載入 state、解密、以及執行完成後的 handoff。你不需要管 worker 的生命週期。

Vercel Queues:自動為下一個 step 排隊。可以跑在 Vercel managed、self-hosted Postgres、或本地記憶體——本地開發和生產環境行為一致。


Pause/Resume:無資源消耗的等待

這是 durable execution 最關鍵的特性,也是傳統方式最難做好的地方。

Workflows 提供兩種暫停機制:

sleep:時間型延遲,不佔用任何 compute。

await workflow.sleep("24 hours")

hook:等待外部事件觸發繼續執行。

const approval = await workflow.hook("payment-confirmed")

workflow 在暫停期間不跑任何東西、不計費、不需要 keep-alive 邏輯。恢復的時候從中斷點繼續,event log 提供所有之前執行的 context。


AI Agent 整合:Durable Streaming

對 AI agent 工作流程來說,Workflows 解決了一個具體問題:用戶斷線後 agent 繼續跑,重連後從斷點看到完整結果

export async function bookingAgent(messages: UIMessage[]) {
  "use workflow";
  const writable = getWritable<UIMessageChunk>();
  const agent = new DurableAgent({
    model: "anthropic/claude-haiku-4.5",
    system: "You are a flight booking assistant.",
    tools: { searchFlights },
  });
  await agent.stream({ messages, writable });
}

DurableAgent 內建 Workflows primitives,stream chunk 也進 event log。客戶端斷線重連,可以從最後一個 chunk 繼續接收,而不是重跑整個 agent。


Beta 期間的數字

Vercel Workflows Beta 規模(單位:百萬)

  • 1 億次 workflow run 處理
  • 5 億次 step 執行
  • 1,500 家以上客戶使用
  • 每週 20 萬次 npm 下載
  • 75 個版本在 beta 期間發布

Mux 用它做影片 AI pipeline,Durable 公司用 160 個 workflow directive 管理 5000 萬個網站,Flora 用它協調 50 個以上的影像生成模型。


和傳統 Orchestration 的差別

面向傳統方式Vercel Workflows
工作流定義位置獨立 orchestration 服務應用程式碼
基礎設施元件Queue + Worker + Status DB + Retry + Orchestrator無需管理
本地開發難以重現生產環境行為完全一致
加密需要自己實作預設全自動
計費worker 持續跑、持續計費只對實際 compute 計費
可觀測性需要另外接工具Event log 內建

Python SDK 與 Workflows 5

Python SDK 現在進入 beta,語法和 TypeScript 版本完全對稱:

@wf.workflow
async def create_site(*, user_id):
    profile = await fetch_user_profile(user_id)
    plan = await generate_site_plan(profile)
    return await build_site(plan)

@wf.step
async def fetch_user_profile(*, user_id):
    return await db.user.find_unique(id=user_id)

Workflows 5 的 roadmap 包含:native concurrency controls 和 lock primitives、全球分散式基礎設施、以及 snapshot-based runtime 減少 replay overhead。


值得說的事

Workflows 的核心賭注是:orchestration 邏輯應該和應用邏輯住在同一個地方。這個判斷對一定規模以下的團隊(Durable 的六人工程團隊管理 5000 萬個網站是個具體案例)是有說服力的。

但這個模型有一個隱性前提:你的 stack 在 Vercel 生態圈裡,或者願意用他們的 SDK。雖然有 self-hosted 和 community 的 World 實作,但核心優勢(managed encryption、Fluid Compute、Vercel Queues 的無縫整合)還是綁定在 Vercel 平台上。

如果你已經在 Vercel 上跑 Next.js 或其他框架,"use workflow""use step" 是一個很低門檻的方式來做原本需要另外搭一整套基礎設施才能做的事。