Workflow SDK：免Temporal部署，改代码不炸，告别Airflow画图！
内容提要
Vercel推出Workflow SDK，用TypeScript和普通代码实现持久化工作流，无需部署Temporal等复杂基础设施。它通过“use workflow”和“use step”指令自动拆分代码，用数据库作为编排引擎，解决版本固定和步骤开销问题。已处理超1亿次运行，获2200星，简化了异步应用和AI代理的开发。
延伸解读
从画图到写代码：工作流引擎的范式转变
Airflow要求开发者用DAG图描述任务依赖，业务逻辑被埋在节点里，关注点从“做什么”变成“怎么连”。Workflow SDK则主张用普通TypeScript代码表达控制流，代码本身就是DAG，无需额外画图。这种转变降低了认知负担，让开发者更专注于业务逻辑本身。
Temporal的痛点：部署复杂与版本噩梦
Temporal虽解决了画图问题，但自托管需部署多个服务并管理Kubernetes集群，连Datadog都遭遇过严重事故。更棘手的是，修改代码可能导致运行中的工作流因非确定性错误崩溃，官方Patching API让代码长满版本分支，且Worker版本控制直到2025年9月才预览。这些痛点促使开发者寻求更简单的方案。
版本固定：Workflow SDK的独特解法
Workflow SDK不要求开发者写版本分支，而是将每个运行固定在其启动时的部署版本上，新代码不影响旧运行。这避免了非确定性错误，但官方Postgres版本尚未实现该机制，社区已有实现。这种设计将版本管理复杂度从每个开发者转移到基础设施提供者，集中解决。
步骤开销：理想与现实的差距
Workflow SDK的目标是让步骤调用像函数调用一样免费，但当前每次步骤仍涉及网络请求和队列往返。v5版本性能提升最高5倍，Nitro v3集成降低延迟约40%，但团队承认v6将进一步优化，且当前优化主要针对特定后端。通用方案仍在路上，开发者仍需权衡步骤颗粒度。
Q&A
Workflow SDK是什么？它主要解决什么问题？
Workflow SDK是Vercel推出的开源TypeScript SDK，旨在简化异步JavaScript代码的持久性、可靠性和可观测性，让开发者能用普通代码构建可暂停、恢复并维护状态的应用和AI代理，避免传统方案如消息队列、Kubernetes或Temporal的复杂性。
Workflow SDK与Temporal在部署上有什么不同？
Temporal需要部署Frontend、History、Matching、Worker等多个服务以及数据库，并需管理Kubernetes集群和mTLS加密，部署复杂。而Workflow SDK没有自己的编排服务器，后端可替换（如Postgres、Cassandra等），所有工作流逻辑运行在开源客户端库中，部署更简单。
Workflow SDK如何解决版本固定问题？
Workflow SDK通过将每个运行固定在其启动时的具体部署版本来解决版本问题。修改代码后，新运行使用新代码，旧运行继续使用旧代码，避免了旧运行撞上新代码的情况。这不同于Temporal的Patching API，后者需要开发者手动添加版本分支。
Workflow SDK中的'use workflow'和'use step'指令有什么作用？
'use workflow'标记一个异步函数为工作流，'use step'标记需要外部调用的步骤。编译器读取这两个指令，自动将代码拆分为工作流和步骤两个bundle，使控制流成为DAG，无需额外配置。
Workflow SDK的性能表现如何？
Workflow SDK v5版本实现了最高5倍的性能提升，API无变化；Nitro v3原生集成使步骤间延迟降低约40%；zstd压缩加速大payload的存储和读写。但性能优化目前主要针对特定后端，通用方案仍在开发中。
Workflow SDK的采用情况如何？
Workflow SDK的GitHub仓库已超过2200颗星，有504个发布版本，被470个项目依赖。自2025年10月发布beta以来，处理了超过1亿次运行和超过5亿个步骤，覆盖超过1500家客户，每周npm下载量超过20万次。
Workflow SDK的后端可替换性体现在哪些方面？
Workflow SDK的后端是可替换的，持久化层可以使用Postgres、Cassandra、文件系统、Turso、Durable Objects等，队列可以使用Vercel Queues、SQS、Cloudflare Queues。所有组件通过统一的World接口交互，甚至Vercel托管后端也只是一个CRUD API。
