vercel/ai

如果你在用 TypeScript/JavaScript 做基于大模型的应用，这是目前比较成熟的一个起点。但要先想清楚走哪条服务商通道：默认路线经过 Vercel 的付费网关，这会直接影响你的账号和账单。

解决什么问题

团队要在 Next.js 或 React 应用里加一个聊天或智能体功能，很快会撞上一堆琐事：每家服务商的 SDK、消息格式、流式协议和工具调用方式都不一样。换一个模型就得重写胶水代码；把流式返回接到聊天界面上，又得给每种消息片段手工维护状态。

用这个库之后，文本生成和流式调用走同一套与服务商无关的接口，前端用框架 hooks 处理界面状态。团队要换模型时改的是模型标识，而不是应用代码；结构化输出和工具调用展示也不用从零搭。

有什么不同

核心是一层统一的服务商抽象：同一个调用签名覆盖文本生成、结构化对象、智能体和工具调用。前端方面，useChat 这类 hooks 不绑定框架，Next.js、React、Svelte、Vue 都能用；消息按类型拆成多个 part，工具调用可以单独渲染。示例里的智能体能挂图片生成或 shell 工具，服务端到组件的类型保持一致。

代价主要在默认路由上。传入 anthropic/... 这样的模型字符串时，默认走 Vercel AI Gateway，开箱就能访问多家服务商，但你的 Vercel 账号和余额也进入了请求链路。要绕开它，就按 README 的方式安装各家单独的包，直接构造模型对象。这是一个真实的架构取舍：便利和集中计费，还是自己掌控凭证与流量。另外它只是一层库，不负责托管、日志或护栏，发什么、记什么、付多少仍然是你自己的责任。

谁值得试

比较合适的是：已有 TypeScript Web 技术栈，要在产品里做聊天、助手或带工具的智能体，并且预期会先试几家模型再定下来。统一接口和框架 hooks 的价值，主要体现在前后端需要紧密配合的场景。

不太合适的是：想要完全直连服务商、不接受中间层的团队，或者主应用不是 JavaScript/TypeScript 的团队——虽然可以直连各家包，但周边生态仍按 JS 技术栈设计。如果只是后端脚本里调用一次模型，UI 和智能体这两层可能用不上。

使用条件与边界

需要 Node.js 22+ 和包管理器。各家服务商的包要分开安装，多用几家就多几个依赖要跟进。这个库迭代很快，接口有过调整，依赖特定智能体或输出 API 的话建议锁版本。

更需要注意的是账号与计费：走默认网关时，Vercel 余额决定请求能不能执行。2026-06-02 有一条 HN 讨论 质疑：用户自己带服务商的 key 时，为什么还要由 Vercel 余额决定请求是否执行。这反映的是默认路线的体验，不是经过验证的缺陷，README 给出的应对是直连服务商。上手前先确认请求怎么路由、怎么付费。

HotRepo 点评

记录到的两个上榜日是：2026-10-24 有 27,498 星（当日 +16），2026-10-25 有 27,500 星（当日 +12）。这只是一段有时点的快照，还不足以判断热度能否持续。如果你用 TypeScript 且想要多服务商的灵活性，值得上手；但在决定走网关之前，先读 服务商文档，确认你环境里的路由和计费方式。