Back to home

Compare

Comparing: DeepSeek Engineer: AI Streaming Is Three Channels, Not One Pipe & DeepSeek 工程师拆穿一个常见误会:AI 流式回答不是一根长水管

AEN
DeepSeekHarnessstreaming response·

DeepSeek Engineer: AI Streaming Is Three Channels, Not One Pipe

A developer measured one AI response: 1.2K output tokens, 0.8-second time to first token, 80 tokens/sec generation rate. But behind the numbers, what we should really note is the chain structure—it's not one long pipe, but three different channels collaborating; and when the AI was asked to explain its own host architecture, it got it wrong.

What this is

Streaming response—the experience of AI outputting word by word while you watch it generate. After DeepSeek open-sourced the Harness project (an open-source AI middleware layer), one developer traced the actual code, ran a request, and mapped out the complete chain.

The conclusion contradicts the common narrative: the browser submits the question via a one-shot HTTP POST, the model's response streams back to the Harness middleware layer via SSE (Server-Sent Events), and the browser ultimately receives the incremental output via WebSocket (bidirectional long connection). The middleware also writes each fragment to Session logs as the source of truth for recovery, trajectories, and statistics.

Even more noteworthy: the developer asked the model to explain this chain itself, and the model gave a wrong answer—it described the entire flow as SSE. Only real runtime logs and source code can serve as architectural evidence; this is a reminder to everyone who "uses AI to explain AI."

Industry view

The supportive view holds that pulling an open-source product down to a log-auditable granularity shows rare engineering sincerity in the Chinese AI community. Most streaming responses on the market only talk about "speed"—not about "how to recover if disconnected, how to sync across devices."

On the flip side, this breakdown is highly technical—RPC IDs, events.mux, Session event streams—discouraging reading for the vast majority of developers. What it truly affects is middleware and Agent framework designers, not end users. Additionally, over-focusing on underlying channels may obscure more upstream questions: what AI interaction rhythm do users actually need.

Impact on regular people

For enterprise IT: When selecting an AI middleware platform, "streaming response reliability, disconnection recovery, multi-device consistency" are more worth asking about than time to first token.

For individual professionals: When you encounter AI tool lag or dropped messages, understanding that "the middleware is writing logs" can help you judge whether it's a network issue or a product issue.

For the consumer market: Future AI assistant experiences will diverge—not on "whether it can answer," but on "whether you can pick up across devices mid-stream."

Source: juejin.cn
BZH
DeepSeekHarness流式响应·

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 工具卡顿、丢消息时,理解「中间层在写日志」这件事,能帮你判断是网络问题还是产品本身问题。

对消费市场:未来 AI 助手体验会拉开差距——不在「能不能回答」,而在「中途切设备能不能接上」。

Source: juejin.cn