对话过程中切换第三方模型中转站，无法压缩上下文

[KseekerX]

在对话过程中，我切换到了通过第三方模型中转站使用的模型，发现无法再压缩上下文，导致对话花费巨大，对话过程中经常显示“
本轮运行失败pi-ai detected context overflow for model "deepseek-flash"”，但实际上完成了对话；并且输入问题后经常不显示思考，而是卡在那里，必须要刷新网页才行，而刷新后上一轮对话内容就会消失，如何解决呢

[PerryLink]

压缩需要目标模型的正整数上下文窗口——切到中转站模型后，这一项很可能拿不到

1. 代码依据（HEAD = dsh-v0.2.1-alpha.1）

packages/compaction/compaction-basic/src/config.ts
:153  export function resolveCompactSpec(…)
:155    contextWindow: number,            ← 由"目标模型"提供
:159    if (!Number.isInteger(contextWindow) || contextWindow <= 0) {
:162      `BasicCompactionConfig: contextWindow (${contextWindow}) must be a positive integer`,

⇒ 也就是说：压缩规格是按"目标模型的上下文窗口"推导的（阈值 = contextWindow × thresholdRatio 之类），而这个值必须由适配器/目录给出。

⇒ 所以你遇到的很可能不是"压缩坏了"，而是：切到第三方中转站的模型后，那个模型没有可用的上下文窗口 ⇒ 规格推导不出来 ⇒ 无法压缩。⇒ 而你同时看到的 pi-ai detected context overflow for model "deepseek-flash" 说明它仍然按原模型（或某个已记录模型）在判溢出 ⇒ 这两者叠加正好解释"既溢出又不压"。

2. 建议的诉求（两条）

1. 让该模型声明上下文窗口（第三方中转模型需要目录条目/显式配置）⇒ 这是根因侧的修法；
2. 拿不到窗口时应当明确报错（说明"该模型缺少上下文窗口，压缩不可用"），而不是静默地"能溢出但不压缩"。

第 2 条成本最低，且它能把你现在"对话花费巨大 + 只看到溢出提示"的困惑变成一句可读的诊断。

3. 你提到的第二个问题请单独提一条

"输入问题后不显示思考、卡住、必须刷新；刷新后上一轮内容消失"。⇒ 这是UI 状态/刷新语义问题，与压缩无关。建议拆开，并补：刷新后消失的是"上一轮的回答"还是"整轮记录"（前者是渲染，后者是持久化）。

4. 请补三样

1. 切换前后各自的 provider/model（含中转站的模型名）；
2. 该模型是否在设置里能看到上下文窗口（设置 → 模型目录）；
3. 版本（当前最新 0.2.1-alpha.1）。

5. 一条边界

我确认的是压缩规格依赖正向整数 contextWindow、且该值由目标侧提供（:153-162 逐行）。你的中转模型是否缺这个值以第 4 节的观察为准——我没有该环境。

[KseekerX]

您好，第一个问题在声明上下文窗口后得到解决。针对第二个问题，消失的情况有多种，“上一轮回答”可能部分或全部消失，也可能出现一定的顺序错乱。在提出问题并回车后，看不到这个问题，会显示“深度求索中...“，但不输出任何内容，必须要刷新后才会正常显示。补充内容：
1、切换前provider为deepseek，model为deepseek-flash，切换后provider为在问ai平台，model为deepseek-flash
2、可以看到上下文窗口
3、0.2.0-rc.2
在第一个问题解决后，第二个问题经过几轮尝试似乎也已解决，我还需要再尝试几次。感谢🙏！

[mimicode]

手动压缩 也压缩不了，所以是不是过于严格了。自动不了， 是不是手动也应该可以，而不是推导不出来就不让压缩。

[PerryLink]

手动压缩确实不看上下文窗口，所以"推导不出来就不让压缩"这个判断在这里不成立——它和自动压缩走的不是同一条路。

packages/compaction/compaction-basic/src/index.ts:383-399 的 compactNow 只做三件事：agent.runMaintenance(...)、this.ctx.tokenMeter.measure(session)、selectCompactableRange(..., 0)。它没有调用 llm.resolveModelInfo，也没有调用 resolveCompactSpec。窗口只在自动路径上被读：:304 先取 resolveModelInfo，:307-313 在 info.context === undefined 时抛 TargetPressureConfigError，:314-318 才把窗口交给 resolveCompactSpec。

selectCompactableRange 的第三个参数是 retainTokens——保留多少 token 的近期尾巴不压（compaction-basic/src/region.ts:112-121）。手动传 0，意思是尾巴一点都不保留，尽可能多压。所以手动这条路径不但不需要窗口，它比自动还更激进。

那"手动也压不了"就是另一个失败点。/compact 会把能力错误翻成人话，只有六种（packages/compaction/command-compact/src/index.ts:24-52）：busy、cancelled、changed、summary、commit、persistence，另有 No compactable history yet.（:68）。这六句指向完全不同的原因：

• busy：进程里已有压缩在跑，或 agent 不空闲。压缩是 runMaintenance 独占的，前台在跑就不会开始。
• summary：摘要那次调用失败。中转站最常见的失败点，尤其是模型不支持长输入或直接断流。
• changed / commit / persistence：历史在压缩过程中变了、落盘没完成、或写盘失败。

所以请把你手动压时屏幕上那句原话贴出来——它是哪一句，就决定了要修什么。如果是 summary，那和你切中转站是同一件事，跟窗口无关；如果是 busy，那连"严格"都谈不上。

至于"是不是过于严格"：自动那条必须严格，因为阈值是窗口的一个比例，没有窗口就没有阈值可算，这不是保守，是无从计算。但我同意现在的呈现是错的——它抛的是一个配置异常，用户只看到"不能压缩"，看不到"这个模型缺上下文窗口"。该改的是把缺窗口变成一句明确诊断，而不是放宽阈值。

[mimicode]

我的场景是这样的，接入的是 opencode go 。设置dsv4.1flash ，如图：

1. 首先他不会自动压缩，这个好像是窗口计算的问题（ai说的）
2. 手动压缩出现 Compaction could not produce a useful summary. The attempt is recorded in the session log.

[mimicode]

所以我的困惑点是，手动压缩理论应该可以完成的，毕竟上下文最大是1m.不知道是不是我理解的不对

[PerryLink]

理论上，最有可能的原因是因为你的上下文窗口就是449,535，而且你把最大输出写成了384K。上下文窗口减掉输出，就只剩65K给输入了，压缩阈值成负数了。
所以自动压缩会失败，手动压缩也失败。
把上下文窗口改成 1000000、输出改成 32K/64K，你再试试。