一条 part 分支，给出生成式 UI 的设计前提
消息流里出现'tool-generateImage'时，UI 层要决定渲染什么。官方示例的做法是分支：
case 'text': return <div key={index}>{part.text}</div>; case 'tool-generateImage': return <ImageGenerationView key={index} invocation={part} />;这段代码背后是对“生成式 UI”的一种设计取舍：模型没有把组件代码写进消息流，模型只是触发了一个开发者预先注册的工具调用，前端拿到这个结构化 part 后，从本地组件实现中选出ImageGenerationView。真正被“生成”的，是消息流中的文本与工具输出；UI 容器仍受开发者声明的组件清单控制。
这个示例来自 Vercel AI SDK。README 给自己的定义是 provider-agnostic TypeScript toolkit：面向 AI 应用与 Agent，覆盖 Next.js、React、Svelte、Vue、Angular 等 UI 框架和 Node.js runtime，要求 Node.js 22+。项目作者是 Vercel 与 Next.js 团队成员，并接受社区贡献。如果你只把它当作一个 LLM 调用封装，会忽略它真正想解决的问题：让 AI 应用与 Agent 的前后端交互拥有一套统一、类型化的数据结构。
若你使用 Claude Code、Cursor 这类编码 Agent，官方还建议在仓库中加入对应的 skill：npx skills add vercel/ai。这算是项目对“Agent 对话工程化”的自我定位细节。
Provider 接入有两条默认不同的路径
接入模型时，README 展示了两种写法。第一种直接传模型字符串：
const result = await generateText({ model: 'anthropic/claude-opus-4.6', // 或 'openai/gpt-5.4', 'google/gemini-3-flash' prompt: 'Hello!', });这段代码下方注明：默认情况下，AI SDK 使用 Vercel AI Gateway 接入各主要 Provider。因此这里有一个需要提前确认的工程边界：最简写法并不等价于请求直连模型厂商，默认接入通道是 Vercel 的 AI Gateway。若你的场景要求直连，README 给出的替代路径是安装对应 Provider 的 SDK 包：
import { anthropic } from '@ai-sdk/anthropic'; const result = await generateText({ model: anthropic('claude-opus-4-6'), prompt: 'Hello!', });两种写法并存，给 AI SDK 留出了“默认方便”与“链路可控”的切换空间。但这也意味着选型时就要确定走哪条路：模型字符串方案把 Provider 路由交给网关；直连方案会让代码多一层对 provider SDK 的引用。
从 Agent 工具到前端消息类型的完整链路
在基础生成能力上，README 还出现了几个关键原语：generateText负责文本生成；配合Output.object与 zod schema 可让模型返回结构化数据；ToolLoopAgent则把模型、system prompt 与 tools 组合成一个 Agent 对象。对 TypeScript 团队来说，结构化输出沿用了自己熟悉的 zod 生态，SDK 不必为此引入另一套 schema 语言。
真正把 Agent 与 UI 连接起来的设计，体现在图片生成 Agent 的示例中。Agent 在服务端定义：
export const imageGenerationAgent = new ToolLoopAgent({ model: 'openai/gpt-5.4', tools: { generateImage: openai.tools.imageGeneration({ partialImages: 3, }), }, });随后通过InferAgentUIMessage把 Agent 的工具集合直接推导为前端消息类型：
export type ImageGenerationAgentMessage = InferAgentUIMessage< typeof imageGenerationAgent >;服务端路由把请求接到 Agent 的响应通道上：
export async function POST(req: Request) { const { messages } = await req.json(); return createAgentUIStreamResponse({ agent: imageGenerationAgent, messages, }); }前端useChat<ImageGenerationAgentMessage>()拿到消息后，对message.parts做类型分支。对应的图片生成组件，接收的 prop 类型直接来自工具本身：
import { openai } from '@ai-sdk/openai'; import { UIToolInvocation } from 'ai'; export default function ImageGenerationView({ invocation, }: { invocation: UIToolInvocation<ReturnType<typeof openai.tools.imageGeneration>>; }) { switch (invocation.state) { case 'input-available': return <div>Generating image...</div>; case 'output-available': return <img src={`data:image/png;base64,${invocation.output.result}`} />; } }从官方 README 的图片生成示例可看出，“生成式 UI”的一种实现模式是：服务端声明 Agent 的工具集，工具类型被InferAgentUIMessage推导到前端；前端每个工具 part 对应一个组件；组件又通过invocation.state感知工具在服务端的执行阶段。模型只在“选择哪个已注册工具、生成什么内容”上有自由度，不再有“生成任意组件结构”的自由度。
这套边界适合什么场景
基于 README 的示例，可以提炼出几个可供选型判断的工程结论。
第一，如果你的应用需要 Agent 工具执行结果驱动前端展示，AI SDK 的这套类型链路会省掉大量手写消息协议的功夫。Agent 每增加一个工具，前端消息类型在类型层面会相应扩展；UI 组件只要按约定实现并做分支即可。至于类型推导的具体边界，可进一步用ToolLoopAgent的源码验证。
第二，UI 的可表达范围以“预先注册的工具”为上限。想展示新的界面形态，必须先在 Agent 侧定义工具、再在前端注册对应组件。如果产品需要的不是工具调用型交互，而是模型自由布局式的界面生成，这套把 UI 工具化的模型反而会成为约束。
第三，部署链路不是“开箱即直连”。README 默认接入的是 Vercel AI Gateway；不经过网关的用法需要改用 provider 直连 SDK。README 只在开头声明 Node.js 22+，并未给出边缘 Runtime 或自建网关的说明，这类环境兼容性应在官方文档或最小验证中确认。
如果准备进一步读源码，建议优先验证这几个问题：createAgentUIStreamResponse内部使用什么协议切分流式消息？ToolLoopAgent如何控制循环边界与工具异常？Svelte、Vue 的 UI hooks 与 React 版本的能力是否完全平级？这些问题都无法从当前 README 的示例中获得结论，但决定了 AI SDK 是否值得放进你的长期技术底座。
