主流 AI 应用的“流式技术”的探索交流

weixin79893765432...2025-12-15 8:22

目录

前言

在正文开始之前，我们不妨先思考一个问题------"为什么主流 AI Agent 需要"切片分段输出"，而不是等模型算完再一起返回？"

主流 AI Agent 必须切片分段输出，不是因为"体验更好"，而是因为：

  • 大模型天生流式生成的
  • Agent 本质是长期运行的进程
  • 执行路径与耗时不可预期
  • 中间状态本身就是"结果的一部分"
  • 系统必须可中断、可观察、可协作

一、AI 应用中常见的流式技术（六大类）

当前 AI 应用（Chat / Agent / Copilot / 多模态） 中，真正常用且成熟的流式技术主要是：

技术 层级 是否主流 Agent 友好度 实时性 复杂度
Token Streaming 模型 ⭐⭐⭐⭐⭐ ⭐ 极高 低
HTTP Chunk 传输 ⭐⭐⭐ ⭐ 高 低
SSE（Server-Sent Events） 网络 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ 高 中
WebSocket 网络 ⭐⭐⭐⭐ ⭐⭐⭐⭐ 极高 高
Async Generator 运行时 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 高 中
Message Stream 系统 ⭐⭐⭐ ⭐⭐⭐⭐ 中 高

注意：

  • "流式 ≠ 网络协议"
  • 它是从 "模型 → 进程 → 网络 → 前端" 的一整条链路

下面逐一展开。

1、LLM Token Streaming（最底层）

原理：

  • 大模型 每生成一个 token 就立刻返回
  • SDK / API 层把 token 当成流
  • decode token → emit → client

常见形式：

  • OpenAI stream=true
  • Claude streaming
  • DeepSeek / Qwen streaming

优缺点：

优点 缺点
最低延迟 只有文本
实现简单 无语义
符合模型本性 不支持 Agent

适用：

  • Chat
  • 补全
  • 编辑器 Copilot

所有 AI 流式的"源头"

2、HTTP Chunked Transfer（传输层流）

原理：

  • HTTP/1.1 的 Transfer-Encoding: chunked
  • 服务端边算边写 response
bash 复制代码 
chunk1\r\n
chunk2\r\n
chunk3\r\n

特点：

  • 不定义事件
  • 只是"数据块"

优缺点：

优点 缺点
无额外协议 前端解析困难
基础设施兼容 无事件语义
实现成本低 不可扩展

3、SSE（Server-Sent Events）（AI 应用主流）

原理：

  • 基于 HTTP 长连接
  • 服务端主动 push 事件
  • 客户端 EventSource 监听
bash 复制代码 
event: token
event: tool_start
event: tool_end
event: final

为什么 AI 特别适合 SSE？

  • 单向（Agent → 用户）
  • 天然支持 事件类型
  • 不需要复杂连接管理

AI 中常见事件：

json 复制代码 
{ "type": "delta" }
{ "type": "tool_call" }
{ "type": "observation" }
{ "type": "final" }

优缺点：

优点 缺点
Agent 友好 单向
HTTP 友好 不适合高频控制
易调试 需要事件规范

ChatGPT / LangChain / Vercel AI 首选

4、WebSocket（双向实时流）

原理：

  • 建立全双工长连接
  • 双方随时发送消息
  • Client ⇄ AI Runtime

常见 AI 用法：

  • 实时 token 流
  • 用户中断 / 追问
  • Agent 控制指令

优缺点：

优点 缺点
双向 实现复杂
实时 连接管理难
强交互 基础设施要求高

典型场景：

  • DE Copilot
  • 多模态实时对话
  • 语音 Agent

强交互 AI 才值得用

5、Async Generator / Iterator（进程内流）

⚠️ 这是Agent 内部最重要、但最容易被忽略的流式技术

原理：

AI 执行逻辑本身就是：

typescript 复制代码 
async function* runAgent() {
  yield plan
  yield tool_call
  yield observation
  yield final
}

特点：

  • 不关心网络
  • 描述的是 执行过程的"时间流"

优缺点：

