用 Vercel AI SDK 6 和 AI Gateway 构建多模型应用

2025 年 12 月 22 日，Vercel 发布了 AI SDK 6。这次发布不只是版本升级，更接近于重新定义 2026 年 agent 应用的设计方式 — 因为 Agents、ToolLoopAgent、human-in-the-loop tool approval、DevTools、full MCP support、reranking、image editing、带 tool calling 的 stable structured outputs，一次性都整合了进来。

与此同时，AI Gateway 的模型 fallback 文档从运维角度给出了重要提示。网关会先把请求发给 primary model，对该模型应用 provider routing 规则；如果绑定在这个模型上的所有 provider 都失败了，就会尝试 models 数组里的下一个模型。最终响应，来自最先成功的那一组 model 与 provider 组合。

剩下的问题只有一个：2026 年的 AI 应用为什么要把多模型当作默认设计？把 AI SDK 6 和 AI Gateway 结合起来用，到底会带来什么实际变化？

为什么 2026 年多模型会成为默认选项

2026 年的 AI 产品运维，光靠单一模型的优化已经很难撑住。原因很明确。

不同模型的强项不同 — 有的推理能力强，有的响应速度和成本更有优势。
即便是同一个模型，不同 provider 之间也会出现可用性、延迟、rate limit、区域品质的差异。
tool calling、多模态、structured output、长上下文这类功能的支持范围并不完全一致。
在生产环境里，稳定性一旦先于准确率崩掉，整个产品体验都会跟着动摇。

也就是说，2026 年的应用架构，与其说是「找出一个最好的模型」，不如说更接近「按请求类型设计出最合适的模型路径」。多模型策略不是可选项，而是一种可靠性设计。

AI SDK 6 如何改变了 agent 设计

在 AI SDK 5 时代，组合 generateText 和 streamText 自己搭控制流是常见做法。这种方式依然有效，但 AI SDK 6 把 agent 层抬高到了更明确的位置。

这次发布里，特别重要的变化如下。

借助 Agents 和 ToolLoopAgent，可以更一致地设计反复的工具执行循环。
通过 tool execution approval 与 human-in-the-loop approval，可以把有风险的操作改造成基于审批的流程。
新增的 DevTools 让观察工具调用与执行流程变得更容易。
@ai-sdk/mcp 包里的 MCP 支持进入 stable，并且覆盖了 OAuth authentication、resources、prompts、elicitation。
可以在 tool calling 的同时使用 stable structured outputs，让 UI 与后端之间的契约更牢固。
加入了 reranking 和 image editing，让检索型应用和多模态应用的组合选项变多了。

关键在于，重心已经从「调用模型」转移到了「设计 agent 系统」。比起只是把 prompt 写好的团队，能把工具审批边界和模型路由策略设计好的团队，现在更占优势。

多模型应用的基本结构

最实用的起点是下面这套三层结构。

UI 与流式输出由 Next.js Route Handler 或 Server Action 管理。
模型调用的接口层统一用 AI SDK 6。
可用性与路由交给 AI Gateway 处理。

这样划分之后，应用代码里只留下「要做什么」，而运维策略可以逐步转移到网关那一层。

import { streamText } from 'ai';

export async function POST(req: Request) {
  const { prompt } = await req.json();

  const result = streamText({
    model: 'openai/gpt-5.4',
    prompt,
    providerOptions: {
      gateway: {
        order: ['azure', 'openai'],
        models: [
          'anthropic/claude-sonnet-4.6',
          'google/gemini-3-flash',
        ],
      },
    },
  });

  return result.toUIMessageStreamResponse();
}

这个例子的要点很简单。

primary model 放在 model 字段里。
backup model 放在 providerOptions.gateway.models 数组里。
provider 的优先级由 order 控制。

在实际服务中，这套配置不仅对故障应对有效，对成本优化和功能兼容性应对也同样有效。

AI Gateway 的 fallback 与 provider routing 实际是怎么运作的

按 Vercel 文档的说法，运作顺序很明确。

网关首先把请求发给 primary model。
对每个模型应用 provider routing 规则。
如果该模型能用的所有 provider 都失败了，就转到下一个 fallback model。
最先成功的那组 model 与 provider 组合的响应会被返回。

理解了这个顺序，就能把运维策略定得更贴近实际。

好的 fallback 设计示例

主模型：高质量的通用模型
第一层 fallback：更便宜但 tool calling 稳定的模型
第二层 fallback：以响应速度见长的模型

应该避免的设计

把功能特性不同的模型不加区分地塞进同一条链
明明 structured output 的 schema 可能会破，却不做校验就信任响应
把 provider 故障和 model capability mismatch 一概用同一种方式处理

