[bug] 上下文超长被误判成普通 API 错误：自动压缩 124 次失败 102 次，会话永久卡死

[redfireblade]

目标仓库：deepseek-ai/deepseek-harness · 通道：GitHub Discussions（该仓库 Issues 已关闭，CONTRIBUTING.md 指定 bug 走 Discussions）
复现版本：@deepseek-ai/dsh-* 0.1.5-rc.2（DSH Desktop 0.9.0 内置）

Summary

在一个长中文 + 代码会话里，真实 prompt 已经涨到模型窗口的 1.31–1.47 倍，但 harness 完全没有意识到「上下文超长」这件事：

• 自动压缩触发了 124 次，其中 102 次失败，失败原因全部是
  {"failure":{"message":"Response incomplete: length","code":"PI_AI_ERROR"}}；
• 压缩失败被 agent/pre-step 静默吞掉（只打一行 warning），turn 照常继续；
• agent/request-error 的溢出恢复逻辑因为 failure.code !== CONTEXT_WINDOW_EXCEEDED_CODE 而一次都没触发；
• 主请求最终以同一个 PI_AI_ERROR 死掉，会话从此无法继续，只能新开。

关键点：不是压缩没触发，而是压缩在结构上不可能成功，并且所有兜底路径都被同一个错误分类问题挡住了。

Reproduction

1. 配置一个 api: openai-responses 的 provider。本例：

   volcengine-ark:
     api: openai-responses
     baseURL: https://ark.cn-beijing.volces.com/api/plan/v3
     models:
       deepseek-v4-1-flash: { contextWindow: 131072, maxTokens: 16384 }

2. 跑一个长会话（中文 + 代码，token 密度高），让真实 prompt 超过 contextWindow。
3. 等自动压缩触发。压缩请求本身返回 status=incomplete + incomplete_details.reason="length"。
4. 观察 agent/pre-step 只留下 step compaction failed: ...; continuing the turn，上下文永不缩小。
5. 最终主请求返回同样的错误，turn 直接结束，之后每个 turn 都在 30 秒内以同样方式死掉。

Current behavior

会话 session-05e8fec4-7176-47a2-9d5b-e111058f5d93（workspace E:\mu_ai）的
session.v3.jsonl.zstd 实测数据：

1. 压缩统计

compaction/end 事件共 124 次：成功 22 次，失败 102 次。
首次失败 2026-09-23T09:08:34.393Z，最后一次失败 2026-09-23T13:27:49.072Z。
最后一次成功是 seq 3189 / 2026-09-23T12:07:31.970Z —— 之后 3 小时内压缩 再没成功过一次。

2. 成功的摘要全部顶到 8192 输出上限

最后一次成功的几次摘要，outputTokens 分别是
7732, 8071, 8096, 8138, 8129, 7356, 7915 —— 明显是贴着 maxTokens 默认值 8192 被截断的。

3. 主请求的死法完全一样

seq	时间	事件
3711	12:52:06.622Z	turn 10 结束，{"failure":{"message":"Response incomplete: length","code":"PI_AI_ERROR"}}
3722	13:09:49.447Z	turn 11 结束，同上
3734	13:27:52.190Z	turn 12 结束，同上

4. 真实 prompt 早就超窗了（provider 自己数的）

usage (input / cacheRead / output)	真实 prompt = input+cacheRead	相对 131072
5486 / 166528 / 999	172,014	1.31×
13671 / 171904 / 16	185,575	1.42×
7277 / 185472 / 16	192,749	1.47×

（totalTokens == inputTokens + cacheReadTokens + outputTokens 已在多个样本上核对。
注意 outputTokens 只有 16 / 999，所以这不是输出被截断，而是输入侧早就超窗。）

也就是说：harness 手里已经有能证明溢出的精确 usage 数字，只是错误分类那条路径完全没有用它们。

根因链

① 触发点（第三方依赖） @earendil-works/pi-ai@0.85.1

dist/api/openai-responses-shared.js:660-688 mapStopReason：

