在 AI 应用开发的初期，我们往往会被那种“打字机效果”的流式输出迷得神魂颠倒。kan着文字一个接一个地蹦出来仿佛拥有了生命。于是我们兴致勃勃地打开编辑器，开始手写 SSE服务，自己处理 `response.body` 的读取器，自己拼接字符串。Demo 跑通了效果hen棒，但当你真正试图把这个 Demo 搬进生产环境，去构建一个类似 ChatGPT 的完整聊天应用时噩梦才刚刚开始。

说实话，生产环境里极少有人会坚持从头到尾手写流式响应。这倒不是因为大家变懒了而是因为那里面藏着的坑，比你想象的要深得多。今天我们就来聊聊为什么我们要从手写流式切到像 Vercel AI SDK 这样的工具，以及这背后那套精妙的三层架构是如何拯救我们的发际线的。

当“流”不仅仅是文字：手写流式的隐形陷阱

hen多人一开始的误区在于，以为流式响应就是“把字吐出来”。Ru果你只是Zuo一个简单的“一言”生成器，那确实没问题。但一旦涉及到多轮对话、工具调用、错误处理，手写流的复杂度就会呈指数级上升。

Zui让人头疼的是边界问题。网络传输过来的数据块是物理层面的切分，它根本不懂什么叫业务逻辑的完整性。一个中文字符可Neng被无情地拆分在前后两个 chunk 里Ru果你直接拿去解析，屏幕上就会显示乱码；geng糟糕的是Ru果模型返回的是 JSON 格式的工具调用参数，你只拿到了半截就急着 `JSON.parse`，服务端直接给你抛个异常，整个对话瞬间崩盘。

这时候你还得自己去处理 SSE 的协议细节：按 ` ` 切分事件、挑出 `data` 字段、识别结束标记 ``。这些代码写起来枯燥，改起来容易出错，而且跟你的核心业务逻辑毫无关系。你会发现，花时间的地方不再是业务，而是这些重复又容易出错的细节。

而且，Ru果流里只有字，浏览器根本没法区分哪段是思考、哪段是工具调用、哪段是错误、哪段是Zui终回答。前端就像一个盲人，只Neng被动地接收一串字符流，根本不知道当前 AI 到底是在“干活”还是在“发呆”。这种体验上的断层，是手写流式难以逾越的鸿沟。

餐厅经营哲学：AI SDK 的三层架构解密

为了解决这些乱七八糟的问题，Vercel AI SDK 提出了一套非常清晰的架构模式。为了方便理解，我们不妨把构建一个 AI 应用比作经营一家餐厅。

一家餐厅要正常运转，得有三个关键角色：供应商、后厨、前台。AI SDK 的设计逻辑几乎就是原封不动地搬了过来。

第一层：供应商与收货台

你得有食材。在 AI 领域，这就是各大模型厂商——OpenAI、Anthropic、DeepSeek 等等。但问题来了不同供应商送来的东西规格千差万别。有的按斤，有的按箱，包装单据也dou不一样。

DeepSeek 是一家独立的大模型公司，它的 API 形状和 OpenAI 高度兼容，但这并不意味着所有厂商dou这么乖。Claude 就走的是另一条路，它有自己独立的 API 形状，路径、鉴权 header、事件类型、字段结构dou和 OpenAI 不一样。

Ru果后厨每接一家就要重学一遍人家的规矩，这家餐厅根本开不起来。所以稍微大一点的餐厅dou会有一个收货环节。不管哪家供应商送来的，dou按统一的规格入库。

在代码里这就是 provider 和 adapter 干的事。比如 DeepSeek，虽然它不是 OpenAI，但只要协议对得上，我们就Ke以用 @ai-sdk/openai-compatible 这个包来接：

import { createOpenAICompatible } from '@ai-sdk/openai-compatible';
export function createDeepSeekAiSdkProvider {
    return createOpenAICompatible({
        name: 'deepseek',
        apiKey: process.env.DEEPSEEK_API_KEY!,
        baseURL: process.env.DEEPSEEK_BASE_URL ?? 'https://api.deepseek.com'
    });
}

你kan，@ai-sdk/openai-compatible 根本不在乎对面是 OpenAI 还是 DeepSeek，它只kan协议形状对不对，给它配上 baseURL 和 apiKey 就行。而像 Claude 这种特立独行的，就走 @ai-sdk/anthropic 专门适配。这一层先替你接住的，不是页面而是上游模型 API 的差异。

第二层：后厨的标准化烹饪

食材收进来统一规格后就进了后厨。后厨不关心这块牛肉是哪家送的，它只认入库后的规格，按照统一的菜单Zuo菜，再按统一的餐具盛出来。

对应到代码里这就是你的服务端入口。在这里AI SDK Zuo了两件极其重要的事：“进去翻一次、出来也翻一次”。

模型只认扁平的 role + content，但前端传来的往往是复杂的 UI 消息结构。这时候，convertToModelMessages 就像翻译官，把前端消息格式翻成模型Neng认的格式：

import { convertToModelMessages, streamText, type UIMessage } from 'ai';
export async function POST {
    const { messages }: { messages: UIMessage } = await req.json;
    const result = streamText({
        model: deepseek.chatModel,
        messages: await convertToModelMessages
    });
    return result.toUIMessageStreamResponse;
}

这里streamText 负责调模型拿流式结果，而 toUIMessageStreamResponse 则是把模型流再翻回前端Neng消费的事件流。

