[Bug][Desktop] 特定旧会话只能输出 Reasoning，Text 正文通道持续缺失

[Rainunknow]

1. 环境信息（Environment）

• 应用： DeepSeek Harness Desktop (DSH)

• 版本： 0.2.1-rc.3

• Electron： 44.7.0

• Node.js： v24.21.0

• 操作系统： Windows 11

• Provider： deepseek-official

• Model： deepseek-flash

• Reasoning Effort： high

• Workspace： default-workspace

异常会话 ID： Available upon request（如开发者需要，可私下提供）。

2. 问题描述（Description）

一个已经持续使用较长时间的旧会话突然出现异常：Assistant 不再正常通过 Text 通道输出回复正文，而是将生成的内容全部或几乎全部输出到 Reasoning（思考）区域。

目前确认：

1. 问题仅发生在特定旧会话中。

2. 相同 Provider、Model 和配置在新会话中可以正常输出 Text。

3. 在异常会话中，多次要求模型通过正常正文通道回复，问题仍然存在。

4. 偶尔可以成功输出极短的 Text 内容。例如，要求模型回复「在」时，曾成功通过 Text 通道输出「在」，但不稳定。

5. 故障发生前，该会话一直能够正常输出正文。

因此，这似乎不是全局模型配置问题，而是与特定会话状态或处理流程有关。

3. 故障时间线（Timeline）

根据原始会话日志：

• Turn 536： 仍然存在正常 Text 输出。

• Turn 537： 首次发现只有 Reasoning、没有 Text 的情况。

• Turn 537 之后： 大部分回复只有 Reasoning。

• Turn 541： 短暂恢复，出现 Reasoning + Text。

• Turn 547、549、555： 用户主动测试正文通道时，模型曾成功通过 Text 输出单字「在」。

• Turn 558–563： 连续六轮只有 Reasoning，没有任何 Text 区块。

这表明问题是在已有会话运行过程中出现的，并且偶尔会短暂恢复。

4. 原始日志分析（Session Log Evidence）

检查了原始会话文件及独立保存的故障现场备份：

session.v4.jsonl.zstd

在 Turn 558–563 中发现：

• assistant/message 的 content 数组只有 reasoning 类型区块。

• 没有 text 类型区块。

• 对应的 stream 记录中，chunk 同样只有 reasoning。

• 流结束原因记录为 stop。

• step/end 和 turn/end 事件正常出现。

• Turn 结束状态为 completed。

这意味着问题不只是 UI 将正常正文错误地显示在 Reasoning 区域。至少在 DSH 保存的流式事件和最终消息数据中，Text 区块本身就不存在。

不过，目前无法确认是 DeepSeek 服务端没有返回 Text，还是 DSH 的 DeepSeek Adapter 在接收、解析或保存流式响应时丢失了 Text。

5. 已完成的排查（Investigation）

5.1 请求配置

检查了故障发生前后的 request/header 事件：

• Provider 始终为 deepseek-official。

• Model 始终为 deepseek-flash。

• Reasoning Effort 始终为 high。

• Max Tokens 始终为 256000。

没有发现相关配置变化。

5.2 会话压缩（Compaction）

第四次完整压缩发生在 Turn 523，但压缩后 Turn 524–536 仍然能够正常输出 Text。

因此，目前没有证据证明这次压缩直接导致故障。

5.3 Inbox 消息处理

检查了故障时间段内的 agent/inbox/spliced 事件。

消息插入和移除操作总体规律一致，暂时没有发现明显的队列异常。

5.4 Delivery Accepted

检查了 79 条 session-log-deepseek/delivery-accepted 事件：

• 所有事件的 sessionFormatVersion 均为 4。

• 每条事件的 throughSeq 均等于对应的 seq - 1。

• 没有发现明显的序号断层。

这些事件不包含原始模型响应或 Text/Reasoning 流式内容。

5.5 故障时间段内的事件类型

检查范围：seq 17300–17985

事件类型 | 数量 -- | -- session-log-deepseek/delivery-accepted | 79 user/message | 52 request/header | 2 assistant/message | 78 agent/inbox/spliced | 82

