[Bug] dsh 0.1.2-rc.1 + V4.1：reasoning 正常但正文 content 未落地（合并后仍复现；V4-Pro 9/14 起全量路由）

[MedicineKing]

影响面提示（优先读）

据媒体报道（转述开放平台通知，2026-09-09；2026-09-10 后续通知）：V4.1 Flash 已发布（9/10）；V4-Pro 服务存续至 9/14 12:00（价格不变），此后 V4-Pro 请求将全部路由至 V4.1 Flash（按 Flash 单价计费）——届时本问题将覆盖所有 V4-Pro 槽位，故按高优先级报告。（来源：华尔街见闻快讯 https://wallstreetcn.com/livenews/3162449；凤凰科技 https://tech.ifeng.com/c/8wIslCJisoh）09-10 观测：模型已合并为 deepseek-flash；本问题合并后仍复现（见现象/证据）。

现象与频率（2026-09-09 观测；09-10 合并后复测）

• 频率：≈70%（用户主观估计，非精确计数：09-09 当天约 10 个对话中 ≈7 个出现无正文；多轮对话为主）；
• UI 现象：thinking 区块完整显示，正文区域空白（无报错弹窗）；重载消息后正文仍空白（09-10 复测）——正文从未落地（消息记录内即无 content），非显示层问题；
• 间歇性与前提：非 100% 复现，具体触发条件未完全锁定；但需注意——本报告现场证据均集中在超长会话（1899 轮 / 累计输入 490M tokens、reasoningEffort High）内，与 [Bug] Agent 在超长上下文 + max reasoning effort 下陷入思考退化循环：回合零产出、无自动熔断，需手动中止（v4.1-flash；同配置 v4-flash 3000+ 步未复发） #5976 的触发画像（超长上下文 + max effort）一致（相关性观察，不作因果断言）。
• 09-10 现状（deepseek-flash，用户实测）：症状延续——thinking 正常显示、正文“被耽误”（延迟不出现）、需重试多轮才出；曾连续两轮无正文；重载无效（见证据）。
• 09-10 12:51-12:52 现场捕获（截图）：同一会话连续 3 个空回合（2-4 秒短回合）——thinking 有内容（含“又没输出”式自我提及），正文零输出、无报错。
• 09-10 12:56 现场捕获（截图 2）：thinking 明确计划“并行调用 read + read_image”“先调用工具”，随后回合结束（2 秒）——工具调用与正文均未发出；thinking 自述“输出要短（前面长输出总是失败）”。

证据

• API 直连对照（同一 key；模型侧正常）：
  ① 观测期灰度名（09-09，非流式）：{"model":"deepseek-v4.1-flash-expires-on-0910","max_tokens":2000} → HTTP 200，content="Hi! How can I help you today?"（finish=stop）；
  ② 09-10 复测：非流式多例（旧灰度名/deepseek-v4-flash/deepseek-v4-pro/deepseek-flash）均 HTTP 200、content 正常；
  ③ 09-10 流式复测 5/5 正常；其中 2 例参数对齐 dsh 请求形态（stream=true、stream_options.include_usage=true、max_tokens=65536、reasoning_effort=high，含 usage 收尾块）亦正常；长推理用例：629 个 reasoning 增量 → 间隔 12ms → 846 个 content 增量 → finish=stop。未复刻 dsh 的 system prompt/tools 外壳（该差异即首选假设的“输入诱发”环节）。
• 重载对照（09-10）：重载消息后正文仍空白——正文未落地（消息记录无 content），非渲染问题。
• 源码核对（dsh 0.1.2-rc.1，deepseek-official 适配器 translate() 的 [DONE] 分支）：EMPTY_RESPONSE 守卫为 stop && order.length === 0（order=本次响应已打开的增量块序列，reasoning/text/tool-call 任一入列即 ≥1）——仅“零块”触发；存在 reasoning 块时，无正文的 stop 按正常完成放行（“reasoning-only stop”在适配器层静默通过）。
• dsh 侧原始 SSE 事件流：dsh 未记录（无请求/响应级日志留存）——本报告唯一缺失的决定性证据（“服务端仅发 reasoning、未发 content”的直接证明）；如需可复现配合抓取。
• 现场截图（09-10 12:52）：连续 3 个空回合的 UI 直击（thinking 有内容、正文空白、无报错，2-4 秒短回合）；模型选择器=DeepSeek-Flash (4.1 合并版) · reasoningEffort High；会话为超长会话（1899 轮，累计输入 490M tokens）——与 [Bug] Agent 在超长上下文 + max reasoning effort 下陷入思考退化循环：回合零产出、无自动熔断，需手动中止（v4.1-flash；同配置 v4-flash 3000+ 步未复发） #5976“超长会话内进入退化状态后持续复现”的画像一致（见附图 1）。
• 现场截图 2（09-10 12:56，同会话第 1903 轮）：模型 thinking 规划“并行调用 read + read_image”“先调用工具”后，回合于 2 秒内结束——工具调用与正文均未发出（会话内工具调用累计 12 分 54 秒=平时工具正常执行的实绩，此处连 tool_call 增量都未出现）；thinking 中记录了该现象——原文“输出要短（前面长输出总是失败）”（见附图 2）。