优点 缺点
非常优雅 不是传输协议
易组合 需对外包装
Agent 天然匹配 前端不可直接用

使用框架：

  • LangGraph
  • CrewAI（内部）
  • AutoGen（内部）

Agent 的"内核流式模型"

6、Message Stream / Queue（系统级流）

原理：

  • Agent 把结果写入流
  • 多个消费者订阅
  • Agent → Kafka / Redis Stream → UI / Logger / Monitor

特点：

  • 非实时
  • 高可靠
  • 可回放

优缺点：

优点 缺点
高可靠 延迟高
多订阅 架构复杂
可审计 不适合 Chat

适用：

  • 企业级 Agent
  • 长任务
  • 多 Agent 协同

二、AI 应用中的"流式分层模型"（非常重要）

成熟 AI 应用一定是"多层流式"叠加：

不是选一个，而是"每一层都流式"。

三、ReadableStream 在"流式分层模型"中扮演着什么角色？

前面我们一起学习了"SSE / WebSocket / Token Streaming / Async Generator"，ReadableStream 正好是把这些"流"真正串起来的那一层。

一句话概述：ReadableStream 是 AI 应用中"流式数据的标准承载体与拼装层 "，不是协议，而是能力底座。

1、ReadableStream 的核心定位

在 AI 流式体系中的位置：

typescript 复制代码 
LLM Token
   ↓
Async Generator（Agent 执行流）
   ↓ yield
ReadableStream  ← ★关键承载层
   ↓ encode / format
SSE / HTTP Chunk / WebSocket
   ↓
Browser EventSource
   ↓
UI Render

它是：

  • Agent 执行过程的"可观察接口"
  • 流式协议的"物理承载层"
  • 工程上连接模型、系统、UI 的桥梁

换句话讲，ReadableStream 是"把时间序列的数据变成可传输流"的那一层。

2、ReadableStream 到底解决了什么问题？

（1）、把"异步产出"变成"标准流接口"

Agent / LLM 常见输出形态是：

typescript 复制代码 
async function* generate() {
  yield chunk1
  await tool()
  yield chunk2
}

ReadableStream 的作用：

typescript 复制代码 
new ReadableStream({
  async pull(controller) {
    const { value, done } = await iterator.next()
    controller.enqueue(value)
    if (done) controller.close()
  }
})

它把"生成逻辑"和"传输逻辑"彻底解耦

（2）、 统一 Node / Edge / Browser 的流模型

ReadableStream 是：

  • Web 标准
  • Node 18+ / Bun / Deno / Edge 全支持
  • Fetch API 原生兼容
typescript 复制代码 
return new Response(stream)

这就是为什么 Vercel / Cloudflare / Edge Agent 都围绕它构建

3、ReadableStream 在 AI 中的三种"主流用法"

用法1：LLM Token → HTTP Response

typescript 复制代码 
const stream = new ReadableStream({
  async start(controller) {
    for await (const token of llm.stream()) {
      controller.enqueue(encoder.encode(token))
    }
    controller.close()
  }
})

return new Response(stream)

最基础的 Chat 流式返回

用法2：Agent Event → SSE

typescript 复制代码 
controller.enqueue(
  encoder.encode(
    `event: tool\ndata: ${JSON.stringify(data)}\n\n`
  )
)

ReadableStream 在这里：

  • 管理 backpressure
  • 控制连接生命周期
  • 顺序推送事件

SSE 本身就跑在 ReadableStream 之上

用法3：ReadableStream 作为"流式组合器"

typescript 复制代码 
const stream = new ReadableStream({
  async start(controller) {
    for await (const event of agent.run()) {
      controller.enqueue(format(event))
    }
  }
})

Agent 的"外放接口"

4、ReadableStream vs SSE vs WebSocket（非常关键）

很多人会混淆这三者

技术 是什么 解决什么
ReadableStream 流抽象 数据如何连续产生
SSE 协议约定 事件如何表达
WebSocket 通信通道 双向如何通信

用类比的思维一句话总结：

  • ReadableStream：水管
  • SSE：水的分段规则
  • WebSocket：双向管道

