Vercel AI SDK：从 README 看 TypeScript AI 工具链的选型

从选型而不是新闻的角度看，Vercel AI SDK 官方 README 最有价值的内容，是它对自身定义、Provider 抽象和 UI 集成方式给出的具体代码路径。它并不是在讲一套“AI 应用应该长什么样”的概念，而是直接展示了从模型调用到前端工具渲染的工程链条。

先把事实边界划清楚。README 对项目的定义是：AI SDK 是一个 provider-agnostic 的 TypeScript toolkit，用于帮助开发者用 Next.js、React、Svelte、Vue、Angular 等 UI 框架，以及 Node.js 运行时构建 AI 应用和 agent。这个定义比“Next.js 专用模型库”宽很多，也决定了它后续的 API 分层方式：统一的模型访问入口、结构化输出与工具循环、以及框架级 UI hooks。

本文基于当前官方 README 快照，后续版本可能变化。

1. 安装边界与编码 Agent 入口

README 给出的安装条件很具体：本地需要 Node.js 22+，使用 npm 或兼容包管理器，安装核心包使用：

npm install ai

值得注意的是，README 还推荐使用 Claude Code、Cursor 等编码 agent 的团队在仓库中执行：

npx skills add vercel/ai

这表示 AI SDK 的官方支持路径中，已经包含了“让编码 agent 理解 AI SDK 用法”这一层。对团队来说，这是一个工程选择信号：如果团队已经在用 coding agent，AI SDK 提供了比普通 prompt 更结构化的接入方式；但 skill 文件具体能做什么、覆盖哪些 API，README 没有展开，需要在仓库中实际查看。

另一条容易被忽略的事实边界是：README 要求 Node.js 22+，这个版本要求会直接影响 CI 镜像、函数运行时和本地开发环境。它不是可选的推荐配置，而是官方安装前置条件。

2. Provider 抽象：两条可以并存的接入路径

README 的 Unified Provider Architecture 部分给出了两条模型接入路径，这两条路径不是二选一的关系，而是一套同样 API 下的不同部署方式。

第一种是默认通过 Vercel AI Gateway 使用模型。官方说明是，AI SDK 默认使用 Vercel AI Gateway，让开发者开箱即用地访问 OpenAI、Anthropic、Google 等 provider。这时只需要传一个 model string：

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

第二种是直接安装并使用 provider 的 SDK 包：

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

从工程角度看，这里值得注意的不是某一个模型的名称，而是 model string 与 provider 函数调用两种写法并存。前者走 Vercel AI Gateway，更适合快速验证多厂商接入；后者绕开 Gateway，直连服务商 SDK，适合已经有明确 provider 依赖、或需要避免中间层的情况。具体网关配置、可用模型目录和直连参数差异，官方 README 没有完整列出，必须继续查 https://ai-sdk.dev/providers/ai-sdk-providers 下的文档。README 中出现的 claude-opus-4.6、gpt-5.4、gemini-3-flash 只是代码示例，不能当作当前所有模型的完整清单。

3. 结构化输出：zod 成了输出协议的一部分

README 并不仅仅把模型当成文本生成器。它的结构化数据示例，直接使用 Output.object 配合 zod schema：

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

这里真正重要的事实是：zod 不是额外封装的第三方“增强功能”，而是出现在 ai 核心包的官方示例中。也就是说，AI SDK 对结构化输出的默认预期，不只要求开发者给出 JSON schema，而是将 schema 做成模型输出的一种类型约束。对已经用 TypeScript zod 的团队来说，这会降低从“任意 JSON”到“可信数据”之间的验证成本；但如果团队不使用 zod，就需要重新评估这个依赖是否可接受。

4. Agent 与 UI：README 展示了一种有类型的 Agent UI 链路

README 中信息增量最大的内容，是它用 image generation agent 串起了一条从 agent 定义到前端组件的完整链路：

