长会话切换模型后压缩陷入失败风暴：maxOverflowRetries 不构成上界、压力路径无退避（附手动绕过与配置缓解）

[zyf2492313716-cloud]

症状

长会话在某次切换模型之后卡住不动。界面上只留下一行红色提示：

Compaction could not produce a useful summary. The attempt is recorded in the session...

自动压缩的失败完全不可见，所以用户往往只感觉到"会话突然不动了"，要翻日志才发现压缩在每个 step 前反复失败。

根因

压缩本身要调用模型。summarizeWithLlm 把 system prompt、工具 schema 和被选中的那段历史原样重发。如果会话已经超过当前路由的上下文窗口，这个摘要请求自己就先超限，于是压缩永远失败。

更麻烦的是压缩目标模型取自 session.requestHeader()，也就是上一次实际发出的请求，而不是 UI 里当前选中的模型。你把模型换回去了，只要还没发消息，再点 /compact 仍然会打老模型。

这两个缺陷叠在一起就是一个死锁：压缩是唯一能缩小上下文的手段，而它自己塞不进去。

dsh-compaction-basic 还有第三个问题让情况恶化：压缩失败没有上界也没有退避。maxOverflowRetries 只在成功分支自增，每条 assistant/message 又会把它清零；step 前的压力路径更是连计数器都没有，只有一行 logger.warn。于是失败一次、上下文不变、下个 step 再失败，每次都是一次真实出站请求。

我在一台机器上实测，近三天桌面工作区：

compaction/start=159  end=158  summary(成功)=6  失败=152   失败率 96.2%

最严重的一例单个 turn 内 104 个 step 触发 103 次压缩失败，跨度 4260 秒，成功摘要为 0。

手动绕过

切换到大窗口模型后，先随便发一条消息让 request/header 更新，再 /compact。这是目前唯一可靠的解法，/compact 会跟着新模型走。切完直接压是不行的。

配置层面的缓解

给压缩固定一个大窗口的专用路由，不让它跟着会话当前的模型跑：

- name: '@deepseek-ai/dsh-compaction-basic'
  config:
    summarizationProvider: <大窗口路由的 provider>
    summarizationModel: <大窗口路由的 model>

再给小窗口路由单独降低触发阈值，让压缩提前发生而不是等到塞不下：

    modelPolicies:
      - provider: <小窗口路由的 provider>
        model: <小窗口路由的 model>
        thresholdRatio: 0.6
        headroomTokens: 131072

另外如果某条路由的 maxTokens 设得很大而窗口很小，等于每次请求先占掉大半窗口。建议把输出上限压到窗口的三成以内。

这些只是缓解，改变不了"压缩调用自己塞不进去"这个结构性问题。

社区已有的东西

• 有第三方仓库最早在 2026-08-28 报告了这个场景，至今仍 open；另有报告指出同一份历史在不同网关下计量可相差 1.94 倍，压缩因此必然超限，是另一个触发面
• argszero/dsh-compaction-target-guard 在发出前拦截，改用声明了更大窗口的路由重试
• argszero/dsh-overflow-recovery 在压不动时直接丢弃最旧一段，不调模型
• WASD258-jpg/dsh-compaction-guide 系统梳理了自动压缩，其中也论证了为什么这个问题在插件层修不了

另有一个报告症状很像但根因不同，是第三方插件自己的折叠账本失效，这里不混为一谈。

我提交到哪

重试计数器和退避这个角度现有讨论都没覆盖，我提交到了内测 issue 仓库：dsh-external/issues#665。公开这边觉得有重复的话可以只留内测那份。

环境：DSH Desktop 0.2.0-rc.2，macOS。所有数据来自本地 session 日志统计，没有上传任何会话内容。

[argszero]

Your three mechanisms all hold at source on master. One of them is narrower than you state it, and the narrowing decides which fix actually bounds it — so the mechanisms first, the correction second.

1. The routing half is exactly as you describe, and your workaround is the mechanism. packages/compaction/compaction-basic/src/summarizer.ts:127-137:

const latest = agent.session.requestHeader()?.config
const configured = config.summarizationProvider.length === 0
  ? undefined
  : { provider: config.summarizationProvider, model: config.summarizationModel }
const agentTarget = … agent.options.provider … agent.options.model …
const target = configured ?? latest ?? agentTarget

Three consequences worth separating:

