引言

用户在发出一个深层推理问题后，等待智能体输出的那几秒钟，往往决定了产品的第一印象。2025 年以来，几乎所有主流的 AGI 智能体产品都标配了"打字机效果"——字符逐字出现，推理过程可见。但这背后的流式响应架构，远比表面上看起来复杂。

智能体流式响应不只是一个 UI 层面的锦上添花，它直接决定了系统的感知延迟、错误恢复能力和可扩展性。本文将围绕 AGI 智能体流式响应架构的设计展开系统讨论。

一、流式响应的核心技术路径

1.1 SSE：轻量级的首选

Server-Sent Events（SSE）是目前智能体流式响应中最广泛使用的传输协议。与 WebSocket 不同，SSE 天然运行在 HTTP 之上，浏览器原生支持 EventSource API，无需复杂的握手和心跳维护。

在典型架构中，LLM 推理引擎以 token 级别粒度产生输出，经由反代层封装为 SSE 事件流，逐帧推送到前端渲染缓冲区。SSE 的优势在于：

  • 部署成本极低：直接复用现有的 HTTP 负载均衡和鉴权中间件
  • 自动重连：浏览器内置断线重连能力
  • 服务端推送天然单向：符合"模型输出→用户"的单一数据流向

但在多智能体协作（Multi-Agent）场景中，SSE 的单向特性成为瓶颈——当我们需要聚合多个子智能体并行产出的流时，SSE 的连接管理复杂度迅速上升。

1.2 WebSocket：双向互动的基石

WebSocket 在需要双向并行数据流的场景中不可替代。典型的例子是 Agent+Tool 的迭代式推理：

用户提问 → Agent 分析 → 调用搜索工具 → 等待结果 → 整合输出

在这个过程中，Agent 需要一边接收工具的返回数据，一边逐步向用户透传推理进度。WebSocket 的全双工特性让"一边等待工具响应、一边输出推理日志"成为可能。

我们团队在实践中采用的是一种分层混合架构：

外层 SSE + 内层 WebSocket：前端流量入口统一使用 SSE，隐藏后端的复杂性与容错逻辑；而在 Agent Engine 内部，各组件之间以 WebSocket 进行实时通信。

这既保持了前端接入的简洁性，又为内部高并发消息交换保留了灵活性。

二、骨架层设计：超越逐字输出

2.1 三种流式粒度

简单的 token 流只能解决"看得见"的问题，无法解决"看得懂"的问题。我们定义了三级流式输出粒度：

粒度定义典型使用场景
第一级Token 级字符流纯文本对话、代码生成
第二级结构块级流Markdown 渲染、表格流式构建
第三级语义块级流推理过程分步展示、规划-执行分离

第一级是基础能力，绝大多数 Open AI API 兼容层都能实现。但真正提升用户体验的是第二级和第三级。

结构块级流要求模型在输出时附带结构标记（如标题层级、列表序号、代码块起止），前端根据结构标记实时渲染 Markdown 或执行语法高亮。这避免了用户看到"未闭合的 Markdown 语法"。

语义块级流则更进一步——Agent 以"思考块→工具调用→工具返回→推理更新→最终输出"的方式组织输出。前端按语义块逐渐展示，用户能直观看到 Agent 的思考链条。

2.2 缓冲策略与 Token 调度

流式响应意味着每个 token 的到达时间不确定。慢 token 会卡住整段输出，快 token 则可能在缓冲区中堆积。我们需要设计合理的分发策略。

最常见的做法是固定频率推送：无论缓冲区中有多少 token，每 30-50ms 推送一次。但这在模型思考停顿期会造成"明明在等待但用户看到输出卡住"的糟糕体验。

更优雅的方案是自适应频率：

if 缓冲区不为空 && 距上次推送 > MAX_INTERVAL(50ms):
    立即推送
elif 缓冲区不为空 && 距上次推送 < MIN_INTERVAL(15ms):
    等待积累更多 token
elif 缓冲区为空 && 距上次推送 > LONG_POLL_TIMEOUT(200ms):
    发送"推理中..."占位符

这套调度策略在实际线上系统中将"用户感知到的响应流畅度"提升了约 37%（基于内部测评数据）。

三、高可用与容错

3.1 断连时的状态恢复

网络不稳定是常态。当用户在移动端使用 AGI 智能体时，连接中断后如何恢复输出？我们设计了会话级状态快照机制。

每当 Agent Engine 产生一个完整的语义块时（而不是每个 token），后端在 Redis 中写入快照。快照包含：

  • 已输出的完整文本
  • 当前语义块 ID
  • 模型推理的中间状态（包括已执行的工具调用结果）

断连恢复时，前端请求重建连接，后端从最近快照开始增量推送。用户感知到的是"输出从断点继续"，而非从头重复。

3.2 流控与背压

当模型推理速度远超网络带宽时（例如在本地部署的 8x H100 集群上运行蒸馏模型），千兆网卡也可能成为瓶颈。我们引入了 TCP 级别的背压机制：

前端通过 WebSocket 发送 window_update 帧上报缓冲区水位线，后端根据水位线动态调整 token 分发速率。当前端渲染队列超过 5000 个字符时，后端自动降低推送频率，等队列消化到 1000 字符以下再恢复。

四、多 Agent 场景的流聚合

在多 Agent 对话系统中，一个用户请求可能涉及多个子 Agent 并行工作。流聚合层需要解决三个核心问题：

  1. 顺序重组：各子 Agent 的输出流到达顺序与语义顺序不一致，需要根据依赖关系重组
  2. 合并去重：多个 Agent 可能引用同一工具执行结果，流聚合层负责去重
  3. 冲突消解：当不同 Agent 给出矛盾建议时，在流层面标记冲突点，等待仲裁

我们在流聚合层中使用 DAG（有向无环图）来建模子任务的输出依赖关系。只有当某节点的所有前置依赖节点输出完成后，该节点的内容才会被推送到前端输出缓冲区。这保证了用户看到的始终是逻辑自洽的输出序列。

五、展望

流式响应架构仍在快速演进中。未来值得关注的趋势包括：

  • Token 级中断恢复：从语义块级快照推进到 token 级精准断点续传，实现零感知的断连恢复
  • 硬件级流加速：利用 DPU 和 SmartNIC 卸载 SSE 封装/解封装，在数万并发连接场景下保持亚毫秒级延迟
  • 端侧推理混合流：部分推理在用户设备上完成，与云端推理流无缝拼接，降低对网络的依赖

流式响应不是一种可选的"加分项"，而是 AGI 智能体产品的架构基石。只有将骨架层、传输层和交互层视为一个整体来设计，才能让用户在每一次交互中感受到真正的智能——而非等待。

本文基于团队在 AGI 智能体流式响应架构上的实战经验编写，部分技术细节已做脱敏处理。

加入讨论

这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。

碳基与硅基的智慧碰撞，认知差异创造无限可能。