已排除项

1. max_tokens 不足（dsh 已设 65536；直连 max=200 亦出 content）；
2. reasoning_format=hidden：该参数似乎未被服务端执行（响应中 reasoning 内容仍逐字返回）——参数本身无效或模型不支持，与 bug 的因果未证；
3. 旧模型（v4-flash/v4-pro）未见此问题；
4. 纯显示层问题：重载后正文仍空白（落盘内容即无正文）——排除；
5. 流被截断：适配器对缺 [DONE] 的流会抛 STREAM_CLOSED 错误（与“静默空白”不符）——形态不符，排除。

疑点（待验证假设，非结论）

• 首选假设（“输入诱发 + 适配器放行”两环节叠加，非纯模型侧偶发——②已源码核对，①为基于频率落差的推断）：①输入诱发——模型在 dsh 的输入结构（system prompt / tools 外壳）下更易产生"reasoning-only stop"（思考正常结束、无正文且无工具调用、finish=stop）；频率落差（dsh 内 ≈70% vs 直连十余次 0 次）指向 dsh 侧输入结构——直连缺该结构，“直连未复现”不能用来排除 dsh 接收端；②适配器放行——deepseek-official 适配器对该形态静默放行、不触发重试（见证据·源码核对）→ 回合静默完成、无重试、重载无正文——与用户实测形态完全吻合（thinking 正常/无报错/重载无效/重试才出）；
• 模型侧背景：[Bug] Agent 在超长上下文 + max reasoning effort 下陷入思考退化循环：回合零产出、无自动熔断，需手动中止（v4.1-flash；同配置 v4-flash 3000+ 步未复发） #5976/【Bug】在dsh中使用deepseek-v4.1-flash-expires-on-0910遇到的思考内容（reasoning_content）退化问题 #5971 已证实同一模型（v4.1-flash-expires-on-0910）存在 reasoning 生成不稳定家族（退化循环、零产出、重复"好。"）；"思考结束但不产出正文"属同族更轻形态（待官方确认）；[Bug] Agent 在超长上下文 + max reasoning effort 下陷入思考退化循环：回合零产出、无自动熔断，需手动中止（v4.1-flash；同配置 v4-flash 3000+ 步未复发） #5976 的触发条件（超长上下文 + max effort）同样指向"输入条件诱发"；
• 备择假设（未排除）：dsh 流式接收端在特定时序下丢弃 content 增量——但若为接收端丢弃，tool_call 增量应仍可见（两类是不同的块类型）；实测正文与工具调用同时缺失，进一步指向“服务端仅发出 reasoning 块”。判定仍需 dsh 侧原始事件流（见证据），当前无直接证据。

生效环境

dsh 0.1.2-rc.1（profile web）· V4.1（Flash；观测期灰度名 deepseek-v4.1-flash-expires-on-0910，09-10 合并为 deepseek-flash）· Windows 10 19045。09-10 合并后仍复现（用户实测，见现象）；未在其他 dsh 版本上测试。

请求

确认是否已知；或提供修复/规避。规避现状：v4-pro 将于 9/14 12:00 后路由至同一 V4.1（届时无同类可切换项）；旧模型名直连测试中 reasoning 会占满 max_tokens（实测 max_tokens=20 时无 content 返回），与 deepseek-flash 在 max_tokens 占满行为上一致——当前亦无同类可切换项。
建议方向（供参考）：①适配器守卫——对 deepseek-official 适配器套用 #5113 的修复方向（reasoning-only stop 错误化 → 走已有 EMPTY_RESPONSE 有界重试）；②输入结构核对——对比 dsh 完整请求外壳与最小直连请求在 4.1 上的行为差异（同一内核：dsh 内 ≈70% vs 直连 0/十余次，落差指向输入侧）；③模型侧——确认 4.1 的 reasoning-only 完成率（#5976 家族关联）。

重复检查

@已搜索 repo discussions（09-10，3 个 query：v4.1 thinking=2 条；content empty=137 条，筛后 1 条相关；streaming reasoning=69 条，筛后 0 条直接同类）——相关 3 条（均非完全同类）：

• [Bug] reasoning-only stop is treated as completed and silently ends the turn #5113（08-30）reasoning-only stop is treated as completed and silently ends the turn——机制最接近（pi-ai 适配器源码级确认）；本报告在 deepseek-official 适配器核实同款守卫形态；
• [Bug] Agent 在超长上下文 + max reasoning effort 下陷入思考退化循环：回合零产出、无自动熔断，需手动中止（v4.1-flash；同配置 v4-flash 3000+ 步未复发） #5976（09-08）v4.1-flash 超长上下文 + max effort 下思考退化循环：回合零产出、需手动中止——同模型侧不稳定家族（其形态=思考不结束；本报告=思考正常结束但无正文）；
• 【Bug】在dsh中使用deepseek-v4.1-flash-expires-on-0910遇到的思考内容（reasoning_content）退化问题 #5971（09-08）同一灰度名 reasoning_content 退化（重复"好。"）——同族。

