为什么你这个Agent项目选择用 SSE 而不是 WebSocket？是怎么考虑的技术选型

在最近的 AI Agent 相关面试中，我发现这是一个必考的“送分题”。如果仅仅背诵“SSE 是单向、WebSocket 是双向”这类基础定义，很难打动面试官。

面试官真正想考察的，是你对业务场景的适配能力以及对网络协议架构的深度思考。以下是我总结的深度回答思路。

一、 核心分歧点：场景驱动选型

在面试中，我通常会先抛出一个观点：没有最好的协议，只有最适合业务的协议。

• SSE (Server-Sent Events)：本质是基于 HTTP 的“长轮询升级版”。服务器在处理完请求后，保持连接开启，不断推送数据（流式）。
• WebSocket：一个独立的 TCP 全双工协议。客户端和服务器可以随时随地相互“插话”。

二、 为什么在 AI Agent 中 SSE 是首选？

大部分 AI Agent（如智能对话助手）的核心诉求是 “流式输出（Streaming）” ，即大模型生成内容的速度较慢，前端需要逐字显示。此时使用 SSE 具有显著优势：

1. 协议轻量，兼容性好：SSE 基于标准 HTTP。在大多数企业架构中，负载均衡器（Nginx, HAProxy）对 HTTP 的支持非常完善，不需要特殊的协议升级配置。
2. 自带“重连”特性：SSE 协议标准中内置了 Last-Event-ID，当网络发生抖动断开时，浏览器会自动尝试重连并请求断点续传。这在弱网环境下对 AI 对话体验极其重要。
3. 开发运维成本极低：后端只需将响应头设置为 Content-Type: text/event-stream，无需维护复杂的心跳检测（Heartbeat）机制。

三、 什么时候必须“弃 SSE 投 WebSocket”？

当面试官追问“什么时候必须用 WebSocket”时，我会列举以下场景：

• 真正的双向实时性：如果 AI Agent 需要支持 “语音实时打断” 功能。用户在说话时，必须立即向服务器发送中止指令，此时 SSE 的单向性无法满足，必须使用 WebSocket 实现全双工通信。
• 高频交互与多端协同：如果 AI Agent 不仅仅是问答，还涉及到多人同时操作一个画布、实时状态同步，WebSocket 的低延迟和双向控制能力是 SSE 无法替代的。
• 复杂二进制传输：WebSocket 支持二进制帧传输，如果业务涉及实时流式处理音频、视频或复杂的 protobuf 数据，WebSocket 的效率会更高。

四、 面试总结：我的回答模板

在面试回答时，我会采用 “结论先行 + 场景对比 + 进阶思考” 的逻辑：

“在 AI Agent 的开发中，我倾向于优先选择 SSE，因为大模型对话本质上是基于 HTTP 的单向流式渲染，SSE 能够以最小的运维成本实现流畅的‘打字机效果’，且自带重连，用户体验极佳。

但如果业务进入了 ‘实时交互’（如语音对话打断） 或 ‘多端协同’ 阶段，我会切换为 WebSocket。因为此时我们需要双向的高频交互，SSE 的单向性会成为架构的瓶颈。

此外，我认为技术选型还应考量运维复杂性。SSE 在 Nginx 等中间件配置上非常简单，而 WebSocket 需要考虑连接保活（心跳包）、多实例下的 Session 同步等问题，如果不是刚需，我会尽量规避 WebSocket 的复杂性。”