如果你最近把 OpenClaw 从 2026.5.x 升级到 2026.6.10，突然发现飞书里的回复变得很“慢”，一字一字、逐 token 往外蹦，先别急着怀疑模型、网络或者 DeepSeek API。

我这次也踩到了同一个坑：同样的模型、同样的 API，在别的入口速度正常；只有 OpenClaw 的飞书通道看起来慢得离谱。最后查下来，问题不在模型生成速度，而在 OpenClaw 6.10 飞书通道默认开启了 interactive card streaming。

最终修复很简单：

openclaw config set channels.feishu.streaming false --strict-jsonopenclaw config set channels.feishu.blockStreaming false --strict-jsonopenclaw gateway restart

下面把完整排查过程整理出来，给后来遇到同样问题的人少走点弯路。

现象：升级后飞书开始“逐字蹦出”

升级前，我的飞书机器人回复方式比较像这样：

1. 模型先在后台生成完整答案。
2. 生成结束后，飞书里一次性出现完整回复。
3. 体感上是“等几秒，然后整段出来”。

升级到 OpenClaw 2026.6.10 后，体验变成了：

1. 飞书消息卡片很快出现。
2. 内容开始一个 token、一个 token 更新。
3. 看起来像模型在慢慢打字，长回复尤其明显。

一开始很容易误判成“模型慢了”或者“DeepSeek API 变慢了”。但对比之后会发现：同模型在其他客户端里速度正常，日志里模型调用耗时也没有离谱，真正慢的是飞书里可见回复的展示方式。

这点很关键：生成慢和展示慢是两回事。前者是模型/API 问题，后者可能只是通道投递策略变了。

排查过程：几个看起来合理但其实不对的方向

1. 先怀疑 fast mode

OpenClaw 6.10 的 changelog 里提到了 fast talks auto mode，还提到了 delivery behavior。看到这里，我第一反应是：是不是 fast mode 改了回复投递方式？

这个猜测并不离谱，因为“delivery behavior”确实像是在说消息怎么发出去。但继续查配置和源码后发现，fast mode 不是这次问题的关键。它影响的是会话模式、短对话优化和 fallback 行为，而不是飞书通道是否逐 token 更新卡片。

所以 fast mode 可以先放一边，不要一上来就改它。

2. 尝试 acp.stream.deliveryMode

我试过把 ACP stream delivery 改成 final_only：

openclaw config set acp.stream.deliveryMode '"final_only"' --strict-jsonopenclaw gateway restart

这个配置看起来非常像正确答案，因为 final_only 的字面意思就是“只交付最终结果”。但它实际管的是 ACP / 子代理相关的流式输出，不管飞书主通道的可见回复。

结果：飞书仍然逐字显示。

3. 尝试 messages.visibleReplies

我也试过动 visible replies，例如：

openclaw config set messages.visibleReplies false --strict-jsonopenclaw gateway restart

这个方向也容易误解。messages.visibleReplies 控制的是“最终可见回复是否自动发出、是否要求 message tool”，不是“是否等生成完再发”。

如果把它设错，可能不是变成一次性回复，而是直接不发可见回复。日志里可能还能看到模型跑完了，但飞书里没有消息。

结果：不适合解决这个问题。

4. 尝试模型层 streaming

另一个很自然的想法是：既然逐 token 显示，那是不是把模型 streaming 关掉就行？

比如类似这种配置：

{  agents: {    defaults: {      models: {        "deepseek/deepseek-v4-pro": {          streaming: false        }      }    }  }}

这个方向也不对。模型层 streaming 影响的是 OpenClaw 调模型 API 的方式；而这次我们要解决的是飞书通道如何把已经生成中的内容展示给用户。

更麻烦的是，有些 OpenAI-compatible provider 或特定模型配置关掉模型 streaming 后，可能出现不返回、无回复或兼容性异常。

结果：不建议用模型层 streaming 来修飞书逐字显示。

根因：Feishu channel 的 streaming 默认开启

真正的根因在飞书通道配置：

