如果一个 TypeScript 项目要同时接 OpenAI、Anthropic 和 Google常见做法是自己写一层适配器把各家 SDK 的调用参数和返回结构抹平。vercel/ai 的 README 给出的方案是把这层抽象直接放进工具包同一个 generateTextmodel 参数既可以写成 anthropic/claude-opus-4.6 这样的字符串也可以换成 anthropic(claude-opus-4-6) 这类 SDK 实例。AI SDK 的自我描述是 provider-agnostic TypeScript toolkit用于构建 AI-powered applications and agents明确列出的 UI 框架是 Next.js、React、Svelte、Vue、Angularruntime 提到 Node.js。安装门槛写得很具体Node.js 22以及 npm 或其他包管理器主包安装命令是 npm install ai。两条 Provider 接入路径README 的 Unified Provider Architecture 一节给出两条路径。默认情况下 AI SDK 使用 Vercel AI Gateway因此只需传一个模型字符串const result await generateText({ model: anthropic/claude-opus-4.6, prompt: Hello!, });也可以绕过 Gateway 直连 provider安装对应 SDK 包README 举的例子是 ai-sdk/openai、ai-sdk/anthropic、ai-sdk/google再按 provider 包裹模型名import { anthropic } from ai-sdk/anthropic; const result await generateText({ model: anthropic(claude-opus-4-6), prompt: Hello!, });从工程角度看这两条路径的差别不只是用不用网关。字符串形式把 provider 选择推迟到运行时配置模型名以 provider/model 的形式出现SDK 形式把 provider 变成 import 的模块构造过程落在代码里。前者适合模型需要可切换、凭据集中管理的场景后者适合需要 provider 特有参数或不想引入中间层的场景。README 没有说明两条路径在能力覆盖上是否完全等价这一点在接入前需要自行验证。结构化输出与类型系统README 的结构化数据示例把 zod schema 直接交给 Output.objectconst { 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., });这里值得注意的不是支持结构化输出本身而是 schema 作为调用参数出现模型输出的形状与 TypeScript 的类型描述共用同一份定义。对表单填充、配置生成这类任务这比在调用之后再做一次解析加校验更容易收敛。Agent 定义与 UI 消息类型是同一套README 的 Agent 示例用 ToolLoopAgent 定义 agenttools 字段里放具体工具。两个例子分别是 openai.tools.localShellexecute 中通过沙箱执行命令示例注释指向 Vercel Sandbox和 openai.tools.imageGeneration({ partialImages: 3 })。关键连接点在类型导出上export type ImageGenerationAgentMessage InferAgentUIMessage typeof imageGenerationAgent ;这个类型在 Next.js App Router 的 route handler 里被 createAgentUIStreamResponse 使用在前端则被 useChat () 使用。也就是说agent 定义在服务端消息类型推导到客户端两端共用。前端渲染逻辑同样值得看messages 中每条消息有 parts 数组遍历时按 part.type 分支text 渲染文本tool-generateImage 渲染工具调用视图。工具视图组件接收 UIToolInvocation并按 invocation.state 分支示例处理了 input-available 和 output-available 两个状态图像结果在示例中以 base64 数据放进 img 标签。对做生成式 UI 的团队来说这个结构说明了一件事工具调用的中间状态被建模成消息的一部分而不是藏在某个 loading 变量里。这直接决定 UI 能表达什么——参数已就绪但结果未返回和结果已返回是两个可以分别处理的状态。README 里没有回答的部分以下内容在当前 README 中并未展开。如果有实际依赖需要到文档或源码确认不能从给出的示例外推不同 provider 之间工具调用能力如何归一化。示例中的 localShell 和 imageGeneration 都来自 openai.toolsREADME 没有说明其他 provider 是否有对等实现。ToolLoopAgent 的循环终止条件、步数上限、错误重试策略。Vercel AI Gateway 与直连 provider 在鉴权、配额、计费上的具体差异。流式传输的协议细节以及 createAgentUIStreamResponse 返回的数据格式。Angular 在 UI 集成中的位置。框架支持列表包含 Angular但 UI 集成一节明确列出的是 Next.js、React、Svelte、Vue并说明 hooks 是 framework agnostic。另外README 建议使用 coding agents 的团队把 AI SDK skill 加进仓库npx skills add vercel/ai对象是 Claude Code、Cursor 这类工具。这个入口本身说明项目把让编码代理理解 SDK 用法当作安装流程的一部分。评估同类工具包时的检查项如果正在对比 AI 工具包可以从这份 README 中提取几个可验证的问题统一抽象覆盖到哪一层。AI SDK 覆盖模型调用generateText和结构化输出Output.object更细的 provider 专有参数是否可透传需要验证。类型是否从服务端贯通到客户端。这里给出的答案是 InferAgentUIMessage 加 useChat。工具调用状态是否可渲染。看 UIToolInvocation 的状态分支与消息 parts 的组织方式。默认接入路径是否引入额外依赖。默认走 Vercel AI Gateway会影响部署与凭据管理方式。运行时要求。README 写明 Node.js 22。README 也说明了作者信息由 Vercel 和 Next.js 团队成员创建接受开源社区贡献。真正决定是否采用的仍然是上面这些具体机制能否对上现有架构——尤其是工具调用和 provider 差异这两块README 只给了入口没有给结论。