在 TypeScript 技术栈里接入大模型，最直接的痛点不是调用某个 API，而是每换一家 Provider 就要重写一遍调用层。OpenAI、Anthropic、Google 的请求体、流式事件格式、工具调用协议各不相同，前端与全栈项目往往被迫在业务代码里散落大量 if-else。vercel/ai（AI SDK）正是针对这个问题给出的开源方案：官方将其定位为 provider-agnostic 的 TypeScript 工具包，用于构建 AI 应用与 agent，支持 Next.js、React、Svelte、Vue、Angular 等 UI 框架以及 Node.js 运行时。
统一接口是它的核心抽象。README 明确说明 AI SDK 提供 unified API 来对接 OpenAI、Anthropic、Google 等模型提供方，并给出两条接入路径。第一条是默认走 Vercel AI Gateway：只需传入一个模型字符串，例如 'anthropic/claude-opus-5.5'，或 'openai/gpt-6-astra'、'google/gemini-3.8-flash'，即可调用受支持的模型。第二条是直连 Provider 的 SDK 包，安装 @ai-sdk/openai、@ai-sdk/anthropic、@ai-sdk/google 后，用 anthropic('claude-opus-5-5')、openai('gpt-6-astra')、google('gemini-3.8-flash') 这样的调用方式把模型实例传给 generateText。两条路径共用同一套上层 API，这意味着切换 Provider 时业务逻辑基本不动，差异被收敛到 model 参数这一层。
从工程取舍看，这两条路径对应不同的部署约束。Gateway 路径的优势是开箱即用、无需为每家 Provider 单独管理密钥与 SDK 依赖，适合快速验证和多模型对比；直连路径则把控制权交回开发者，便于自管凭证、走自有网关或满足特定合规要求。README 没有展开 Gateway 的计费、限流与数据流向细节，这部分需要开发者自行查阅官方文档确认，不能想当然。
统一接口的价值不止于文本生成。README 展示了结构化数据输出：通过 generateText 配合 Output.object 与 zod schema，可以约束模型返回符合类型定义的对象，例如一份包含 name、ingredients、steps 的菜谱。对 TypeScript 项目而言，这把模型输出纳入了类型系统，减少了运行时的解析与校验负担。
Agent 能力同样建立在统一抽象之上。README 给出 ToolLoopAgent 的用法：构造时传入 model、system 提示词和 tools，工具可以是 Provider 提供的预置能力，例如 openai.tools.localShell 或 openai.tools.imageGeneration，也可以是自定义实现。示例中 localShell 的 execute 回调里接入了 Vercel Sandbox 来运行命令并返回 stdout。这说明工具调用被设计成可插拔结构，模型负责决策，执行逻辑由开发者掌控。
UI 集成是另一个关键结合点。AI SDK UI 模块提供一组 hooks，官方强调这些 hooks 是 framework agnostic 的，可用于 Next.js、React、Svelte 和 Vue，使用时按框架安装对应包，例如 @ai-sdk/react。README 的完整示例展示了典型链路：在 agent 文件中用 ToolLoopAgent 定义 imageGenerationAgent 并导出 InferAgentUIMessage 类型；在 Next.js App Router 的 route.ts 中用 createAgentUIStreamResponse 把 agent 与 messages 转成流式响应；前端用 useChat 消费消息，并按 message.parts 的 type 分支渲染文本或工具调用结果，工具部分用 UIToolInvocation 类型约束 invocation.state（如 input-available、output-available）。这条链路把服务端流式输出、工具调用状态和前端渲染串成了可类型推导的整体。
对前端与全栈开发者的选型含义可以归纳为几点。其一，如果项目已经在 Next.js 或 React 生态，AI SDK 的 hooks 与 App Router 集成路径最短，类型推导能覆盖到消息与工具调用。其二，如果团队需要在多个 Provider 间做 A/B 或降级，统一接口显著降低切换成本，但应先用小规模用例验证目标模型在流式、工具调用、结构化输出上的实际行为是否一致。其三，Svelte、Vue、Angular 用户同样被官方列为支持对象，但具体集成机制、hooks 在各框架下的差异，README 未逐一展开，需要查阅对应文档与模板验证。
需要提醒的是，本文所述均来自官方 README 的公开描述。Provider 适配的内部抽象方式、流式响应的具体事件协议、工具调用的错误处理与重试策略、Agent 循环的终止条件等实现细节，README 并未给出，不能当作既定结论。建议的验证路径是：先跑通 generateText 的 Gateway 与直连两种写法，再逐步加入结构化输出、工具调用与 UI 流式渲染，逐层确认行为边界。