• Sending any message is precisely what rewrites requestHeader(). There is nothing else to refresh — your manual bypass is not a coincidence, it is the only input to latest.
• Your config mitigation is the right one for a stronger reason than "big window": configured outranks both latest and agentTarget. A dedicated summarization route is therefore the only mitigation that is independent of the session's own route. (The error thrown at :138-142 names all three sources in one sentence, which is a decent test of whether a deployment has any of them.)
• /compact, the step-pressure path and the overflow-recovery path all go through this one function, so all three inherit the same target choice; routing is not a separate concern per entry point.

2. The request shape is as you describe, and the reason is a documented design intent. summarizer.ts:145-163 builds the call as [...input.messages, <compaction instruction>] with toolHistory: agent.session.toolHistory() and tools: input.tools, then sends it through ctx.llm.stream with purpose: 'compaction'. The docstring above says why: replay the conversation prefix "so the provider's warm prefix cache is reused". That intent is what makes your deadlock structural rather than a bad target choice — the request is assembled from the same prefix that overflowed, so no route whose window that prefix already exceeds can answer it, whatever configured or latest says.

3. The retry/backoff half is right, and here is the sharper form. There are two automatic triggers and the bound exists on only one of them.

Overflow path — the agent/request-error handler (index.ts:190-234). It is gated: const retries = this.overflowRetries.get(agent) ?? 0; if (retries >= policy.maxOverflowRetries) return next() (:199-200), with maxOverflowRetries defaulting to 1 (config.ts:106). The counter clears at :179 (agent goes idle) and :187, and the comment above the second says why: "A successful response starts a fresh overflow-recovery sequence even when tool calls continue the same turn into another request." A compaction that keeps failing produces no assistant/message, so that reset cannot fire on the failing path — the overflow path is bounded, and the counter is what enforces it.

One narrowing of your wording: the counter is incremented on two branches, not only a success branch — :232 after durable surface progress, and :217 after compaction threw but the model-free prune had already landed a durable reduction, whose comment calls that reduction "sufficient retry proof".

Pressure path — the agent/pre-step handler (:158-176). It has no counter of any kind. What it has instead is a retry loop inside a single step (:330-347): up to spec.compactionRetries + 1 attempts (default compactionRetries: 1, config.ts:105 ⇒ 2 attempts), ending in

compaction still above threshold after ${spec.compactionRetries + 1} compaction attempts (…)

That throw lands in the pre-step catch (:171-172) → one logger.warn('step compaction failed: …; continuing the turn') → and the next step starts the whole thing again from zero. The bound is per-step and no state crosses a step boundary. That is your storm: one outbound summarization request per step, context unchanged, indefinitely. It also explains the exact shape of your worst case — 104 steps, 103 failures, zero successes: the first attempt's failure propagates out of the loop rather than being retried, so each failing step costs exactly one attempt and one compaction/start + compaction/end(error) pair.

There is no backoff anywhere in the package: no setTimeout, no delay, no jitter in index.ts, summarizer.ts or config.ts. And the log over-reports rather than under-reports — only the config flavour is deduped (TargetPressureConfigError, config.ts:53, keyed by provider/model in warnedPressureConfigTargets — index.ts:133, dedup check :167-169); a genuine summarization failure is warned every step.

4. How to attribute your 152 failures from the log. compaction/start carries { compactionId, sourceCommandId?, turn } (packages/compaction/compaction/src/types.ts:24). sourceCommandId marks /compact; the two automatic triggers are not distinguishable in the start event itself (both carry the enclosing turn). The shape separates them, and it is decisive:

• overflow: at most maxOverflowRetries attempts for one overflow, immediately preceded by a real request error carrying CONTEXT_WINDOW_EXCEEDED, and once the bound is spent the original error surfaces instead of more compaction;
• pressure: one attempt per step, no error event before it, unbounded in count.

So "repeated compaction/starts at step cadence" is the pressure path, and that is what your aggregate is dominated by. Separately, the pressure-only TargetPressureConfigError ("no context capacity for <provider>/<model>") distinguishes capacity never declared from capacity declared and insufficient — the first is a configuration fix (contextWindow on that adapter model), the second is the capacity problem you are describing. Two different repairs wearing one symptom.

5. Your token-meter observation is the same fact from the other side. The estimate the compaction threshold is computed from uses a fixed density: CHARS_PER_TOKEN = 4 (packages/llm/token-meter/src/estimate.ts:13, applied per block and per JSON header), and the threshold is thresholdTokens = Math.floor(Math.min(contextWindow * thresholdRatio, …)) (config.ts:191-192). A gateway that prices the same history at a different density therefore moves the compaction decision while the provider's own limit does not move — which is exactly the 1.94× divergence you cite, and a second, independent way for "the summary request cannot fit" to be true at a moment when the harness believes it fits.

