AI 应用的新胶水层

这两年，大家聊 AI 应用，最容易高估的一件事，是模型本身。

好像只要接上一个大模型 API ，产品就自动有了 AI 能力。

但真做过的人很快会发现，模型调用只是最表面的一层。真正耗时间的，往往是后面的胶水工作：

模型怎么切换
流式输出怎么处理
聊天状态怎么维护
工具调用怎么定义和执行
JSON 输出怎么校验
前端怎么展示 tool result
Agent 的执行过程怎么暴露给用户
某一步出错时怎么重试和追踪

这些问题单独看都不性感，但每一个都绕不开。

所以， AI 应用开发其实正在从“调模型 API ”，进入“搭应用栈”的阶段。

而 Vercel 的 AI SDK，想解决的就是这层应用栈里的胶水问题。

它不是模型，而是模型之上的应用层

先说结论：

AI SDK 不是模型，也不是传统意义上的 Agent 平台。它更像一个 TypeScript/JavaScript 生态里的 AI 应用开发工具箱。

它的核心价值，不是帮你“拿到更强的模型”，而是帮你把模型能力更顺地接进产品里。

以前如果你要同时接 OpenAI 、 Anthropic 、 Google 、 xAI 、 Mistral ，通常会遇到一个经典问题：每家 API 都不一样。

参数结构不一样
消息格式不一样
流式输出协议不一样
tool calling 细节不一样
错误处理方式也不一样

做 Demo 的时候，这些问题都能靠硬写解决。

但一旦你准备把 AI 功能放进真实产品，问题就来了：你不可能把业务逻辑永久绑死在某一个供应商上。

今天 GPT 更强，明天 Claude 更稳，后天 Gemini 更便宜。再过几个月，你可能还会想试 DeepSeek 、 Mistral ，甚至本地模型。

所以你真正需要的，不是某一家模型的 SDK ，而是一层统一抽象。

AI SDK 做的第一件事，就是把这种统一接口标准化。

第一层价值：统一模型调用

AI SDK 最基础的一层叫 Core。

你可以把它理解成：负责后端/服务端的模型调用能力，包括：

文本生成
流式输出
结构化输出
工具调用
embedding
rerank
图像、语音等能力

最常见的几个函数是：

generateText
streamText
generateObject
streamObject

比如最简单的文本生成：

import{generateText}from'ai';

constresult=awaitgenerateText({
model:'openai/gpt-5.4',
prompt:'用一句话解释什么是 AI SDK',
});

console.log(result.text);

这段代码本身不复杂，但背后的意义很明确：

你开始用统一方式调不同模型，而不是让业务逻辑直接依赖某个厂商的 SDK 。

这件事听上去朴素，但它其实是 AI 应用工程化的起点。

因为从这一步开始，你写的不再是“ OpenAI 项目”或“ Claude 项目”，而是一个可以替换底层模型的应用。

第二层价值： AI 应用默认是流式的

如果说普通 Web 应用最重要的体验是响应速度，那 AI 应用最重要的体验之一，就是流式输出。

用户已经被 ChatGPT 训练过了。他们默认认为，一个 AI 助手应该一边思考，一边往外吐结果，而不是黑屏十秒后一次性返回一大段文字。

所以，流式输出几乎是 AI 产品的默认能力。

问题在于，流式不是“让字一个个出现”这么简单。真正麻烦的是整条链路：

服务端怎么接模型的 stream
怎么转成前端能消费的响应
浏览器端怎么实时更新消息
用户中途停止怎么办
tool call 中间态怎么展示
发生错误时怎么补偿
最终消息怎么落库

这些都属于典型的胶水层问题。

AI SDK 的做法是把这层标准化。

服务端可以这样写：

import{streamText}from'ai';

constresult=streamText({
model:'openai/gpt-5.4',
prompt:'写一段 AI SDK 的产品介绍',
});

returnresult.toUIMessageStreamResponse();

如果你用 React ，前端再配 useChat，就能得到一套比较自然的聊天流式体验。

这层能力的重要性在于：

AI 应用的体验，不只取决于模型输出了什么，也取决于这段输出如何被呈现。

很多团队以为自己在做模型集成，实际上花时间最多的，是前后端之间这条流式协议。

AI SDK 把这部分收拢了。

第三个问题：模型输出不能只有自然语言

很多人刚开始用大模型时，会把它当成一个“高级文本接口”。

你问，它答；你写 prompt ，它回一段自然语言。

但只要你想让 AI 真正进入业务系统，就会马上碰到另一个需求：

模型输出必须是结构化的。

比如这些场景：

从简历里提取姓名、技能、工作年限
从合同里提取金额、甲乙方、付款节点
把用户输入分类成不同意图
给文章提取标题、摘要、标签
把一段自然语言转成表单字段

这些场景里，你不想要一段“看起来差不多”的描述。你要的是一个稳定的 JSON 。

所以 AI SDK 的 generateObject / streamObject 很关键。

