自动压缩在中文密集会话与大陆中转站下失效：两类根因 + 实测证据

[zjgulai]

自动压缩在中文密集会话与大陆中转站下失效：两类根因 + 实测证据

环境：DSH Desktop 2.0.5 / harness 0.1.2-rc.1（macOS arm64）
触发场景：中文为主的编码会话 + 硅基流动（api.siliconflow.cn/v1，openai-completions 协议）+ 跨模型切换
症状：上下文溢出后回合直接中止；/compact 或 compact_now 也失败

我在本机做了完整取证，确认这是两个互相独立的根因，都会让自动压缩在关键路径上静默失效。源码行号按 0.1.2-rc.1。

---

根因 1（P0）：provider 的溢出报文不被 isContextWindowExceededError 识别 → 溢出恢复分支永不执行

实测报文

硅基流动在超长输入时返回 HTTP 400：

{"code":20015,"message":"number of input tokens (150019) has exceeded max_prompt_tokens (98304) limit."}

分类结果

@deepseek-ai/dsh-llm 的 isContextWindowExceededError（lib/index.js:145）
与 pi-ai 的 24 条 OVERFLOW_PATTERNS（pi-ai/dist/utils/overflow.js）全部不匹配：

$ node --input-type=module -e "import {isContextWindowExceededError} from './dsh-llm/lib/index.js';
  console.log(isContextWindowExceededError('number of input tokens (150019) has exceeded max_prompt_tokens (98304) limit.'))"
false

对照：同站另一模型的报文格式是命中的，所以同站不同模型行为不一致（这解释了「时好时坏」的观感）：

$ node ... "This model's maximum context length is 262144 tokens. ..."
true     # 命中 OVERFLOW_PATTERNS[8] /maximum context length is \d+ tokens/i

失败链

1. classifyPiAiError 把 HTTP 400 判为 INVALID_REQUEST，不是 CONTEXT_WINDOW_EXCEEDED
2. dsh-compaction-basic 的溢出恢复钩子首行即放行：
   if (failure.code !== CONTEXT_WINDOW_EXCEEDED_CODE || signal.aborted) return next()（lib/index.js:805）
3. dsh-llm-retry 对 INVALID_REQUEST 不重试
4. → 回合硬中止，从不压缩、从不重试

建议

把这类报文纳入分类器。最小改动是给 OVERFLOW_PATTERNS 与 isContextWindowExceededError
补两条模式（max_prompt_tokens 与「N input tokens 超过 max_prompt_tokens(M)」），
并考虑纳入 max_prompt_tokens / max_input_tokens 这类「输入侧上限 ≠ 模型上下文长度」的措辞。

---

根因 2（P0）：token-meter 的 chars/4 估算让中文会话的阈值晚到 2.21 倍

dsh-token-meter/lib/types/estimate.js 用固定 CHARS_PER_TOKEN = 4。

实测

取本机一天前真实会话中 12 段中文密集内容（16,566 字），用 deepseek 官方 tokenizer 实测：

真实 prompt_tokens = 9160      → 1.81 chars/token
启发式 chars/4     = 4139      → 低估 2.21 倍

后果

compaction-basic 的 thresholdRatio 是估算口径的比例，于是：

thresholdRatio: 0.75, contextWindow: 262144
名义触发 = 196,608（估算口径）
换算真实 ≈ 196,608 × 2.21 ≈ 434,000 真实 token

thresholdRatio: 0.75 实际等价于「真实上下文的 166% 才触发」 —— 永远够不着，
provider 早在真实上限处就拒绝了。中文比重越高越严重（英文会话偏差小得多）。

这同时解释了为什么加 maxOverflowRetries / compactionRetries 都没用：
压力触发根本没到，而溢出的那条路被根因 1 切断了。

建议

不必改全局常数（它同时服务 UI 上下文环，改动面太大）。可用其中任一：

• 在 estimate.ts 里对 CJK 区间按加权密度估算（例如按 CJK 字符占比在 4 与 ~1.8 之间插值）；
• 或让 thresholdRatio 的语义改为「真实口径」，由 compaction-basic 内部按同一估算器做折算；
• 至少应在文档里写明 thresholdRatio 是估算口径，并在 CJK 会话下提示折算系数。

---

附带（同类故障，供参考）：摘要调用自身溢出 → 自锁

buildSummarizationInput 把「完整 system prompt + 全部 tool schema + 全部被遮蔽对话」
打包后回发给摘要模型。本机 system + tools 常达数万 token，因此 26 万 token 的会话做摘要时
是一个 30 万 token 的请求 —— 若摘要走对话路由，必然再溢出一次：

