面试题库

30 天从前端工程师到 Agent 工程师

D1 LLM API 基础：messages/roles、token、流式、temperature；Agent 到底是什么

• 为什么 LLM 应用几乎都用流式输出？SSE 和 WebSocket 该怎么选？Why do LLM apps stream responses, and how do you choose between SSE and WebSockets?

  国内高频海外高频进阶#streaming#protocol

  分析过程 · 先想清楚再作答

  1. 第一问考的是对延迟指标的敏感度：要能区分「首字延迟」和「全文延迟」，并说出模型逐 token 生成决定了前者远小于后者。
  2. 把它翻译成产品语言：用户 1 秒内看到反馈 vs 对着空白等 20 秒，这是体验的分水岭，不是锦上添花。
  3. 第二问不要背优缺点表，先问自己「客户端需不需要频繁上行」——这一条几乎决定了答案。
  4. 只需要服务器往下推 token，SSE 就够：它跑在普通 HTTP 上，代理和负载均衡友好，还自带重连。需要语音、协同、频繁打断这类双向高频交互，才值得上 WebSocket。
  5. 给出多数产品的真实形态：请求走普通 POST，回复走 SSE，另配一个取消接口——顺势可以引到「POST 的 SSE 用不了 EventSource 的自动重连」这个坑。

  How to reason about it · think before answering

  1. The first half tests latency literacy: separate time-to-first-token from total latency and tie it to sequential generation.
  2. Translate to product terms: feedback within a second versus twenty seconds of blank screen.
  3. For the second half, skip the pros-and-cons table and ask whether the client needs frequent upstream messages.
  4. Server-to-client tokens only means SSE suffices: plain HTTP, proxy-friendly, with built-in reconnection. Voice, collaboration or frequent interrupts justify WebSockets.
  5. State the common shape: plain POST for the request, SSE for the reply, plus a cancel endpoint — which sets up the trap that POST-based SSE cannot use EventSource auto-reconnect.

  答题要点

  • 模型逐 token 生成，首字延迟远小于全文延迟；流式让用户 1 秒内看到反馈而不是等 20 秒
  • SSE 是单向、基于 HTTP 的文本协议，自动重连、穿透代理容易，天然适合服务器→客户端的 token 流
  • WebSocket 双向、更适合需要客户端频繁上行（语音、协同编辑、打断）的场景，但代理/负载均衡更麻烦
  • 多数聊天产品：请求用普通 HTTP POST，回复用 SSE；需要打断时再加一个取消接口

  Key points

  • Models emit tokens sequentially; time-to-first-token is far lower than full latency
  • SSE is one-way over HTTP with built-in reconnect and easy proxying, ideal for server→client token streams
  • WebSockets are bidirectional, better when the client sends often (voice, collaboration, interrupts) but harder to load-balance
  • Most chat products: plain POST for the request, SSE for the reply, plus a cancel endpoint