ToolLoopAgent 来自 ai 包，负责持有 model、system 和 tools；
InferAgentUIMessage 从 agent 类型反推消息类型；
Next.js App Router 路由中通过 createAgentUIStreamResponse 返回流式响应；
前端 useChat() 拿到消息；
对于工具调用，React 组件用 UIToolInvocation 接住 invocation，并根据 invocation.state 渲染不同状态。

README 中 Image Generation 的 agent 定义示例是：

export const imageGenerationAgent = new ToolLoopAgent({
  model: 'openai/gpt-5.4',
  tools: {
    generateImage: openai.tools.imageGeneration({
      partialImages: 3,
    }),
  },
});

export type ImageGenerationAgentMessage = InferAgentUIMessage;

对应的 Next.js Route Handler 是：

import { imageGenerationAgent } from '@/agent/image-generation-agent';
import { createAgentUIStreamResponse } from 'ai';

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

  return createAgentUIStreamResponse({
    agent: imageGenerationAgent,
    messages,
  });
}

而在 React 组件中，README 用 invocation.state 区分工具执行中的输入态与输出态：

if (invocation.state === 'input-available') {
  return Generating image...;
}

if (invocation.state === 'output-available') {
  return ;
}

这段代码最值得分析的地方，不是“图片生成很炫”，而是工具调用结果被 TypeScript 类型明确标注成了 message 中的一个 part。前端不是拿到一段难以解析的文本，而是拿到 part.type === 'tool-generateImage' 这样的结构化分支。这意味着 Agent UI 不再只是“打字机文本”，而是把工具执行过程变成了可渲染的 UI 事件。

需要强调，README 只给出了图片生成这一个完整 UI 示例，input-available 与 output-available 是示例中出现且可验证的状态分支，并不代表所有自定义工具都只有这两个状态。如果要为工具定义更复杂的 loading、error、中断或恢复流程，仍需要去 AI SDK 的 API Reference 确认状态协议，不能直接从这份 README 推断。

5. 框架覆盖里的一个细节

仔细读第一段和 UI Integration 段，会发现覆盖范围并不完全对齐。第一段把 Angular 列入了受支持的 UI 框架，但 UI Integration 段在解释 framework-agnostic hooks 时，列举的是 Next.js、React、Svelte 和 Vue，没有明确点名 Angular。

这不是说 Angular 一定不可用，而是说明：核心工具包可能支持 Angular 项目，但 @ai-sdk/react 这类独立 UI 适配包的覆盖边界，需要按框架分别确认。对 Angular 团队而言，选型前应该先找到 Angular 对应的官方 package、示例模板或明确文档，而不是假设“支持 Vue/Svelte 就自动支持 Angular”。

6. 回到选型判断

综合官方 README，可以给出几个克制的工程判断：

第一，AI SDK 的边界不是“模型调用”，而是从模型调用到框架 UI 的整段链路。如果团队只是想要一个最小化的 OpenAI 封装，直接使用官方 SDK 反而更轻；但如果团队要同时接入多个 provider，并且需要把结构化输出、工具调用和前端状态串起来，AI SDK 提供的抽象层次是真实的。

第二，AI SDK 在 UI 层走的是“类型化消息流 + 可插拔 React 组件”的路线。这个设计对 TypeScript 团队比较友好，但它也要求团队接受 zod、类型推断和框架 hooks 带来的约束。

第三，README 没有提供任何性能 benchmark、生产可用性指标或 Gateway 稳定性承诺。真正要判别它是否适合生产，团队需要自己拿真实模型、真实工具链和真实网络环境做验证。Provider 清单、Agent 底层循环实现、UI 流式传输协议和 Angular 支持程度，都属于下一步必须用官方文档和源码回答的问题。

从工程选型的角度，这份 README 已经提供了足够的结构：它说明 AI SDK 更像一套连接模型、Agent 与 UI 层的 TypeScript 工具链，而不是某个单一模型的客户端。具体选不选，最后仍然取决于团队愿不愿意把这套类型约束和 Provider 抽象接进自己的应用架构。