当 TypeScript 团队需要同时接多个大模型 Provider，还要把模型调用、Agent 工具执行和前端 UI 串起来时，选型往往会停留在“要不要再加一层 SDK”的取舍上。

多包一层，意味着接口统一，但也意味着要接受该层对 Provider、运行时和消息协议的裁剪。要判断裁剪是否可接受，先要知道它在官方公开信息里暴露了哪些可执行抽象。以下内容仅依据 Vercel AI SDK 官方 GitHub README 中公开的信息，不把内部实现或仓库之外的推断当成既定事实。

README 给出的定位与安装前提

开源仓库对自身定位的表述是：

provider-agnostic TypeScript toolkit

也就是说，它不是某个模型的专用 SDK，而是面向“AI 应用和 Agent”的 TypeScript 工具集。README 点名的前端框架包括 Next.js、React、Svelte、Vue、Angular，运行时明确提到了 Node.js。

一个容易被忽略的事实是环境要求：README 写的是 Node.js 22+，并通过 npm 或其他包管理器安装 ai。对仍在 Node 18/20 LTS 上的存量项目，这个前提不是可选项。

另一个值得注意的入口是安装命令：

npx skills add vercel/ai

README 说这条命令适合 Claude Code、Cursor 等编码 Agent 场景。工程上可以把它理解为一个“面向编码 Agent 的官方 skill 分发”，而不是所有项目都必须使用的运行时依赖。

两条 Provider 接入路径

随后 README 展示了最重要的事实：统一 Provider 架构。它给出了一个非常简短的调用写法：

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

这里 mode 使用的是 provider/model-id 形式的字符串；示例中出现了 Anthropic、OpenAI、Google 类型的写法。README 的表述是：默认情况下，SDK 通过 Vercel AI Gateway 让开发者直接访问主流 Provider。这意味着模型字符串本身可以省去为各家单独初始化客户端的步骤。

同时，README 提供了第二条路径：

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

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

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

从工程选型角度看，这里有真正的分叉点：

  • 走 Gateway + 模型字符串，团队不需要逐个接入 Provider SDK，但默认访问链路经过 Vercel AI Gateway，API Key、网络出口和可用性都由该链路承接；
  • 走 Provider 直连包，会引入多个 @ai-sdk/* 依赖，但可以绕过默认网关。

README 对“默认走 Gateway”没有展开成完整的架构说明，因此团队若把网关视为不可接受的外部依赖，不能只根据这段文档下结论。能做的是先用 @ai-sdk/openai 这类直连包做最小验证，再去读配置文档确认所有调用是否都能被设置为预期的访问路径。

文本、结构化数据、Agent 三层能力

基础文本生成是 generateText。紧接着 README 给了结构化输出示例：

import { generateText, Output } from 'ai';
import { z } from 'zod';

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.',
});

能确认的是：结构化输出的接口不是“你给我 JSON 字符串”，而是用 Output.object + Zod schema 将输出约束为可校验结构。这对 TypeScript 项目有两个实际意义：下游拿到的数据有了 schema 边界，Zod 类型可以直接复用到业务代码中。

Agent 部分是 README 里信息量最大的内容。它直接导出了 ToolLoopAgent：

import { ToolLoopAgent } from 'ai';

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 中执行
      },
    }),
  },
});

可以看出它在 Agent 层做的是“模型 + 工具”的声明式封装：ToolLoopAgent 接收模型、系统提示词和工具列表，把循环执行、工具结果回填这类机制收进对象内部。

但 README 没有描述 ToolLoopAgent 内部循环什么时候结束、工具错误怎么重试、多个工具之间是否有并行策略。若要判断“这个 Agent 抽象是否够深”，只停留在 demo 层面不够，下一步应该直接读 ai 包源码里的 ToolLoopAgent 实现。

此外，示例中的 shell 工具名是 localShell，而注释出现的执行环境是 Vercel Sandbox。换句话说，README 示例中的 shell 并不是“一定在本机直接执行”，而是把命令交给沙箱执行。对安全敏感的团队，这一点必须先验证。

从 Agent 到生成式 UI 的消息闭环

生成式 UI 是这套 SDK 在设计上的主要差异点之一。README 给出一套完整的图片生成 Agent 示例：

  1. Agent 端使用 openai.tools.imageGeneration 生成图片；
  2. 用 InferAgentUIMessage 推导消息类型；
  3. Next.js Route Handler 里通过 createAgentUIStreamResponse 返回流式响应；
  4. 前端用 useChat() 接收消息；
  5. 渲染时按 part.type 区分文本和工具调用，工具部分使用 UIToolInvocation 根据 invocation.state 渲染不同 UI。

其中关键机制是：Agent 的工具调用会变成消息流中的一个 part，而不是一个游离的 JSON 响应。前端组件能拿到 invocation.output.result 并直接渲染成 base64 图片。

这一部分对选型可能有决定影响。若业务需要一个能持续生成内容、并把中间工具结果实时展示到页面的应用，这种“工具调用即 UI 更新”的抽象能省掉自建消息协议的工作。官方同时说明，UI 模块中的 hooks 是框架无关的，README 列出的前端是 Next.js、React、Svelte、Vue；Angular 在仓库总定位中被提起，但没有出现在 UI hooks 的示例中，选择 Angular 时需要单独验证 hooks 覆盖度。

对 TypeScript 团队的评估清单

结合以上 README 事实，一个 TypeScript 团队可以在立项时按以下顺序做判断：

  1. 确认 Node 运行时版本。 当前环境是否 ≥ 22；是否接受新增 ai 运行时依赖。若不满足，先解决环境问题，而不是直接把包引入旧运行时。
  2. 确认 Provider 策略。 只想快速接多家模型，可以接受默认网关；团队已有统一模型网关，则应优先验证 Provider 直连包的配置能力。
  3. 确认 Agent 执行边界。 README 展示的 sandbox 说明“工具拥有执行能力”，但这不等于安全模型已满足生产要求。Agent 若会被投喂不可信输入，执行环境的隔离策略必须单独验证和加固。
  4. 确认前端渲染路径。 React/Next.js 项目可以直接对齐 @ai-sdk/react 示例；Svelte、Vue、Angular 项目需要验证对应包与 hooks 的能力边界。
  5. 对生产级评判保留边界。 本次能确认的是 API 表面，不能确认的是 SDK 内部的流式传输细节、工具循环策略、不同 Provider 错误语义是否已统一，以及网关不可用时的行为。应通过阅读源码和搭建最小验证工程来补齐证据。

README 给出的进一步验证入口包括 AI SDK 官方文档 和 API Reference。

选型结论不应建立在“这个仓库看起来什么都能做”上。Vercel AI SDK 的价值在于它已经把 Provider 接入、结构化输出、ToolLoopAgent 和生成式 UI 放在同一套 TypeScript API 里；但接入方仍要替它补完执行环境、安全边界和可观测性三块工程拼图。