裸 413（无错误体）被归一化为 INVALID_REQUEST → 长会话永久卡死（0.1.6-alpha.2）

[IsaacAi001]

诊断报告：DeepSeek Messages 接口返回「裸 413」被归一化为 INVALID_REQUEST → 长会话永久卡死

版本：@deepseek-ai/dsh@0.1.6-alpha.2 ｜ 日期：2026-09-20 ｜ OS：Windows x64 ｜ 模型：deepseek-flash

TL;DR

1. 服务端对某个请求返回不带错误体的 413（裸 413，无 JSON 详情）。
2. 适配器把它归一化为 INVALID_REQUEST：@deepseek-ai/dsh-llm-deepseek/lib/index.js 第 1159 行 if (status === 413) return "INVALID_REQUEST";，第 2340 行兜底文案 `DeepSeek Messages request failed (${status})` —— 该文案出现即说明响应体里没有 error.message。
3. 由于只有 CONTEXT_WINDOW_EXCEEDED 才会驱动 compaction-basic 的溢出恢复，自动压缩与重试完全不触发，该轮直接失败。
4. 坏状态留在会话历史中：此后每一次发送都 413 —— 连 /compact 的摘要请求也 413，会话永久卡死，用户只能新建会话（丢上下文）。

环境

项	值
DSH	0.1.6-alpha.2（升级前 0.1.5-rc.1 正常）
模型	deepseek-flash（V4.1 Flash），reasoningEffort: high
协议	适配器默认 messages（/anthropic/v1/messages）
OS / 运行时	Windows x64 / Node 24.19.0
首次失败	2026-09-20 09:01（服务 08:56 重启；受影响会话均跨越 9/10、9/16、9/19 三次版本升级）

症状

• 在某会话中发送任意消息（哪怕只有一句纯文本），step 1 立即失败：

finish.reason = { kind: "error", failure: {
  message: "DeepSeek Messages request failed (413)",
  code: "INVALID_REQUEST", status: 413 } }

• 在该会话内把模型 deepseek-flash → deepseek-v4-pro，仍然 413。
• 在该会话执行 /compact：compaction/end 事件同样记录 error: "DeepSeek Messages request failed (413)"，界面提示 Compaction could not produce a useful summary.
• 新建会话完全正常；同账号、同服务、同模型的其他会话均正常。

受影响会话 vs 正常会话（同机实测）

会话	日志大小	压力 tokens(占窗口)	413 次数	最后成功	状态
A（8/31 创建，421 轮）	9.8 MB	90,908 (9%)†	10	09-17 09:31	❌ 卡死
B（旧会话）	8.9 MB	—	2	09-19 12:16	❌ 卡死
C（旧会话）	8.5 MB	—	2	09-17 09:31	❌ 卡死
D（同工作区，正常）	9.8 MB	484,364 (48%)	0	09-17 15:30	✅ 正常
E（当日新建）	0.6 MB	—	0	09-20 09:16	✅ 正常

† 卡死会话的压力值是卡死前的旧快照（失败轮次不更新投影）。

注意 D 与 A 日志同为 9.8 MB，且 D 的压力（48%）远高于 A（9%），但 D 正常 → 与体积/上下文占用无关。

已实测排除（均为直接调用 DeepSeek 接口，非推测）

假设	实测结果
输入超 100 万 tokens	✅ 通过：累计 950,037 tokens → HTTP 200
请求体字节数超限	✅ 通过：单请求体 33.4 MB → HTTP 200
图片过大	✅ 通过：单张 9.29 MB PNG（base64 12.4 MB）→ HTTP 200
图片数量多	✅ 通过：5 张大图（33.4 MB）→ HTTP 200
消息条数多	✅ 通过：3,000 条 messages → HTTP 200
content 片段数多	✅ 通过：单条消息 3,000 个 text 片段 → HTTP 200
max_tokens 预留值	✅ 通过：256000 / 200000 / 131072 / 64000 均 200
thinking 签名无效/缺失	✅ 通过：伪造签名、缺失签名均 200
历史含 <system-reminder> 注入消息	✅ 通过：200
对话中间出现 role: "system" 消息	✅ 通过：200
单个 tool_result 过大	⚠️ 200–1000 KB 返回 400（content[].thinking must be passed back，属另一问题），非 413
模型路由（flash / v4-pro、systemPromptUpdate: in-history）	❌ 无区分度：卡死会话三种路由各不相同
工作区路径 / cwd 不匹配	❌ 无证据：会话身份 cwd 与日志一致，工作区内无指令文件

