Vercel AI SDK Workflow 2.0.59：引入非流式 generate 能力

Vercel AI SDK 的 Workflow 模块发布了 2.0.59 补丁版本（@ai-sdk/workflow@2.0.59），虽然版本号只是一次 patch 更新，但其中包含了一项对工作流代理（WorkflowAgent）颇为关键的能力补充——支持非流式（non-streaming）的持久化生成。对于正在用 AI SDK 构建多步骤 Agent 的开发者来说，这次更新值得关注。

核心更新：durable 非流式 generate()

本次版本最重要的改动是为 WorkflowAgent 新增了 generate() 方法（提交 0ca1ab9）。此前 Workflow 主要围绕流式（streaming）场景设计，而新加入的 generate() 提供了一条不依赖流式输出的持久化执行路径。

其设计细节包括：

• 共享工具循环（shared tool loop）：复用底层核心逻辑处理工具调用，避免流式与非流式两套实现分叉。
• 默认 20 步上限：为多步骤工具调用设置了合理的默认执行边界，防止 Agent 陷入无限循环。
• 类型化输出（typed output）：延续了 AI SDK 一贯的类型安全设计，让生成结果可被静态推断。
• 复用核心结果构造：通过内部导出复用核心结果与内容构造逻辑，同时保持既有的 Workflow 流式行为不受影响。

换句话说，开发者现在可以在不需要逐 token 流式返回的场景下（如后台批处理、定时任务、不面向交互式 UI 的 Agent 任务）直接调用 generate() 拿到完整结果，而不必额外处理流。

持久化（durable）执行是 AI 工作流中的一个重要概念，指工作流的执行状态可以被序列化保存，在中断或失败后从断点恢复，而不必从头重跑。这与普通的无状态函数调用根本不同——持久化执行能跨越进程重启、服务器宕机或长时间等待（如等待人工审批）。Vercel AI SDK 的 Workflow 模块基于 Durable Execution 思想构建，因此 generate() 方法中的"durable"并不只是意味着"同步返回完整结果"，还意味着其执行过程可以被编排引擎追踪、挂起与恢复。相比之下，流式（streaming）模式下逐 token 的输出天然是短暂且难以持久化的，这正是非流式 generate() 在批处理与后台 Agent 场景下不可替代的原因。

工具审批与流式解耦

另一组值得留意的改动围绕工具审批（tool approval）机制展开。提交 57dadb5 将工具审批请求的创建从流式逻辑中独立出来，使得 WorkflowAgent.generate 以及没有可写流（writable）的 stream 都能够恢复（resume）已被批准的调用。

这意味着审批流程不再与是否存在流式输出绑定——即便是非流式执行，也能完整支持“工具调用需人工/外部批准”这一人机协作模式。同时该版本保留了 provider 层面的审批请求，并原样转发审批响应，而不会在本地执行 provider 工具，保证了审批语义的一致性。

不过官方也说明，传输无关（transport-independent）的审批创建仍属于后续工作，当前版本只是迈出了解耦的第一步。

**工具审批（tool approval）**是 Human-in-the-Loop（人机协作）模式的核心机制：当 Agent 准备调用某个敏感或高风险工具时，执行流程会暂停，等待人工或外部系统确认后才继续。这一模式在自动化程度较高的 Agent 系统中尤为重要，例如执行数据库写入、发送通知或调用付费 API 等操作前需要审批。此前工具审批的实现与流式输出深度耦合，意味着只有在有活跃流连接的情况下才能触发和恢复审批，这限制了批处理和异步场景的使用。将审批创建从流式逻辑中解耦后，审批请求可以在没有 WebSocket 或 SSE 连接的环境中独立存储与恢复，为构建更健壮的异步审批流程奠定了基础。

工作流恢复的边界约定

提交 a471b4c 对 WorkflowAgent 的多个运行时行为进行了文档化和校验，涵盖：

• 生成的截止期限（generation deadlines）
• 重试边界（retry boundaries）
• Hook 取消（hook cancellation）
• 工作流恢复（resumption）过程中选定结果的序列化

这些约定对于构建可靠的持久化工作流至关重要。持久化工作流的难点往往在于“中断后如何正确恢复”，明确截止期限、重试与序列化行为，能减少跨恢复周期的状态不一致问题。

**截止期限（deadline）与重试边界（retry boundary）**是分布式任务调度中的两个关键概念。截止期限规定了一次生成任务允许运行的最长时间，超时后系统可以将其标记为失败或触发告警，避免僵尸任务永久占用资源。重试边界则定义了失败后自动重试的范围与次数上限，以及哪些错误类型是可重试的（如网络超时）、哪些是不可重试的（如鉴权失败）。在持久化工作流中，这两项约定尤其重要：若不明确重试范围，一次部分成功的多步骤 Agent 任务可能在恢复时重复执行已完成的步骤，产生副作用；而序列化行为的规范则确保中间状态在跨进程传递时保持一致，是正确恢复的前提。

若干稳定性修复

除了功能性增强，本次补丁还修复了几个会影响对话一致性的问题：

• 69ea843：保留受长度限制的 assistant 响应，确保它们仍留在对话消息中，避免被意外丢弃。
• c89c76c：在 assistant 文本消息上保留 provider 元数据（provider metadata），防止上下游信息丢失。
• 6accb1c：重构了 WorkflowAgent 的调用准备、模型调用结果与执行收尾逻辑，为非流式生成铺路，同时保持流式行为不变。

这几项修复看似细碎，但对于长对话、多轮工具调用的 Agent 而言，消息完整性与元数据保留直接关系到后续推理的准确性。

依赖同步升级

作为 monorepo 中的一个包，本次发布同时同步升级了多个底层依赖：

• ai@7.0.128
• @ai-sdk/provider@4.0.22
• @ai-sdk/provider-utils@5.0.54

使用 Workflow 模块的项目在升级时需要留意这些关联依赖的版本协同，建议整体对齐以避免潜在的兼容性问题。

小结

从更新内容看，@ai-sdk/workflow@2.0.59 并非大版本跃迁，但它补齐了 Workflow 在非流式场景下的一块重要拼图：generate() 方法 + 与流式解耦的工具审批 + 明确的恢复语义。对于希望用 AI SDK 构建既能流式交互、又能在后台可靠批处理的 Agent 的团队，这次更新降低了实现门槛。感兴趣的开发者可以在 Vercel AI 仓库的 release 页面查看完整变更记录与提交哈希。