36 lines
2.2 KiB
Markdown
36 lines
2.2 KiB
Markdown
---
|
||
name: "fix-reply-streaming"
|
||
description: "飞书/WebUI 回复不逐字（整条一起蹦出、第一句丢失）时修复流式：先查会话 thinking 级别，再设为 off。"
|
||
---
|
||
|
||
# 修复回复不流式（飞书 / WebUI）
|
||
|
||
触发：用户说「消息不逐字显示了」「一整段吐出来」「回复整条蹦出来」「WebUI 里显示不对」，或流式在 OpenClaw 更新后消失。
|
||
|
||
## 1. 先看证据：文本被推迟到终段投递
|
||
|
||
对出问题的会话跑 `sessions_history`（`includeTools: true`）。流式被掐的标记是：
|
||
|
||
- 工具调用前的解说文本单独成一条 assistant 消息，带 `openclawStreamFallback: { replacementText, source: "segment", itemId: "commentary-N" }`；
|
||
- 同一 run 里另一条消息带 `openclawDelivery: { textPhaseRequiresTerminal: true }`。
|
||
|
||
看到这两个标记 = 核心把文本攒到消息末尾一次性投递。飞书侧表现为「攒完一起蹦」；WebUI 侧那条解说行可能整条不渲染（但它在会话历史里是存在的，别据此判断「消息丢了」）。
|
||
|
||
## 2. 查 thinking 级别（根因）
|
||
|
||
看 `session_status` 输出里的 `🎛️ Modes:` 行。`think` 不是 off（例如 `think xhigh`）就是根因：
|
||
|
||
- 模型每输出 thinking（推理）→ 核心 `beginReasoning()` 给该条打 `textPhaseRequiresTerminal: true`（8.2 `dist/worker/worker.mjs` 源码确认）→ 文本不再逐段推送。
|
||
- 所以**只要模型带推理，流式必被掐**：8.2 与 9.3 实测都一样，与版本无关。
|
||
|
||
## 3. 修
|
||
|
||
1. `sessions(action="patch", sessionKey="<会话>", thinkingLevel="off")`
|
||
2. `session_status` 复查，`🎛️ Modes:` 应显示 `think off`。只对**下一轮**生效，正在跑的那轮不受影响。
|
||
3. 让用户配合分段验证：回一次「发一句 → sleep 15 秒 → 再发一句」。第一句在 sleep 期间就出现 = 已恢复。
|
||
|
||
## 4. 不要走弯路
|
||
|
||
- **降级 OpenClaw / 飞书插件不解决**（实测降到 8.2 仍被掐）。
|
||
- `agents.defaults.blockStreamingDefault`、`channels.feishu.streaming.block.enabled` 是 9.x 时代为追这个 bug 加的开关，**不是修复项**；清掉它们、只留 thinking off 即可（清后实测流式正常）。
|