case "incomplete":
  return incompleteReason === "max_output_tokens"
    ? { stopReason: "length" }
    : { stopReason: "error", errorMessage: `Response incomplete: ${incompleteReason}` };

Ark 返回的是 incomplete_details.reason = "length"，不等于 "max_output_tokens"，
于是被映射成 stopReason: "error" + 消息 Response incomplete: length。

② pi-ai 自己的溢出检测也因此失效 dist/utils/overflow.js:130-155（本机 0.85.1 实测）

• case 1（:132-138）：要求 stopReason === "error" 且消息命中 OVERFLOW_PATTERNS → "Response incomplete: length" 一条都不命中；
• case 3（:149-154）：要求 stopReason === "length" 且 usage.output === 0 → 这里 stopReason 是 error，且 output 是 16/999，两道门都过不去；
• 连带 isRecoverableLength（:163-165）也要求 stopReason === "length"，同样失效。

⚠️ 注意：光把 length 映射对还不够。 case 3 里 output === 0 这个条件在 0.85.1 里依然存在
（上游 PR #7540「允许非零 output」虽已合并，但并未出现在本机这个构建里），
所以本次的 output=16 / 999 即使 stopReason 正确也仍会被判成"非溢出"。

③ DSH 侧退化成通用错误 @deepseek-ai/dsh-llm-pi-ai/lib/index.js:1389-1443 mapStopReason

const piAiOverflow = isContextOverflow(message, contextWindow);
const harnessOverflow = stopReason === "error" && errorMessage !== undefined
  && isContextWindowExceededError(errorMessage);

@deepseek-ai/dsh-llm/lib/index.js:152-167 isContextWindowExceededError 的所有正则
（STRUCTURED_CONTEXT_OVERFLOW / TOO_LARGE_FOR_CONTEXT / EXCEEDS_MODEL_CONTEXT …）
都要求消息里出现明确的 “context” 字样，"Response incomplete: length" 一条都不命中。
→ 最终 classifyPiAiError(text) 给出 code: "PI_AI_ERROR"。

④ 兜底路径被这个 code 挡住

• dsh-compaction-basic/lib/index.js:820-839 agent/request-error：
  failure.code !== CONTEXT_WINDOW_EXCEEDED_CODE 就直接 next() → 溢出恢复永不触发；
• dsh-compaction-basic/lib/index.js:798-811 agent/pre-step：
  压缩失败只 log('step compaction failed: ...; continuing the turn') 然后 next() → turn 带着超窗上下文继续跑；
• dsh-compaction-basic/lib/index.js:873-920 compactIfNeeded：
  thresholdTokens = floor(contextWindow * thresholdRatio)，超过重试次数后抛
  compaction still above threshold after N compaction attempts —— 但此时已经晚了。

⑤ 阈值本身就算错了

dsh-token-meter/lib/index.js:16 与 pi-ai/dist/utils/estimate.js:1 都用 CHARS_PER_TOKEN = 4。
在中文 + 代码场景下低估约 1.37×（pi-ai 的 clamp 反推估计值 ≈126k，而 provider 数出 172k）。
于是 preset 里的 thresholdRatio: 0.75 → 估计 98,304 ≈ 真实 134k，
压缩触发点已经落在真实窗口之外，必然先溢出再压缩。

⑥ 一旦 surface 超窗，压缩在数学上不可能成功

摘要请求要重放整个可压缩前缀（surface 减去约 20,971 token 的 retain 尾巴），
输入本身还是超窗 → 又是 incomplete/length → 死循环。
这就是 124 次触发里 102 次失败、且成功的那 22 次全在窗口还没被撑爆之前的原因。

Expected behavior

1. 真实 prompt 超过 contextWindow 时，应当被识别为上下文溢出（CONTEXT_WINDOW_EXCEEDED），而不是通用 PI_AI_ERROR；
2. 溢出恢复（agent/request-error）应当被触发，而不是被 code 挡在门外；
3. 压缩失败不应被静默吞掉后继续 turn —— 至少要阻塞 turn 并明确告诉用户「上下文已满，压缩失败」；
4. 摘要输出上限不应默认 8192（中文摘要会被腰斩，且腰斩的摘要会被当成有效 checkpoint）；
5. token 估计应当在中文场景下不至于低估到让压缩触发点落在窗口之外。

