一个 TypeScript AI 工具包，同时出现在 Next.js、React、Svelte、Vue、Angular 和 Node.js 的交叉点上，它的 README 真正承诺了什么？这是阅读 Vercel AI SDK 官方仓库时需要回答的第一个问题。

官方 README 对 AI SDK 的定义非常明确：一个 provider-agnostic 的 TypeScript 工具包，用于构建 AI 应用和 Agent，支持 Next.js、React、Svelte、Vue、Angular 等 UI 框架，以及 Node.js 运行时。安装前提是 Node.js 22+，核心安装命令只有一条：

npm install ai

注意这里没有把某个框架绑定为前置条件。ai 是核心包，框架接入是另一层。README 后续给出的 @ai-sdk/react 安装示例，以及 UI 模块对 Next.js、React、Svelte、Vue 的覆盖声明，都指向同一个架构判断：核心（模型调用、Agent、输出解析）与 UI 层是解耦的。

Unified Provider：默认网关注入，直接连接作为可选项

README 对模型接入的描述，是本文最值得关注的工程信息。它提供了一条默认路径和一条显式路径：

默认路径下，AI SDK 使用 Vercel AI Gateway，开发者不需要安装任何 Provider SDK，直接传模型字符串即可：

const result = await generateText({
  model: 'anthropic/claude-opus-4.6', // or 'openai/gpt-5.4', 'google/gemini-3-flash', etc.
  prompt: 'Hello!',
});

显式路径下，开发者安装 Provider 专属包并传入模型实例：

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

两段示例同时存在，说明 README 认可两种接入方式并存。需要注意的边界是：README 只把 OpenAI、Anthropic、Google 列为示例 Provider，并给出“and more”的指向，但没有列出完整 Provider 清单。对团队而言，选型时验证目标 Provider 是否被官方覆盖，需要去 ai-sdk.dev 的 Providers 索引确认，而不是默认“所有模型服务都支持”。

另一个容易被忽略的细节是：README 中的模型字符串（claude-opus-4.6、gpt-5.4、gemini-3-flash）本质上是示例占位。它们能说明“模型字符串 + Gateway”这一路由机制的存在，但不能被当作这些模型已发布的证据。

结构化输出与 Agent 循环：README 公开的三个能力切片

README 给出了三个能力分层，分别对应文本生成、结构化数据生成和 Agent 工具循环。

文本生成是最薄的一层：

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

结构化输出使用 Output.object 配合 Zod schema。注意这个 API 的形状与语言模型直接返回 JSON 不同——它把 schema 声明放在调用参数中，由 SDK 层处理输出约束：

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

Agent 示例引入了 ToolLoopAgent，这是 README 中语义最重的一个公开 API。它表示一个带工具执行循环的 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 }) => {
        const [cmd, ...args] = action.command;
        const sandbox = await getSandbox(); // Vercel Sandbox
        const command = await sandbox.runCommand({ cmd, args });
        return { output: await command.stdout() };
      },
    }),
  },
});

这里值得明确区分：ToolLoopAgent、openai.tools.localShell、getSandbox() 都是代码示例中出现的内容。前两个是 README 声明的公开 API 形态，getSandbox() 则是被注释为 Vercel Sandbox 的外部依赖。Agent 内部的循环机制——如何决定调用哪个工具、如何终止、如何做上下文裁剪——README 并未展开，那些信息需要从源码或官方文档进一步验证。

生成式 UI 的完整链路：Agent 输出到 React 组件

README 用一个图片生成 Agent 示例，展示了从 Agent 定义到 UI 渲染的完整链路。这个示例的价值在于，它把前文提到的几层能力串成了一个可运行的架构：

  1. Agent 层定义图片生成工具：
import { openai } from '@ai-sdk/openai';
import { ToolLoopAgent, InferAgentUIMessage } from 'ai';

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

export type ImageGenerationAgentMessage = InferAgentUIMessage;
  1. Next.js App Router 路由层把 Agent 执行结果转为流式 UI 响应：
import { createAgentUIStreamResponse } from 'ai';

export async function POST(req: Request) {
  const { messages } = await req.json();
  return createAgentUIStreamResponse({
    agent: imageGenerationAgent,
    messages,
  });
}
  1. 前端通过 @ai-sdk/react 的 useChat 消费消息流，并按消息 part 类型分发到不同 UI 组件：
const { messages, status, sendMessage } = useChat();

{messages.map(message => (

    {`${message.role}: `}
    {message.parts.map((part, index) => {
      switch (part.type) {
        case 'text':
          return {part.text};
        case 'tool-generateImage':
          return ;
      }
    })}

))}
  1. 图片生成组件根据工具调用的状态机切换渲染：
export default function ImageGenerationView({ invocation }: {
  invocation: UIToolInvocation>;
}) {
  switch (invocation.state) {
    case 'input-available':
      return Generating image...;
    case 'output-available':
      return ;
  }
}

这个例子带有明显的高阶抽象特征：InferAgentUIMessage 从 Agent 类型推导消息类型，UIToolInvocation 让组件感知工具调用的生命周期，createAgentUIStreamResponse 屏蔽了流式协议细节。对开发团队而言，真正需要评估的是这些抽象是否与自己的应用形态匹配——如果只是做简单的聊天补全，这套链路可能偏重；如果要做工具调用密集的 Agent UI，这种按 part 类型渲染的模型反而比纯文本流更容易维护。

README 还提到 UI hooks 是 framework agnostic 的，可用于 Next.js、React、Svelte、Vue，并给出了 npm install @ai-sdk/react 的安装示例。但具体到 Vue、Svelte 的 hooks 形态是否与 React 完全一致，README 没有展开，需要查阅对应框架包的文档或源码确认。

从 README 能得出的工程判断

基于官方 README 公开的信息，可以形成几个保守但有效的判断：

  • 这不是一个绑定 Next.js 的库。README 对 Next.js 的支持体现在示例路由使用了 App Router，但核心包、UI hooks、Provider 抽象都是独立层。
  • 模型接入的默认路径是 Vercel AI Gateway，这意味默认情况下模型请求会经过 Vercel 的网关。对数据合规敏感的团队，直接 Provider 接入是明确的替代路径。
  • ToolLoopAgent 加上 createAgentUIStreamResponse 的组合，说明 SDK 正在把 Agent 执行与前端 UI 状态同步作为一个整体问题来解决。这是它区别于单纯 LLM SDK 的关键。
  • README 给出的 API 形状（generateText、Output.object、useChat）已经足够作为初步技术选型的依据，但 Agent 内部循环、网关路由策略、各框架 UI 模块的差异，仍需要从源码和文档进一步验证。

对于正在做 AI 应用技术选型的团队，一个可行的做法是：先用默认的 generateText 加模型字符串跑通最小链路，再决定是否需要引入 Agent 抽象和 UI 流式渲染。AI SDK 的低门槛入口在 README 中展示得很清楚；它的复杂度峰值——也就是 Agent 工具循环和跨框架 UI——则应该在真正需要时再进入。