step compaction failed: pi-ai detected context overflow for model "zai-org/GLM-5.3"; continuing the turn
context-overflow compaction failed: pi-ai detected context overflow for model "zai-org/GLM-5.3"; preserving the original request error

已在本地用「摘要路由固定到 1M 上下文模型」绕过。建议上游考虑在摘要输入超预算时先裁剪
（而非整段回发），或至少把这条失败标注成「摘要输入溢出」以便区分。

另外一条实测（非 bug，但值得写进文档）：maxTokens 默认 8192 对中文六段式 checkpoint 偏小。
本机 25.7 万 token 会话实测：

compaction/start  1789144728744
compaction/end    1789144764618  error: summarization truncated at the token cap (incomplete checkpoint)
耗时 35874 ms

35.9 秒（非秒退）证明是真跑满输出预算后截断，且输出预算里还含 reasoning token。
提到 48K 后解决。

---

附：大陆中转站的容量事实（harness 无法自动获知）

硅基流动 GET /v1/models 只返回 id/object/created/owned_by，不含容量，故
llm-pi-ai 的 contextWindow 只能手配。而我实测的 provider 真实上限与官方文档标称不一致：

模型	文档标称	provider 实测
zai-org/GLM-4.5-Air	131K	98304
zai-org/GLM-4.5V	131K	65536
Qwen/Qwen3.6-35B-A3B	262K	262144
zai-org/GLM-5.3	1049K	≥700000（700K 实测通过）

而 dsh-llm-pi-ai 对未声明容量的模型回落 defaultContextWindow: 262144
（DEFAULT_CONTEXT_WINDOW，lib/index.js:857）。对上面两个小窗口模型，这个默认值是
危险值：压力触发按 75% 算是 196,608，而 provider 在 65536/98304 就拒绝了。

建议：文档里明确「未声明容量 ≠ 安全默认」，并建议中转站路由显式设置
defaultContextWindow 为站内最小值。

---

复现清单

# 1) 分类器判定（需本机 harness 安装路径）
node --input-type=module -e "
import {isContextWindowExceededError} from '<app.asar.unpacked>/node_modules/@deepseek-ai/dsh-llm/lib/index.js';
console.log(isContextWindowExceededError('number of input tokens (150019) has exceeded max_prompt_tokens (98304) limit.'))"

# 2) provider 真实上限（任意 OpenAI 兼容端点的超长请求都会回显精确值）
curl -s https://api.siliconflow.cn/v1/chat/completions \
  -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' \
  -d '{"model":"zai-org/GLM-4.5-Air","max_tokens":4,"messages":[{"role":"user","content":"<150K token 填充>"}]}'

# 3) 中文 chars/token（对任意 OpenAI 兼容端点）
#    发一段中文取 usage.prompt_tokens，与 字符数/4 对比即可复现 2.21 倍偏差

同一 DSH 版本下，把 thresholdRatio 折到 0.45、把 summarizationProvider/Model
固定到大窗口独立路由、并给每个中转站模型显式写实测 contextWindow 之后，
本机长中文会话的溢出中止已停止复现。

[argszero]

感谢这份取证——两类根因的分离、实测 tokenizer 对照、以及「同站不同模型行为不一致」这条观察，都直接可用。我按 master @ c291e7961a 逐条核了源码，补充四点对你两条根因的定位修正，以及一个已经把根因 1 做好的插件。

---

一、根因 1 的分类落点：400 走的是 DeepSeek 适配器，不是 classifyPiAiError

这决定了补丁该打在哪。

• classifyPiAiError（llm-pi-ai/src/stream.ts:41-67）里确实没有输入侧上限的措辞，你的判断对；
• 但 httpErrorCode（llm-deepseek/src/adapter.ts:337-351）同样只在 400 分支调 isContextWindowExceededError，不命中就 return 'INVALID_REQUEST'。这是两条独立的失败路径，补一条不会顺带修好另一条；
• 而且 pi-ai 还有第三条兜底：mapStopReason 里 isContextOverflow(message, contextWindow)（stream.ts:81）用的是目录里的 contextWindow 做用量比较。中转站不发布上下文长度 ⇒ context 为 undefined ⇒ 这条也永远不命中，最终落到 PI_AI_ERROR（stream.ts:67）。

所以「补两条模式」实际要落在三处：isContextWindowExceededError（治两个适配器的文本路径）+ pi-ai 那条 usage 路径的 undefined 回退。

二、根因 2 比你描述的更硬：thresholdRatio 的分母根本不存在

你说「估算口径」，准确说它是 contextWindow 的口径：

thresholdTokens = Math.floor(contextWindow * policy.thresholdRatio)   // config.ts:144