Suggested fixes

按「最小改动 → 收益」排序：

1. dsh-llm-pi-ai：加 usage 兜底判定（收益最大、改动最小，且不依赖上游）
   在 mapStopReason 里，除了看错误文本，再用 provider 的 usage 判定：
   若 inputTokens + cacheReadTokens >= 0.99 * contextWindow，无论文本是什么都判为
   CONTEXT_WINDOW_EXCEEDED。本例的 172k / 185k / 192k 会被立刻正确识别。
   这条不依赖 provider 的 incomplete_details.reason 字符串，所以上游不改也能生效。

2. dsh-llm：让 isContextWindowExceededError 认识 pi-ai 自己的包装文本
   Response incomplete: <reason> 是 pi-ai 造出来的字符串，DSH 认识它才算闭环。

3. dsh-compaction-basic:820-839：溢出恢复不要只认 CONTEXT_WINDOW_EXCEEDED_CODE
   改为 code === CONTEXT_WINDOW_EXCEEDED_CODE || usageBasedOverflow。

4. dsh-compaction-basic:798-811：压缩失败要「响」
   至少 next(new Error(...)) 或发出一个用户可见事件；continuing the turn 是这次事故里最贵的 11 个单词。

5. dsh-compaction-basic:72：maxTokens: config.maxTokens ?? 8192 默认值过低
   建议默认取 min(model.maxTokens, 某上限) 而不是硬编码 8192（本例模型 maxTokens: 16384）。

6. dsh-token-meter:16：CHARS_PER_TOKEN = 4 对 CJK 严重低估
   建议按 CJK 字符占比做加权估计。

7. 阈值用真实 usage 而不是估计值
   既然 usage 里已经有精确的 input + cacheRead，压力判断就应该以它为准（或至少取 max(估计, 上次真实 usage)）。

上游现状（重要：不能指望上游）

我在写这份报告前先查了上游，结论是DSH 必须自己兜住：

• 上游 earendil-works/pi PR 桌面端 #7817「fix(ai): treat incomplete reason 'length' as a length stop, not an error」
  提的正是本报告 ① 的修复（描述里明确点名 Doubao / Volcengine Ark），
  但创建当天就被 github-actions[bot] 自动关闭且未合并，理由是：

  Only contributors approved with lgtm can open PRs. Open an issue first and ask a maintainer for approval.

• 同类 issue HTTP 402 (insufficient provider balance) never reaches the terminal QUOTA failure code #7052 也是在创建 8 秒后被机器人自动关闭。
  该仓库的策略是「issue/PR 先自动关闭，维护者事后挑着 reopen」，所以上游修复的时间不可控。
• 更关键的是：即使 ① 被上游接受，② 的 output === 0 条件仍会漏掉本例（见上）。
  也就是说这次事故需要上游两处同时改才对 DSH 生效。

因此我的建议是：DSH 侧先加 usage 兜底（下面的第 1 条），不要等上游。
同时我会另开一个上游 issue 说明 ①+②，但那只是长期对齐，不应当作为 DSH 的修复前提。

附带一条：官方 OpenAI 也会这样

上游 issue #7052 里有一个和本例几乎同构的数据（官方 openai-responses，272k 窗口）：

{"usage":{"input":3,"output":264,"cacheRead":267059,"cacheWrite":637,"reasoning":110},
 "stopReason":"length"}

input + cacheRead = 267,062 ≈ 98% 窗口，output 极小 —— 和本例「输入早已贴满窗口、输出只有 16/999」
是同一个现象，只是官方返回的 reason 是 max_output_tokens（能被 pi-ai 正确识别），
Ark 返回的是 length（被误判成 error）。
这反过来说明：本例的 reason: "length" 极可能同样是输入侧窗口耗尽，而不是输出被截断，
所以用 usage 判定溢出是语义上正确的做法。

Environment

