Streaming（流式输出）
LLM 逐 token 返回生成结果的输出模式，而非等全部生成完毕后一次性返回。技术上通常基于 SSE（Server-Sent Events）实现。这不是 API 的优化技巧，而是 Transformer 自回归生成机制的直接映射——模型每次只预测一个 token。
为什么是"流"而不是"一次性返回"？
Transformer 是自回归模型：每次基于已有的全部 token 预测下一个 token，然后把预测结果追加到序列中，再预测下一个。生成 100 个 token 的回答需要跑 100 次前向传播。
流式输出就是把每次前向传播的结果实时推送给客户端，而不是等 100 次全跑完再返回。用户看到的"逐字打出"效果，是模型生成过程的真实速度。
技术实现
主流方案是 SSE（Server-Sent Events）——HTTP 长连接，服务端单向推送，客户端只接收。比 WebSocket 轻量，适合"服务端持续输出、客户端只读"的场景。
典型的数据流：
text
data: {"token": "你"}
data: {"token": "好"}
data: {"token": "，"}
data: {"token": "请问"}
...
data: [DONE]
AI SDK 的 streamText 和 useChat 封装了这个过程：服务端用 streamText 生成 SSE 流，客户端用 useChat 自动解析并逐步渲染。
为什么不一次性返回？
三个原因：
- 延迟体验：GPT-4o 生成 500 token 的回答需要 3-8 秒。一次性返回意味着用户盯着空白页等 8 秒；流式输出让用户在 200ms 内就看到第一个字
- 内存效率：长回答的完整响应可能很大，流式处理允许客户端逐块消费，不需要一次性缓存全部内容
- 可中断性：用户可以在生成过程中取消请求，避免浪费算力。对于 Agent 场景，中间步骤的流式输出还能让用户实时监控执行过程
与 Agent 的关系
在 Agent 循环中，流式输出的价值更大：每轮 Thought → Action → Observation 都可以实时推送给用户，让"黑盒执行"变成"透明过程"。AI SDK 的 maxSteps 配合 streamText，会在每个 step 完成时推送中间状态，而不是等整个 Agent 循环结束。
引用本术语的文章