generateText 的 model 字段同时接受两种形态：'openai/gpt-5.4' 这样的字符串，或者 anthropic('claude-opus-4-6') 这样的 provider 实例。README 把 AI SDK 定义为 provider-agnostic 的 TypeScript toolkit，用于构建 AI-powered applications 和 agents。对这个项目而言，真正值得拆开看的不是“支持多少模型”，而是这条抽象在代码里如何把 Provider 接入、Agent 循环和 UI 状态串成一条带类型的链路。

Provider 接入的两条路径

第一条路径是默认走 Vercel AI Gateway。传入 model 字符串即可访问所有主要 Provider：

const result = await generateText({
  model: 'anthropic/claude-opus-4.6',
  prompt: 'Hello!',
});

README 中给出的字符串示例包括 anthropic/claude-opus-4.6、openai/gpt-5.4、google/gemini-3-flash。第二条路径是绕开 Gateway，直接安装对应 SDK 包：npm install @ai-sdk/openai @ai-sdk/anthropic @ai-sdk/google，再以 anthropic('claude-opus-4-6') 这类形式调用。两条路径共用同一套上层 API，这是 provider-agnostic 定位在代码层面最直接的体现。

需要注意的是，这些 model 字符串只是 README 中的示例写法，并非该版本锁定的模型清单。选型时更应关注的是：当团队需要切换 Provider 时，改动是否只发生在 model 参数或 provider 工厂函数这一层，而不会穿透到业务逻辑。

安装前置与开发辅助

README 明确的前置条件是 Node.js 22+ 和 npm（或其他包管理器），核心包通过 npm install ai 安装。针对使用 Claude Code 或 Cursor 这类 coding agents 的场景，README 推荐执行 npx skills add vercel/ai，把 AI SDK 相关的 skill 加进仓库。这属于 README 明确提供的开发工作流入口，而不是业务运行时能力，两者不宜混为一谈。

生成、结构化输出与 Agent

基础生成由 generateText 承担。结构化输出通过 Output.object 结合 zod schema 实现，README 示例是把 schema 声明为包含 recipe 对象的结构，再从返回结果中取 output。这条路径的价值在于把“模型输出文本”转成“受 schema 约束的对象”，工程上便于下游直接消费。

Agent 侧的核心类是 ToolLoopAgent。README 给出两个定义示例：一个使用 openai.tools.localShell，execute 中通过 getSandbox() 获取 Vercel Sandbox，再执行 runCommand 并返回 command.stdout()；另一个是 imageGenerationAgent，模型为 'openai/gpt-5.4'，工具为 openai.tools.imageGeneration({ partialImages: 3 })。

这里有两个可以观察的工程点。其一，工具的返回值直接进入 Agent 的循环，localShell 示例中返回的是包含 output 的对象，因此工具的返回结构本身就是设计契约的一部分。其二，partialImages: 3 是 imageGeneration 工具在 README 中明确展示的参数名与取值，属于该工具的定义层配置。

UI 层：hooks 与类型契约

AI SDK UI 模块提供一组 hook，用于构建 chatbots 和 generative user interfaces。README 明确说明这些 hook 是 framework agnostic，可用于 Next.js、React、Svelte 和 Vue。安装方式按框架对应包执行，例如 npm install @ai-sdk/react。（页面开头的能力列表中还提到 Angular，但 UI 模块段落只列了 Next.js、React、Svelte、Vue，两者范围不同，引用时不应互换。）

README 展示的完整链路里，类型贯穿了多个文件。Agent 文件导出 imageGenerationAgent，并通过 InferAgentUIMessage 派生出 ImageGenerationAgentMessage；UI 页面用 useChat() 拿到 messages、status、sendMessage。这种写法把 Agent 定义作为类型源头，UI 消息类型由它推导，而不是在 UI 侧手工重复声明。

消息渲染采用 message.parts 遍历。README 示例中处理两类分支：part.type === 'text' 直接渲染 part.text；part.type === 'tool-generateImage' 则交给独立组件，传入的是 part。工具名与 part type 前缀 tool- 的组合关系，在示例里是显式的。

工具 UI 组件接收 UIToolInvocation>。示例中根据 invocation.state 分支渲染：'input-available' 显示“Generating image...”，'output-available' 渲染 base64 图片。这两个状态来自 README 示例，构成一个显式的状态机分支；除此之外的状态未在 README 中列出，实际实现时需要以官方文档为准。

服务端一侧，Next.js App Router 的路由通过 createAgentUIStreamResponse({ agent, messages }) 返回响应，agent 与 messages 作为参数传入。README 未展开该函数内部的流式实现，从命名可以判断它与流式返回相关，但具体机制需要查看文档再下结论。

工程判断与边界

从工程角度看，AI SDK 的接入价值集中在三点。第一，Provider 抽象被压缩成 model 参数一层，通过 Gateway 字符串和 @ai-sdk/* 包两种入口覆盖不同部署偏好。第二，Agent 工具的定义、UI 消息类型和工具 UI 组件的 props 类型形成了可推导的链条，InferAgentUIMessage 与 UIToolInvocation 分别负责 Agent 到消息、工具到组件两端的类型传递。第三，hooks 的框架无关性降低了前端技术栈的绑定成本。

边界同样清楚。README 没有说明 Provider 抽象的内部实现，也没有展开流式输出的缓冲、取消和重试策略，更没有解释 Agent 循环的终止条件与并发行为。这些都需要结合官方文档和源码进一步验证，不能仅凭 README 的示例推断。README 提到的 templates 提供不同用例、Provider 和框架的起点，但模板内容本身不在当前资料范围内。

一个可行的评估做法是：先用最小 generateText 跑通一条 Provider 路径，再切到另一条路径，观察业务代码是否需要改动；随后引入 ToolLoopAgent 并加一个自定义工具，确认工具返回值类型如何流到 UI 组件；最后验证 useChat 的 status 与 invocation.state 在真实异步工具下的切换行为。这三步覆盖了 README 已经明确的部分，剩余不确定项则应回到官方文档核对。