• DSH Desktop 0.9.0，内置 @deepseek-ai/dsh-* 0.1.5-rc.2（Windows 11）
• provider：volcengine-ark，api: openai-responses，baseURL https://ark.cn-beijing.volces.com/api/plan/v3
• model：deepseek-v4-1-flash，contextWindow: 131072，maxTokens: 16384
• 依赖：@earendil-works/pi-ai@0.85.1
• preset：standard-70（compaction-basic 的 thresholdRatio 被手工设为 0.75）
• 会话文件：$DSH_HOME\sessions\<workspace-key>\session-05e8fec4-...\session.v3.jsonl.zstd
  （多帧 zstd，需按 magic 28 B5 2F FD 切帧后逐帧解压）

相关讨论 / 上游记录

• DSH DSH 中的 pi 组件把 API 错误误判成「上下文超长」，导致不会触发自动重试 #4657「DSH 中的 pi 组件把 API 错误误判成『上下文超长』」—— 同一个分类器的反方向误判，可作为对照。
• DSH 上下文占满窗口时没有任何明确的用户提醒：不知道「输入上下文已满」，也没有 /compact、/clear 的引导 #2335「上下文占满窗口时没有任何明确的用户提醒」—— 本次事故正是这条的极端后果。
• 上游 earendil-works/pi PR 桌面端 #7817 —— 修 ① 的 PR，被机器人自动关闭未合并。
• 上游 earendil-works/pi PR dsh-plugin-teamflow v0.2.0 — from one sentence of requirements to an accepted delivery (multi-agent pipeline for DeepSeek Harness) #7540（已合并）—— 引入「length stop + usage 接近窗口 ⇒ 视为溢出」的思路，
  但其「允许非零 output」的放宽未出现在 pi-ai@0.85.1 构建中。
• 上游 earendil-works/pi issue HTTP 402 (insufficient provider balance) never reaches the terminal QUOTA failure code #7052 —— 官方 OpenAI 上的同构现象（输入 ≈98% 窗口 + 极小 output）。
• 上游 earendil-works/pi issue [修复方案] 源码启动 prepare 崩溃：profile 解析锚点未规范化导致 tsx 跳过 paths（fork 分支 + 回归测试 + 端到端验证） #7048 —— 摘要被 token cap 截断后仍被当作有效 checkpoint 持久化。

[argszero]

Thanks for this report — the chain you traced is the one I get too, line for line, and your suggested fix #1 is the right minimal one. I've implemented it as a mountable plugin so it works on the prerelease you are already running, without waiting for a release.

The plugin

@argszero/cordis-plugin-length-stop-overflow@0.3.0 — npm · source

npm i @argszero/cordis-plugin-length-stop-overflow

