AI SDK v0.0.92 更新：统一版本线与推理控制优化

AI SDK 发布了 v0.0.92 版本，这次更新围绕版本管理统一化、推理（reasoning）控制逻辑修复以及模型目录刷新展开，解决了多个在实际集成中容易踩坑的问题。对于使用 Cline 生态以及接入多家大模型提供商的开发者而言，这次升级值得关注。

版本线统一：告别逐包升级

此次更新最重要的工程层面变化，是整个 AI SDK 转向统一发布线。核心包 ai 升级至 7.0.120，所有 @ai-sdk/* 系列包统一基于 @ai-sdk/provider-utils 5.0.50。

在此之前的做法是 ai 停留在 7.0.79，而各个附属包逐个单独升级（bumped one by one）。这种分散的版本管理方式容易导致依赖版本错配、兼容性难以追踪。统一到同一发布线后，开发者在管理依赖时可以更明确地对齐版本，减少因版本碎片化带来的集成问题。

这类看似琐碎的工程改进，实际上是 SDK 走向成熟的信号——当生态包数量增多时，版本协调一致比单个功能更新更能降低长期维护成本。

推理开关逻辑修复：按模型能力区分

这次更新中对开发者影响最直接的，是关闭推理（reasoning）功能时的行为修正。

OpenAI 模型的处理

之前关闭推理时，SDK 会向所有 OpenAI 模型发送 reasoning.effort: "none"。但部分模型并不支持关闭推理，例如 GPT-6 Astra 和 GPT-6.1 Sol，它们会直接返回 400 错误（原文举例是在提交信息生成场景中触发）。更新后，SDK 不再向这些无法关闭推理的模型发送该参数，而 GPT-5.x 以及 GPT-6 Sol/Luna 仍会正常收到 "none"。

Claude 模型的处理

类似的问题也出现在 Claude 模型上。此前关闭推理会发送 thinking: {type: "disabled"}，但 Claude Fable 5 和 Opus 5.5 等模型并不支持关闭 thinking，会返回报错 "thinking.type.disabled" is not supported for this model。现在 SDK 对这类模型不再发送 disabled 参数，而其他支持的 Claude 模型依然保留 disabled 行为。

这两处修复的共同逻辑是：根据模型的实际能力差异化下发参数，而不是一刀切。随着各家厂商模型能力矩阵越来越复杂，SDK 层面做这种能力感知的适配，能显著减少开发者遇到的意外 400 错误。

这里所说的「推理（reasoning）」，指的是大模型在生成最终答案之前先进行内部思维链推演的能力，有时也称为「扩展思考（extended thinking）」。OpenAI 通过 reasoning.effort 参数控制推理投入程度（low / medium / high / none），Anthropic 则通过 thinking 字段开关该行为。开启推理通常会显著提升模型在数学、代码、逻辑等复杂任务上的准确率，但代价是更高的延迟和 token 消耗。对于代码补全、提交信息生成等轻量高频场景，开发者往往希望关闭推理以换取更快的响应速度，这也是 SDK 需要正确传递「关闭推理」信号的实际动机所在。

稳定性与崩溃防护

除了功能逻辑，v0.0.92 还修复了几处可能导致进程崩溃的隐患。

Stdio MCP 客户端现在能正确处理 EPIPE 错误——当服务端在读完全部输入前就退出时，之前会在宿主进程上抛出未捕获异常，现在得到了妥善处理。

SAP AI Core provider 也不再安装 winston 的全局 uncaughtException 处理器。该处理器此前会在任何未捕获错误发生三秒后调用 process.exit(1)，这种全局副作用对宿主应用是相当危险的，移除后避免了意外的进程退出。

此外，旧版 provider-settings 迁移逻辑不再向 providers.json 写入空的 sapaicore 条目。此前由于扩展默认写入 sapAiCoreUseOrchestrationMode，导致每个迁移用户都被添加了这一冗余条目。

MCP（Model Context Protocol）是 Anthropic 主导推出的一套标准协议，用于统一 AI 模型与外部工具、数据源之间的通信接口。Stdio 传输模式是 MCP 的一种运行方式，客户端通过标准输入/输出流与 MCP Server 子进程通信。EPIPE 错误发生于向已关闭的管道写入数据时——典型场景是 Server 子进程意外退出，而客户端仍在尝试写入，此时操作系统会向写入方发送 SIGPIPE 信号或返回 EPIPE 错误码。在 Node.js 中，若未对该错误进行捕获，会导致宿主进程抛出未捕获异常，进而可能使整个应用崩溃。这次修复使 SDK 能够优雅地处理此类边界情况，而不是将错误上抛给调用方。

模型目录刷新与默认模型变更

v0.0.92 刷新了模型目录，新增了 Claude Haiku 5.5。多个提供商的默认模型随之调整，整体趋势是转向 Claude Haiku 5.5。

受影响的提供商包括 Google Vertex AI（从 Claude Sonnet 5.5 改为 Claude Haiku 5.5）、Cortecs、DevPass（LLM Gateway）、Eden AI、GitHub Copilot、LLM Gateway、NanoGPT、OpenCode Go、Requesty 以及 Vivgrid，多数默认切换到了 Claude Haiku 5.5。

默认模型集体转向 Haiku 这类更轻量快速的模型，往往反映了在成本与响应速度之间寻求平衡的取向——对于代码补全、提交信息生成等高频轻量任务，更快更省的模型通常体验更佳。

同时，@cline/core 新导出了 parseMcpHeaders，供 CLI 的 mcp add 向导使用，用于保留 --header 的值。

小结

这是一次典型的工程打磨型更新：没有爆点功能，但统一版本线、按模型能力区分推理参数、修复多处崩溃隐患，都是直接关乎稳定性与可维护性的改进。对于深度使用 AI SDK 对接多家模型提供商的开发者，升级到 v0.0.92 能减少不少踩坑成本。