type
Post
status
Published
date
Apr 29, 2026
slug
openclaw-qwen35-thinking-leak-postmortem
summary
一次真实生产事故复盘：从 SGLang/Qwen3.5 的 reasoning 输出，到 OpenClaw 聊天面思维链泄漏的双层根因。
tags
OpenClaw
升级复盘
Qwen3.5
SGLang
事故复盘
category
技术分享
icon
password
关键词：OpenClaw / Qwen3.5 / SGLang / Thinking Process / Telegram / reasoning 泄漏
这次最值得单独写一篇的，不是升级本身，而是升级后暴露出的一次真实生产事故：Telegram 私聊里直接收到了 Thinking Process、</think>，甚至“我应该怎么回”这类内部过程话。
这不是普通的文案污染，而是系统把本来不该对外可见的内部推理内容，当成了最终聊天正文发出去。
01｜问题现象：为什么这类故障特别伤
因为它直接击穿了用户面对系统时最基本的边界感。
- 一方面，它会暴露模型内部草稿；
- 另一方面，它会让用户怀疑整条对话链路是不是不可信。
对聊天系统来说，只要对外聊天面还在漏思维链，这条链路就不能算修好。
02｜第一层根因：模型/协议层本来就可能产出 reasoning 内容
Qwen3.5 / SGLang 的真实会话链路，本身就可能返回 reasoning 相关内容，比如 Thinking Process、<think> / </think>、流式碎片，甚至伪装成正文的内部过程话。
这说明底层协议层不是天然“无害”的，它会产出需要被正确吸收、隔离或过滤的内容。
03｜第二层根因：OpenClaw 出站链路没有把内部过程和用户正文彻底隔开
真正让事故落到用户面前的，是第二层：OpenClaw 的真实聊天出站链路把这类内容直接作为正文送往 Telegram。
于是协议层的问题，不再停留在 API 层，而是变成了用户可感知的事故。
04｜再往里拆：为什么 reasoning 解析会失控
- reasoning 默认值解析不稳；
- chat-template 默认值参与 reasoning-mode 决策时行为不一致；
- <think> 不完整 token 的流式解析存在瑕疵。
这类问题的共同特点是：单看某一个点都不致命，但叠在一起，就足以让内部过程一路穿透到最终聊天面。
05｜解决思路：不能只修 API，要修真实聊天面
这次真正有效的修法，不是停留在“裸打接口看起来没问题”，而是分层做：
- 修 reasoning-mode 决策顺序，让显式请求参数、模板默认值、parser fallback 的优先级更清晰；
- 修 <think> 残片流式解析，减少碎片误缓冲；
- 把验收标准从“接口正常”提升为“Telegram 私聊真实链路 clean”。
06｜这件事给聊天系统的一个硬提醒
面向用户的聊天产品，不能把“协议正确”误当成“体验正确”。只要真实聊天面还在外露内部过程，这条链路就没有交付。
07｜真正有效的验收是什么
- Telegram 私聊真实链路 clean；
- OpenClaw 真链路返回干净正文；
- 最小回归不再出现 Thinking Process、</think>、内部过程话。
所以这次修复后的稳定口径，不该表述成“Qwen3.5 完全不再产生 reasoning 内容”，而应该表述成：OpenClaw 对外聊天主链路已经修住了思维链泄漏主问题。
- 作者:Leisurelywolf
- 链接:https://blog.869669.xyz//technology/openclaw-qwen35-thinking-leak-postmortem
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
