在 TypeScript 生态里构建 LLM 应用，长期存在一个工程痛点：模型厂商的 SDK 接口、流式协议、工具调用格式各不相同，前端框架又各有自己的状态管理方式。vercel/ai（AI SDK）试图用一层 provider-agnostic 的抽象把这两端都收敛起来。它由 Vercel 与 Next.js 团队成员创建，采用开源许可，GitHub 上已有约 27k star、5.2k fork，仓库 topics 明确标注了 openai、anthropic、gemini、language-model、generative-ui、nextjs、react、svelte、vue 等关键词。

定位：不是模型封装，而是接入层

官方 README 对它的定义是“provider-agnostic TypeScript toolkit”，目标是帮助开发者用 Next.js、React、Svelte、Vue、Angular 等 UI 框架，以及 Node.js 等运行时，构建 AI 应用与 Agent。注意这里的措辞：它不训练模型，也不托管推理，而是把“调用模型”这件事标准化。安装门槛是 Node.js 22+ 与 npm（或其他包管理器），核心包只有一个：npm install ai。

统一 Provider 架构：字符串即模型

AI SDK 的默认路径是走 Vercel AI Gateway，开发者只需传一个模型字符串：

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

README 中给出的示例还包括 openai/gpt-6-astra、google/gemini-3.8-flash 等写法。这种设计的工程价值在于：切换模型不需要改调用代码结构，只改一个字符串。

如果不想经过 Gateway，也可以直连厂商 SDK 包，例如安装 @ai-sdk/openai、@ai-sdk/anthropic、@ai-sdk/google，然后以函数形式传入模型：

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

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

两条路径共用同一套 generateText 等上层 API，差异被压缩在 model 参数的构造方式上。这是该库处理多 Provider 差异的核心思路：把差异挡在参数层，而不是让业务代码感知。

结构化输出：用 schema 约束返回值

LLM 应用里另一类高频需求是拿到可解析的结构化数据。AI SDK 提供了 Output.object 配合 zod schema 的方式：

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

const { output } = await generateText({
  model: 'openai/gpt-6-astra',
  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.',
});

从工程角度看，这相当于把“提示词工程”部分转化为“类型契约”：schema 既是运行时校验，也是 TypeScript 类型来源。对需要把模型输出直接喂给下游系统的场景，这比手工解析 JSON 更可控。

Agent：ToolLoopAgent 与工具循环

README 中 Agent 能力由 ToolLoopAgent 承载。示例构造了一个带 shell 工具的 sandbox agent：

import { ToolLoopAgent } from 'ai';

const sandboxAgent = new ToolLoopAgent({
  model: 'openai/gpt-6-astra',
  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();
        const command = await sandbox.runCommand({ cmd, args });
        return { output: await command.stdout() };
      },
    }),
  },
});

这里可以看到几个关键设计：工具以对象形式注册，execute 是普通异步函数，返回值即工具结果；模型侧的工具定义（如 openai.tools.localShell）与执行逻辑分离，执行环境由开发者自己决定（示例中是 Vercel Sandbox）。ToolLoopAgent 这个名字本身暗示了它会自动处理“模型请求工具 → 执行 → 回传结果 → 继续推理”的循环，开发者不必手写 while 循环。

生成式 UI：把工具调用状态映射到组件

AI SDK UI 模块提供了一组框架无关的 hooks，可用于 Next.js、React、Svelte、Vue。以 React 为例，需要安装 @ai-sdk/react。

一个完整的图像生成 Agent 链路在 README 中被拆成四层：

第一层是 Agent 定义，用 InferAgentUIMessage 导出消息类型：

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

export type ImageGenerationAgentMessage =
  InferAgentUIMessage;

第二层是 Next.js App Router 的路由，用 createAgentUIStreamResponse 把 agent 与 messages 转成流式响应：

export async function POST(req: Request) {
  const { messages } = await req.json();
  return createAgentUIStreamResponse({
    agent: imageGenerationAgent,
    messages,
  });
}

第三层是工具 UI 组件，通过 UIToolInvocation 接收调用状态，按 input-available、output-available 等 state 分支渲染：

export default function ImageGenerationView({ invocation }: {
  invocation: UIToolInvocation
  >;
}) {
  switch (invocation.state) {
    case 'input-available':
      return Generating image...;
    case 'output-available':
      return ;
  }
}

第四层是页面组件，用 useChat 拿到 messages、status、sendMessage，然后遍历 message.parts，按 part.type 分派到文本或 tool-generateImage 组件。

这条链路体现了“生成式 UI”的落地方式：模型输出的不是纯文本，而是带类型的 part 序列，前端按 part 类型渲染不同组件。工具调用的中间状态（生成中、已完成）直接暴露给 UI，开发者可以据此做加载态、流式图片等交互。

适用边界与工程取舍

从官方资料能确认的边界包括：需要 Node.js 22+；默认走 Vercel AI Gateway，直连厂商则需额外安装对应 @ai-sdk/* 包；UI hooks 覆盖 Next.js、React、Svelte、Vue，README 提到 Angular 属于支持框架之一但未给出对应示例代码。

需要区分的是，以下属于工程判断而非官方事实：其一，走 Gateway 还是直连厂商，涉及网络路径、计费与合规，官方 README 未展开对比；其二，ToolLoopAgent 的循环终止条件、最大步数、错误重试策略等细节，README 未说明，实际使用需查阅 API Reference 与 Documentation；其三，结构化输出依赖 zod，若项目已有其他校验方案，需要评估引入成本。

对正在选型的 TypeScript 团队来说，这个库的吸引力在于：它把多 Provider 差异、流式协议、工具调用循环、前端状态同步这几件重复劳动收敛成一套 API，且与 Next.js 生态同源。代价是抽象层带来的调试复杂度，以及默认路径对 Vercel 基础设施的倾向性。是否采用，取决于项目对 Provider 可替换性的需求强度，以及团队是否愿意接受这层抽象。