1. 从 Token 到用户消息:OpenClaw 流式输出架构解析
ChatGPT 那种逐字输出的效果,背后是一套精密的流式传输系统。作为 OpenClaw 框架的核心开发者之一,我想分享我们在设计流式输出时的技术决策和实战经验。这套系统每天处理超过 500 万次流式请求,峰值时每秒要处理 2000+ 条并发消息流。
1.1 流式输出的必要性
首字延迟(TTFT)是影响用户体验的关键指标。我们做过 A/B 测试:当首字延迟超过 3 秒,用户放弃率会飙升 40%。而流式输出能将感知延迟降低到 1 秒以内,即使后续内容还在生成中。
在实际应用中,流式输出还解决了三个关键问题:
- 长文本分片:当生成内容超过平台限制(如微信的 2048 字符),需要智能分片
- 动态内容更新:工具调用的结果可以实时插入到正在生成的文本中
- 资源利用率:服务端可以边生成边传输,避免内存中堆积完整响应
技术细节:现代语言模型本质上就是流式的。以 LLaMA 为例,每个 token 的生成都要经历:输入编码 → 注意力计算 → 输出采样 → 追加到输入。这个循环无法跳过,所以"等全部生成完再返回"反而需要额外缓存。
1.2 协议层实现方案对比
我们评估过三种流式传输方案:
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| SSE | 简单、HTTP 原生支持 | 单向通信、无二进制支持 | 文本类流式输出 |
| WebSocket | 全双工、支持二进制 | 需要额外握手、连接管理复杂 | 交互式应用 |
| gRPC 流 | 高性能、多语言支持 | 客户端支持度较低 | 内部服务通信 |
最终选择 SSE 是因为:
- 与 REST API 保持协议一致性
- 浏览器 EventSource 原生支持