then add it through a bundle patch (this is the package's own cordis.patch.yml):

- insert:
    - id: length-stop-overflow
      name: '@argszero/cordis-plugin-length-stop-overflow'

It observes the public llm/stream waterfall and rewrites the terminal frame into the CONTEXT_WINDOW_EXCEEDED failure your ④ identifies as the gate — compaction-basic/src/index.ts:194, if (failure.code !== CONTEXT_WINDOW_EXCEEDED_CODE || signal.aborted) return next().

The rule that addresses your #1

On an error finish whose code nothing else attributed, the plugin compares the provider's own count — inputTokens + cacheReadTokens + cacheWriteTokens — against the window resolved for the same route through ctx.llm.resolveModelInfo(...).context.contextWindow. At saturationRatio (default 0.99) or above, the failure is reclassified.

Your three samples classify on the first gate, with no wording consulted at all:

usage (input / cacheRead)	your prompt	vs 131,072
5486 / 166528	172,014	1.31×
13671 / 171904	185,575	1.42×
7277 / 185472	192,749	1.47×

That is the point of reading the numbers instead of the text: Response incomplete: length matches nothing, while the provider's arithmetic already names the reason. The synthesized failure keeps the provider's message verbatim and adds both numbers, so the rewrite is checkable against the session log:

volcengine-ark/deepseek-v4-1-flash failed as PI_AI_ERROR after the provider counted
192749 prompt token(s) against the 131072-token window that route advertises (1.47x):
Response incomplete: length. Reclassified as CONTEXT_WINDOW_EXCEEDED by
length-stop-overflow (discussion #7632): on a prompt this full the provider's own
numbers name the reason, and the code it arrived with is one no recovery reads.

Two properties are deliberate, because this rule must not fire on someone else's failure:

• fail-closed twice — no usage chunk, no verdict; no resolvable window (or a capacity that is not a positive integer), no verdict;
• the window lookup runs last, after both other rules have declined the finish and the failure alone has passed every window-independent gate — resolving a window costs an adapter call, so a healthy turn never pays for it, and a resolver that throws leaves the stream untouched.

classifySaturatedFailures: false turns this off without touching the other two rules; saturationRatio moves the bar.

One correction, in your favour

Your ③ is right that the text fallback misses this. But the usage path was added to llm-pi-ai before your build: commit 4791b40b26 ("fix(llm-pi-ai): classify usage-based context overflow", 2026-07-19) is an ancestor of dsh-v0.1.5-rc.2, and it forwards the resolved capacity into pi-ai's own classifier — llm-pi-ai/src/stream.ts calls isContextOverflow(message, contextWindow) and returns CONTEXT_WINDOW_EXCEEDED on a hit.

The gap is exactly one conjunct. I installed @earendil-works/pi-ai@0.85.1 and read dist/utils/overflow.js; its two arithmetic branches are:

// Case 2: Silent overflow (z.ai style) - successful but usage exceeds context
if (contextWindow && message.stopReason === "stop") { /* input + cacheRead > contextWindow */ }

// Case 3: Length-stop overflow (Xiaomi MiMo style)
if (contextWindow && message.stopReason === "length" && message.usage.output === 0) {
  /* input + cacheRead >= contextWindow * 0.99 */
}

Ark gave you stopReason: "error" (your ①, via mapStopReason's incomplete branch), so both arithmetic branches are skipped by a stopReason test — not by the token counts, which would have matched immediately. Case 1 needs wording, and Response incomplete: length has none. So the DSH-side usage fallback is present and still misses this shape, which is why the plugin's rule keys on the counts and not on stopReason at all.

(Your reading of case 3 is otherwise identical to mine, including the usage.output === 0 condition that PR #7540 relaxes upstream and that is absent from the 0.85.1 build.)

Honest boundary

• It cannot make an over-window summarization succeed. Where the compactable prefix is itself past the window, the summarizer's request is refused too — and that failure now gets the same treatment, so the log names the reason there as well. What changes for your session is: the turn ends with the code the recovery reads (and the provider's two numbers) instead of an opaque PI_AI_ERROR, and the built-in recovery runs instead of never running.
• It may still buy you progress: the overflow path in compaction-basic performs the model-free tool-result prune before choosing a summary region (tool-result-pruner, mounted in the standard preset), and durable reduction from that pass is accepted as retry proof even when the later summarization throws. So a session that is past the window because of large tool results can shrink and continue.
• The plugin is bounded like everything else here: one recovery attempt, maxOverflowRetries default 1, no retry loop. It never re-dispatches a request of its own.

Your items 4, 5, 6 and 7 stay core-side and are untouched by this: compaction failure still logs continuing the turn (compaction-basic/src/index.ts:172), the summarizer's maxTokens default is still 8192, CHARS_PER_TOKEN = 4 still under-counts CJK, and the pressure threshold still prices an estimate rather than the last real usage. 7 in particular is the one I would most like to see landed, since it is what puts the 0.75 trigger inside the window in the first place — the plugin can only repair the classification after the request has already gone out.

Context

The same package already covers two neighbouring shapes, both of which reach the same dead end through different evidence: a length finish with a negligible output count (the max_tokens: 1 clamp, #7214) and a request refused outright for its size with no body to read (#7626). All three rewrite to the same code, so the recovery sees one shape rather than three. Start with mode: 'warn' if you want to measure your own traffic before letting it change behaviour.

Thanks again for the session-file forensics — the input + cacheRead columns are what made this checkable rather than guesswork.