在大模型多智能体架构推向多端部署（PC 浏览器、移动端 App、小程序以及内网微服务调用）的过程中，实时流式交互是用户体验的核心支柱。然而在通信协议的选型上，技术团队经常爆发争论：前端工程师更偏爱轻量、原生的 Server-Sent Events（SSE），因为其天然支持断线重连且对 HTTP 代理极度友好；而客户端与全双工协同团队则极力主张使用 WebSocket，以支持端到端双向事件交互与中途打断控制。
如果只押注一种协议，往往会在特定终端场景遭遇工程碰壁（例如微信小程序对原生 EventSource 支持较弱，而复杂的反向代理网络又经常掐断无心跳的 WebSocket）。
打造一个支持双向自适应协商的统一流式网关（Unified Streaming Gateway），让网关根据客户端能力、网络环境与业务交互复杂度动态切换 SSE 或 WebSocket，是构建企业级 Agent 通信中枢的最佳实践。
场景解构：SSE 与 WebSocket 的技术特性对比
要做好动态分流，首先必须从物理层和协议层彻底理清两者的优缺点：
| 通信模型 | 单向流（服务端下发，客户端走独立 HTTP POST） | 全双工双向（单个 Socket 自由双向收发） |
| 底层协议 | 纯 HTTP/1.1 或 HTTP/2，天然穿透企业防火墙 | 依赖 HTTP Upgrade 握手，切换为独立 TCP 帧协议 |
| 断线重连 | 浏览器原生支持，自带 Last-Event-ID 状态追溯 | 需客户端手动编写心跳、重试与状态追赶逻辑 |
| 移动端/小程序兼容性 | 移动端某些旧内核解析流式 Chunk 较繁琐 | 各大小程序及移动端原生 SDK 支持极其完备 |
| 资源消耗 | 基于 HTTP 请求生命周期，连接结束后资源立即回收 | 常驻长连接，单机连接数上限受限于文件描述符 |
统一网关的双协议协商与路由设计
统一流式网关的核心职责，是屏蔽底层传输差异，向上游 Agent 编排引擎提供统一的 StreamSink 抽象管道。
网关在接收客户端首包握手时，通过协商机制完成协议绑定：
package gateway
import (
"context"
"net/http"
"github.com/gorilla/websocket"
)
// StreamSink 屏蔽底层传输协议差异的统一下发抽象
type StreamSink interface {
SendToken(token string, seq uint64) error
Close() error
}
// SSESink 针对 Server-Sent Events 的实现
type SSESink struct {
w http.ResponseWriter
flusher http.Flusher
}
func (s *SSESink) SendToken(token string, seq uint64) error {
_, err := s.w.Write([]byte("data: " + token + "\\n\\n"))
if err != nil {
return err
}
s.flusher.Flush()
return nil
}
func (s *SSESink) Close() error {
return nil
}
// WebSocketSink 针对全双工长连接的实现
type WebSocketSink struct {
conn *websocket.Conn
}
func (ws *WebSocketSink) SendToken(token string, seq uint64) error {
return ws.conn.WriteJSON(map[string]any{
"seq": seq,
"delta": token,
})
}
func (ws *WebSocketSink) Close() error {
return ws.conn.Close()
}
中途打断（Interruption）的双向闭环方案
在长文本推理或复杂 Agent 工具链执行中，用户点击“停止生成”是极高频的操作。对于 WebSocket 而言，客户端直接向当前连接发送一个 {"action": "abort"} 帧即可触发终止；而对于只读的 SSE 链路，客户端关闭连接只能单向切断网络读取。
统一网关必须抹平这种控制差异：
- SSE 链路的协同打断：客户端在关闭 EventSource 的同时，必须向网关的 /api/v1/agent/abort 接口异步抛出一个轻量的控制包（携带 SessionID）。
- 网关上下文取消广播：网关在内存中维护 SessionID -> context.CancelFunc 映射表。一旦捕获到客户端打断信号，立即执行 cancel()，切断下游大模型推理与工具执行协程，实现与 WebSocket 完全一致的毫秒级算力释放。
生产落地的运维调优与防坑守则
在构建双协议流式网关时，有两个网络基础设施层面的深水坑必须提前规避：
第一，Nginx 反向代理的缓冲（Buffering）陷阱。对于 SSE 流量，很多工程师上线后发现前端依然收不到实时流，必须等后端生成全部 2000 字后才一口气刷出。这是因为 Nginx 默认开启了 proxy_buffering on;。必须在网关响应头中显式加上 X-Accel-Buffering: no;，或者在 Nginx 配置中针对流式路径关闭响应缓冲，保证 TCP 数据包即时穿透。
第二，WebSocket 的跨可用区负载均衡与会话漂移。WebSocket 是状态化长连接，如果直接挂在普通的四层负载均衡器（L4 SLB）后面，单台网关节点重启会导致数万连接瞬间集中断开并重连到少数存活节点，引发惊群效应。推荐使用带有连接平滑迁移和自适应限速的七层网关（如 Envoy），并在网关滚动更新前主动向客户端广播断线重连通知，实现流量平滑迁移。
统一双协议网关将底层的网络协议争论转化为纯粹的架构适配层，让多智能体系统在兼顾全场景终端兼容性的同时，赋予了终端用户流畅、稳定的实时推理交互体验。
