一句话定义：WebSocket 是一种网络通信协议，客户端与服务端经过一次 HTTP 握手（handshake）建立连接后，这条连接会持续保持，双方随时可以互相发送数据——也就是全双工（full-duplex）。
它解决了什么问题
HTTP 的基本模式是"客户端问、服务端答"：发一个请求，拿一个响应，这次交互就结束了。如果服务端后来产生了新消息，它没法主动告诉你，只能等你下次来问。这叫轮询（polling）：问得太勤浪费资源，问得太慢消息就延迟。
打个比方，HTTP 像点外卖——你下单，商家送一趟，交易结束；想知道有没有新情况，只能反复重新下单问一句。WebSocket 像打电话——拨通之后双方随时可以开口，不用每次都重新拨号。
它是怎么做到的
客户端先发一个带 Upgrade 头的 HTTP 请求，表示希望升级协议；服务端同意后返回 101 状态码，这条 TCP 连接就从 HTTP 切换为 WebSocket。此后双方按"帧（frame）"收发数据，文本和二进制都支持，也不需要每次都背着一大堆请求头，开销小得多。
和相邻概念的区别
| 方式 | 通信方向 | 是否每次重建连接 | 典型场景 |
|---|---|---|---|
| HTTP 短轮询 | 客户端 → 服务端 | 是 | 兼容性优先的简单场景 |
| HTTP 长轮询 | 服务端 → 客户端（有延迟） | 是 | 早期聊天、通知 |
| SSE | 服务端 → 客户端单向 | 否 | 服务端单向推文本流 |
| WebSocket | 双向 | 否 | 实时语音、协作编辑、事件推送 |
SSE（Server-Sent Events）同样保持长连接，但只能服务端往客户端推；客户端想说话还得另开 HTTP 请求。
对 AI 从业者的意义
实时语音是最典型的场景。语音对话要求"边说边传"：麦克风音频持续上行，模型生成的语音持续下行。若每个音频块都发一次 HTTP 请求，握手与请求头的开销会直接拖垮体验；在 WebSocket 上，一条连接就能承载双向流式音频。
Agent 事件推送同理。一个 Agent 执行多步任务时会产生大量中间事件：工具调用开始与结束、思考过程、流式 token、进度状态。用 WebSocket 把这些事件实时推给前端，界面就能"边跑边显示"，而不是等任务全部结束才一次性返回。
代价
长连接是有状态的：服务端要维护连接表、用心跳（ping/pong）保活、处理断线重连，扩容与负载均衡也比无状态 HTTP 麻烦。所以它适合"持续双向"的场景，不适合一次性的请求—响应。选型时别把 WebSocket 当成"更快的 HTTP"，它们是两种不同的通信模型。