长会话被服务端以裸 413 拒绝且不可恢复；默认协议切到 messages 后集中出现

[Laplus777]

长会话被服务端以裸 413 拒绝且不可恢复；默认协议切到 messages 后集中出现

背景：这是 Discussion #2770（"长对话卡住……触发 api 413 报错"）之后的补充证据。该讨论的采纳答案把成因归于"provider 侧上下文超限"，此结论正确但不完整——本贴补充两点新事实：① 默认协议已在 b0641b83fc 切换到 messages，触发面随之改变；② 实测证明 413 与请求体体积无关（见下文排除法）。同时指出一条可零成本确认的可观测性缺口。

Summary

b0641b83fc 把 DeepSeek 默认协议从 chat-completions 切到 messages 之后，原本可正常使用的长会话开始被服务端以 HTTP 413 拒绝，且此后每次恢复都失败、无法自救——恢复必须重放整份历史，于是每次重发都再次 413。实测窗口：升级到 0.1.6-alpha.1 后 39 分钟首次出现，升级前同一条会话一直可用。

本贴有两条可独立确认的问题线索：

1. 可观测性缺口：服务端只返回裸 413（无 error.message），而 DSH 已把原始响应体读进内存（protocols/chat-completions/adapter.ts:348 的 rawResponse）、放进 Error.cause:364，却从不写入会话事件。结果是 UI 与日志里只剩一个状态码，用户和维护者都无法据此定位——这一条不依赖任何复现成本，读代码即可确认；
2. 诱因待定：413 的触发条件尚无定论。下文给出了排除法实测，证明"请求体字节数超限"这一直觉解释不成立。

Reproduction

复现成本较高（需要一条长期积累的大会话），故分两部分给出。

现象部分：

1. 在 messages 协议（当前默认）下积累长会话（本机实例：会话日志约 13 MB，含多张图片附件）；
2. 发起下一轮 → 服务端 413；
3. 此后每次恢复/继续都 413。注意：413 不被自动重试——它映射为 INVALID_REQUEST，不在默认重试集合内（packages/llm/llm/src/retry-policy.ts:18-24 的 DEFAULT_RETRYABLE_CODES 只有 EMPTY_RESPONSE/RATE_LIMIT/SERVER/TIMEOUT/TRANSPORT）。本机会话日志中该会话共有 5 次 413 尝试，位于 turn 76–80、每回合各 1 次、间隔 11 分钟至 22 小时，均为手动重发，期间无 llm/retry 事件；
4. 对照：同一条会话在升级前（默认 chat-completions）一直正常工作。

可独立确认部分（无需大会话）：

在 protocols/chat-completions/adapter.ts:346-352 可以看到，报错文案仅在响应体可解析且含 error.message 时才被替换：

let message = `DeepSeek API error (HTTP ${response.status})`   // 默认：只有状态码
const rawResponse = await response.text()
try { const parsed = JSON.parse(rawResponse); if (providerError?.message) message = providerError.message } catch { }

UI 上看到默认文案，即证明服务端未提供 message；而该响应体不出现在会话日志里（本机逐类事件核查未发现承载它的记录），因此无从取证。protocols/messages/transport.ts:25 同理（缺省回退为 DeepSeek Messages request failed (${status})）。

Current behavior

• 报错文案不含原因：

  本轮运行失败  DeepSeek Messages request failed (413)      # messages 适配器
  本轮运行失败  DeepSeek API error (HTTP 413)               # chat-completions 适配器
  

• 不可恢复：恢复会话必须重放整份历史，每次尝试都重复触发同一个 413；

• 该会话历史中曾成功压缩过一次（compaction/start → compaction/summary，约 40 KB），但未能阻止 413。

413 出现在"恢复后的第一次请求"（本机实例，两次分别在不同协议下）：

时间	协议	事件序列（同一步内）
2026-09-15T12:42:38Z	messages	user/message(293 B) → request/header(28 KB) → assistant/attempt → 413 → turn/end
2026-09-15T13:06:24Z	chat-completions	同上 → 413 → turn/end

（另三次同型失败：turn 78/79 于 2026-09-15T13:17:49Z、13:28:59Z，turn 80 于 2026-09-16T11:30:19Z——均为手动重发。）

已排除"请求体字节数超限"（同机实测，Node v26，同一网络环境）：

端点	请求体	结果
/chat/completions	0.10 → 7.63 MB	全部 401（无效 key 的正常响应），无一 413
/anthropic/v1/messages	0.10 → 7.63 MB	全部 401，无一 413

即网关本身并不按该量级拒收 body；413 更可能来自认证之后的语义层判定。另注：protocols/chat-completions/adapter.spec.ts:1424 的既有预期为 httpErrorCode(413, { code: 'context_length_exceeded' })，倾向于同一方向。

升级时间线（本机 update-dsh.log）：

2026-09-14 22:35  升级 → c291e7961a          正常
2026-09-15 20:14  升级 → 0d1f50007f (0.1.6-alpha.1，含协议默认切换)
2026-09-15 20:59  首次 413

Expected behavior

按优先级建议：

