# 中继不引入 WebSocket，插件的 WebSocket 用流式响应加普通请求模拟

插件桥要转发 better-sidebar 的两条 WebSocket（「文件变动」与「智能体打开文件」）时，沿用中继的既有约定「单次调用走普通 HTTP 请求、订阅走 NDJSON 流式响应、不自己实现 WebSocket」：子客户端后台在本机接住浏览器的 WebSocket，服务端→浏览器方向走一条中继流式响应，浏览器→服务端的指令逐条走普通请求；主服务端用 Node 自带的 WebSocket 客户端连本机插件。理由：这两条 WebSocket 几乎是单向的，上行只有偶发的小指令，模拟成本低；让 WebSocket 真正穿过网关，要改网关对桌面应用端的放行规则，并给中继新增一种双向通道。

## Consequences

- 若将来出现上行频繁或对延迟敏感的插件 WebSocket（如逐键交互），每条上行消息一次请求的模拟会成为瓶颈，届时应重新评估本决定。
- 2.2 的落地实现（PB-10）与上文「Node 自带的 WebSocket 客户端连本机插件」的设想不同：最终是**字节隧道，帧不解析**。子客户端把浏览器的升级请求头与双向字节原样搬运——服务端→浏览器一条 NDJSON 流式响应，浏览器→服务端按序分块的普通请求；服务端用收到的头向本机插件**手写升级请求**，之后双向字节各自原样穿过，中继与网关全程不解析 WebSocket 帧，帧与关闭语义由两端真正的 WebSocket 端点处理。「每条上行消息一次请求」的瓶颈因此不成立：上行按 64 KiB 块流水，与消息边界无关；协议形状见 `docs/remote-access.md` 的「插件桥的 WebSocket 字节隧道」一节。