你的 0.75 × 262144 推导没问题。但关键在分母怎么来——index.ts:296：

const context = (await this.ctx.llm.resolveModelInfo(target.provider, target.model, signal)).context
if (context === undefined) {
  throw new TargetPressureConfigError(
    `${targetKey}: no context capacity for ${targetKey}; configure contextWindow on that adapter model`)
}

中转站路由不发布上下文长度 ⇒ context 是 undefined ⇒ 这一行直接抛 TargetPressureConfigError。 压力压缩不是「阈值晚到」，是整条路径根本走不到阈值比较。

这一层抛出被 agent/pre-step 的 try/catch 吞掉，只 logger.warn('step compaction failed: …') 一次，并按 targetKey 记进 warnedPressureConfigTargets 去重（index.ts:154-161）——所以第二次之后连 warn 都没有。「静默失效」的观感来源在这里，而不只在比例上。 而且 thresholdRatio 当分母为 0/不存在时，任何比例取值都同样无效——这解释了为什么调 thresholdRatio 也没用。

结论：根因 2 对中转站场景其实是「配置缺失 + 静默告警」（warn 升 error + 文档写明必须配 contextWindow），而 CJK 的 chars/4 低估则是另一个独立面，只在分母存在时才谈得上。你实测的 1.81 chars/token 与插值建议对后者有效，我完全同意不必动全局常数。

三、被低估的一条：修复根因 1 会绕过根因 2

这是两条根因最实用的耦合关系，值得写进结论：

context-overflow 触发分支不查 thresholdRatio，也不查 contextWindow——它直接剪枝 + 选范围 + 压缩（index.ts:284-291），并且文档注释明说「overflow bypasses the normal threshold and retained-tail policy so it can force one useful balanced reduction」（index.ts:250-259）。

也就是说：根因 1 一旦修好，中文会话/中转站这种「真实已溢出但估算没到」的场景，就由溢出分支强制做一次均衡压缩——不需要先修估算器，也不需要分母存在。 反过来才不成立（修了估算器，溢出报文仍被误判，回合照旧硬中止）。所以优先级：先根因 1。

四、插件：@argszero/cordis-plugin-overflow-classifier-guard@0.1.0

上游 Issues/PR 通道对本仓库是关的，所以我按社区插件惯例把根因 1 直接做成了可挂载插件（源码级实现，不是 workaround 脚本）：

• npm：@argszero/cordis-plugin-overflow-classifier-guard
• 仓库：https://github.com/argszero/cordis-plugin-overflow-classifier-guard

挂载（bundle patch 已带，零配置；mode 默认 error）：

npm install @argszero/cordis-plugin-overflow-classifier-guard

- insert:
    - id: overflow-classifier-guard
      name: '@argszero/cordis-plugin-overflow-classifier-guard'

实现要点（都对着源码核过）：

1. 站在 llm/stream waterfall 上改写终帧的 finish.reason——assembler.ts:89 case 'finish': this._finish = chunk.reason 使改写后的判定是权威的；
2. 复用 harness 自己的常量与谓词（CONTEXT_WINDOW_EXCEEDED_CODE、chunkHasVisibleText、isContextWindowExceededError、isQuotaExceededError），不重写字符串——合成判定与适配器自产的判定不可区分，也不会与恢复路径所判的 key 漂移；
3. 不缓冲：判定只需要终帧，而终帧就是 provider 最后发的那一帧，所以逐 chunk 即时转发，实时流与 durable log 不受影响（有一条测试专门在它一旦开始缓冲时失败）；
4. 四条同时成立才改写：error 终帧（非 aborted）· 尚未流式输出过可见内容 · 失败码是终态请求形状类（INVALID_REQUEST / PI_AI_ERROR / 任意 HTTP_4xx；RATE_LIMIT/SERVER/TIMEOUT/TRANSPORT 归重试策略，AUTH/QUOTA/EMPTY_RESPONSE 另有解法）· 报文点名的是输入侧预算（max_prompt_tokens / max_input_tokens 一类），且排除 max_tokens 这类输出侧措辞——缩短请求对它没有帮助；
5. 你说的报文逐字进了测试，并且两个语序都覆盖：硅基流动是「input tokens (150019) has exceeded max_prompt_tokens」，动词在前；另有网关是「max_input_tokens exceeded」，名词在前。判定用有界窗口（名字两侧各 160 字符）同时接受两者，又不会因为「先提预算、远远之后另说一个不相干超额」而误判；
6. 恢复仍是有界的：判定经 agent/request-error 交给 dsh-compaction-basic，受 maxOverflowRetries（默认 1，config.ts:93）约束，不会成环。

