先把模型当成字符串

const result = await generateText({
  model: 'openai/gpt-5.4',
  prompt: 'What is an agent?',
});

这是 Vercel AI SDK README 中展示的基础用法。model 直接接收一个带 provider 前缀的模型字符串，而不是先构造某个 provider 的 client。README 对 AI SDK 的定义是：一个 provider-agnostic 的 TypeScript 工具包，用于在 Next.js、React、Svelte、Vue、Angular 等 UI 框架以及 Node.js 运行时上，构建 AI 应用和 Agent。

这里真正值得关注的是“provider-agnostic”被拆成了两层接入方式，而不是一句宣传语。

两层接入：Gateway 与 direct SDK

README 给出的默认路径是：像 model: 'anthropic/claude-opus-4.6'、'openai/gpt-5.4'、'google/gemini-3-flash' 这样的字符串，直接通过 Vercel AI Gateway 访问各大主流模型 provider，不需要额外安装 provider 包。

另一条路径是安装 provider SDK 后直连：

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

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

README 明确列出的 provider 包包括 @ai-sdk/openai、@ai-sdk/anthropic、@ai-sdk/google。

对开发团队来说，这首先是一个网络与凭据路径的选型：走 Gateway 时，模型请求路由由 Vercel AI Gateway 接管；走 direct SDK 时，provider 的客户端逻辑在应用进程内执行。README 没有展开这两条路径在超时、重试、限流和可观测性上的差异，这些需要查阅官方 API Reference 或做实际验证。

几个直接影响选型的公开信息

第一，本地环境要求 Node.js 22+，核心安装命令是 npm install ai（README 同时说明可以使用 npm 或其他包管理器）。注意这里说的是本地开发机，README 没有定义生产运行时的 Node 版本。另外，“AI SDK”不是一个单文件依赖：UI 接入需要另外安装框架包，比如 @ai-sdk/react；直连 provider 需要另外安装 provider 包。这意味着接入成本不是一次 npm install ai 就能全部覆盖，而是由核心包、UI 包和 provider 包共同组成。

第二，结构化输出被放进了核心示例。generateText 可以配合 Output.object 和 Zod schema 使用，README 用一份 recipe 结构展示了如何让模型返回带嵌套字段的、可被 TypeScript 类型约束的数据。相比只拿自由文本，这更接近真实工程需求。

第三，Agent 不是一个概念，而是一个可复用类：ToolLoopAgent。README 中的示例把工具通过 tools 字段注入，其中一个工具是 openai.tools.localShell，另一个是用于生成图片的 openai.tools.imageGeneration。Agent 的消息类型由 InferAgentUIMessage 从 agent 定义中推导出来，并直接传给 useChat。

第四，README 还提到官方提供了 templates，覆盖不同 use cases、providers 和 frameworks，帮助快速起步。对团队来说，templates 不是文档补充，而是可执行的集成范例；但 README 没有逐个展开模板内容。

从 Agent 到 UI：工具调用进入消息流

README 用一个 image generation agent 示例展示了完整的 UI 集成路径：

  • Agent 定义中配置 openai.tools.imageGeneration({ partialImages: 3 })；
  • Next.js App Router 路由中通过 createAgentUIStreamResponse 返回响应；
  • 客户端组件通过 useChat() 读取消息；
  • 前端对消息里的 tool-generateImage part 单独渲染，UIToolInvocation 区分 input-available 和 output-available 两种状态。

README 对 UI 模块的说明是：这些 hooks 是 framework agnostic 的，可用于 Next.js、React、Svelte 和 Vue。也就是说，Agent 消息与工具渲染并没有被绑死在某个具体框架版本里。

换句话说，模型执行工具的结果不再只是服务端日志里的一行记录，而是变成前端消息流中一个可以被针对性渲染的 part。图片生成工具的输出甚至可以直接以 base64 形式放进 `` 标签。这就是生成式 UI 的一种具体实现方式：模型的一次工具调用，对应前端组件的一个渲染状态。

coding agent 场景：项目自带的 skill

README 还建议使用 Claude Code 或 Cursor 这类 coding agent 的开发者，在仓库中执行 npx skills add vercel/ai 来添加 AI SDK skill。

这个细节没有进入大多数“AI SDK 介绍”的视野，但它至少说明官方把“开发者怎么在编辑器里使用这个 SDK”也当成了产品的一部分。对团队而言，是否引入这个 skill，取决于你多大程度依赖 coding agent 自动生成 AI 调用代码；如果团队主要是手写 API 调用，它的实际增量有限。

选型前需要验证的边界

README 没有解释 AI SDK 内部的抽象层、数据流、流式协议、缓存或性能机制。因此在选型阶段，至少需要确认下面几个问题：

  • 默认走 Vercel AI Gateway 时，模型请求是否会经过 Vercel 的网络？对数据合规和延迟敏感场景是否可接受？
  • direct provider 路径是否完整保留 provider 特有能力，比如 reasoning 参数、function calling 的原始事件格式？
  • ToolLoopAgent 的循环终止条件、最大步数、超时和失败重试策略是什么？README 没有给出。
  • createAgentUIStreamResponse 的流式语义与现有前端鉴权、错误处理、缓存策略是否兼容？
  • localShell 示例中出现了 Vercel Sandbox 的注释，但 README 没有展开沙箱机制。把 shell 工具交给 Agent 时，权限控制和资源隔离必须由应用层自己补上。

这些问题不全是 README 的缺陷，而是说“AI SDK 值得评估”和“AI SDK 可以直接上生产”之间还有一段需要验证的距离。

结论

从公开 README 看，AI SDK 的选型价值在于它把模型接入、结构化输出、Agent 工具循环和前端 UI 渲染放在同一条 TypeScript 工具链里。这个库由 Vercel 和 Next.js 团队成员创建，UI 定位覆盖 Next.js、React、Svelte、Vue、Angular 等框架，对 TypeScript 全栈团队有天然的契合度。

但选型的边界也同样清晰：Node.js 22+ 是本地开发基线；Gateway 与 direct provider 是两条不同路径；Agent 工具循环和流式 UI 的状态语义需要继续看文档或源码。最稳妥的做法是先用一个非核心项目，在真实 provider、真实工具和真实流量下跑完整链路，再决定是否让它进入生产栈。