没有发现独立记录的 stream、adapter、response 或 llm 事件。

5.6 DSH 诊断包

另外检查了 DSH 导出的诊断 JSON。

诊断包没有包含当前故障时刻的 DeepSeek 原始响应体或完整 Provider 流式响应，因此无法直接判断问题发生在服务端还是客户端。

其中发现的一些旧错误发生在当前故障之前，目前没有证据证明它们与本次问题直接相关。

6. 当前判断（Current Assessment）

目前主要有两种可能：

可能 A： DeepSeek 服务端或 API 返回的响应流本身缺少正常 Text 内容。

可能 B： DSH 的 DeepSeek Adapter 在流式接收、解析、分块合并或消息保存过程中，没有正确处理 Text 区块。

目前已经确认的是：DSH 保存的异常响应流和最终消息中都缺少 Text，但尚不能确定真正原因。

考虑到相同 Provider、Model 和配置在新会话中工作正常，而旧会话出现异常，希望开发者特别关注：

• Session Resume 处理流程；

• 长会话上下文处理；

• 历史 Compaction 与会话恢复之间的交互；

• DeepSeek Adapter 的 Streaming 和 Reasoning/Text Block Parsing 逻辑。

7. 希望开发者协助确认的问题（Questions）

1. DeepSeek Adapter 是否可能在特定会话的 Resume 或长上下文场景下错误地丢弃 Text 区块？

2. deepseek-messages 响应格式在 Reasoning 和 Text 区块的解析、合并过程中，是否可能出现异常？

3. 是否有办法在不修改原有会话历史的情况下，检查该会话实际收到的原始 Provider Response Stream？

4. 是否存在与特定会话状态、历史 Compaction 或 Streaming Recovery 有关的已知问题？

8. 数据保护情况（Data Preservation）

目前已经保留：

• 原始异常会话文件；

• 独立的故障现场备份；

• 旧版会话备份；

• DSH 诊断 JSON。

故障现场备份已经通过 SHA-256 校验，确认与原始文件一致。

目前没有执行任何破坏性操作，包括删除会话历史、重置会话、重建会话、修改原始会话文件或清理历史记录。

希望能够在不丢失、不修改现有会话历史的前提下，进一步定位并解决这个问题。

如果开发者需要，我可以在确认隐私保护方式后提供相关诊断材料。

[Rainunknow]

更新（2026-11-01）：已找到有效的恢复方法，原会话成功重新输出 Text

经过进一步排查，目前已通过 DSH 内置的 /compact 命令，让原故障会话重新生成正常的最终正文。

1. 新确认的故障证据

进一步核查发现，Turn 534 的最后一步（534.3）就已出现 reasoning-only 输出。Turn 536 仍有正常 Text，但之后异常开始频繁出现。

例如：

• Turn 554：只有 reasoning，没有 text block，也没有 text-chunks。
• Turn 555：相似的简单回复测试，成功生成 reasoning + text。
• Turn 564：再次出现 reasoning-only，turn/end.reason 为 completed。

这些差异已通过 Session 中持久化的消息与 stream 结构确认，并非单纯的 UI 显示问题。

2. 找到另一个独立的 UI 折叠问题

DSH 的 Work details 设为 Standard 等折叠模式时，如果某个已完成 Turn 的最后一步没有正常 Text，之前步骤中已经生成的正文也可能被一起折叠隐藏。

将设置改为：

Settings → Work details → Verbose

能够重新显示这些已有的正文内容。

但这只能解决显示问题，无法修复真正没有 text block 的 reasoning-only 输出。

3. 通过 Branch 验证恢复方向

从故障前最后一个完整正常的 Turn 533 创建新分支后，新会话连续两次成功生成正常正文，包括一次需要理解历史上下文的回答。

这提示后续对话历史或模型实际接收的上下文状态可能参与了故障，但不能据此确定根因。

4. 原会话通过 /compact 恢复

为了保留原 Session，先对压缩前文件进行了独立备份和 SHA256 验证。

随后，在原故障会话中手动执行一次：

/compact

DSH 返回：

已压缩 610 条历史记录（约 194464 tokens）

进一步检查确认：

