1. 从“一问一答”到“边想边说”流式交互的本质如果你做过传统的聊天应用或者调用过OpenAI的早期接口你一定熟悉那个模式前端把用户的问题打包成一个请求发送给后端后端拿着这个问题去调用大模型API模型吭哧吭哧地“思考”几秒甚至十几秒然后把完整的答案一次性吐出来后端再把这个完整的答案返回给前端前端一次性渲染出来。整个过程就像两个人发邮件一来一回中间是漫长的等待用户盯着一个空白的输入框或者一个转圈的加载图标心里没底。这种“一问一答”的批处理模式在生成短文本时还行但面对大模型生成长内容比如一篇故事、一段代码、一个复杂的分析时体验就非常糟糕了。用户不知道后端是卡住了还是在工作只能干等。而“边想边说”的流式传输彻底改变了这个交互范式。它的核心思想是后端一旦从大模型那里拿到第一个“词元”token就立刻推送给前端而不是等所有词元都生成完毕。这带来的体验提升是颠覆性的。用户几乎在发送问题后的瞬间就能看到第一个字开始“流”出来然后逐字、逐句地补全。这个过程模拟了人类对话的节奏消除了等待的焦虑也让应用感觉更加“智能”和“实时”。Vercel AI SDK 正是为了简化这种“边想边说”的复杂实现而生的一个工具包它封装了前后端处理流式数据的脏活累活。那么这个“流”到底是怎么流的前端怎么知道数据来了后端又怎么把模型生成的一串数据变成持续的“溪流”这背后依赖的是一种名为Server-Sent Events (SSE)的技术协议。很多人会把它和 WebSocket 搞混但它们的定位截然不同。WebSocket 是双向通信协议适合聊天室、实时游戏这种需要前后端高频互发的场景。而 SSE 是服务器向客户端单向推送的协议完美契合了“服务器生成内容持续推给客户端”的流式响应场景。它基于普通的 HTTP实现更简单天然支持自动重连是流式 AI 响应的“官配”。接下来我们就深入这个“流”的内部看看 Vercel AI SDK 是如何利用 SSE在前端和后端之间搭建起这条“边想边说”的高速通道的。2. 协议基石SSE 是如何工作的要理解 AI SDK 的流式协议必须先把 SSE 的原理吃透。SSE 不是一个多么新奇的技术它其实是 HTML5 标准的一部分只是在前些年实时通信被 WebSocket 的光芒掩盖了。但在流式输出这个特定场景下SSE 的优势非常明显。SSE 连接始于客户端的一个普通 HTTP GET 请求但有几个关键的头信息HeadersAccept: text/event-stream 这是最重要的告诉服务器“我准备接收事件流了别把连接马上关了。”Cache-Control: no-cache 确保不缓存响应。Connection: keep-alive 保持长连接。服务器收到这个请求后会返回一个状态码为 200 的响应并设置Content-Type: text/event-stream。此时HTTP 连接并不会像普通请求那样在返回数据后立即关闭而是会一直保持打开状态。服务器可以随时通过这个连接向客户端发送数据块。数据块的格式有严格的规范它不是随便的 JSON 字符串。一个标准的 SSE 数据块看起来是这样的event: message data: {content: Hello, type: token} data: This is a data: multi-line data: message : this is a comment lineevent: 事件类型。客户端可以根据不同的事件类型进行不同的处理。最常见的类型是message。AI SDK 也可能会定义自定义事件如tool_call。data: 数据行。这是核心内容。如果一个消息的数据有多行每行都要以data:开头。最终客户端会将所有data:行用换行符连接起来作为一个完整的数据段。注意数据本身必须是纯文本所以复杂的对象需要被JSON.stringify成字符串。空行 一个数据块的结束标志。当客户端收到一个空行即连续的两个换行符\n\n时就会触发一次MessageEvent将之前累积的data内容作为event.data传递给前端的事件监听器。: 冒号开头的行是注释会被客户端忽略。为什么是 SSE 而不是 WebSocket成本与复杂度。对于 AI 流式响应这种典型的“服务器主动推客户端被动收”的场景WebSocket 的双工能力是过剩的。SSE 基于 HTTP无需额外的协议升级握手更轻量浏览器原生支持EventSourceAPI开箱即用并且自动处理连接重试。在 AI SDK 的语境下前端只需要监听message事件就能源源不断地收到后端推送过来的模型生成的 token。注意 一个常见的误区是认为流式传输能极大减少整体响应时间。实际上模型生成所有 token 的总计算时间几乎是固定的。流式传输的核心价值在于降低了“首字响应时间”并将漫长的等待过程转化为一个持续的、有反馈的输入过程从而极大提升了用户体验的“感知速度”和流畅度。3. 后端视角从模型输出到 SSE 流现在我们站到后端的角度。你的服务器收到了一个带有聊天消息列表的 POST 请求需要调用 OpenAI、Anthropic 或本地的 Ollama 等大模型并开启流式输出。这个过程可以分解为几个关键步骤。3.1 接收请求与构造提示首先后端需要从请求体比如 JSON中解析出用户的输入消息、对话历史以及可能的参数如模型名称、温度 temperature。AI SDK 的openai、anthropic等 provider 适配器通常会提供一个统一的createStream或类似的方法。你的工作是将这些参数按照对应模型 API 的要求构造成正确的请求格式。例如使用 OpenAI 的 Node.js SDK 原生方式开启流式import OpenAI from openai; const openai new OpenAI(); const stream await openai.chat.completions.create({ model: gpt-4, messages: [{ role: user, content: userInput }], stream: true, // 最关键的一步开启流式 });这个stream对象是一个异步迭代器。3.2 桥接模型流与 HTTP 响应这是最核心的一步。你不能等这个异步迭代器跑完再一次性响应。你需要立即建立一个 SSE 的 HTTP 响应然后一边从模型流中读取数据一边往 HTTP 响应里写。// 以 Node.js Express 为例 app.post(/api/chat, async (req, res) { // 1. 设置 SSE 头 res.setHeader(Content-Type, text/event-stream); res.setHeader(Cache-Control, no-cache); res.setHeader(Connection, keep-alive); res.flushHeaders(); // 立即发送头信息建立连接 // 2. 获取模型流 const modelStream await getModelStream(req.body); // 你的函数返回异步迭代器 // 3. 管道式传输 try { for await (const chunk of modelStream) { // chunk 是模型返回的原始数据块例如 OpenAI 的格式 // data: {id:...,object:chat.completion.chunk,choices:[{delta:{content:Hello}}]} const content chunk.choices[0]?.delta?.content; if (content) { // 将数据封装成 SSE 格式并发送 const sseData data: ${JSON.stringify({ content, type: token })}\n\n; res.write(sseData); } } } catch (err) { // 发送一个错误事件 const errorData event: error\ndata: ${JSON.stringify({ error: err.message })}\n\n; res.write(errorData); } finally { // 发送结束标志并关闭连接 res.write(event: end\ndata: [DONE]\n\n); res.end(); } });Vercel AI SDK 的StreamingTextResponse类或者其各个 provider 的streamText等方法内部做的就是这类事情。它们封装了不同模型 API 的流式响应细节并将其统一转换为标准的、AI SDK 前端能识别的 SSE 数据格式。3.3 处理复杂结构工具调用与函数调用现代的对话模型不仅会输出文本还可能输出结构化的“工具调用”请求。例如模型说“我需要查询天气这是参数{“city”: “北京”}”。在流式传输中这个结构化的调用信息也必须被流式地传递。AI SDK 的协议对此做了扩展。它可能通过不同的事件类型来区分文本 token 和工具调用。例如data: {type: text, text: 让我帮你查一下} data: {type: tool_call, toolCall: {id: call_123, name: get_weather, arguments: {\city\: \北京\}}}后端在从模型流中解析到工具调用开始和参数流时就需要组装成这样的结构并通过 SSE 发送一个完整的tool_call事件块。这比纯文本流复杂得多需要后端仔细解析模型返回的特定字段如 OpenAI 的tool_calls。4. 前端视角从 SSE 流到动态 UI前端是流式体验的最终呈现者。它的任务是与后端建立的 SSE 连接保持通信并实时处理收到的数据块更新用户界面。4.1 建立连接与基础监听在现代前端框架如 React、Vue、Svelte中我们通常不会直接使用原始的EventSource而是使用 AI SDK 提供的更高级的 Hook例如useChat或useCompletion。但理解其底层原理至关重要。一个原生的EventSource连接看起来是这样的const eventSource new EventSource(/api/chat-stream); eventSource.addEventListener(message, (event) { const data JSON.parse(event.data); if (data.type token) { // 将 data.content 追加到 UI 的答案中 appendToAnswer(data.content); } }); eventSource.addEventListener(error, (event) { console.error(SSE connection error:, event); // 处理错误EventSource 会自动尝试重连 }); eventSource.addEventListener(end, (event) { console.log(Stream finished.); eventSource.close(); });useChat这个 Hook 在底层帮你管理了这一切建立连接、发送请求POST 你的消息、监听message事件、解析数据、并将流式的 token 累积到内部的messages状态中。你只需要从useChat返回的messages和append等函数来操作即可。4.2 处理流式文本的累积与渲染前端收到一个个的 token可能是字、词或子词需要将它们平滑地“打”到屏幕上。这里有几个关键的细节状态管理 你需要一个状态来存储当前正在生成的回答。不能直接修改历史消息中的内容因为 React/Vue 的响应式系统依赖于不可变更新。通常的做法是在流式响应开始时在消息列表末尾添加一条role为assistant、content为空的消息。然后每当收到一个 token就更新这条消息的content字段旧content 新token。渲染优化 如果每收到一个 token 就触发一次完整的 UI 重渲染比如 React 的 re-render对于长文本来说性能会很差。AI SDK 的 Hook 和现代框架的响应式系统通常已经做了优化。但如果你是自己实现可能需要考虑使用useDeferredValueReact或防抖来降低更新频率或者直接操作 DOM在简单场景下。光标与滚动 一个良好的用户体验是随着文本流出输入框下方的聊天区域应自动滚动到底部让用户始终看到最新的内容。这需要在每次更新内容后触发一个滚动到底部的操作。同时在流式输出过程中最好能显示一个闪烁的光标动画强化“正在输入”的感知。4.3 处理结构化数据与交互当流式响应中包含了工具调用时前端的工作就复杂了。你不能简单地把{name: “get_weather”, “arguments”: …}这段 JSON 字符串显示给用户。前端需要解析出工具调用的信息。可能在 UI 上用一个特殊的“卡片”或“模块”来展示这个调用比如显示“正在调用天气查询工具...”。将工具调用信息发送给你的后端另一个端点或同一个端点的后续处理由后端真正去执行这个工具如调用天气 API。获取工具执行的结果如“北京晴25°C”。将这个结果作为一条新的消息再次发送给大模型让模型基于工具结果生成后续的回答。而这个后续回答同样需要以流式的方式传回前端。AI SDK 的useChat通过toolInvocation等回调函数提供了处理这类复杂交互的框架。它帮你管理了工具调用的生命周期状态invokingresult你只需要在回调函数中实现具体的工具执行逻辑即可。5. 实战中的坑与最佳实践流式协议听起来美好但在实际集成中从后端到前端每一步都可能遇到坑。下面是我在多个项目中趟过的一些雷区以及对应的解决方案。5.1 后端常见陷阱连接超时与代理问题 Nginx、Apache 等反向代理默认可能有较短的代理超时时间如 60 秒。对于生成长内容的流这会导致连接在生成中途被代理切断。必须在代理配置中为流式路径增加超时设置例如在 Nginx 中proxy_read_timeout 300s;设置一个足够长的时间或直接禁用。响应缓冲区 一些服务器或中间件包括 Node.js 的res对象、Python 的 WSGI 服务器会有输出缓冲区。为了达到真正的“流式”效果必须确保每个数据块都能立即刷新flush到客户端。在 Node.js 的 Express 中调用res.flushHeaders()和确保res.write后立即刷新很重要。在 Python 的 FastAPI 中要使用StreamingResponse并确保生成器是异步的。错误处理不完整 在流式生成过程中模型 API 可能出错网络可能中断。你的后端必须捕获这些错误并通过 SSE 发送一个格式化的错误事件如event: error给前端然后优雅地关闭连接。绝不能任由未处理的异常导致服务器崩溃或留下僵尸连接。流式与非流式接口混淆 确保你的模型调用参数明确设置了stream: true。很多问题源于不小心调用了非流式接口然后试图去“模拟”流式。5.2 前端常见陷阱连接管理与重连 虽然EventSource支持自动重连但在复杂的 SPA 中组件卸载时忘记手动关闭 SSE 连接 (eventSource.close())会导致内存泄漏和意外的请求。使用 AI SDK 的 Hook 时它通常会在组件卸载时自动清理。如果自己实现务必在useEffect的清理函数中关闭连接。数据解析错误 SSE 的data必须是纯文本。如果你发送了一个 JavaScript 对象必须在后端JSON.stringify在前端JSON.parse。一个常见的错误是后端直接res.write(JSON.stringify(obj))而忘记了前面的data:前缀和后面的\n\n结束符。UI 状态竞争 在快速连续发送多条消息时如果上一条的流还没结束就开始了下一条容易导致 UI 状态混乱。AI SDK 的useChat通过isLoading状态来防止这种情况。自己实现时需要类似的锁机制或者在发送新消息前中止之前的流请求这需要后端也支持中止通常通过AbortController实现。移动端与弱网环境 在弱网络下SSE 连接可能不稳定。需要设计良好的加载状态和错误提示。考虑在连接断开时提供“重新连接”或“继续生成”的按钮。AI SDK 本身可能不直接提供“断点续传”但你可以通过保存已接收的 token 和最后的上下文在重连时让模型继续。5.3 性能与监控Token 合并发送 为了减少 HTTP 帧的数量提升效率后端不必真的一个 token 就发送一次。可以积累几个 token比如每 3-5 个或每 100 毫秒批量发送一次。这需要在响应速度和网络效率之间做权衡。AI SDK 的内部实现可能已经做了优化。监控流式质量 你需要监控“首 Token 时间”TTFT和“Token 吞吐率”。TTFT 是从请求发出到收到第一个 token 的时间直接影响用户体验。吞吐率是每秒收到的 token 数影响整体生成速度。这些指标可以帮助你评估模型性能和网络状况。流式协议是构建现代 AI 应用体验的基石。Vercel AI SDK 通过抽象底层细节让开发者能更专注于提示工程和业务逻辑而不是陷于处理 SSE 数据帧的繁琐中。理解这套协议如何运作不仅能让你更好地使用 SDK更能在它不满足你定制化需求时有能力自己去扩展和优化这条“边想边说”的数据管道。
