在 AI SDK 的 README 中，生成文本的最小示例是：

import { generateText } from 'ai';

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

这段代码真正的特点不是“能调用 OpenAI 模型”，而是 model 字段只是一个字符串。README 随后说明：默认情况下，AI SDK 会通过 Vercel AI Gateway 转发请求，应用层可以用统一的模型字符串访问 OpenAI、Anthropic、Google 等 provider。对上层应用来说，这种做法的意义在于，模型差异被收敛到了 SDK 边界以内。

继续读 README，会发现它的边界并不停留在“多模型适配”。AI SDK 将自己定义为 provider-agnostic 的 TypeScript 工具包，用于在 Next.js、React、Svelte、Vue、Angular 等 UI 框架和 Node.js 运行时上构建 AI 应用与 agent；本地要求是 Node.js 22+，核心安装命令是 npm install ai。

另一个容易被忽略的信号，是 README 为编码代理单独留了一节：使用 Claude Code 或 Cursor 的开发者，可以用 npx skills add vercel/ai 把 AI SDK skill 加入仓库。这说明项目已经把“编码代理如何接入”当成一个第一类使用场景，而不是开发者社区的自发集成。

模型接入：字符串与 provider 包

真正决定工程形态的，是 README 中两条并行的 provider 接入路径。

第一条是模型字符串。调用方不需要安装各家 SDK，直接写 model: 'openai/gpt-5.4' 或 model: 'anthropic/claude-opus-4.6' 这类带 provider 前缀的字符串，由默认网关完成访问。

第二条是直连包。安装 @ai-sdk/openai、@ai-sdk/anthropic、@ai-sdk/google 后，代码改为 openai(...)、anthropic(...)、google(...) 这类函数调用。README 没有用“二选一”的语气比较两者，而是并列呈现。对团队来说，这意味着可以先走字符串路径验证效果，再切到直连包做生产部署；也可以让不同服务各选一种方式。

这里需要明确一个工程问题：模型字符串默认依赖的是 Vercel AI Gateway。如果生产环境不在 Vercel，或者请求路径必须留在指定网络内，默认网关会进入应用的流量路径。团队在选型阶段应该验证网关的配置项，或者直接评估第二条路径，避免把基础设施决策交给默认值。

结构化输出与 agent 工具

生成能力上，README 展示的核心入口是 generateText，但它并不只输出文本。通过 Output.object 与 zod schema，可以让模型直接返回结构化数据；官方示例用菜谱的“名称、原料、步骤”结构演示了这一点。对 TypeScript 应用来说，这等于在模型输出与业务数据之间加了一道结构契约，而不是在拿到字符串之后再做一层自己的解析。

再往上是 agent 层。ToolLoopAgent 是 README 中明确的 agent 构造方式：传入 model、system 和一个 tools 对象。agent 可执行的工具由开发者注入，以 shell 工具为例，执行函数要自己完成沙箱调用并读取 stdout。README 没有声称替你管理沙箱安全，它把“agent 能做什么”的权限边界留给了接入方。

同时要注意，示例中的 openai.tools.localShell、openai.tools.imageGeneration 都带有 openai 前缀。这个细节说明：统一模型 API 并不等于统一 provider 的扩展能力。选型时不能只看“是否支持 Anthropic 或 Google”，还要看业务依赖的工具是否落在目标 provider 的工具命名空间里。

生成式 UI 的接入方式

真正让 AI SDK 区别于普通模型封装包的，是 UI 集成部分提供的完整链路。

README 以图片生成 agent 为例：一个 ImageGenerationAgent 挂上 openai.tools.imageGeneration 工具；Next.js App Router 的 route handler 用 createAgentUIStreamResponse 把执行结果转成响应流；前端通过 @ai-sdk/react 的 useChat 消费消息。消息中的 parts 会区分普通文本与工具调用；对于 tool-generateImage 类型的 part，示例组件根据 invocation.state 显示“生成中”状态或直接渲染 base64 图片。

这个例子的工程含义是：agent 工具的执行状态被编码成可以流式传输的消息部分，前端组件只需要把工具类型和状态翻译成界面。它把“生成式 UI”从概念变成了一种具体约定：服务端执行工具、客户端渲染工具视图、中间用带类型的消息连接。

还要提醒一个容易混淆的点：README 总述里的目标框架包括 Angular，但 UI hooks 段落写的是 Next.js、React、Svelte 和 Vue，并称这些 hooks 是 framework agnostic。Angular 团队不应只根据总述下结论，UI hooks 在 Angular 中的支持程度需要到 AI SDK UI 专项文档里确认。

选型前需要继续验证的部分

把 README 摊开看，AI SDK 在工程上的构成已经比较清楚：一个统一模型入口、一种结构化输出方式、一套 agent 工具编排模型，以及一组连接前端框架的 UI hooks。它没有做业务层的事：工具执行环境、数据来源、安全边界和最终 UI 展示都由应用代码负责。

因此，选型检查的重点不是“能否跑通 demo”，而是四个问题：两条 provider 接入路径哪一条更符合生产环境的网络与数据要求；业务真正依赖的工具是否被对应 provider 包暴露；结构化输出与 agent tools 的失败、重试和长任务行为是否能满足业务；以及技术栈对应的 UI hooks 是否已经达到团队需要的维护状态。

另外，README 没有展开的细节，应当回到官方 Documentation、API Reference 和模板页去验证。AI SDK 给出了一个相当完整的 TypeScript AI 应用构建起点，但工具链越完整，团队越需要确认默认值是否适合自己的部署环境与业务边界。