channels.feishu.streaming

在 OpenClaw 6.10 里，飞书通道支持 interactive card streaming。也就是说，它会在飞书里创建或更新交互式卡片，把模型生成过程中的 partial reply 持续推到飞书界面上。

这本身不是 bug，甚至对某些人是功能：你可以更快看到模型开始输出。但如果你习惯了旧版本那种“等生成完一次性发完整消息”的体验，就会觉得它突然变慢了。

关键点是：

channels.feishu.streaming: true

会让飞书通道实时更新卡片；

channels.feishu.streaming: false

会让飞书通道不要绑定 partial reply，等最终回复出来后再发送。

也就是说，这个开关是通道层的，不是模型层的。

正确修复：关闭飞书通道 streaming

如果你想恢复升级前那种“完整生成后一次性发送”的体验，直接执行下面三行：

openclaw config set channels.feishu.streaming false --strict-jsonopenclaw config set channels.feishu.blockStreaming false --strict-jsonopenclaw gateway restart

执行完可以检查一下配置是否生效：

openclaw config get channels.feishu.streaming --jsonopenclaw config get channels.feishu.blockStreaming --jsonopenclaw gateway status

预期输出里应该能看到：

falsefalseRuntime: runningConnectivity probe: ok

如果你更喜欢直接看配置片段，最终效果大概是这样：

{  channels: {    feishu: {      streaming: false,      blockStreaming: false    }  }}

注意：这里不要顺手改 agents.defaults.models.*.streaming。那是另一层东西。

踩坑清单：这三个配置为什么不行

坑 1：acp.stream.deliveryMode

openclaw config set acp.stream.deliveryMode '"final_only"' --strict-json

这个名字很像答案，但它管 ACP / 子代理流，不管飞书主回复通道。飞书逐字显示仍然会继续。

坑 2：messages.visibleReplies

openclaw config set messages.visibleReplies false --strict-json

这个配置不是“最终一次性显示”，而是影响可见回复策略。设错之后可能会让飞书不显示回复，排查时反而更迷惑。

坑 3：模型层 streaming: false

{  agents: {    defaults: {      models: {        "your-provider/your-model": {          streaming: false        }      }    }  }}

这个改的是模型 API 调用方式，不是飞书卡片更新方式。对一些 provider 来说还可能引入兼容性问题。飞书逐字显示应该从 channels.feishu.streaming 入手。

如果改完还是慢，怎么继续查

先确认你改的是正确路径：

openclaw config get channels.feishu.streaming --jsonopenclaw config get channels.feishu.blockStreaming --json

如果还是 true，说明配置没有写进去，或者写到了另一个 profile / state dir。

再确认 Gateway 是否真的重启：

openclaw gateway status

如果 Gateway 没重启，旧配置可能还在运行。

最后看日志：

openclaw logs --follow

重点看飞书相关日志里是否还有 streaming card、partial reply、queuedFinal、replies 之类的信息。通常配置正确后，飞书不应该继续逐 token 更新卡片。

教训总结

这次最大的教训是：看到“逐 token 显示”，不要本能地只盯着模型 streaming。

OpenClaw 这类多通道 agent 系统里，至少有三层“流式”概念：

1. 模型 API 是否 streaming。
2. Agent / ACP / 子代理内部如何交付中间输出。
3. 具体聊天通道如何把回复展示给用户。

这次飞书变慢，卡在第 3 层。

所以正确思路不是“哪里有 streaming 就关哪里”，而是先问一句：慢的是生成，还是展示？

如果模型本身 7 秒生成完，但飞书里 50 秒才逐字显示完，那根因大概率不是模型，而是飞书通道的消息投递策略。

最终记住这条就够了：

openclaw config set channels.feishu.streaming false --strict-jsonopenclaw config set channels.feishu.blockStreaming false --strict-jsonopenclaw gateway restart

希望这篇能帮你少折腾一小时。升级后的新功能不一定是坏事，只是默认体验变了；找到真正的配置层级，问题就很小。