运维上重要的是，「失败了就换一个模型」并不是终点。得先定义清楚哪些功能必须保持不变。比如 tool calling、JSON schema 兼容性、是否支持图片输入这些如果不一样，即便放进同一条 fallback 链，也最好按请求类型拆开会更安全。

什么时候必须加入 human approval

AI SDK 6 的 human-in-the-loop tool approval，不应该被当作演示功能，而应该看作一种运维控制装置。尤其是下面这些操作，最好把审批环节设为默认值。

支付、退款、订单变更这类涉及金钱的操作
数据删除、权限变更、执行部署这类难以撤回的操作
会对外部系统产生写入的 CRM、ERP、工单系统集成
直接发送给客户的邮件、消息、公告
安全敏感度较高的内部工具调用

反过来，可以不经审批就自动化的操作大致是下面这些。

只读检索
文档摘要与草稿撰写
low-risk 的分类工作
可缓存的内部查询

团队在实务中可以直接套用的标准很简单 — 按「一旦误执行，人工善后的成本大不大」来划分就够了。

审批边界最好设在工具层，而不是模型层

很多团队觉得用了高性能模型，审批环节就可以减少，但从运维角度看恰恰相反。模型质量越好，就越想把更多权限交出去，这反而让工具层的策略变得更重要。

推荐的模式如下。

读取类工具自动通过
写入类工具需要用户审批或基于角色的审批
高风险工具需要两阶段审批
所有审批事件都记入审计日志

const toolPolicy = {
  searchDocs: 'auto',
  readTicket: 'auto',
  updateTicketStatus: 'requires-approval',
  refundPayment: 'requires-approval',
  deployProduction: 'requires-approval',
} as const;

这种策略表比 prompt 更经用，因为即使换掉模型，运维原则依然能保留下来。

MCP 在多模型应用中为什么重要

随着 AI SDK 6 里的 @ai-sdk/mcp 进入 stable，MCP 已经从一种实验性的连接格式，越来越接近一个可用于生产的集成层。尤其是对 OAuth authentication、resources、prompts、elicitation 的支持，对企业级集成有直接意义。

这个变化重要，理由有两个。

更容易把工具和上下文的供给方式，从各个模型专属的定制代码中拆分出来。
agent 不再只是一个 API 调用器，而是发展成能与组织内部系统对接的标准运行时。

在多模型环境里，模型经常会被替换。这时如果连工具的连接方式都按模型各自绑死，维护成本会急剧上升。用好 MCP，就容易把模型层和工具层之间的耦合降下来。

面向 Next.js 团队的落地清单

下面这份清单，是按「本季度内就要真正落地」的团队来整理的。

1. 先按请求类型拆分

不要只做一个万能的聊天端点，至少按下面这些类别拆开会更好。

常规问答
基于检索的回答
调用工具类的任务
后台审批类的任务

只有先把请求类型分开，fallback 策略和模型选择才能跟着分开。

2. 先把 structured output 标准化

先定好 UI 要渲染的 JSON 形态、tool result 形态、日志字段，这样以后换模型的成本就会降低。

3. fallback 链按功能来分组

不要只看速度和成本，下面这些项目也要一起检查。

tool calling 的稳定性
JSON 输出的一致性
是否支持图片输入
上下文长度
provider availability

4. 用代码管理审批策略

不要只靠 prompt 里的一句话来控制是否需要审批，用服务端的策略对象或数据表来管理会更安全。

5. DevTools 与日志一起看

AI SDK 6 的 DevTools 能提升开发速度，但在生产环境中，每个请求用了哪个 model、哪个 provider、是否触发了 fallback、tool approval 事件，都得同时留在日志和指标里。

6. 评估标准一次只提升一项

最好不要一开始就想同时做到最高准确率、最低成本、最高稳定性。通常下面这个顺序更现实。

能不能做到不失败地响应
tool 调用是否安全
structured output 是否稳定
成本是否落在预算内
平均延迟是否满足目标

结语

2026 年 AI 应用的竞争力，不会只靠「用了哪个模型」来决定。更重要的是，先把「即使换了模型，服务质量和运维管控也能保持住」的结构搭起来。AI SDK 6 让 agent 设计、工具审批、MCP 集成变得更实用，AI Gateway 则让多模型运维的一部分可以从产品代码里分离出去。

归纳一下，方向很明确 — 与其把所有期待都押在单一模型上，不如把模型选择、provider routing、human approval 都提升为系统设计的一部分。这就是 2026 年这一代 AI 产品团队该有的基本功。

用 Vercel AI SDK 6 和 AI Gateway 构建多模型应用：2026 实战指南