50 个测试；mode: warn 可以先只观测不改行为，日志会点名它本来会替换掉哪个码；extraPatterns + eligibleCodes 可接你遇到的其它网关措辞。

这不是 core 修复。 正解仍是把命名输入上限纳入 isContextWindowExceededError（并给 pi-ai 的 usage 路径补 undefined 回退）——适配器手里已经有 detail 字符串，位置也现成。插件只是在你升级前，把这类失败重新分类到机器已经在看的地方。

五、两个附带项我也核了一下

• 摘要自锁：与 project-compaction-summarizer-context-overflow-deadlock 属同一缺口（摘要调用自身超窗，无 headroom），上游尚无修；你「摘要路由固定到 1M 模型」是当前正确的绕法。
• maxTokens 默认 8192 对中文六段式偏小：你那条 35.9s + summarization truncated at the token cap 正是「真跑满输出预算后截断」的判据，提 48K 合理。

---

TL;DR (EN) — Verified both root causes on master @ c291e7961a, with three corrections worth having before a patch is written:

1. Root cause 1 has three failure sites, not one. The reported JSON goes through httpErrorCode (llm-deepseek/src/adapter.ts:337-351), a different site from classifyPiAiError. pi-ai adds a third: its usage-based isContextOverflow compares against the catalog context window, so a relay route publishing none falls through to PI_AI_ERROR (stream.ts:81, :67).
2. Root cause 2 is harder than a ratio problem. thresholdTokens = contextWindow * thresholdRatio (config.ts:144) — and for a route that publishes no context length, resolveModelInfo(...).context is undefined, so the pressure path throws TargetPressureConfigError before any comparison (index.ts:296-302). That throw is caught at agent/pre-step, logged once, then suppressed per target by warnedPressureConfigTargets (:154-161) — that is where "silently fails" comes from, and why no value of thresholdRatio helps. The CJK chars/4 underestimate is a separate axis that only matters once the denominator exists.
3. Fixing root cause 1 bypasses root cause 2. The context-overflow branch never consults thresholdRatio or contextWindow; it prunes and compacts directly (index.ts:284-291), deliberately bypassing the normal threshold and retained-tail policy (:250-259). So the overflow branch does the useful reduction for a Chinese-dense session whose estimate never reached the trigger — no estimator change and no missing denominator required. The converse does not hold.

Plugin (root cause 1, mountable today): @argszero/cordis-plugin-overflow-classifier-guard@0.1.0 — https://github.com/argszero/cordis-plugin-overflow-classifier-guard — observes the llm/stream waterfall (identical seam to the shipped empty-response-guard), imports the harness' own CONTEXT_WINDOW_EXCEEDED_CODE so a synthesized verdict cannot drift from the key the recovery path tests, never buffers (the verdict needs only the terminal chunk), preserves provider text verbatim, and gates the rewrite on four conditions: an error finish, no visible content already streamed, a terminal request-shape code, and a named input budget. The reported body is in the tests verbatim, in both word orders (verb-first as reported; name-first as other gateways write it), matched within a bounded window. Recovery stays bounded by maxOverflowRetries. 50 tests. Not the core fix — the real repair is widening isContextWindowExceededError (plus an undefined fallback on pi-ai's usage path); this keeps the failure classified where the machinery already looks until upstream decides.

[VillagerUncle02]

补一个不同口径的数据点，不改动你根因 2 的结论。

你测的是中文密集内容的 chars/token（官方 tokenizer，2.21×）。我这边测的是真实混合会话里
meter 估算 vs API 实际 usage：5 个会话 / 6039 个 step，real/estimate 中位 1.338（+34%），
范围 +26%~+57%，100% 低估。

两者不冲突，是同一件事的两个切面：纯中文段落偏 2.21×，而真实会话里混了大量英文工具结果与源码，
整体偏差被稀释到 +34% 左右。

顺带一个可能对你有用的口径细节：meter 的总量是 provider-anchored

dsh-token-meter/lib/index.js:652-664
baseline = usageTokens(usage) >= estimatedAnchorTokens ? usage : estimated

也就是拿到过真实 usage 之后，整量会以真实值为锚，低估主要作用于"每步新增的增量"。
这大概能解释"中文会话观感上偏差很大、但总量没有按 chars/4 那么离谱地偏"。

中转站那一半我没测，只补 meter 这个切面。

（环境：DSH 0.1.5-rc.1 / Windows 11 / deepseek-flash / contextWindow 1048576）

影响的能力

• token 计量准确性 / 压缩时机：计量偏差决定压缩早触发还是晚触发，进而决定长任务在撞上
  provider 上限之前有没有机会自己收敛。
• 长任务相关：是。