流式响应与实时搜索完全指南：把 AI Web 体验从等待改成对话

同样一个 AI 功能，为什么有的产品一用就觉得“挺聪明”，有的却让人感觉“像在等接口返回”？

很多时候，差距不在模型本身，而在交互链路。

用户并不会天然关心：

你用的是哪个 provider
你的 prompt 写得多漂亮
你的服务端是不是做了 fancy 的 orchestration

用户只会直接感受到三件事：

点完以后多久有反馈
过程中是否知道系统在干什么
当他改变主意时，能不能立即打断和继续

这就是为什么流式响应和实时搜索体验，在 AI 产品里格外重要。

一个总耗时 8 秒的回答：

如果 8 秒后一次性吐出来，用户觉得卡
如果 600ms 内开始出字，用户觉得系统在思考

一个搜索框：

如果每次都整页提交再等待
和边输入边给建议、边更新结果

体感几乎不是同一个产品。

所以这篇文章不想只讲 SSE 怎么写，而是想把“AI Web 体验”这件事完整讲透：

为什么流式响应本质上是在优化感知延迟
SSE、WebSocket、轮询分别适合什么场景
怎样设计增量渲染、取消请求、错误恢复
实时搜索为什么容易把后端打爆，又该怎样兜底
怎样把这套体验做成可观测、可治理、可上线的系统

如果你在做聊天、AI 搜索、智能问答、辅助创作，这篇会很实用。

一、先统一认知：流式体验优化的不是总耗时，而是用户心智

很多工程师讨论流式输出时，最常见的误区是：

流式又不会让模型真的更快，只是把结果拆开发而已。

这句话技术上没错，但产品上不够完整。

因为用户体验里有一个非常关键的概念：感知等待时间。

1.1 为什么“先出一点”这么值钱

当用户点击发送后，如果界面立刻进入完全静止状态，哪怕只等 2 秒，体感也容易变差。

但如果系统在 500ms 内就开始：

显示 loading 状态
回显用户消息
给出搜索建议
逐步输出文本

用户对等待的容忍度会明显提高。

1.2 流式不只是“酷”，而是降低放弃率

在很多 AI 产品里，流式最大的业务价值并不是炫技，而是：

提高首反馈速度感知
降低用户重复点击
降低“系统是不是卡了”的不确定性
让长回答看起来不是“死等”

这就是为什么一个真正成熟的 AI 前端，几乎都会认真设计流式链路。

二、三种常见实时传输方式，别一上来就默认 `WebSocket`

很多团队一听“实时”，第一反应就是 WebSocket。

但真实工程里，AI 文本生成场景最常用的反而是 SSE。

2.1 `SSE`：最适合单向增量输出

SSE（Server-Sent Events）的特点是：

服务端持续向客户端推送数据
协议基于普通 HTTP
实现相对简单
天然适合“服务端不断出字，客户端不断展示”

它特别适合：

聊天回答流式输出
摘要生成
文本改写
搜索结果增量返回

2.2 `WebSocket`：适合双向高频互动

如果你的场景需要：

双向实时协作
高频事件交互
客户端不断回传控制信号

那 WebSocket 更合适。

但如果只是单向输出文本，用 WebSocket 往往复杂度更高、收益不一定更高。

2.3 轮询和长轮询：不是不能用，但通常不够优雅

轮询更适合：

兼容旧系统
实时性要求没那么高
开发和部署环境有限

但在 AI 文本交互里，轮询会天然带来：

空请求浪费
延迟抖动
体验断裂

2.4 一个简单判断表

方案	适合场景	不适合场景
`SSE`	单向流式文本、增量结果	强双向互动
`WebSocket`	协作、双向状态同步	只做简单文本流
轮询	低实时要求、兼容方案	高体验 AI 对话

三、`SSE` 落地时，真正难的不是写出来，而是把整条链路打通

3.1 一个最小 `SSE` 示例

export async function streamAnswer(req, res) {
  res.setHeader('Content-Type', 'text/event-stream; charset=utf-8')
  res.setHeader('Cache-Control', 'no-cache, no-transform')
  res.setHeader('Connection', 'keep-alive')

  for await (const chunk of llm.stream(req.body.messages)) {
    res.write(`data: ${JSON.stringify({ delta: chunk })}\n\n`)
  }

  res.write('event: done\ndata: {}\n\n')
  res.end()
}

代码看起来不复杂。

真正复杂的是，你要确认：

网关是否允许持续流式透传
代理层是否会缓冲响应
CDN 是否会把流式连接处理坏
前端断开时服务端能否及时停止上游请求

3.2 最常见的链路问题

问题 A：代理缓冲

有些代理默认会缓冲响应，导致你以为自己在流式输出，用户实际还是最后一次性收到。

问题 B：超时配置过短

长回答还没结束，链路已经被代理断开。

