什么是流式输出,后端怎么生成,前端怎么渲染

什么是流式输出,后端怎么生成,前端怎么渲染

流式输出(Streaming Output) 就像是在看视频直播,内容是一边产生一边传输给你的,而不是像下载电影那样,必须等整个文件下完才能开始看。

在 AI 领域(比如 ChatGPT),流式输出表现为文字一个接一个地“蹦”出来,而不是转半天圈圈后突然甩出一大段话。


什么是流式输出,有什么特点

1. 它是怎么实现的?

流式输出的核心技术通常是 SSE (Server-Sent Events,服务器发送事件)

在传统的 HTTP 请求中,模式是“一问一答”:客户端发请求,服务器处理完全部逻辑,打成一个大包发回客户端。而在流式输出中,过程如下:

  1. 建立持久连接:客户端发送一个请求,并在 HTTP 头部声明 Accept: text/event-stream
  2. 分块传输:服务器每生成一个字(或一个 Token),就立即将其封装成一个小数据块发送出去。
  3. 保持连接:直到内容生成完毕,服务器才会发送一个特殊的结束标志(如 [DONE]),随后关闭连接。

2. 流式输出的特点

特点说明
低首字节延迟 (TTFB)用户能瞬间看到反馈,大大缓解了等待焦虑。
实时性适合长文本生成。如果是普通模式,生成 1000 字可能需要 20 秒,流式模式下第 1 秒就开始显示。
单向通讯不同于 WebSocket 的双向奔跑,SSE 主要是服务器向客户端“单向投喂”数据。
资源占用因为要长时间维持一个 HTTP 连接,对服务器的并发处理能力有一定要求。

3. 为什么 AI 必须用它?

大语言模型(LLM)的推理过程是自回归的。简单来说,它每生成一个词,都要基于前面所有的词重新算一遍概率。

P(wt+1∣w1,w2,...,wt)P(w_{t+1} | w_1, w_2, ..., w_t)P(wt+1​∣w1​,w2​,...,wt​)

这个过程本身就很耗时。如果等 2000 个 Token 全部算完再给用户,用户可能以为网页卡死了。流式输出完美契合了模型“一个一个词往外蹦”的运行逻辑。

后端怎么实现

在后端实现流式输出,本质上是打破“处理完全部逻辑再返回”的传统模式,改为利用 HTTP 分块传输(Chunked Transfer Encoding) 持续向客户端推送数据。

最常见的方法是使用 SSE (Server-Sent Events)。下面我以 Python (FastAPI) 和 Node.js (Express) 为例展示核心逻辑。


1. Python 实现 (以 FastAPI 为例)

FastAPI 内置了 StreamingResponse,非常适合配合大模型的生成器(Generator)使用。


2. Node.js 实现 (以 Express 为例)

在 Node.js 中,通过手动设置 HTTP 响应头并使用 res.write() 来持续发送数据。


3. 实现的关键要素

要确保后端流式输出成功,必须满足以下几个条件:

  • 正确的 Content-Type: 必须设置为 text/event-stream
  • 禁用缓冲 (Buffering):
    • 如果你使用了 Nginx 等反向代理,它可能会默认缓存后端的数据,攒够一波再发给前端。
    • 解决方法: 在 Nginx 配置中设置 proxy_buffering off;,或者让后端返回 X-Accel-Buffering: no 响应头。
  • 特定的数据格式:
    • 每条消息必须以 data: 开头。
    • 每条消息必须以两个换行符 \n\n 结尾。

4. 进阶:如何对接大模型 (LLM)

如果你是在调用 OpenAI 或 Anthropic 的 API,它们通常提供 stream=True 参数。你的后端实际上充当了一个中转站(Proxy)

  1. 后端调用 AI API(开启流式)。
  2. 后端迭代接收 AI 返回的每一个 Chunk。
  3. 后端立刻将这个 Chunk 转发给前端。

前端怎么实现

在前端捕获流式数据,主要有两种主流方案:传统的 EventSource 和现代的 fetch + ReadableStream

由于现在的 AI 接口(如 OpenAI)大多使用 POST 请求,方案二 (fetch) 是目前最通用的做法。


方案一:使用 fetch 结合 ReadableStream (推荐)

fetch API 本身支持流式读取。通过 response.body,你可以获取一个读取器(Reader),逐块解析数据。


方案二:使用 EventSource (仅限 GET)

如果你的后端接口支持 GET 请求,EventSource 是最简单的原生实现,它会自动处理重连和心跳。


核心难点:如何优雅地“渲染”?