原来这层里那一坨读流、缓冲、拼字符串的代码，现在基本就剩调一个函数加返回一个函数。你不用再自己读 response.body，也不用自己一边拼字符串，一边维护 isStreaming 什么时候开、什么时候关。模型原始 SSE 里文本增量走的是厂商自己的字段路径，结束信号也走的是厂商自己的结束格式，全部被 provider adapter 加 streamText 在内部接走了。

Zui后那条“怎么把结果回给前端”的统一响应，则由 toUIMessageStreamResponse 接走。它把混乱的厂商，统一翻译成了前端听得懂的标准语。

第三层：前台的记忆与服务

菜Zuo好了得端给客人。前台的工作又是另一回事。它不Zuo菜，但它要记住这一桌点了什么、上到第几道、客人有没有催菜、Neng不Neng换菜。

在手写版里我们通常会用一个简单的 useState 来存答案：

const  = useState;
const  = useState;

这种写法在单轮对话里kan着挺清爽，但一旦需求里出现多轮历史、重生成、从中间分叉，每条消息还得分清是用户还是 AI、是文字还是工具调用、有没有完成，这一串东西塞不进一个字符串里。一段字符串记得住一句话，记不住一段对话。

这时候，useChat 的价值就体现出来了。它接住的是请求发送、流读取、消息追加、状态流转这一整套逻辑：

const { messages, sendMessage, status } = useChat({
    transport: new DefaultChatTransport
});

useChat 接的是聊天状态，不是聊天页面长相。它暴露的不是 answer，是整个 messages 数组。输入框 state、消息怎么渲染、错误 UI 怎么展示、按钮什么时候禁用、滚动什么时候到底，这些还是业务自己决定。但 useChat 帮你把底层的脏活累活全干了。

为什么说“少用手写”？因为那是无底洞

讲完这三层架构，我们再回过头来kan标题的问题：为什么生产环境hen少手写流式响应？

因为手写版的问题不是不Neng跑，是你一旦从 demo 往真实聊天应用走，就得在协议和状态这两层各造一套自己的基础设施。

你Ru果每次dou直接对着厂商 API 写代码，hen快就会反复写这一家怎么接、那一家怎么接。geng可怕的是当你想要加功Neng时你会发现地基没打好。

举个例子，“重生成”功Neng。在手写版里这件事通常不是再发一次请求这么简单，你得先砍掉Zui后一条 answer把字符串状态倒推回消息数组、再补重发逻辑。而 AI SDK 这边，messages 数组本来就记着每条消息，调一个方法的事。

再比如结构化事件流。打开浏览器 DevTools kan一眼真实返回流会geng直观。SDK 把回流Zuo成了结构化事件流，每个事件dou带 type: "text-delta" 或 type: "tool-call" 这种标签：

{"type":"text-delta","id":"txt-","delta":"Vercel"}
{"type":"text-delta","id":"txt-","delta":" AI"}
{"type":"text-end","id":"txt-"}
{"type":"finish-step"}
{"type":"finish","finishReason":"stop"}

前端kan到什么 type 就走什么分支。中途抛错要让 UI 识别这不是回答内容，结束时还要有一个明确信号解锁输入框。这些工作原本和业务没一点关系，但不接住一个，整条链就走不通。

从 Demo 到生产：必须要跨过的坎

手写流式响应跑通之后往真实聊天应用走，会被两件事情拖住：一是原来服务端那坨 chunk 拼接、JSON 兜底、字段路径的代码，不用再kan第二眼，协议那层不用碰了；二是后面再冒出“重生成”“从某条消息重开”这类需求的时候，你不用先回头重构 state，useChat 暴露的 messages 数组Yi经为这些需求打好地基了。

把 answer 这种单字符串状态换成 useChat 和 messages，后面多轮、重生成、分叉、工具调用才有稳定地基。

省下来的不只是代码行数，geng像是脑子不用再同时装怎么读流和怎么记对话这两件事。AI SDK 把这两类工作，分散到三个位置接走：provider adapter 负责接模型，streamText 负责调模型和回流，useChat 负责前端状态。

未来的挑战：当对话越来越长

当然切到 SDK 并不是终点。多轮对话Zuo起来hen快会碰到另一个问题：聊到后面AI 开始降智了！刚纠正过的要求下一轮没记住修好的 bug 出现，明确说过不Zuo的功Neng又被提起来。

原因在上下文这件事情上：聊长了发给模型的内容越来越重，重点开始被淹没。OpenAI、Claude 等大模型的 HTTP 接口其实dou没有会话这个概念，每次请求dou得把整段对话历史重新喂一次，模型拿到数组那一刻才“恢复”出上下文，生成完立刻丢掉。

所以这条链上的服务端入口每次dou是全新的、无记忆的，它只是个转发层，状态落在前端的 messages 数组里。对话越来越长之后这个数组也会越来越大，token 吃不消了怎么办、记忆怎么维护，这是下一篇要讲的事。

今天聊的是 为什么要从手写切到 Vercel AI SDK。这不仅仅是一个工具的选择，geng是一种工程思维的转变。

从模型怎么接进来、服务端怎么调模型、到前端怎么维护对话状态，整条链dou覆盖了。原来手写版那一大坨读流、缓冲、拼字符串的代码，基本dou被这三个函数接走了。服务端轻下来的不是业务逻辑，是那些重复的流式协议处理。

所以真正少的不是代码行数，是你不用自己从零搭一套消息结构。当你下次再想手写流式响应时不妨先问问自己：我是真的想写一个解析器，还是只想Zuo一个Neng用的 AI 应用？

感谢您的阅读～🌹

---