• 第 5 次 Compaction 完整提交，没有发现 error；
• 610 条旧记录被 shadow；
• 原始 Turn 1–564 的事件与压缩前备份逐条一致，没有丢失或修改；
• 压缩后的有效 surface 中仍保留 1 条 reasoning-only assistant message（Turn 564）。

压缩后第一次回复测试（Turn 565）成功生成非空最终正文。底层验证结果：

• message.content 包含非空 text block；
• stream 存在 text-chunks；
• 没有 tool-call；
• Turn 正常 completed；
• Session 可完整解析，事件 seq 连续。

因此，原故障 Session 已成功恢复至少一次真实的最终 Text 输出，同时保留了完整的原始历史记录。

5. 当前结论

/compact 是本次实验中有效的恢复 workaround，但尚未确认最初的故障根因。

仍然不能确定问题来自：

• 模型受历史上下文中异常输出模式的影响；
• DeepSeek 上游响应偶发缺少 Text；
• DSH Adapter 或其他响应处理环节。

目前没有捕获到故障时的原始 Provider SSE，因此不能直接区分以上可能。

另外，压缩后的长期稳定性尚未验证，现阶段不能声称底层问题已经彻底修复。

希望这些新证据和恢复步骤能够帮助开发者及其他遇到类似问题的用户。感谢！如果问题再次出现，我会继续补充后续结果。

[Rainunknow]

补充：Adapter 与原始 SSE 排查

对当前安装版本的 DeepSeek Adapter 进行了静态源码检查，未发现合法标准 text_delta 被正常接收后静默丢弃的明确代码路径。

但 Session 中保存的 stream 并不等同于 Provider 原始 SSE。此前准备过 metadata-only SSE Observer，最终没有执行真实响应采集，因此仍无法确定上游是否实际发送了 Text。

此外，重启 DSH 并未解决原故障会话的持续 reasoning-only 问题。最终有效的恢复步骤是后续手动执行的 /compact。

[Rainunknow]

后续更新：/compact 恢复后仍出现一次间歇性复发

在原会话通过 /compact 恢复正常正文输出后，今天再次观察到一次 reasoning-only 异常。

只读核查 Session 事件确认：

• Turn 644：前 3 条 assistant message 包含 reasoning、text 和 tool-call，3 次工具调用全部成功；但最后一条 assistant message 只有 reasoning，没有非空 text block，也没有 text-chunks。整个 Turn 仍以 completed 结束。
• Turn 645：正常生成非空 text block 和 text-chunks。
• Turn 646：正常生成非空 text block 和 text-chunks。

因此，Turn 644 与此前 Turn 534 的故障结构相似，但本次没有持续发生，后续两轮自行恢复。

这表明 /compact 是本次有效的恢复 workaround，但不能证明底层故障已经永久解决。目前仍未捕获故障发生时的原始 Provider SSE，根因保持未知。

本轮仅进行了只读验证，没有再次执行 /compact 或修改任何配置、源码及 Session。

[Rainunknow]

更新（2026-11-02）：/compact 后故障复发；切换 V4 Pro 后持续恢复正常

继续补充原故障会话的后续观察。本次发现了一个比此前 /compact 更持久的恢复方向：在保留原 Session 和历史记录的情况下，将模型从 deepseek-flash 切换至 deepseek-v4-pro。

目前原会话已在 Pro 下连续运行二十多个后续 Turn，在此前容易出现异常的对话场景中，暂未观察到 reasoning-only 或短句重复循环复发。

1. /compact 并未彻底解决故障

此前更新中，原会话在第 5 次 Compaction 后，于 Turn 565 成功恢复了正常 Text 输出。

但后续使用证明，这只是暂时恢复。

在继续使用 deepseek-flash 的过程中，原会话再次出现：

• Turn completed，但最终只有 reasoning、没有非空 Text；

• 短句反复生成，例如「好。」「写。」「做。」一类自我指令；

• 长时间重复推理，需要用户主动终止；

• 偶尔自行恢复正常，随后再次复发。

其中两个比较明显的案例：

