部分回合产出为空正文（正文空、思考里有内容），IM 通道只收到兜底句

[Lynn214321]

环境：Windows 11 桌面版 DSH 0.2.1-rc.3（CLI 同为 0.2.1-rc.3），模型 deepseek-flash，通过 @xmanrui/dsh-im 5.6.0 接微信。

现象：部分回合结束时，助手没有产出任何正文。GUI 里的「思考」面板能完整看到答案（甚至带着自己的草稿行），但没有生成 assistant 正文；IM 通道因此收到插件自己填的兜底句「本轮处理已结束，没有文本回复。」。该兜底句在 dsh-im 的 src/channels/shared/harness-client.mjs:2124 生成，也就是插件确认“回合成功结束、但没拿到任何文本”。所以不是通道丢包，是那一回合真的没有正文。

频率：一个下午加一个晚上约 7 到 8 次，没有固定触发词。特征：多发生在用户提问很短、回答也很短的回合；同一轮没有工具调用时更容易出现；长回答、带工具调用的回合几乎没出现过。

已尝试：把推理等级从 High 降到 Low，无效；关闭 dsh-im 的「上下文增强」，曾让卡住的那条迟一点发出来，未根治；关闭 MCP 插件、卸载 7 个用不上的插件（18 降到 11），之后一段时间未再复现，但样本太少无法确认；重启 DSH 短期不再复现，过一阵又出现。

一点猜测：可能与工具定义数量和系统提示词体积有关（插件多的时候复现更频繁）；也可能与思考文本和正文的切分有关，因为答案整段落在思考侧、正文侧为空。

想请教：这是已知问题吗，有没有开关（比如空正文自动重试一次）？是否与工具数量或提示词体积相关，能否在回合结束时对“无正文”做一次自动重试？需要哪些日志我可以提供。

[Lynn214321]

补图

[PerryLink]

这个能对上一条具体的代码路径：只有「一个内容块都没有」才被当成空回复。

packages/llm/llm-pi-ai/src/stream.ts:99-107 里，stop 分支只在 message.content.length === 0 时返回 EMPTY_RESPONSE；而思考块本身就是 content 里的一个块（同一文件 :175 产出的 block-end 类型是 reasoning）。所以「正文空、思考里有内容」的回合，content.length 不是 0，会走到 :108 的 { kind: 'stop' }——一次正常结束，没有错误，也不会触发任何恢复。

这就是你看到的「回合成功结束、但没有正文」，IM 那边只能填兜底句。

现在没有「空正文自动重试一次」的开关；这条判据在适配器里不存在，不是配置问题。如果要做，位置就在 :99 这个判断——把它从「没有内容块」改成「没有 text 块」，才能覆盖这个形态。

你可以拿日志确认一下：这类回合的 turn/end reason 应该是 stop 而不是 error。是 stop 就说明走的是这条路径。

我只读了源码（22ddee3），没有跑模型。

[PerryLink]

先更正我上一条：文件引错了。

我引的是 pi-ai 适配器（llm-pi-ai/src/stream.ts:99-107），而 deepseek-flash 在桌面默认走 deepseek-account——packages/llm/llm-deepseek-account/src/index.ts 里就是 registerDeepSeekProvider 注册的这个 provider，用的是 llm-deepseek 的适配器。它那条路的判据在 packages/llm/llm-deepseek/src/translate.ts:149：

if (blocks.size === 0 && reason.kind === 'stop') throw new LlmError('DeepSeek Messages returned no content', 'EMPTY_RESPONSE')

blocks 是所有 content_block_start 的集合（:105 的 Map；:121-127 把 text、reasoning、tool-call 都放进去），所以「只有 reasoning 块」时 blocks.size === 0 不成立，同样不会抛 EMPTY_RESPONSE，照样落到 { kind: 'stop' }。

结论不变，位置要改：你这条路要改的是 translate.ts:149，把「没有块」换成「没有 text / tool-call 块」；pi-ai 的 stream.ts:99 是另一条适配器上的同一个形状。两边都改才覆盖所有 provider。

如果你这次其实不是 deepseek-account（比如自己配了第三方中转），那就以你日志里 request/header 的 provider 为准，按同一个判据去对。

只读了源码（22ddee3），没有运行。

[Lynn214321]

谢谢，位置对上了。

我按你说的去翻了装好的包（桌面版 0.2.1-rc.3，app.asar 里的 dsh-llm-deepseek/lib/index.js）：

• 第 2007 行确实是 if (blocks.size === 0 && reason.kind === "stop") throw new LlmError(..., "EMPTY_RESPONSE")，和 translate.ts:149 对得上；
• 1847 行的 startBlock 里，case "thinking" 会产出 type: "reasoning" 的块并写进 blocks，所以“只有 thinking”时 blocks.size 确实不为 0，走到正常结束。

症状也复现了一次：讨论这个 bug 的过程中正好有一条回复是空的，IM 侧那一轮最终文本长度为 0，而且没有任何报错。

turn/end 的 reason 还没核到。会话日志是自定义分帧的 zstd，直接读不出来，所以暂时没法确认是不是 stop。等能取到证据再补。

目前我在 IM 插件那一层做了个临时兜底：有 reasoning、没正文时，把 reasoning 尾部发出去。核心没动。核心那处还是希望按你说的，把判据从“没有块”改成“没有 text / tool-call 块”；如果顺带能让它抛成 error，进到重试链路就更好了。