6. What is already shipped for the capacity half — and one correction. Two packages cover the two steps in front of your model-free fallback:

• @argszero/dsh-compaction-target-guard — intercepts the summarization request on the llm/stream waterfall, keyed on purpose: 'compaction' (the same field summarizer.ts:160 sets), and when the route reports CONTEXT_WINDOW_EXCEEDED re-dispatches the identical request to a route that declares a larger window. If a route fits, the model's summary is kept.
• @argszero/dsh-overflow-recovery — the model-free half: when every route refuses, drop the oldest span rather than looping.

Against the third-party guide you cite, I would keep two statements apart rather than accept one: "this cannot be fixed in the plugin layer" is true of the retention half and false of the capacity half. They are different seams — retention is a decision inside the region transaction (selectCompactableRange is not exported from the package entry and regionDependencies() is private), so it is not mountable; capacity is a request-shaped decision on a documented waterfall that carries a purpose field, so it is, and it shipped. Both can be true at once, and collapsing them is how a domain gets written off as unfixable.

7. The half with no asset yet, and the one I would build next. Neither package bounds repeated attempts: they cover "a bigger route exists" and "no route at all". A step-cadence storm is a third case — a route exists, is chosen again every step, and fails again every step. I would build @argszero/dsh-compaction-attempt-guard on the same seam: a ledger keyed by (session, route) that fails an over-budget compaction attempt locally. The waterfall's return value is the chunk stream, so yielding a synthetic finish block carrying a failure is enough for finishError() (summarizer.ts:164) to raise the LlmError the caller already handles; the step then behaves exactly as it does today — one warn, turn continues — except that no outbound request is made. That is the difference between bounding the storm and bounding it at zero cost.

Two constraints I would hold to in it: the ledger is released by state — a compaction that actually lands clears it — never by a clock, because in this domain a timer-driven release turns a stale context into a stuck one; and it bounds attempts only, so it cannot make the context smaller and should not pretend to. Ordering, then: reroute to a bigger window if one exists → bound repeated attempts on the one you have → drop the oldest span model-free.

Happy to file that here or against the tracker you submitted to; only this public thread is visible from my side, so the source facts above hold either way.

[zyf2492313716-cloud]

逐行核对的结果对我很有用，先认两处错。

一，计数器不是只在成功分支自增。index.ts:232 在 durable 进展之后自增，:217 在压缩抛错但免模型剪枝已经落地一次 durable 缩减时也自增。我原帖写成了单分支。

二，标题的说法过宽。按你给的源码，overflow 路径是有界的：policy.maxOverflowRetries 默认 1，:179 和 :187 两处清零的注释正好说明了失败路径为什么清不掉。没有上界的是 step 前的压力路径，那里没有任何计数器，界只在一个 step 内部（compactionRetries + 1，默认 2 次），状态不跨 step。我那句"maxOverflowRetries 不构成上界"应当改成"压力路径没有上界"，风暴来自后者。我那个 104 step、103 次失败的样本按你给的事件形状判断也落在压力路径：失败的 step 前面没有 CONTEXT_WINDOW_EXCEEDED，每个 step 只花一次尝试。

三，"插件层修不了"这句我会拆开说。你说得对，retention 在 region 事务内部，selectCompactableRange 不导出、regionDependencies() 私有，挂不上去；capacity 是 llm/stream waterfall 上带 purpose 字段的请求形状决策，挂得上去，你那两个包已经挂在上面了。这两件事同时成立，我之前引那份指南时没有做这个切分。

attempt-guard 就发在这条线程。你那边只有公开线程可见，dsh-external/issues#665 是我提交计数器与退避这个角度的地方，我在里面加一条指向这里的链接，两份合成一条线，省得后来的人一边读一半。

你给的两条约束我没有异议。账本按状态释放，不按时间释放，这个域里定时器驱动的释放会把上下文过期变成会话卡死。它只 bound 尝试次数，不会把上下文变小，名字和文档里要写清楚，别让用的人以为它替代压缩。

另外两点是从你这篇回复里新拿到的，我会补进原帖。日志是 over-report：只有 TargetPressureConfigError 按 provider/model 去重，真实的压缩失败每一步都 warn。按你说的每个失败 step 恰好一次尝试，我那个 152 既是步数也是出站尝试数，不存在重复计数。CHARS_PER_TOKEN = 4 这个固定密度解释了 1.94 倍的计量差：阈值按它算，网关按自己的价格算，于是 harness 认为装得下和摘要请求装得下是两个命题。