1. 把 provider 原始响应记入会话事件：rawResponse 已在 cause 里，仅差一步写入。当前缺口使这类问题只能靠外部复现，用户与维护者都无从定位；建议至少记录其分类结果，避免泄露敏感 body 时也可只记 status + provider 错误码/类型；
2. 协议默认值变更时提示存量会话兼容性风险：设计笔记 .agents/notes/implemented/feature/2026-09-07-deepseek-messages-adapter.zh.md 写明"切换协议保留已有端点覆盖，部署者负责其兼容性"，但未覆盖"存量会话可能因此不可用"。建议在发布说明中提示，或提供迁移检查；
3. 给出可操作的失败指引：当 413 在会话首步重复出现时，提示"该会话可能已超出该协议可接受的请求规模，建议新开会话"，而不是只显示状态码；
4. （长期）上下文压力估算偏低导致压缩不及时——社区 Discussion #2770 与跟踪帖 Web profile ships compaction-basic/command-compact/tool-result-pruner disabled - web sessions never auto-compact, long sessions hit context-exceeded #2107 涉及同一现象。

Environment

• DSH 0.1.6-alpha.1（0d1f50007f），Windows 11
• deepseek-official / deepseek-flash（DeepSeek-V41-Flash）；contextWindow = 默认 1_000_000，maxTokens = 默认 256_000
• 协议 messages（默认）；实测显式切 chat-completions 后同样 413，故非协议本身所致
• 相关代码：protocols/messages/transport.ts:25、protocols/chat-completions/adapter.ts:346-364、common/models.ts、common/request-pricing.ts
• 相关提交：b0641b83fc、7d3dab66a2、a7070008e7
• 相关讨论：Discussion #2770

[PerryLink]

先说结论：你在 master 上引用的代码与结论都成立——provider 原始响应体确实被读进 Error.cause，但没有任何路径把它写入会话事件，UI 和日志里只剩状态码。这一条读代码即可确认，我逐行核对过。

可观测性缺口属实。chat-completions 侧 packages/llm/llm-deepseek/src/protocols/chat-completions/adapter.ts:346-364：报错文案默认只有状态码（:346 let message = `DeepSeek API error (HTTP ${response.status})` ），响应体在 :348 读入 rawResponse，仅在能解析出 error.message 时才替换文案（:352），最后 :363-364 把原文放进 cause。messages 侧同理：protocols/messages/transport.ts:25 缺省回退为 DeepSeek Messages request failed (${status ?? 'stream error'})，messages/adapter.ts:144 也是 cause: new Error(text)。

关键在于 cause 永远不会落地：LlmError.failure 只保留 message/code/status/providerRetryAfterMs/requestId/offloadImages（packages/llm/llm/src/index.ts:119-126），turn/end 记录的是 error.failure（packages/core/agent-loop/src/agent.ts:330-340），流终止帧的归一化 normalizeLlmFailure 同样只保留这些字段（packages/llm/llm/src/adapter-failure.ts:16-28）。三个持久化出口都没有 cause，所以服务端裸 413 时你确实无从取证。

环境事实核对：默认协议在 master 确实是 messages（packages/llm/llm-deepseek/src/config.ts:26-27、:81 protocol: … .default('messages')）；你引用的 common/models.ts 现在位于 packages/llm/llm-deepseek/src/common/models.ts:5-6（DEFAULT_MODELS 目录定义在此），默认值在 src/common/defaults.ts:6,8（DEFAULT_CONTEXT_WINDOW = 1_000_000、DEFAULT_MAX_TOKENS = 256_000）。恢复必须重放整份历史也属实——loop 请求是 session log 的纯函数（packages/llm/llm/src/index.ts:64-68 的 reconstructability 注释），所以每次恢复都会再次撞上同一个 413。

实践建议（根因在 provider 侧，DSH 无法自救，这点得说清楚）：

1. 长尾工作另开新会话，把需要保留的内容先复制出来；不要在 413 会话上反复恢复，每次恢复都是全量重放、必然再失败。
2. 如果配置允许，给该 provider 调小 contextWindow/maxTokens（这两个都是 config.ts:86-87 的可配字段），缩小单请求规模，也许能压回服务端判定阈值以内——但既然你实测排除了 body 字节数，这只值得一试，别抱太大期望。
3. 你已试过压缩无效，与"压缩后仍超过语义层判定"的猜测一致，不必再重复试。

另外两个值得留意的点：413 在两侧都被映射为 INVALID_REQUEST（chat-completions adapter.ts:99、messages transport.ts:33），它不在默认重试集合里（packages/llm/llm/src/retry-policy.ts:18-24），所以"5/5 重试"说明你的 provider 重试策略可能被改过，或者重试发生在别的环节（这是推断，未验证：你的实际配置我这边看不到）。以及你在 Discussion #6815（你本人报的 messages 序列化问题）里指出的方向——messages 路径对历史的严格校验——和本帖的"恢复即重放即失败"是同一族问题，两贴可以互相印证；与 Discussion #2770 的上下文超限结论也不冲突。你给的 adapter.spec.ts:1424 那条 413→context_length_exceeded 的既有预期，我也倾向于是语义层判定的旁证。

如果方便，把 turn/end 前后几十行会话日志贴出来（脱敏后），我可以帮你确认失败发生在恢复后的哪一步。