5、为什么现代 AI 框架"强依赖" ReadableStream？

（1）、Fetch-first 架构的必然选择

现代 AI 框架普遍：

  • 不再暴露 res.write
  • 使用 return new Response(stream)
  • ReadableStream 是 唯一标准方式

（2）、Backpressure（背压）能力非常关键

AI 输出特点：

  • token 很多
  • UI 消费速度不稳定

ReadableStream 内置：

  • highWaterMark
  • 自动 pull / pause

这是直接写 socket 做不到的

（3）、可以被"多次变换（TransformStream）"

typescript 复制代码 
stream
  .pipeThrough(formatter)
  .pipeThrough(compressor)
  .pipeTo(response)

非常适合：

  • Token → Event
  • Event → UI
  • 插件化 Agent 输出

四、工程实践建议（非常重要）

要做的工程 推荐的技术组合
Web Agent / Copilot Async Generator + SSE
复杂多步骤 Agent LangGraph + Event
IDE / 可中断 Agent WebSocket + Event
企业级 Agent 平台 Event Bus + Workflow

五、实际主流厂商是怎么做的？

主流大厂并不是"是否流式"的差异，而是：

  • 流式到什么粒度？
  • 是否把 Agent 的过程事件化？
  • 对开发者暴露到哪一层为止？

四大厂商在"流式"上的共识是：

  • 底层：Token 级流式是必选
  • 传输：HTTP + 流（SSE / chunk）是主流
  • 语义：开始向"事件流"而不是"纯文本流"演进
  • Agent 能力：只"半开放"，核心推理不全暴露
厂商 传输协议 流式粒度 事件语义 Agent 感 工程取向
OpenAI SSE Token + Event 极强 ⭐⭐⭐⭐⭐ 平台化
Claude HTTP Stream Token 弱 ⭐⭐ 稳定优先
DeepSeek HTTP Stream Token 极弱 ⭐ 兼容优先
Gemini WS / gRPC / HTTP Token / Frame 强 ⭐⭐⭐⭐ 多模态

1、OpenAI：事件流做得最彻底、最工程化

（1）、接口层：SSE + Event Stream（事实标准）

你实际拿到的是什么？

  • HTTP 长连接
  • Content-Type: text/event-stream
  • 强事件语义
json 复制代码 
{
  "type": "response.output_text.delta",
  "delta": "Hello"
}
json 复制代码 
{
  "type": "response.tool_call",
  "name": "search"
}

特点总结：

维度 表现
传输 SSE
粒度 Token / Event
事件种类 非常丰富
Agent 感 ⭐⭐⭐⭐⭐

（2）、内部真实模型（推断）

bash 复制代码 
Model Token Stream
   ↓
Internal Agent Runtime
   ↓
Event Normalizer
   ↓
ReadableStream
   ↓
SSE

关键点：

  • ReadableStream 是核心承载
  • Token 只是事件的一种
  • Tool / Reasoning / Output 全事件化

OpenAI 实际已经是"Agent Runtime as a Service"

（3）、为什么 OpenAI 要做这么复杂？

支持：

  • 工具调用
  • 多模态
  • 多阶段输出

为未来：

  • 多 Agent
  • 长任务
  • 可中断执行

Chat 只是最简单的 use case

2、Claude（Anthropic）：保守但非常"干净"的流式

（1）、接口层：HTTP Streaming（SSE-lite）

Claude 的 streaming：

  • 本质是 HTTP chunked
  • 表面看像 SSE
  • 但 事件种类明显更少
json 复制代码 
{ "type": "content_block_delta" }
json 复制代码 
{ "type": "message_stop" }

（2）、设计哲学

Anthropic 的取舍是：

  • "给你流式文本 + 最小必要结构，但不暴露 Agent 内部"

特点：

维度 表现
事件数量 少
语义 克制
Agent 暴露 低
稳定性 极高

（3）、推断的内部结构

typescript 复制代码 
LLM Token Stream
   ↓
Lightweight Stream Wrapper
   ↓
HTTP Chunk / SSE-like

