openclaw20260213已经有188k星星 但是还是太新问题太多 居然连上下文压缩没有做好--一次艰难的排错记录

AIYA
,
1

openclaw20260213已经有188k星星 但是还是太新问题太多 居然连上下文压缩没有做好–一次艰难的排错记录

作者：三局两胜
时间：2026-02-13

这篇是我这两天和机器人一起硬啃出来的一次完整排错记录。结论先放前面：

  • “空回复”不是模型不可用，也不是QQ插件单点故障。
  • 根因是会话上下文失控膨胀后，触发了 silent overflow（output=0）。
  • OpenClaw 当前版本在这个场景下确实存在“无提示、无自动恢复”的问题（官方已有 issue/PR）。

一、故障现象（我遇到的真实情况）

我这边出现的是：

  1. QQ 群里机器人突然开始“空回复”（看起来像没回，或只记录了 assistant turn 但内容为空）。
  2. TG 同期看起来又是正常的，造成错觉“是不是QQ插件坏了”。
  3. WebUI 能看到会话在继续写日志，但用户侧没有有效文本。

最开始排查非常混乱，因为同一时段里还夹杂了：

  • 文件发送链路问题（NapCat rich media）
  • 群触发词/艾特逻辑
  • 管理员与黑名单配置

这些问题会互相干扰观测，让“空回复”的根因不容易被第一时间抓住。

二、排查路径（按时间顺序）

1) 先确认不是 API 全挂

  • 我先验证了上游 API（newapi/cpa）在其他客户端可用。
  • 再看 OpenClaw 本地会话日志，发现并不是请求失败，而是出现了典型记录：
    • usage.input 非常大（20万~30万级）
    • usage.output = 0
    • content = []

这一步很关键：说明不是“发不出去”，而是“模型端返回了空输出”。

2) 对比 QQ 与 TG 会话体积

我把关键会话文件都拉出来看：

  • QQ 群会话：cb77ecdc-6d64-489f-8aa1-d63a92d67ce7.jsonl
  • TG 私聊会话：9c1c29b4-b309-4b71-a1bd-5a7fd8541679.jsonl

结果非常直观：

  • QQ 会话历史非常大，且多次出现 input≈260k~282k。
  • TG 同时段大概 input≈36k~38k，回复正常。

3) 精确定位“哪一次突然膨胀”

在 QQ 群会话里，膨胀拐点对应一次“搜索任务”：

  • 连续写入了多条超长 toolResult（SearchResults）
  • 单条长度约几十 KB（例如 48k / 38k / 24k）
  • 之后输入 token 立刻跳到 282k，并出现连续空回复

也就是说，不是某一句用户普通聊天把上下文炸掉，而是工具结果被完整写入会话，把本来已经很大的会话推过了临界点。

4) 验证“TG 搜索是否进上下文”

我特意做了对照：

  • TG 也会写入 toolResult（同样会进上下文）
  • 但 TG 会话基数小，所以没马上爆

这一步打破了误区：

  • 不是“TG不进上下文，QQ才进”
  • 而是“两边都进，谁先到上限谁先炸”

5) 做强制实验（证明不是错觉）

我做了两轮实验：

  • 先改会话指向（TG 指向 QQ 会话）
  • 再做文件级覆盖实验（把 QQ 大会话内容复制到 TG 会话文件）

最终确认：只要让 TG 吃到那份超大历史，也会出现空回复。这个验证把根因进一步坐实了。

三、最终根因结论

根因可以概括为三句话：

  1. 会话历史过大（尤其包含大量 toolResult/raw 搜索内容）。
  2. 请求达到/超过模型有效上下文窗口后，返回 stopReason=length + output=0。
  3. 当前 OpenClaw 在这个“silent overflow”分支上恢复策略不足，用户侧表现就是“机器人像死了一样空回复”。

四、为什么这个问题体感这么差

因为它有三个“反直觉点”：

  • 不是报错：很多时候不会直接抛明显错误，而是“看起来成功结束但没内容”。
  • 不是立刻复现：往往是长会话积累后突然触发。
  • 不是单平台限定：QQ/TG 都可能中，只是先后与会话体积有关。

五、我这边临时止血方案（可落地）

  1. 遇到空回复先 /newsession 或切新会话键，不要在已膨胀会话里硬聊。
  2. 减少大段工具原文入库，尤其是搜索结果和长网页正文。
  3. 把“上下文过重预警”做在插件层（比如 input 超阈值就提示重开会话）。
  4. 群场景建议用“测试小群（双人群）”做运维观测，便于快速确认机器人状态。

六、官方现状：已有 Issue/PR，但问题还在修复中

1) 官方 issue（同类问题）

2) 对应修复 PR（核心思路）

这条 PR 的关键思路是：

  • 识别“silent overflow”这个分支
  • 把它纳入 overflow recovery（触发 compaction/retry），而不是当成正常完成

我认为这条思路是对的，至少比“用户手动删会话文件”靠谱得多。

七、我这边额外做过的相关改造（插件侧）

这次排错期间，我这边还落地了一批配套修复（避免把别的问题混进来）：

  • 修复 QQ 私聊/群聊会话键隔离，避免跨通道串线。
  • /newsession 从“表面命令”修成“真实清会话”。
  • 增加空回复兜底提示，避免用户感知为彻底失联。
  • 修复忙碌后缀重复叠加（避免 昵称(输入中)(输入中)）。

但要强调：这些只能改善体验，真正的“超大上下文 silent overflow”仍需要内核层处理。

八、给后来者的建议

如果你也遇到“日志看起来在跑，但就是空回复”：

  1. 先查对应 session 的 usage.input/output。
  2. 看到 output=0 且 input 巨大，优先怀疑上下文溢出。
  3. 立即开新会话验证，不要在旧会话里反复试。
  4. 检查是否把大 toolResult（搜索/网页）无裁剪写入会话。
  5. 关注官方 #14064 / #14157 的合并进展。

这次确实是一次“很艰难但很值”的排错。
OpenClaw 很强，但也还很新，边用边补是常态。
希望这份记录能让后来人少走弯路。

— 三局两胜