小龙虾(OpenClaw)源码分析7：流式输出机制，回复为什么又快又稳

很多同学体验AI助手时，最在意的一点就是“回得快不快”。
但真实工程里，快和稳经常打架。OpenClaw在这块做了不少折中。

两种常见输出模式

先把概念捋清：

• 非流式：模型算完再一次性返回
• 流式：边生成边发（用户感知更快）

OpenClaw在此基础上还有一层“块级流式（block streaming）”策略，让输出更可控。

为什么不是永远全流式

现实里各渠道能力不同：

• 有些渠道支持消息编辑，流式体验好
• 有些渠道不适合频繁改消息，容易刷屏或失败

所以工程上不能只追求“token级推送”，还要考虑渠道兼容和失败回退。

block streaming在解决什么

文档里提到text_end、message_end、chunk范围这些配置。
核心目标是：

• 不要每个字都发一次（太碎）
• 尽量按段落或句子切块（可读性更好）
• 降低渠道侧API压力

简单说就是：在流式速度和可读性之间找平衡点。

体验层面的三个关键点

我觉得这块最关键是三件事：

1. chunk边界策略（段落优先）
2. coalesce合并策略（减少碎片刷屏）
3. 失败时回退到最终完整消息

这三点做好了，用户才会觉得“快且不乱”。

配置示意

{
  agents: {
    defaults: {
      blockStreamingDefault: "off",
      blockStreamingBreak: "text_end"
    }
  }
}

建议先在你最常用渠道上小范围开启，观察日志和用户体验，再扩大范围。

实战建议

• 群聊场景优先稳，别过度细粒度流式
• 私聊场景可以更激进，提升响应感知速度
• 工具调用多的场景，配合工具事件摘要，避免“沉默等待”

小结

这篇的核心结论：

• 流式不是越细越好，而是越“合适”越好
• block streaming是工程折中，不是功能炫技
• 渠道能力差异决定了最终策略

下一篇我们看AGENTS.md / SOUL.md / TOOLS.md这些工作空间文件，看看它们是如何实质影响Agent行为的。

参考链接

• https://docs.openclaw.ai/concepts/streaming