Workflow SDK 5.2.0 默认走 WebSocket，流式响应提速4.2倍

从 HTTP 到 WebSocket：一次无需改代码的底层升级

Vercel 的 Workflow SDK 在 5.2.0 版本中把事件写入和流写入默认切换到了 WebSocket 通道。此前每一次写入——无论是单个事件还是流式数据的一个分组——都要占用一次独立的 HTTP 请求。升级之后，这些写入都复用同一条 WebSocket 连接，开发者不需要改动任何业务代码，只需把依赖升到 workflow@5.2.0 或更高版本即可。

Workflow SDK 更新公告

这条变更看似只是传输层的小调整，实际触及的是工作流引擎在 AI 场景下的核心瓶颈：当一次运行包含大量步骤或持续输出 token 时，HTTP 请求的数量会随写入次数线性增长，而 WebSocket 把它压成了常数级连接。

WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议，通过 HTTP 升级握手建立，之后客户端与服务器可以随时互相推送数据帧，而无需像 HTTP 那样每次通信都携带完整的请求头和响应头。对于高频、小粒度、持续性的写入场景，WebSocket 消除了反复建立连接和头部开销的成本，把 N 次请求压缩为 1 条连接上的 N 个帧。这也是它在实时聊天、协同编辑、金融行情和 AI token 流式输出中被广泛采用的原因。

值得注意的是，WebSocket 并非在所有场景都优于 HTTP。它需要维护连接状态，对负载均衡、代理和超时策略都有额外要求；当写入频率很低时，HTTP 的简单性和无状态特性反而更易运维。文章所讨论的改动之所以成立，前提正是工作流的事件写入和流式输出属于典型的高频写入模式。

流式场景的收益最直接

官方给出的 benchmark 用一个 AI agent 的 token 流做回放测试：v5.2.0 交付完整响应的速度比 v4.8.12 快了 4.2 倍，且没有任何一个 chunk 的延迟超过一秒。这个数字对做 AI 流式输出的团队来说意义明确——用户看到首字到末字之间的等待被显著压缩，长回答不再出现"前面很快、后面卡顿"的割裂感。

从代码层面看，现有的流式写法完全兼容。getWritable() 拿到的 writer 依然是逐块写入，"use step" 和 "use workflow" 的语义没有变化，SDK 会在 WebSocket 打开后把这一串 chunk 批量送出去。也就是说，升级前写好的 token 流代码，升级后自动获得更快的传输路径。

import { getWritable } from "workflow";

async function streamChunks(chunks: string[]) {
  "use step";
  const writer = getWritable<string>().getWriter();
  for (const chunk of chunks) {
    await writer.write(chunk);
  }
  writer.releaseLock();
}

export async function streamingWorkflow(chunks: string[]) {
  "use workflow";
  await streamChunks(chunks);
}

在 Workflow SDK 中，getWritable() 返回一个可写流，调用 getWriter() 后通过 write() 逐块追加数据，这与 Web Streams API 的标准用法一致。releaseLock() 用于释放 writer 对流的锁定，使其他消费者可以接管。

"use step" 和 "use workflow" 是 Workflow SDK 的指令标记：前者声明一个函数为可持久化、可重试的工作流步骤，后者声明工作流入口。SDK 会在编译或运行时识别这些指令，将步骤的执行结果记录下来以支持断点续跑。理解这一点有助于明白为什么每次 step 的启动和完成都会产生一次事件写入——这些记录正是工作流可恢复性的基础，而 WebSocket 改造降低的正是记录这些状态的传输成本。

事件写入：步骤越多，省下的请求越多

工作流里每个 step 的启动和完成都是一次事件写入。步骤数量一多，HTTP 请求数就跟着膨胀。切到 WebSocket 后，这些事件在同一条连接上发出，请求数量大幅下降。Vercel 的表述是"提升性能并降低成本"——对按请求计费的部署形态来说，这一条对账单的影响可能比延迟更让团队在意。

需要说明的是连接的生命周期：队列处理器为每一次投递打开连接。这意味着 WebSocket 并非全局长连接池，而是按投递粒度建立和复用，SDK 在内部管理这一层，开发者无需自行处理重连逻辑。

所谓“队列处理器为每一次投递打开连接”，指的是工作流引擎的消息队列在向执行器投递任务时，会为该次投递建立一条 WebSocket 连接并在其生命周期内复用。这与传统意义上进程级或应用级的全局连接池不同：连接的边界由投递单元决定，而非由进程或租户决定。

这种设计的取舍在于：它避免了长连接在空闲期的资源占用和跨部署的复杂性，同时仍能在单次投递内部把多次写入合并到一条连接上。由于连接建立、复用和关闭都由 SDK 内部管理，开发者既不需要处理重连与心跳，也无法直接控制连接池大小；如果对连接行为有特殊需求，需要关注 SDK 后续版本是否暴露相关配置。

升级注意事项

升级本身很简单：

npm install workflow@latest

有一个行为边界需要知道：升级部署后，新启动的运行会走 WebSocket 路径，而升级时已经在途的运行会继续跑在它们启动时所在的那个部署上，不会中途切换传输方式。这对长周期工作流是合理的设计，避免运行中被协议切换打断。

另外，从 4.x 跨到 5.x 是主版本升级，官方建议先阅读升级指南，而不是直接跳到 5.2.0。5.2.0 只是把 WebSocket 写入设为默认，底层的 5.0 变更仍需要按指南逐步处理。

为什么这个改动值得关注

把工作流的写入通道从"每次一个 HTTP 请求"改成"一条 WebSocket"，本质上是在为 AI 工作负载重新设计 I/O 模型。AI agent 的输出天然是连续、细粒度、长时间持续的，这与 HTTP 请求-响应模型并不匹配。Vercel 这次把这一层默认行为改掉，等于承认了流式写入应当是工作流引擎的一等公民，而不是靠开发者自己优化。

对正在用 Workflow SDK 构建 AI 应用的团队，升级到 5.2.0 的成本接近零，收益体现在响应速度和请求开销两端。至于是否要在自建的工作流系统中借鉴同样的思路，取决于你的写入频率——如果一次运行只有寥寥几个 step，HTTP 的简单性依然有优势；一旦进入高频写入或 token 流场景，WebSocket 带来的差距就会迅速拉开。