问题 C：服务端只顾输出，不管取消

用户关闭页面了，模型还在后台继续生成，这会平白浪费 token 和资源。

四、前端增量渲染：不是把文本拼起来就完事

很多前端在做 AI 聊天时，会先写一个最简单版本：

收到一个 chunk
直接 append 到字符串尾部
然后重新渲染整块内容

这在 demo 阶段够用，但实际产品里会遇到很多细节问题。

4.1 需要处理的四种状态

正在生成
用户主动取消
网络中断或流式异常终止
生成完成后进入可复制 / 可引用状态

4.2 一个 React 风格的思路示例

const [message, setMessage] = useState('')
const [status, setStatus] = useState<'idle' | 'streaming' | 'done' | 'error'>('idle')

function appendDelta(delta: string) {
  setMessage(prev => prev + delta)
}

表面看很简单，但一旦内容里有：

Markdown
代码块
表格
引用片段

你就要考虑：

每个 chunk 是否会打断语法结构
渲染频率是否过高导致卡顿
是否要做节流更新

4.3 一个更稳的做法

先在内存里累积 chunk
每隔 30~100ms 批量刷新一次 UI
最终完成时再做完整 Markdown 渲染

这样既保留“在持续输出”的感觉，也避免高频重渲染造成卡顿。

五、取消控制：一个成熟 AI 产品必须允许“用户反悔”

这点非常重要，但经常被忽略。

在 AI 场景里，用户经常会：

问到一半改问题
发现答案方向错了
直接切换页面
连续发两个问题

如果你的系统不支持取消，结果会很糟：

旧请求还在跑
新请求又开始跑
token 成本增加
UI 状态混乱

5.1 前端取消示例

const controller = new AbortController()

fetch('/api/chat/stream', {
  method: 'POST',
  body: JSON.stringify(payload),
  signal: controller.signal,
})

function stopGeneration() {
  controller.abort()
}

5.2 服务端也必须感知取消

前端断开只是第一步。更重要的是服务端能不能把这个取消传到上游模型调用层。

否则链路前半段停了，后半段还在烧钱。

六、实时搜索：体验升级很大，风险也放大得很快

很多 AI 搜索产品的第一眼惊艳，不是答案多聪明，而是：

你刚输入几个字，就已经在给建议
搜索结果逐步更新
有些模块先出来，有些模块后补齐

这类体验会让产品显得非常“活”。

但工程上，实时搜索也是最容易把后端打穿的模块之一。

6.1 为什么实时搜索容易出问题

因为输入是连续的。

用户打“向量数据库怎么选”这 9 个字时，系统可能收到：

向
向量
向量数
向量数据库
向量数据库怎
…

如果每次都全量触发：

检索
rerank
LLM 总结

那系统会迅速进入“为了实时而疯狂自耗”的状态。

6.2 三个必须做的控制

A. 防抖（Debounce）

不要每次按键都打请求。

B. 请求废弃

旧请求结果回来时，如果已经不是当前输入，必须丢弃。

C. 分层搜索

先做轻量建议，再做重型生成。

6.3 一个简单防抖示例

let timer: ReturnType<typeof setTimeout> | null = null

function onInputChange(value: string) {
  if (timer) clearTimeout(timer)

  timer = setTimeout(() => {
    search(value)
  }, 250)
}

250ms 并不是标准答案，但它体现了一种思路：

实时搜索不是“越快越好”，而是“用户体感足够快，同时后端可承受”。

七、增量搜索结果：不是一次请求只出一种内容

更成熟的 AI 搜索体验，往往会把结果拆层返回。

例如：

先返回关键词建议
再返回传统检索结果列表
最后流式返回 AI 总结

这样用户在第一个几百毫秒内就能获得反馈，不用把所有体验都绑死在 LLM 最终回答上。

7.1 为什么分层结果特别重要

因为它让产品从“全有或全无”变成“逐步完成”：

就算 AI 总结稍慢，用户也已经能开始浏览原始结果
就算生成失败，传统检索结果仍然可用
体验和稳定性都更可控

这也是很多 AI 搜索产品真正好用的原因：

它们不是用 AI 替代搜索，而是让 AI 增强搜索。

八、观测：流式体验最怕“看起来偶尔卡一下，但没人知道为什么”

流式链路一旦出问题，往往不如普通接口那样容易发现。

因为它常见的故障不是直接 500，而是：

首包延迟异常高
中途断流
chunk 间隔抖动很大
代理偶发缓冲
客户端取消没有真正取消上游

8.1 至少该看这些指标

指标	价值
首字节时间 / 首 token 时间	看第一反馈够不够快
平均流式持续时间	看长响应表现
中断率	看链路稳定性
用户取消率	看答案是否常常不对路
废弃请求比例	看实时搜索是否过度触发
单次输入触发请求数	看前端节流是否失效