Claude 更像"增强版 Chat Completion"

3、DeepSeek：典型"中国工程取向"------实用优先

（1）、接口层：OpenAI-compatible + streaming

DeepSeek 的实际策略是：

  • 高度兼容 OpenAI
  • streaming 参数与 OpenAI 基本一致
  • JSON delta 返
json 复制代码 
{
  "choices": [{
    "delta": { "content": "..." }
  }]
}

（2）、特点总结

维度 表现
兼容性 ⭐⭐⭐⭐⭐
流式 Token 为主
Agent 事件 少
工程成本 低

（3）、架构判断

typescript 复制代码 
LLM Token Stream
   ↓
OpenAI-style Delta Wrapper
   ↓
HTTP Stream

非常适合国内/企业"快速 Agent 落地"

4、Gemini（Google）：双轨制，非常"Google 风格"

（1）、两套体系并存（很关键）

①、API / Web 场景
  • HTTP streaming
  • JSON chunk
  • 类似 Claude / OpenAI
②、实时 / 多模态场景
  • WebSocket / gRPC
  • 强实时
  • 语音、视频

（2）、Gemini 的真正优势点

  • 原生多模态流式
  • 音频 / 视频 frame 级流
  • 极强的 低延迟双向能力
  • Audio Frame ⇄ Model ⇄ Audio Frame

（3）、推断内部结构

typescript 复制代码 
Multi-modal Stream
   ↓
gRPC / WebSocket
   ↓
Web / Mobile SDK

Gemini 的"流式"不是为 Chat，而是为"实时智能体"

5、给我们的工程启示（非常实用）

如果你要"对齐主流厂商"

  • 接口层
    • SSE（事件化）
  • 承载层
    • ReadableStream
  • 内部
    • Async Generator / Event Emitter

最推荐的结构：

typescript 复制代码 
Agent (async generator)
   ↓
Event Normalize
   ↓
ReadableStream
   ↓
SSE / WS

真巧，这正是 OpenAI 正在做的事。

六、前端到底需要关心什么？

对于主流 AI 厂商的"流式能力"，前端只需要关心 6 件事：

  • 如何建立流式连接
  • 如何稳定的持续接收数据
  • 如何区分不同的"分段类型"，然后分别进行正确的解析
  • 如何优雅的渐进渲染
  • 如何中断 / 结束
  • 如何兼容不同厂商

其他的（Agent 内部、模型推理、工具调用）前端不需要知道。

1、前端真正"直接相关"的技术清单（重点）

（1）、SSE（Server-Sent Events）（⭐⭐⭐⭐⭐）

为什么前端必须懂 SSE？

  • OpenAI（新接口）
  • LangChain / LangGraph
  • Vercel AI
  • 大量自建 Agent

前端使用方式

typescript 复制代码 
const es = new EventSource("/api/stream")

es.onmessage = (e) => {
  const data = JSON.parse(e.data)
}

前端关注点：

点 说明
event 类型 token / tool / final
自动重连 浏览器内建
连接关闭 es.close()
错误处理 onerror

这是"ChatGPT 风格体验"的核心

（2）、Fetch + ReadableStream（最重要）（⭐⭐⭐⭐⭐）

⚠️ 前端"真正的底层能力"

标准写法：

typescript 复制代码 
const res = await fetch("/api/stream")
const reader = res.body!.getReader()

while (true) {
  const { value, done } = await reader.read()
  if (done) break
  const text = decoder.decode(value)
}

为什么它如此重要？

  • SSE 底层就是 ReadableStream
  • 可解析：
    • Token
    • JSON
    • 自定义协议
  • Edge / 浏览器统一

前端关注点：

  • TextDecoder
  • chunk 拼接
  • JSON boundary
  • backpressure（隐式）

（3）、WebSocket（可选，但重要）（⭐⭐⭐⭐）

前端适合用 WS 的场景：

  • 实时中断
  • 实时控制 Agent
  • 多模态（语音 / IDE）
typescript 复制代码 
const ws = new WebSocket(url)
ws.onmessage = (e) => {}

