AI SDK 如何统一 OpenAI、Anthropic 与 Google 接入

原创 1小时前 4

#AI SDK #TypeScript #多Provider接入 #生成式UI #ToolLoopAgent

多模型接入的痛点在于，每家模型提供方都有自己的请求协议和 SDK。业务要同时接 OpenAI、Anthropic、Google 三家，工程上就得维护多套调用逻辑、错误处理与流式输出格式，并且每家的模型版本更新还可能带来接口变动。

AI SDK 的做法，是用一层统一的 TypeScript API 来收拢这种差异，让上层代码只依赖一套接口。官方将其定义为 provider-agnostic TypeScript toolkit，由 Vercel 与 Next.js 团队成员创建，定位是帮助开发者用 Next.js、React、Svelte、Vue、Angular 等 UI 框架以及 Node.js runtime 构建 AI 应用和 agent。

需要先说明的是，本文事实以官方 README 为准。README 没有解释统一抽象层的内部实现，因此下面一部分是官方明确能力，一部分是工程判断，两者分开呈现。

两条接入路径

README 描述了两种接入模型的方式。

第一条是默认路径：AI SDK 默认使用 Vercel AI Gateway，调用时直接传 provider/model 格式的模型字符串：

const result = await generateText({
  model: 'anthropic/claude-opus-4.6',
  prompt: 'Hello!',
});

anthropic/claude-opus-4.6 是官方示例中的一个模型字符串，指向 Anthropic 的 Claude 模型。OpenAI 对应 openai/gpt-5.4，Google 对应 google/gemini-3-flash。对上层业务而言，切换模型只是换一个字符串，调用结构本身不变。

第二条路径是与 provider SDK 直连。先安装对应包：

npm install @ai-sdk/openai @ai-sdk/anthropic @ai-sdk/google

再调用各 provider 的工厂函数：

import { anthropic } from '@ai-sdk/anthropic';

const result = await generateText({
  model: anthropic('claude-opus-4-6'),
  prompt: 'Hello!',
});

从工程角度看，这两条路径各有适用场景。Gateway 路径开箱即用，适合快速做模型对比选型；直连路径依赖 provider 自己的 SDK 行为，适合对网络出口、鉴权和单个 provider 深度能力有要求的团队。README 没有给出任何性能或成本数据，所以哪条路径在实际业务中更优，需要团队自己验证。

不止文本生成：结构化输出与 Agent 工具

generateText 是核心调用入口，但不只是文本生成。官方示例显示，通过 Output.object 配合 zod schema，可以直接拿到结构化对象：

const { output } = await generateText({
  model: 'openai/gpt-5.4',
  output: Output.object({
    schema: z.object({
      recipe: z.object({
        name: z.string(),
        ingredients: z.array(z.object({ name: z.string(), amount: z.string() })),
        steps: z.array(z.string()),
      }),
    }),
  }),
  prompt: 'Generate a lasagna recipe.',
});

README 还给出了 ToolLoopAgent，用于构建带工具循环的 agent：

const sandboxAgent = new ToolLoopAgent({
  model: 'openai/gpt-5.4',
  system: 'You are an agent with access to a shell environment.',
  tools: {
    shell: openai.tools.localShell({
      execute: async ({ action }) => {
        // 官方示例中通过 Vercel Sandbox 执行命令
      },
    }),
  },
});

注意 openai.tools.localShell 来自 @ai-sdk/openai，说明 provider 包除了基础模型调用，还附带针对该 provider 的工具扩展。README 示例中，这个工具的 execute 实现借用 Vercel Sandbox 执行 shell 命令，但这只是示例的实现方式。

另一个官方示例是图片生成 agent，工具定义为 openai.tools.imageGeneration，并传入 partialImages: 3。UI 示例中，工具调用在 output-available 状态下返回 data:image/png;base64 格式的图片数据，可以直接用 ` 渲染。README 没有解释partialImages的具体语义，但 UI 示例展示的input-available与output-available` 状态暗示工具调用具备过程感知能力。

生成式 UI：类型安全从 agent 到组件

AI SDK 的 UI 模块是官方重点展示的能力之一。它提供框架无关的 hooks，可用于 Next.js、React、Svelte 和 Vue，按框架安装对应包：

npm install @ai-sdk/react

官方示例展示了一个完整的链路：在 Next.js App Router 下定义 agent 路由，用 createAgentUIStreamResponse 把 agent 的输出转成流式响应；前端页面通过 useChat hook 消费消息。

这里真正值得关注的是类型安全在整个链路上的穿透。示例中先用 InferAgentUIMessage 把 agent 的消息类型推断出来，再把它作为 useChat 的泛型，前端消息 part 就能识别 tool-generateImage 这种类型。UI 组件侧则用 UIToolInvocation 接收有类型的工具调用，并依据 state 渲染界面：

switch (invocation.state) {
  case 'input-available':
    return Generating image...;
  case 'output-available':
    return ;
}

这种从 agent 逻辑到前端组件的类型穿透，是 AI SDK 相比团队自己拼装多 provider SDK 的一个重要收益。后端定义一次 agent，前端就能获得带类型的消息结构和工具调用状态，联调时不需要反复猜测消息格式。

环境要求与周边生态

官方明确的环境要求是 Node.js 22+，安装命令：

npm install ai

README 还提到一个面向编码 agent 的能力。如果你使用 Claude Code、Cursor 这类 coding agent，可以通过以下命令把 AI SDK 的 skill 添加到仓库：

npx skills add vercel/ai

这相当于把 AI SDK 的使用知识添加到仓库中，让编码 agent 能直接参考。此外，官方提供了多个 templates，覆盖不同的 use case、provider 和 framework，并在 Vercel Community 开设了 AI SDK 板块。对刚起步的团队，模板是比文档更快的上手路径。

选型时需要自行验证的部分

按现有官方信息，AI SDK 的默认路径依赖 Vercel AI Gateway。如果团队无法接受这个云链路，需要评估直连模式是否能覆盖全部需求。

以下问题 README 没有给出明确结论，建议在真实项目中验证：

统一抽象层的流式、重试、超时等具体行为，需要查阅 API Reference 或直接实验；
直连各 provider SDK 时，provider 包升级是否会影响 AI SDK 的接口兼容性；
高并发场景下的性能和成本，README 没有提供任何基准数据；
ToolLoopAgent 在复杂工具依赖下的循环控制表现，需要结合自己的场景测试。

工程判断

AI SDK 解决的是一个真实存在的工程问题：多 provider 接入时的 API 分叉，以及 AI 功能与前端框架集成时的成本。它的价值不在于新增模型能力，而在于把模型调用、结构化输出和 UI 状态管理收拢到一套类型系统里。对需要在多个模型间快速对比、前端栈又以 React 或 Next.js 为主的团队，这个 SDK 值得作为选型评估对象。反过来，如果团队长期只绑定一个 provider，并且深度依赖该 provider 的私有特性，引入一层抽象可能并不划算——这正是选型时需要冷静判断的地方。

暂无评论，来说两句吧