目前掌握的边界

• 触发条件不在可枚举的请求量纲里（token / 字节 / 条数 / 图片 / 模型 / 路径 / 内容形态）。
• 触发点位于这三个会话的历史中：整段请求失败，重放历史的压缩请求也失败（压缩会重放最老的 balanced head）。
• 三个卡死会话的共同点：均为跨多次版本升级的老会话（8/31 创建，isSeeded: true，历史含 21–22 条 session/end-seed、6–7 次 compaction/*、8 条 system/message）。新建会话与同日其他会话均正常。
• 倾向判断：老会话的 surface / 压缩 / seed 状态在新版（0.1.6-alpha.x，协议默认切到 messages）下被重新解释，产生了服务端拒绝的请求；但因服务端未返回任何错误体，客户端无法定位具体字段。

建议修复（按优先级）

1. 归一化修正：把 413（以及 Input token exceed the limit 这类生产措辞）归入 CONTEXT_WINDOW_EXCEEDED，使 compaction-basic 的溢出恢复能够触发 —— 本报告的核心诉求。
2. 兜底恢复：即便归类失败，在 INVALID_REQUEST + 413 时也应尝试一次缩减重试（保留最近 N 轮或丢弃最老的非必要内容），避免会话进入"每次都失败"的永久卡死态。
3. 可观测性：错误对象应保留服务端原始响应（即使 body 为空，也记录 status / headers / 请求体字节数 / token 估算），否则现场无法诊断 —— 目前只有一句兜底文案。
4. 请求侧可观测性：在会话日志中记录**序列化后的请求大小（bytes）**与分词估算，便于二分定位。
5. （可选）/compact 失败时应区分"摘要不够小"与"请求被拒"，给出可操作提示。

诊断包（按官方手册模板）

Harness version:        0.1.6-alpha.2 (Web profile)
Surface and profile:    web / $DSH_HOME/profiles/web
Provider and model:     deepseek-official / deepseek-flash（v4-pro 同样失败）
Raw provider status:    413（响应体为空，无 error.message）
Normalized code:        INVALID_REQUEST
Provider contextWindow: 1000000（适配器声明）
Conversation maxTokens: 256000（默认；改为 64000 仍失败）
Compaction:             未覆盖（默认 thresholdRatio 0.8 / maxOverflowRetries 1）
Request 体积:           该会话 surface 约 3.8 MB 事件数据（合成请求 33.4 MB 可通过）
Recovery request:       /compact 的摘要请求同样 413
Repeated fingerprint:   同一会话连续 10 次 413；切换模型后仍 413
New empty session:      正常（同账号、同服务、同模型）
Previous route:         deepseek-flash / 1,000,000
Pending route:          deepseek-v4-pro / 1,000,000（切换后仍 413）

复现路径

1. 用 0.1.5 及更早版本长期运行若干会话（跨多次升级）；
2. 升级到 0.1.6-alpha.2 并重启服务；
3. 打开其中规模较大的老会话，发送任意一句文本 →
   DeepSeek Messages request failed (413) / INVALID_REQUEST，该会话此后永久无法发送（新会话正常）。

备注：本报告已脱敏（不含密钥、用户名、会话 ID、私有路径）。如需原始日志片段可另行提供。
以上报告是我让DSH自己写出来的，我本人是个小白，它修不好那些旧的会话，最后得出一个结论上Github让官方修

[IsaacAi001]

哦我回退到0.1.5
旧版会话就能用了
但旧版打不开新版的对话捏