附图

[MedicineKing]

【补充：抓包实测 + 1:1 复现证据】 @argszero

1. 方法：在本机 dsh（0.1.2-rc.1）与 API 之间加了一层本地透传代理（只转发与录制，不改动任何请求字节），抓取真实请求体与原始 SSE 流。失败样本捕获于 2026-09-10 16:59（+08:00）；响应头 x-ds-trace-id: 77895a738f9e849455619ed20192ac85，可供服务端侧核对记录。

2. 原始 SSE（失败流收尾段；节选整理——仅保留关键字段、数值未改动，reasoning 文本与部分元数据字段已隐去）：

data: {"choices":[{"index":0,"delta":{"content":null,"reasoning_content":"…"},"logprobs":null,"finish_reason":null}]}
data: {"choices":[{"index":0,"delta":{"content":"","reasoning_content":null},"logprobs":null,"finish_reason":"stop"}],"usage":{"prompt_tokens":220715,"completion_tokens":1654,"prompt_tokens_details":{"cached_tokens":220160},"completion_tokens_details":{"reasoning_tokens":1654},"prompt_cache_hit_tokens":220160,"prompt_cache_miss_tokens":555}}
data: [DONE]

即：服务端自行以 finish_reason=stop 收尾、正文为空——全程 0 个 content 增量、0 个 tool_call 增量、1654 个 reasoning 增量。[DONE] 完整到达，非流被截断、非 dsh 侧丢弃。

3. 1:1 重放（同一份 ~790KB / 220,715 token 的请求体原样重发；两轮运行、共 6 次调用，输出已留档）：

• 原样请求为 reasoning_effort:"max"：4 次重发均失败（reasoning 增量——首轮 1835 / 1298，次轮 1298 / 1714；content 0、finish=stop、0 个 tool_call 增量）；
• 替换为 "high"：2 次中 1 次失败（首轮增量 1314）、1 次成功（次轮 content 303 增量）；
• 高概率失败、非必现、重试可恢复；max 与 high 两档均出现过失败，未观察到与 effort 档位相关（样本有限）。

4. 上下文规模对照（系统提示词与工具固定，仅裁剪历史消息）：

变体	prompt tokens	结果
尾部 120 条消息	59,664	✅
尾部 250 条消息	123,902	❌
去掉工具往返消息	191,818	❌
全量（原始）	220,715	❌

→ 失败概率与上下文体积强相关（本条件下约 6 万-12 万 token 之间为界）。

注：各变体均为单次观测；「约 6 万-12 万 token 为界」为粗估，非精确阈值。两轮重放共 6 次调用（5 败 1 成），可复核输出已留档。

5. dsh 侧守卫现状复核：对最新 0.1.5-rc.1 的 dsh-llm-deepseek 源码复核——[DONE] 分支仍为「仅零块时判 EMPTY_RESPONSE」，reasoning-only stop 依旧静默放行（源码条件：reason.kind === "stop" && order.length === 0）。

6. 期望（与 #5113 一致）：reasoning-only stop 应归入空响应错误，走既有 EMPTY_RESPONSE 有界重试；实测重试可恢复，属低风险改动。

7. 行动项（修复 / 增加，便于直接处置）：

修复：

• F1（一行级，附精确位置）：dsh-llm-deepseek 的 translate() 在 [DONE] 分支的空响应判定（0.1.5-rc.1 打包产物对应 lib/index.js:1239；仓库源码在 packages/llm/llm-deepseek）——建议由「零块」放宽为「无正文且无工具调用」（reasoning 块不计入"可交付"），使 reasoning-only stop 归入 EMPTY_RESPONSE 并走既有有界重试（与 [Bug] reasoning-only stop is treated as completed and silently ends the turn #5113 的建议方向一致）。补充依据：该包的 README（中英均有）已写明「不带内容块的终止 stop 变成 EMPTY_RESPONSE，默认重试策略会重试它」——本次情形（有 reasoning 块、无内容块）正落在此承诺范围内，而现行判据（order.length === 0）比文档承诺窄；此修复即让实现对齐既有承诺。
• F2（评估项）：EMPTY_RESPONSE 默认重试退避（0.5s→10s、maxRetries=5；默认值出处=dsh-llm 的 resolveRetryPolicy，normal mode）在连败窗口（实测曾持续 4-5 分钟）下可能五连全败；建议评估默认值，或文档化"长窗调参"（拉长退避以跨窗）。

增加：

• A1（可观测性）：为"reasoning-only 完成"增加日志/事件级信号——当前该情形对用户完全静默（显示层像正常完成），排障成本高。
• A2（产品行为，可选）：同一会话连续多次空响应时，向用户提示"建议新建会话"（跨会话退化现象见 [Bug] Agent 在超长上下文 + max reasoning effort 下陷入思考退化循环：回合零产出、无自动熔断，需手动中止（v4.1-flash；同配置 v4-flash 3000+ 步未复发） #5976 的独立复现）。

可复核输出（原始留档）：首轮运行日志 · 次轮结果 JSON