DeepSeek 工程师拆穿一个常见误会：AI 流式回答不是一根长水管

开发者实测一次 AI 回答：1.2K 输出 token、首 token 延迟 0.8 秒、生成速率 80 tok/s。但数字背后真正值得编辑留意的是链路结构——它不是一根长水管，而是三条不同通道协作；并且当 AI 被要求解释自己的宿主架构时，它答错了。

这是什么

流式回答，就是 AI 一个字一个字往外蹦、你一边看它生成的那种体验。DeepSeek 把 Harness 项目（一个开源 AI 中间层）的代码公开后，一位开发者顺着真实代码跑了一次请求，把链路完整画了出来。

结论与常见说法相反：浏览器用一次性 HTTP POST 提交问题，模型响应通过 SSE（服务器推送事件）流回 Harness 中间层，浏览器最终通过 WebSocket（双向长连接）接收增量。中间层还把每个片段写入 Session 日志，作为恢复、轨迹和统计的事实来源。

更值得注意的是：开发者让模型自己解释这条链路，模型给出了错误答案——它把整个流程都说成 SSE。只有真实运行日志和源码才能作为架构证据，这是给所有「用 AI 解释 AI」的人的提醒。

支持声音认为，把开源产品拉到日志可审计的颗粒度，是中文 AI 社区少见的工程诚意。市面上多数流式回答只讲「快」，不讲「如果断了怎么恢复、多端怎么同步」。

反过来看，这份拆解高度技术化——RPC ID、events.mux、Session 事件流——对绝大多数开发者是劝退阅读。它真正影响的是中间件和 Agent 框架的设计者，而非最终用户。另外，过度聚焦底层通道，也可能掩盖更上游的问题：用户究竟需要怎样的 AI 交互节奏。

对企业 IT：选型 AI 中台时，「流式回答的可靠性、断线恢复、多端一致」比首 token 延迟更值得追问。

对个人职场：遇到 AI 工具卡顿、丢消息时，理解「中间层在写日志」这件事，能帮你判断是网络问题还是产品本身问题。