你可以直接配 schema ：

import{generateObject}from'ai';
import{z}from'zod';

constresult=awaitgenerateObject({
model:'openai/gpt-5.4',
schema:z.object({
title:z.string(),
summary:z.string(),
tags:z.array(z.string()),
}),
prompt:'提取这篇文章的标题、摘要和标签',
});

console.log(result.object);

这里的意义不是“写法更优雅”，而是：

让模型输出从“给人看”变成“给系统用”。

这是 AI 应用能不能真正落地的分水岭。

如果输出只是自然语言，它通常只能停留在聊天框里。
但如果输出是稳定的结构化对象，它才能流进内容系统、工单系统、 CRM 、审批流、数据管道。

也就是说，结构化输出不是附加能力，而是产品化能力。

第四个问题： AI 一定会走向工具调用

模型本身不会查你的订单，不知道数据库里有什么，也不能直接改业务数据。

所以，只要 AI 应用不是纯聊天，它几乎一定会走向 tool calling。

tool calling 本质上就是：

模型决定要用哪个工具，系统执行工具，再把结果回灌给模型。

比如用户问：

“帮我查一下这个订单为什么还没发货。”

模型不能靠猜。它应该去查真实数据，比如：

查订单状态
查库存
查物流
查仓库异常

这就是工具调用的意义。

AI SDK 支持用 schema 的方式定义工具：

import{tool}from'ai';
import{z}from'zod';

constgetWeather=tool({
description:'Get weather for a city',
inputSchema:z.object({
city:z.string(),
}),
execute:async({city})=>{
returnawaitfetchWeather(city);
},
});

模型拿到这些工具后，就能在适当的时候调用它们。

但真正值得注意的，不是“模型会调函数”这件事，而是它意味着模型开始触碰真实世界。

这时候问题就不只是 API 封装，而会迅速变成工程问题：

哪些工具是只读
哪些工具有副作用
哪些操作需要人工审批
工具失败后怎么办
工具返回的数据是否可信
是否需要审计日志
用户权限如何传递

所以 tool calling 不是一个花哨功能，而是 AI 应用和业务系统之间的边界层。

AI SDK 的价值，是让这层边界变成一种标准开发模式，而不是每个团队自己重新造一遍。

第五个问题： AI 应用的前端状态比想象中复杂

很多后端工程师会低估 AI 应用的前端复杂度。

普通聊天消息，大概就是：

{
"role":"assistant",
"content":"你好"
}

但 AI 应用里的消息，通常远远不止这么简单。

一条消息可能包含：

普通文本
reasoning
tool call
tool result
citation
metadata
进度信息
错误信息
图片、表格、文件等多种 part

更麻烦的是，这些内容往往是流式到达的。

例如一个 Agent 正在工作，它可能先说：

“我先检查一下项目结构。”

接着发起 readFile(package.json)。
然后回传工具结果。
再继续说：

“我发现依赖版本不一致，接下来跑测试。”

这已经不是“聊天气泡”了，而更像一个实时任务界面。

AI SDK 5 之后强调的一个重点，是把 UIMessage 做成更清晰的类型化结构。服务端和前端可以围绕同一种消息形态工作。

这件事非常工程化，但也非常关键。

因为未来很多 AI 产品的 UI ，不会只是“一个会说话的输入框”。

它更像一个任务面板：用户既要看答案，也要看 AI 做了什么、调用了什么、走到了哪一步。

这正是 AI SDK 试图标准化的交互协议。

AI SDK 6 的变化：开始正面进入 Agent

如果说早期 AI SDK 更像“统一模型调用 + 流式 UI ”的工具箱，那 AI SDK 6 的变化就更明显了。

官方对这一版的描述里，重点包括：

agents
tool execution approval
DevTools
full MCP support
reranking
image editing

而且官方给出的定位也很直接： AI SDK 6 要把 Agent 作为一等公民来做。

文档里对 Agent 的定义很清楚：

Agent 是会在工具循环里完成任务的大模型。

也就是：

读取任务
决定下一步
调工具
看结果
判断要不要继续
最后收敛成答案

AI SDK 里推荐的方向是 ToolLoopAgent。
这类抽象适合做：

文档问答 Agent
数据分析 Agent
内容生成 Agent
客服 Agent
后台自动处理任务的 Agent

它和 LangGraph 那种复杂状态图不完全一样。 AI SDK 的 Agent 抽象更轻，更贴近 TypeScript 产品开发。

你可以理解为：

它不是在做一个最强 Agent 框架，而是在把轻量 Agent 能力纳入 Web 应用开发栈。

这点很重要。

因为很多团队真正需要的，不是一个可以画状态机的超级框架，而是一个可以比较平滑地把 Agent 接到聊天 UI 、 API endpoint 、后台任务里的统一接口。

MCP 、 DevTools 、 AI Gateway ：它补的不是功能点，而是整层基础设施

