Repository navigation
长会话中推理内容被并入助手正文，两个 DeepSeek 通道均复现 #7552
Description
提交人: 匿名
客户端版本: 0.1.118
现象
长会话里，助手的回复开头会出现一段英文推理文字（例如以 “User asks: …” 或 “Found it: …” 开头），紧接着才是本轮真正的中文答案，两段内容存在同一条助手消息里。界面看上去就是一条回复先播一段自言自语，再给结论。
复现情况
- 同一会话内多次出现，不是单次偶发
- 该会话 135 条助手回复中约 17 条出现（约 12%）
- 换 provider 后依然出现：先是自建 DeepSeek（OpenAI 兼容端点），切换到内置网关的同一模型后仍复现
- 位置不固定，早期回复有，长上下文后期也有
已排除的方向
- 不是模型错：直接调该模型原生接口，
content与reasoning字段是分开返回的，正文里没有推理内容 - 不是协议差异：把自建 provider 从
anthropic-messages改为openai-chat后，问题依旧 - 不是某个通道特有：把伙伴切到内置网关的同一模型后，问题依旧
环境
客户端 0.1.118（当前渠道无可用更新），pi 1.0.2，Windows，模型为 DeepSeek 系带推理的型号。
影响
- 回复可读性严重下降，容易被当成答错
- 这部分推理文字会被写入会话记录并参与后续上下文，进一步污染上下文
期望
推理内容应始终走独立的 thinking 通道，不进入助手正文。即使上游返回格式不规范（推理混在 content 中、或缺少签名的 thinking 块），也应在展示与持久化层面与正文区分开，或至少在渲染上折叠。
备注
无法上传截图，改为文字描述：界面中该条回复是一个连续气泡，上半部分是英文推理段落（含 “User asks: …” 这类自述句），下半部分是中文答复，中间没有分隔或折叠。
提交时的任务环境
仅代表提交时快照,不一定是故障环境。OS 来自提交客户端本机,不含 SSH 远端主机;Harness / 模型来自当前任务。与运行环境无关的反馈可忽略本段。
版本区域: CN
OS: win32 x64 (10.0.26100)
Harness: Pi
Model ID: deepseek-flash
界面语言: zh-CN
Activity
dash-s-cindy commentedon Oct 27, 2026
判断
保证思考模型的思维链与助手答复物理隔离，是维持长会话可读性与上下文纯净度的必要机制。进一步检查发现，长会话中约 12% 偶发的推理文字混入正文，现有证据尚不能排除上游模型在复杂上下文下的原生行为：社区在同系列模型（DeepSeek-V4.1-Flash / deepseek-flash）中已观察到类似在多轮上下文或特定轮次偶发将 Chain-of-Thought（CoT）直接生成在
content字段中的现象。当前首要任务是抓取复现轮次的原始网络数据以明确责任分界，避免盲目在客户端引入易误伤正文的文本启发式截断。行动
reasoning_effort/thinking 配置，并比对响应中英文思考段落究竟来自delta.reasoning_content还是delta.content。delta.content）：确认属上游模型/网关在多轮长上下文下的 CoT 泄漏（与外部同模型报告一致），客户端并未做错误拼合；应推动网关侧排查 template/parser 配置或向上游反馈，不建议在客户端基于正则强行剥离英文自述（避免误伤正常的英文分析或复盘正文）。delta.reasoning_content）：定位客户端 Pi 运行时在对应协议转换（translator.ts或openai-completions）中的解析断点，修复特定时序下 thinking delta 被转为 text 派发的逻辑缺陷。关键依据
thinking_delta事件生成折叠卡片（packages/maker-core/src/agents/pi/translator.ts）；若上游直接将文本通过delta.content下发，客户端会作为普通文本消息（text_delta）流式呈现并持久化，不会进行语义层面的内容猜测。content内。相关记录
reasoning_content导致 400 报错的问题，仅补齐了出站空串回传兜底，不改变响应流的通道映射。