Workflow SDK：免Temporal部署，改代码不炸，告别Airflow画图！
内容提要
Vercel推出Workflow SDK，旨在简化异步代码的持久化与可靠性，避免传统方案如Temporal的复杂部署和版本管理问题。它利用普通TypeScript代码作为工作流引擎，无需额外服务器，支持可替换后端，并固定版本确保安全更新。虽性能提升显著，但通用方案仍在完善中。
延伸解读
从画图到写代码：工作流引擎的范式转变
Airflow 要求开发者用 DAG 图描述任务依赖，业务逻辑被埋在节点里，开发者被迫关注“怎么连”而非“做什么”。Temporal 虽然用代码控制流替代了画图，但引入了复杂的部署和版本管理问题。Workflow SDK 则主张编程语言本身就是工作流引擎，用普通 TypeScript 代码和两个指令（use workflow、use step）即可实现持久化，无需额外服务器或 DSL。
版本管理的另一种思路：固定而非补丁
Temporal 通过 Patching API 和 GetVersion 处理代码变更，但会导致代码充满版本分支，且 Worker 版本控制直到 2025 年 9 月才预览，滚动部署时旧工作流可能撞上新代码。Workflow SDK 则让每个运行固定在其启动时的部署版本，新运行用新代码，旧运行继续用旧代码，避免了非确定性错误。这种设计将版本管理的复杂度从开发者转移到了基础设施提供者。
性能与通用性的权衡：当前局限
Workflow SDK 宣称后端可替换，但 v5 的性能提升（最高 5 倍）主要针对特定后端，官方 Postgres 版本尚未实现版本固定机制，社区实现存在不确定性。步骤调用仍有网络和队列开销，离“完全免费”还有距离。团队承认 v6 会进一步推进并让第三方世界同样快，说明通用方案仍在完善中。
Q&A
Workflow SDK是什么？它主要解决什么问题？
Workflow SDK是Vercel推出的开源TypeScript SDK，旨在简化异步JavaScript代码的持久性、可靠性和可观测性，让开发者能用普通代码构建可暂停、恢复并维护状态的应用和AI代理，避免传统方案如Temporal的复杂部署和版本管理问题。
Workflow SDK与Temporal在部署上有什么不同？
Temporal需要部署Frontend、History、Matching、Worker等多个服务，还要配置数据库和Kubernetes集群，部署复杂；而Workflow SDK没有自己的编排服务器，后端可替换，可以用Postgres、Cassandra等作为持久化层，所有工作流逻辑跑在开源客户端库中，部署更简单。
Workflow SDK如何解决版本更新导致的工作流崩溃问题？
Workflow SDK采用版本固定机制，每个运行都固定在其启动时的具体部署版本上，新代码用于新运行，旧运行继续使用旧代码，避免了旧工作流撞上新代码导致的非确定性错误，无需像Temporal那样写版本补丁。
Workflow SDK的核心设计理念是什么？
核心理念是“编程语言本身就是最好的工作流引擎”，开发者用普通的async/await代码编写工作流，通过'use workflow'和'use step'标记，编译器自动拆分，无需YAML、DSL或额外状态机，控制流即DAG。
Workflow SDK的性能表现如何？
v5版本实现了最高5倍的性能提升，API无变化；Nitro v3原生集成使步骤间延迟降低约40%；zstd压缩加快大payload的存储和读写。但性能优化目前主要针对特定后端，通用方案仍在完善中。
Workflow SDK的版本固定机制在Vercel上如何实现？
在Vercel上，由于Vercel长期保留不可变的部署产物，每个运行固定在其启动时的部署版本上，新代码用于新运行，旧运行继续用旧代码，从而避免版本冲突。官方Postgres版本尚未实现该机制，但社区已有实现。
Workflow SDK与传统工作流引擎（如Airflow）在编写方式上有何不同？
Airflow要求用Python文件描述任务依赖图，业务逻辑埋在节点中；Workflow SDK则直接用普通TypeScript代码编写，控制流即DAG，无需画图，代码怎么写流程就怎么跑。
Workflow SDK的步骤调用开销如何？
目前每次步骤调用涉及网络请求和队列往返，开销在正确性上必要，但破坏了“分布式计算像函数调用”的承诺。团队正努力降低开销，理想状态是让步骤调用像函数调用一样免费，但尚未完全实现。
