← 返回概念解读

Concept Fable精修版

流式响应

Streaming Response · Serving / UX

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

说书人不再等整本书抄完才开口

茶馆里的说书人有个旧习惯:先在后屋把整段故事写完,再走到前台一次念完。故事很好,可客人常在第一句到来前就失去耐心。

掌柜先让说书人写短一点。等待是少了,故事却变薄,遇到复杂情节还是要憋很久。

伙计又挂了沙漏,告诉客人再等一会儿。沙漏让等待显得有解释,却没有改变空白的第一分钟。

后来说书人改成边想边讲。第一句成形就从帘后传出来,后面的句子继续写、继续送,客人能马上知道故事已经开始。

这种办法没有让整本书必然更短。最后一个字到来的时间可能差不多,但沉默被拆开了,客人可以读、可以中止,也能更早发现方向不对。

茶馆也要处理新麻烦:半句不能乱断,错字不能已经念出口才撤回,断线时要知道说到哪里。后来茶馆还发现,边讲边送能提前纠错。客人听到开头发现方向不对,可以立刻摆手;掌柜也能在第一句迟迟不到时判断后屋出了问题。

掌柜给前台加了小铃,每来一句就响一次;账房记录第一句到达时间和整段讲完时间,区分体感等待和总耗时。说书人因此学会把长故事切成自然片段。每片到达都要能接上前文,又不能让半个承诺孤零零挂在外面。流动的交付带来体验,也带来边界管理。

客人后来评价说书人更快了。掌柜知道,真正变化是响应方式:从整包交付改成连续交付,让等待有了可见进度。后来管事把这次经验写进日常规矩:先看场景,再看边界,最后看失败时谁能接手。只有这些都清楚,漂亮演示才会变成可交付的工作。复查时,他们还会拿旧事故对照一遍,确认新规矩不是只在纸上好看,而能在忙乱现场真正挡住同样的错误。

揭示

这个故事讲的是:流式响应

Streaming Response returns generated tokens or chunks as they become available instead of waiting for the full completion. It improves perceived latency and interactivity, especially for chat and agent interfaces. It does not necessarily reduce total generation time, so systems should track both time to first token and total latency.

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 整本书抄完才念:non-streaming full response
  • 第一句先传出来:first streamed token / first chunk
  • 边想边讲:incremental token generation
  • 客人能中止:early cancellation and interactive UX
  • 小铃记录:stream event handling
  • 第一句到达时间与整段时间:TTFT versus total latency

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

token streaminglatency