在处理 AI 流式输出时,你可能会遇到以下两个坑:

  1. Markdown 渲染:数据是一点点出来的,如果你每出一个字就渲染一次 Markdown,性能会炸掉。
    • 对策:使用带缓存的渲染库(如 markdown-it),并限制渲染频率(如 100ms 刷新一次)。
  2. 数据截断:有时候一个 Unicode 字符或者一个 JSON 字符串会被拆分到两个不同的 Data Chunk 中。
    • 对策:在前端维护一个缓冲区(Buffer),将接收到的 value 累加,直到匹配到完整的 \n\n 再进行解析。

Read more

基于Rokid灵珠AI平台的春节全能助手智能体开发实践

基于Rokid灵珠AI平台的春节全能助手智能体开发实践

前言 本次开发基于Rokid灵珠AI平台,聚焦春节高频的抢票出行、路线规划、年货比价核心场景,搭建轻量化春节全能助手智能体,通过平台可视化工作流编排实现功能逻辑串联;因无Rokid Glasses实物,智能体完成灵珠平台内对话测试验证,眼镜端适配仅编写伪代码实现逻辑预留,整体开发聚焦平台核心的智能体配置与工作流开发能力,实现低门槛、高适配的春节场景AI应用落地。 本文应用基于Rokid灵珠智能体/CXR SDK开发,开发指南https://forum.rokid.com/index 一、开发背景与需求分析 春节期间抢票、年货采购、出行路线规划是用户核心需求,依托Rokid灵珠AI平台零门槛、全栈化的开发特性,无需复杂编码即可完成智能体与工作流的搭建,同时平台支持与Rokid Glasses硬件生态的深度集成,为后续眼镜端落地预留适配接口;本次开发核心实现三大功能:12306高铁票查询、春节自驾路线规划、年货好物低价推荐,所有功能通过灵珠平台智能体统一承接,工作流分别处理具体业务逻辑,满足用户春节出行与采购的一站式需求。 二、开发环境与平台核心能力依托 1. 开发平台:

字节开源 DeerFlow 2.0——登顶 GitHub Trending 1,让 AI 可做任何事情

字节开源 DeerFlow 2.0——登顶 GitHub Trending 1,让 AI 可做任何事情

打开 deerflow 的官网,瞬间被首页的这段文字震撼到了,do anything with deerflow。让 agent 做任何事情,这让我同时想到了 openclaw 刚上线时场景。 字节跳动将 DeerFlow 彻底重写,发布 2.0 版本,并在发布当天登上 GitHub Trending 第一名。这不是一次功能迭代,而是一次从"深度研究框架"到"Super Agent 运行时基础设施"的彻底蜕变。 背景:从 v1 到 v2,发生了什么? DeerFlow(Deep Exploration and Efficient Research Flow)

【Unity-AI开发篇】| Unity-MCP最新指南:让AI接管游戏开发

【Unity-AI开发篇】| Unity-MCP最新指南:让AI接管游戏开发

* 前言 * 【Unity-AI开发篇】| Unity-MCP最新指南:让AI接管游戏开发 * 一、🧐 MCP是什么? * 1.1 MCP介绍 * 1.2 为什么要配置MCP? * 1.3 效果展示 * 1.4 使用说明及下载 * 二、🚀MCP安装步骤 * 2.1 前提条件 * 2.2 安装 Unity-MCP包(桥接组件) * 2.2 MCP配置 * 三、🎈Trae配置 * 3.1 添加MCP配置 * 3.2 创建一个智能体并添加Unity-MCP * 3.3 使用AI开发功能 * 总结 前言 * 在人工智能飞速发展的今天,大语言模型早已不仅限于聊天和文本生成。 * 它们开始能够使用工具,与环境进行交互,从而执行复杂任务。 * 对于广大游戏开发者而言,

微信也能养“小龙虾”了?QClaw 爆火背后:AI 正在从“会聊天”走向“会干活”

微信也能养“小龙虾”了?QClaw 爆火背后:AI 正在从“会聊天”走向“会干活”

🔥 个人主页:杨利杰YJlio❄️ 个人专栏:《Sysinternals实战教程》《Windows PowerShell 实战》《WINDOWS教程》《IOS教程》《微信助手》《锤子助手》《Python》《Kali Linux》《那些年未解决的Windows疑难杂症》🌟 让复杂的事情更简单,让重复的工作自动化 微信也能养“小龙虾”了?QClaw 爆火背后:AI 正在从“会聊天”走向“会干活” * 1、微信也能养“小龙虾”了?这次真的不是玩梗 * 2、OpenClaw 为什么突然这么火? * 3、QClaw 和普通 AI 的本质区别,到底在哪? * 3.1 传统 AI 的工作流 * 3.2 QClaw 这类