vercel/ai 在 GitHub 上的自我描述是「The AI Toolkit for TypeScript」，由 Next.js 团队参与创建，定位为免费开源库，用于构建 AI 应用与 Agent。它的 topics 覆盖 openai、anthropic、gemini、language-model、llm、nextjs、react、svelte、vue、generative-ui 等方向。这些元数据本身已经说明了一件事：它不是某个模型厂商的 SDK，而是试图在 TypeScript 生态里做一层跨 Provider 的工具链。对正在选型的开发者来说，关键不是「它支持多少模型」，而是它把哪些问题收进了抽象层，又把哪些问题留给了你。
先看它明确给出的架构事实。README 称 AI SDK 是 provider-agnostic 的 TypeScript 工具包，支持 Next.js、React、Svelte、Vue、Angular 等 UI 框架，以及 Node.js 等运行时。安装要求 Node.js 22+，核心包是 npm install ai。它提供统一 API 来对接 OpenAI、Anthropic、Google 等模型提供方。默认情况下，AI SDK 使用 Vercel AI Gateway，只需传入模型字符串即可调用，例如 model: 'anthropic/claude-opus-5.5'。如果不想走网关，也可以直接安装厂商 SDK 包，例如 @ai-sdk/openai、@ai-sdk/anthropic、@ai-sdk/google，然后以 anthropic('claude-opus-5-5') 这样的形式传入模型。
这两条路径的取舍值得在选型时想清楚。走 Gateway 的写法更短，模型字符串统一，切换 Provider 的成本低；直连厂商 SDK 则把鉴权、配额、网络路径和厂商特性掌握在自己手里。README 没有展开说明 Gateway 的计费、限流、数据留存或故障转移策略，因此这些属于需要自行验证的边界，不能默认它替你解决了。
统一 Provider 架构之外，README 展示了三类典型用法。第一类是文本生成，generateText 返回 text。第二类是结构化数据生成，通过 Output.object 配合 zod schema，让模型输出符合类型定义的对象，示例中生成了一份包含 name、ingredients、steps 的菜谱结构。第三类是 Agent，使用 ToolLoopAgent，示例里定义了一个带 shell 工具的沙箱 Agent，工具执行逻辑由开发者提供，例如调用 Vercel Sandbox 运行命令并返回 stdout。
这里有一个容易被忽略的边界：ToolLoopAgent 的「循环」由 SDK 负责编排，但工具真正做什么、在什么环境里执行、失败如何回滚，仍然是应用侧的责任。README 中的 shell 示例把命令执行交给沙箱，这暗示了安全边界应当由外部环境承担，而不是依赖 SDK 本身。选型时需要确认：工具调用的超时、重试、并发和错误传播策略是否满足你的场景。
生成式 UI 是另一个卖点。README 说明 AI SDK UI 模块提供一组 hooks，用于构建聊天机器人和生成式用户界面，这些 hooks 是框架无关的，可用于 Next.js、React、Svelte 和 Vue，按框架安装对应包，例如 @ai-sdk/react。示例中，Agent 通过 createAgentUIStreamResponse 在 Next.js App Router 的 route handler 中流式返回，前端用 useChat 消费消息，并按 message.parts 的类型分发渲染：文本走 text，工具调用走 tool-generateImage，再由 UIToolInvocation 组件根据 invocation.state 渲染「生成中」或最终图片。
这套模式的价值在于把「模型输出」和「UI 状态」用类型串起来。InferAgentUIMessage 从 Agent 定义推导消息类型，工具调用的输入输出因此能在组件层获得类型提示。但这也意味着你的前端需要接受一种以 parts 为中心的消息结构，而不是传统的纯文本消息。如果现有系统已经有自己的消息协议，迁移成本需要评估。
README 还提到为编码 Agent 准备的 skill，可以通过 npx skills add vercel/ai 加入仓库，以及面向不同用例、Provider 和框架的 templates。这些属于降低上手成本的配套，不改变核心架构判断。
回到选型本身，可以按以下清单逐项验证，而不是只看 README 的示例是否优雅：
- Provider 策略：默认走 Vercel AI Gateway 还是直连厂商 SDK？网关的可用性、计费和数据策略是否可接受？
- 模型抽象边界：统一 API 覆盖了哪些能力，哪些厂商特有参数需要透传或降级？
- 结构化输出：
Output.object与 zod 的组合在你的模型上是否稳定，schema 复杂度上限在哪里？ - Agent 边界：
ToolLoopAgent的循环终止条件、工具错误处理和人工介入点如何配置？ - 工具执行安全：shell、代码执行等高风险工具是否运行在隔离环境中，权限如何收敛？
- UI 集成：
useChat与 parts 消息结构是否与现有前端架构兼容，流式渲染的降级方案是什么？ - 运行时约束：Node.js 22+ 的要求是否与你的部署环境一致，边缘运行时是否支持？
- 可观测性：请求、工具调用和流式响应的日志与追踪由谁提供，是否需要自行埋点？
需要强调的是，以上第 1、3、4、5、8 项在 README 中并没有给出完整答案，它们属于工程侧必须自行验证的部分。vercel/ai 的公开定位清晰：它把多 Provider 接入、语言模型调用、Agent 编排和生成式 UI 收进了一套 TypeScript 优先的抽象。但抽象层越厚，越需要确认它在你的失败模式下的表现。选型的正确姿势不是问「它流不流行」，而是拿你的真实用例去压它的边界。