Turn | 状态 | 观察结果 -- | -- | -- 737 | aborted | 约 79,498 个 reasoning 字符，严重短周期重复 751 | aborted | 约 8,710 个 reasoning 字符，出现类似交错式循环

以上是 reasoning 字符数量，不是 Token 用量。

因此，需要修正此前的恢复结论：/compact 可以暂时恢复正常输出，但目前不能视为可靠的长期修复。

2. 保留原 Session，直接切换模型

在制作并校验完整 Session 备份后，我没有清空历史、重建 Session 或再次执行 /compact，而是直接在原会话中切换模型。

切换前：

provider: deepseek-official
model: deepseek-flash
reasoningEffort: high

切换后：

provider: deepseek-official
model: deepseek-v4-pro
reasoningEffort: high

其他相关条件保持不变：

• DSH 版本仍为 0.2.1-rc.3；

• 使用相同的 DeepSeek Adapter；

• 原 Session 历史及五次 Compaction 记录得到保留；

• 没有修改或替换现有 dsh-repeat-guard 0.3.3；

• 没有安装新的循环检测插件。

这里需要说明：重复检测插件是在最初故障发生之后安装的，并非故障最初出现时的环境组成部分。

3. 切换后的日志证据

Turn 753：首次 Pro 请求

Session 日志记录：

model/selection: deepseek-v4-pro
request/header.model: deepseek-v4-pro
reasoningEffort: high
turn/end.reason: completed

assistant steps: 1
reasoning blocks: 1

non-empty text blocks: 1

text chunks: 104

tool calls: 0

guard CUT: 0

确认这次实际向 Adapter 请求了 deepseek-v4-pro，并成功产生正常 Text，而不是只修改了 UI 模型选择。

Turn 754：第二次 Pro 请求

model: deepseek-v4-pro

turn/end.reason: completed

assistant steps: 1

llm/retry: 0

同样正常完成。

此后继续在原 Session 下自然使用 Pro，至本次更新时，已连续二十多个后续 Turn 未观察到此前的 reasoning-only 和短句循环问题。

后续二十多轮的情况属于持续使用观察；本次尚未逐轮提供完整日志统计。

4. 长上下文与缓存表现

模型切换时，原会话的输入上下文规模约为 72 万 Token。

首次 Pro 请求：

Turn 753

inputTokens: 723108

cacheReadTokens: 0

outputTokens: 411

首次请求发生了完整的缓存未命中。

但第二次 Pro 请求：

Turn 754

inputTokens: 158

cacheReadTokens: 723456

outputTokens: 290

input cache hit rate: 99.978%

说明在这个长会话中，切换 Pro 后的缓存可以在后续请求恢复。

不过 Pro 的 Token 单价仍高于 Flash，缓存恢复也不代表后续每次都能保持相同命中率。

5. 当前判断

此次观察提供了一个值得进一步调查的线索：

在保留相同原 Session、历史上下文及 DSH Adapter 的情况下，更换实际模型后，持续性故障明显改善。

这使得模型相关的生成行为成为值得重点关注的因素。

但目前仍不能断定：

• deepseek-flash 本身就是唯一根因；

• deepseek-v4-pro 可以永久解决问题；

• 故障与 Session 历史或 Compaction 完全无关；

• DSH Adapter 或 Provider 流处理不存在问题。

尤其需要强调，之前未成功捕获故障期间的原始 Provider SSE，因此仍无法最终判断异常 Text 是上游未生成，还是在接收、解析或持久化过程中丢失。

另外，Flash 在此前也曾短暂自行恢复，因此这次持续改善虽然很有意义，但仍属于观察性证据，而不是严格的因果实验。

6. 给遇到类似问题的用户的参考

如果遇到相同的长会话 reasoning-only 或短句重复循环问题，可以考虑在备份原 Session 后，尝试将已有会话切换到另一个实际模型，而不一定需要先清空或重建历史。

对我这个案例而言，切换到 deepseek-v4-pro 后的持续表现明显优于此前的 deepseek-flash。

但需要注意模型能力差异、额外费用，以及不能保证该方法适用于所有用户。

当前状态：原故障 Session 仍保留完整历史，在 V4 Pro 下持续正常使用；如果再次出现相同问题，我会继续更新。