最近 AI SDK 相关文档里，还有三个方向很值得注意。

1 ） MCP

AI SDK 现在支持 MCP （ Model Context Protocol ）相关能力。
文档里已经提供了 createMCPClient() 等接口。

这意味着外部工具可以通过更标准的协议接入，而不是每次都手写自定义封装。

如果你把这个趋势放大看，本质上是：

工具生态正在从私有对接，走向标准协议接入。

2 ） DevTools

AI 应用比普通应用更难调试。

普通应用出错，你查日志、查数据库、查请求链路。
AI 应用出错，可能是 prompt 、上下文、 tool result 、 stream 、 schema 、某一步 reasoning 共同导致的。

所以 AI 应用需要新的调试界面。

AI SDK 文档里已经把 DevTools 放进核心能力里，它的方向很清楚：让你能检查请求、响应、工具调用、多步骤交互和错误路径。

这对生产环境非常重要。

3 ） AI Gateway

AI Gateway 则是在统一模型入口、路由和观测。

官方文档已经把 Gateway 描述成多模型统一入口：通过单一接口访问 OpenAI 、 Anthropic 、 Google 、 Meta 、 xAI 等不同供应商。

如果你在一个产品里要混用多个模型， Gateway 会越来越有吸引力。因为它解决的不只是“怎么调”，而是：

怎么统一接入
怎么切换 provider
怎么做 fallback
怎么控制成本
怎么做观测和计费

也就是说， AI SDK 不只是想做一个 SDK ，它在往 AI 应用基础设施入口 走。

它和 LangChain 、 LangGraph 、 Mastra 不一样

很多人会下意识问一句：

“那它和 LangChain 、 LangGraph 、 Mastra 有什么区别？”

我的理解是，它们的重点不一样。

工具	更像什么
AI SDK	AI 产品接口层
LangChain	通用 LLM 应用框架
LangGraph	Agent 状态机 / 工作流编排层
Mastra	TypeScript Agent / workflow 框架
各家官方 SDK	单一供应商接入层

如果压缩成一句话：

LangGraph 更像 Agent 编排层， AI SDK 更像 AI 产品开发层。

AI SDK 不是最擅长复杂长流程编排的那一个，但它很擅长把模型调用、流式输出、工具调用、前端消息协议这几件事串起来。

尤其是当你的技术栈本来就是 Next.js / React / TypeScript 时，它会很顺手。

它适合谁？

我觉得 AI SDK 特别适合三类团队。

第一类： React / Next.js / TypeScript 团队

如果你的应用本来就是 Web 产品，尤其是 Next.js 技术栈， AI SDK 的接入路径会很自然。

第二类：要把 AI 能力嵌进现有产品的团队

比如你不是要做一个通用 Agent 平台，而是要在自己的产品里加：

AI 客服
AI 搜索
AI 写作
AI 分析
AI Copilot
AI 表单助手

这类场景非常适合 AI SDK 。

第三类：不想被某个模型供应商锁死的团队

如果你想保留模型切换的自由度， AI SDK 这层统一接口会很有价值。

它不适合谁？

当然，它也不是所有场景的标准答案。

不适合复杂长流程编排

如果你要做的是：

多 Agent 协作
长时间运行任务
可恢复工作流
人工审批链路
强状态机控制

那你大概率还需要更重的 workflow / agent runtime 。

不适合 Python-first 团队

AI SDK 的主场是 TypeScript/JavaScript 。
如果团队主要栈是 Python ，那它的吸引力会明显下降。

不适合一次性小脚本

如果只是写个脚本调一次模型，直接用官方 SDK 反而更简单。

AI SDK 的优势在“产品化”，不在“一次性调用”。

AI SDK 真正代表的变化

如果只把 AI SDK 理解成“一个更方便调模型的库”，其实低估了它。

它更大的意义在于：

AI 应用开发开始出现标准栈。

过去大家做 AI 功能，经常是自己拼：

自己接模型
自己搞 stream
自己做聊天状态
自己定义 tool call 协议
自己维护结构化输出
自己调试多步骤执行

每个团队都要把这些轮子再造一遍。

AI SDK 想做的，就是把这层重复劳动标准化。

让开发者把精力从“怎么接”转移到“做什么产品”。

这也是为什么我更愿意把它叫作：

AI 应用的新胶水层。

它不是最底层的模型。
也不是最上层的业务产品。
它站在中间，把模型能力变成开发者能真正嵌进产品的接口。

最后

未来做 AI 应用，大概率不会再是“选一个模型，然后调 API ”这么简单。

真正会留下来的能力，是这整层工程化能力：

模型调用
流式输出
结构化结果
工具调用
Agent 循环
前端消息协议
调试观测
多模型路由

AI SDK 正在试图把这些东西，打包成 TypeScript 开发者熟悉的一层。

所以它代表的，不只是某个库变流行了。

它代表的是一个更大的趋势：

AI 应用开发正在从模型实验，走向产品工程。