AI SDK Workflow 2.0.70 发布：修复流式重连与终端响应丢失问题

Vercel 旗下的 AI SDK 生态又迎来了一次小版本迭代。@ai-sdk/workflow 发布 2.0.70 版本，这是一个以补丁修复为主的更新，但其中几处针对流式传输和 Agent 工作流的修复，对正在构建生产级 AI 应用的开发者而言值得关注。

修复的核心问题一览

本次发布包含 3 个 commit 和一系列依赖更新。从 Changelog 来看，修复集中在 WorkflowChatTransport、流式终端响应保留、无输出流的错误上报，以及工具调用校验的错误信息可读性上。这些都是 AI 应用在实际运行中容易踩到、却不容易定位的"隐性问题"。

WorkflowChatTransport 重连不再无限重试

最说个细节 WorkflowChatTransport 的重试逻辑修复。此前的问题是：当重连请求成功返回、但响应中不包含任何 UI message chunk 时，传输层会陷入无限重试。

修复方案是让空流也计入 maxConsecutiveErrors——也就是说，即便 HTTP 层面是"成功"的，只要没有实际内容送达，就会按错误累加。而接收到真实 chunk 的流则会继续推进 resume cursor，并重置错误计数。

这个改动看似细微，实则解决了一个典型的"假成功"陷阱：连接不断建立、却始终拿不到数据，客户端在后台持续打转。对于依赖长连接恢复的对话式应用，这种修复能直接避免资源空耗和用户体验上的"卡死"。

什么是 UI message chunk 与 resume cursor？ UI message chunk 是 AI SDK 在流式对话中向前端逐块推送的最小数据单元，每个 chunk 通常对应一段增量文本、一次工具调用事件或一个元数据片段。客户端通过消费这些 chunk 来实时渲染对话。而 resume cursor 是断线重连机制中的位置标记，记录着上一次成功接收到的数据点，重连时服务端依据它从断点继续推送，避免重复或遗漏。

两者的关系是关键：只有当客户端真正收到了有效的 UI message chunk，resume cursor 才会向前推进。如果连接建立了却没有任何 chunk 送达，cursor 就停在原地，重试请求会反复落到同一个断点位置，形成看似在恢复、实则无进展的死循环。理解这一点，就能明白为何本次修复要把“空流”与真正的错误同等对待——它本质上是在防止 cursor 无法推进时空耗重试预算。

终端助手响应不再从会话中消失

另一处修复针对流式终端助手响应在会话消息中的保留问题（commit 7400215）。流式输出结束后，终端的 assistant 回复此前可能会从 conversation messages 中丢失，导致会话历史不完整。

对于需要回放会话、做审计或继续多轮对话的产品来说，历史消息的完整性是基础要求。这条修复保证了流式终止后消息仍被正确保留。

无输出模型流与工具校验的错误可读性

本次还修复了"不完整且无输出的模型流"被错误处理的问题，现在这类情况会明确上报为错误（commit 9aef724）。空响应不再被静默吞掉，有助于开发者及时发现上游模型或网络异常。

工具调用的输入校验错误也做了改进（commit 507cd9d），错误信息中将包含可执行的细节，而不是笼统的失败提示。这对调试 Agent 工具链时的排查效率有明显帮助。

流式响应中的“不完整流”与“无输出流”是两种不同的异常形态。 不完整流指流式传输中途被截断，可能已经送达了部分 chunk，但缺少正常的结束信号；无输出流则更彻底——整个流从始至终没有产生任何有效数据。两者在过去都可能被静默处理，导致上层拿不到内容却不报错。显式上报为错误后，开发者可以在日志和监控中直接定位是上游模型返回异常、还是网络在传输过程中断开，而不必靠猜。

工具输入校验错误同样值得展开：Agent 调用工具时，模型的输出需先经过 schema 校验，只有符合工具参数定义才会被执行。校验失败时，过去往往只返回一句笼统的“invalid input”，排查时无法知道是哪个字段、哪条约束不满足。改动后错误信息会携带具体字段路径与期望类型等可执行细节，这对多工具、多参数的复杂 Agent 链路尤为重要。

Agent 遥测与工具结果的边界修复

还有两处与 Agent 运行时相关的修复：一是将 WorkflowAgent 的模型调用遥测派发到全局注册的集成，从模型步骤触发（commit a155baa）；二是保留了 provider 执行的工具结果，以及因长度结束而中断的本地工具调用错误结果（commit 7c0410d）。

前者让遥测数据的采集路径更准确，后者则避免了工具执行结果在特殊终止条件下丢失。对于使用内置或第三方可观测性集成的团队，这些修复能让追踪数据更贴近真实执行链路。

Agent 遥测（telemetry） 指的是运行时采集的模型调用轨迹数据，包括耗时、token 用量、工具调用序列、错误分布等，通常通过 OpenTelemetry 一类框架导出到可观测性平台。本次将 WorkflowAgent 的遥测派发点从原先的位置调整到“模型步骤触发”，意味着每次模型真正发起调用时都会向全局注册的集成上报，而非仅在更高层的 workflow 阶段汇总。这能让追踪数据更细粒度地反映每一步的实际执行情况，避免因调度层聚合而丢失中间步骤的细节。

provider 执行的工具结果则指由模型服务商侧（而非本地）直接完成的工具调用返回，例如某些 provider 内置的 web 搜索或代码执行。这类结果与本地工具调用的错误结果在特殊终止条件下容易被丢弃——比如因输出长度达到上限而中断时。修复后这些结果会被保留，保证追踪记录和会话状态都不会因为非正常结束而缺失关键片段。

依赖同步更新

版本同时更新了若干依赖，包括 ai@7.0.138、@ai-sdk/provider-utils@5.0.59、@ai-sdk/provider@4.0.27 等。这类依赖升级通常是配合上述修复的底层能力对齐，升级时建议一并核对版本兼容性。

小结

@ai-sdk/workflow@2.0.70 不是一次功能发布，而是一轮针对稳定性的集中修补。重连空流的错误计数、终端响应的会话保留、无输出流的显式报错——这些修复都指向同一个方向：让流式 AI 工作流在异常边界下的行为更可预期、更可观测。对正在用 AI SDK 构建生产应用的团队来说，这个补丁值得尽快跟进。