前端复杂度：

点 难度
重连 高
心跳 必须
状态同步 难
协议设计 自己来

不需要双向控制，别用

（4）、流式 UI 渲染（非常关键）（⭐⭐⭐⭐⭐）

前端不只是"接收"，而是要：

  • 边收边渲染，而不是 setState 全量替换

常见做法（React）：

typescript 复制代码 
setText(prev => prev + delta)

进阶关注点：

  • Markdown 增量渲染
  • Code block 未闭合
  • 光标位置
  • 滚动锚点

体验好坏，80% 在这里

（5）、Abort / 中断机制（⭐⭐⭐⭐）

前端必须能"停下来"。

Fetch + AbortController：

typescript 复制代码 
const controller = new AbortController()
fetch(url, { signal: controller.signal })

controller.abort()

SSE：

typescript 复制代码 
es.close()

WebSocket：

typescript 复制代码 
ws.close()

为什么重要？

  • 用户打断
  • Token 失控
  • Agent 卡死

（6、）多厂商协议适配（工程现实）（⭐⭐⭐⭐）

前端面对的真实世界：

厂商 返回结构
OpenAI event + delta
Claude chunk + type
DeepSeek OpenAI-style delta
Gemini chunk / ws

前端推荐做法：

typescript 复制代码 
normalizeChunk(raw) => {
  return {
    type: "text" | "tool" | "final",
    content: string
  }
}

不要把厂商结构写死在 UI 里

2、明确界限：哪些"看起来高级"的东西，其实前端不用管？

Agent 内部状态机看起来很高大上，但前端其实根本不用管：

❌ LangGraph 节点

❌ Tool 调用逻辑

❌ Reasoning Token

❌ ReadableStream 的生产端

前端只要一个东西："稳定、可预测、可中断的流"。

3、前端视角的"主流 AI 流式技术地图"

4、给你的"前端工程建议"

✅ 前端必会的 AI 三件套：

  • Fetch + ReadableStream（必须精通）
  • SSE 的事件模型
  • AbortController + 流式 UI 更新

❌ 不要一开始就碰：

  • 自定义 WS 协议
  • 多 Agent 同屏协作
  • 推理过程可视化
相关推荐
Yu_Lijing2 天前
【个人项目】C++基于websocket的多用户网页五子棋（下）
网络·websocket·网络协议
两个人的幸福online2 天前
cocos 使用 WebSocket（goEasy版）
网络·websocket·网络协议
爱吃土豆的马铃薯ㅤㅤㅤㅤㅤㅤㅤㅤㅤ2 天前
aspect实现请求校验，但是WebSocket 端点类不能被 AOP 代理解决方案
网络·websocket·网络协议
闲人编程3 天前
后台任务与WebSocket实时应用
websocket·web·实时·codecapsule·后台协议·实时应用
教练、我想打篮球3 天前
118 http 协议中如何实现流式的交互数据
websocket·http·流式数据交互
2501_921649494 天前
亚太股票数据API：日股、韩股、新加坡股票、印尼股票市场实时行情，实时数据API-python
开发语言·后端·python·websocket·金融
bleach-4 天前
文件描述符及Linux下利用反弹shell的各种方法
linux·websocket·web安全·网络安全·系统安全·信息与通信
SoleMotive.4 天前
sse和websocket的区别
网络·websocket·网络协议
Misnearch5 天前
通信方式了解
websocket·全双工·单工·半双工
热门推荐
01GitHub 镜像站点02UV安装并设置国内源03【AutoGLM部署】本地私有化部署AI手机Agent04【超详细教程】手把手教你从微软官网免费下载Windows 10官方原版ISO镜像（2025最新版）05Linux下V2Ray安装配置指南06Cursor 又偷偷更新，这个功能太实用：Visual Editor for Cursor Browser07Open-AutoGLM Windows 安装部署教程08BongoCat - 跨平台键盘猫动画工具09Windows 11 官方系统安装与重装完整教程（2025年最新版）10安娜的档案(Anna’s Archive) 镜像网站/国内最新可访问入口（持续更新）