[Bug] pi-ai 路由声明的 contextWindow 未进入 resolveModelInfo，导致自动压缩静默失效、超限被误报为「额度已用尽」（0.2.0-rc.2）

[jiongguo001]

[Bug] pi-ai 路由声明的 contextWindow 未进入 resolveModelInfo，导致自动压缩静默失效、超限被误报为「额度已用尽」（0.2.0-rc.2）

摘要

在 llm-pi-ai 的 provider models[] 中显式声明了 contextWindow 和 maxTokens，但 compaction-basic 的自动压缩对该路由完全失效：它在压力路径上调 ctx.llm.resolveModelInfo() 得到 info.context === undefined，随即抛 TargetPressureConfigError，压缩中止，请求原样发出，被网关以 HTTP 400 拒绝。

UI 最终显示 「当前请求的额度已用尽」，但网关的真实响应是 上下文超限 —— 文案与实际错误不一致，会把排查方向带偏。

关键矛盾：异常信息写着 "configure contextWindow on that adapter model"，但 pi-ai 路由的 contextWindow 已经配在 provider 的 models[] 里了，只是没有进入 llm 服务的 model-info 解析链。这条指引对 pi-ai 路由不成立。

复现步骤

1. DSH Desktop 0.2.0-rc.2，profile desktop，挂载 dsh-llm-pi-ai
2. 在 cordis.patch.yml 声明一个 OpenAI 兼容网关路由：

- id: llm-pi-ai
  name: "@deepseek-ai/dsh-llm-pi-ai"
  config:
    providers:
      my-gateway:
        api: openai-completions
        apiKeyEnv: MY_GATEWAY_KEY
        baseURL: https://example-gw/v1
        models:
          - id: some-large-model
            contextWindow: 1048576
            maxTokens: 65536
            input: [text]

3. 让会话累积到超过 contextWindow × thresholdRatio（默认 thresholdRatio = .8、headroomTokens = 65536，见 resolveConfig()）
4. 发送消息 → 预期自动压缩，实际未压缩

观测到的现象

UI 报错文案：

当前请求的额度已用尽

网关侧同一时刻的真实响应：

{"error":{"message":"estimated input tokens exceed the model's context limit",
          "type":"invalid_request_error","code":"invalid_request_error"}}

把该响应体喂给 @deepseek-ai/dsh-llm 的 isQuotaExceededError 五条正则实测：

判定器	结果
QUOTA（额度）正则 ×5	全部不命中
上下文超限正则	命中 3 条

即：网关的错误分类是正确的，是 UI 文案把它错误地呈现成了额度问题。

代码路径

@deepseek-ai/dsh-compaction-basic 0.2.0-rc.2，lib/index.js：

async compactIfNeeded(agent, trigger, signal) {
    const target = routedTarget(agent.session);
    const policy = resolveTargetPolicy(this.config, target);
    ...
    if (trigger === "context-overflow") {
        // 这条路径不需要 contextWindow，直接压缩
        ...
        return this.compactRegion(range.start, range.end, agent, signal);
    }
    const info = await this.ctx.llm.resolveModelInfo(target.provider, target.model, signal);
    if (info.context === void 0)
        throw new TargetPressureConfigError(targetKey,
          `compaction-basic: no context capacity for ${targetKey}; configure contextWindow on that adapter model`);

形成死循环：压缩需要先知道窗口 → 但要触发溢出判定必须先发请求 → 而压缩在压力阶段就已经失败，context-overflow 分支永远进不去。

补充：手动 /compact（dsh-command-compact）不受影响，可正常完成 —— 后端本身可用，问题只在自动路径的容量解析。

环境信息

• DSH 版本: 0.2.0-rc.2（DSH Desktop，Windows x64，Electron 44.0.0，Node 24.18.1）
• 内核包: @deepseek-ai/dsh-llm-pi-ai / @deepseek-ai/dsh-compaction-basic 均 0.2.0-rc.2
• 操作系统: Windows
• 网关: OpenAI 兼容，/v1/chat/completions
• 无第三方插件参与复现

一个重要的复现前提：该网关的 /v1/models 返回 OpenRouter 风格嵌套 schema：

"input_modalities": [{"type":"text",
  "supported_inputs":{"max_context_length":{"value":1048576,"unit":"token"}}}],
"output_modalities": [{"type":"text","max_length":{"value":1048576,"unit":"token"}}]

顶层没有 context_length / max_output_tokens。DSH 的模型发现解析扁平字段，因此必须手填 contextWindow —— 而手填的值又没进入 resolveModelInfo，正是本 issue 的触发条件。

冒烟测试

• 环境: DSH Desktop 0.2.0-rc.2 + 内核 dsh-llm-pi-ai / dsh-compaction-basic 0.2.0-rc.2
• 执行步骤与观察结果:
  1. 声明 pi-ai provider（api: openai-completions + 手填 contextWindow: 1048576 / maxTokens: 65536）
  2. 用同一网关直接发请求：
     • 小输入 → HTTP 200
     • 输入约 40 万 token → HTTP 200（网关不拦，只在超限时才报错）
     • 输入约 105 万 token → HTTP 400 estimated input tokens exceed the model's context limit
     • 输入约 198 万 token → 同样 HTTP 400
  3. 把 400 的响应体喂给 isQuotaExceededError 的五条正则 → 全部不命中；上下文超限正则命中 3 条
  4. 在 DSH 内让会话超过阈值 → UI 显示「额度已用尽」，压缩未发生
  5. 执行 /compact → 压缩正常完成（证明后端可用，问题在自动路径）
• 对照 / 历史版本差异: 未在其他 DSH 版本上对照（本地仅 0.2.0-rc.2）。步骤 1-3、5 为本次实际执行并记录的输出。

引用代码

• @deepseek-ai/dsh-compaction-basic/lib/index.js — compactIfNeeded() 中 resolveModelInfo 后的 info.context === void 0 抛错分支，以及 context-overflow 分支的早返回
• @deepseek-ai/dsh-compaction-basic/lib/index.js — resolveConfig()：DEFAULT_THRESHOLD_RATIO = .8、headroomTokens = config.headroomTokens ?? 65536、auto: config.auto ?? true
• @deepseek-ai/dsh-llm — isQuotaExceededError() 正则集合，以及 CONTEXT_WINDOW_EXCEEDED_CODE 的判定路径

对应主仓库源码路径形如 packages/compaction/compaction-basic/src/index.ts。

建议方向（供参考）

问题核心是 pi-ai 路由声明的 contextWindow 没有汇入 llm 的 model-info。可能的最小修复面：

1. 让 dsh-llm-pi-ai 在注册路由时把 models[].contextWindow / maxTokens 一并注册进 model-info；
2. 或让 compaction-basic 在 resolveModelInfo 返回 context === undefined 时回退到 pi-ai provider 的声明值；
3. 顺带建议修正 UI 文案分流 —— 上下文超限不应落入 message.failure.quota。

影响面

该问题对所有使用 pi-ai 声明网关的用户静默生效：压缩不报错地失效，只在会话涨过阈值后才以「额度已用尽」的形式暴露，排查方向容易带偏。

[PerryLink]

⭐ 你的链条我逐行核实了——而且它正好证实了我另一条回答里的推断

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

packages/compaction/compaction-basic/src/index.ts:304
    const info = await this.ctx.llm.resolveModelInfo(target.provider, target.model, signal)

packages/llm/llm/src/index.ts
:733  async resolveModelInfo(provider, model, signal)
:738    return this.resolveModelInfoFor(this.registration(provider), model, signal)
:741  private async resolveModelInfoFor(…)

packages/compaction/compaction-basic/src/config.ts
:53   export class TargetPressureConfigError extends Error
:160    throw new TargetPressureConfigError(…)
:166    throw new TargetPressureConfigError(…)

⇒ 你说的每一步都对上了：压缩在压力路径上经 :304 取模型信息 ⇒ 若该路由没有提供上下文窗口（你实测 info.context === undefined）⇒ 规格推导失败 ⇒ :160/:166 抛 TargetPressureConfigError ⇒ 压缩中止、请求原样发出、被网关 400 拒绝。

2. ⭐ 这条正好证实了我此前在另一条帖子里的推断

我在另一条（#8245：切到第三方中转模型后无法压缩）里给出的推断是：

压缩规格由目标模型的上下文窗口推导（config.ts:153 的 resolveCompactSpec 接收 contextWindow，且 :159 校验它必须是正整数）⇒ 中转路由没有这个值 ⇒ 规格推导不出来 ⇒ 不压缩，但仍按已记录模型判溢出。

⇒ 你这条把它落到了确切调用与确切异常上（resolveModelInfo → info.context === undefined → TargetPressureConfigError）。⇒ 建议两条互引：一条给"为什么（缺字段）"，一条给"在哪一步（:304 → config.ts:160/:166）"。

3. ⇒ 诉求（三条，第二条是关键）

1. 路由声明的 contextWindow 必须真正进入 resolveModelInfo（你已显式声明，但它没被读进来 ⇒ 这本身就是该修的缺陷）；
2. 缺字段时不得静默失效：应当明确报"该路由缺少上下文窗口，自动压缩不可用"，而不是中止压缩后让请求撞 400；
3. UI 文案必须与真实原因一致：现在显示"额度已用尽"，而网关真实响应是 400（你说"额度已用尽"是误报）⇒ 这会把人引向完全错误的方向（去充值）。

第 3 条成本最低、收益最大：把网关的原始 400 呈现出来，用户立刻能看到真实原因。

4. 请补三样

1. provider.models[] 里那段声明原文（contextWindow / maxTokens 的实际字段名与位置）⇒ 这是"声明了但没被读到"的直接证据；
2. TargetPressureConfigError 的完整消息（它会点出缺什么）；
3. 版本：你写 0.2.0-rc.2 ⇒ 请确认 0.2.1-alpha.1 是否仍如此（我在最新 HEAD 上核到 :304/:160/:166 均仍在）。

5. 一条边界

我确认的是调用点、异常类与抛出位置（逐行核对）。"声明的 contextWindow 未进入 resolveModelInfo"这一因果以你补的声明原文与错误消息为准——我没有你的路由配置。

[jiongguo001]

三样都补齐了，逐条对应你的 4.4。

1. provider.models[] 声明原文

~/.dsh/profiles/desktop/cordis.patch.yml 第 94-110 行原样摘录（这是当前配置，已无 intern-ai——那批路由后来由 dsh-0-tools 插件接管并改写了；openrouter-free 这条仍在，字段结构完全同型）：

- id: llm-pi-ai
  name: "@deepseek-ai/dsh-llm-pi-ai"
  config:
    providers:
      openrouter-free:
        apiKeyEnv: OPENROUTER_API_KEY
        models:
          - id: openrouter/auto
            name: OpenRouter 免费池（自动挑选）
            input:
              - text
              - image
            contextWindow: 200000        # ← 显式声明
            maxTokens: 8192
        displayName: OpenRouter Free
        api: openai-completions
        baseURL: https://openrouter.ai/api/v1
        compat:
          thinkingFormat: openrouter

出问题的 intern-ai 路由当时是这样写的（api/baseURL/apiKeyEnv 同上，6 个模型每个都带 contextWindow）：

      intern-ai:
        apiKeyEnv: INTERN_AI_API_KEY
        api: openai-completions
        baseURL: https://discovery-api.intern-ai.org.cn/v1
        models:
          - id: deepseek-v4-pro-0813
            name: InternAI/deepseek-v4-pro-0813
            contextWindow: 1048576
            maxTokens: 65536
            input: [text]
          # …另 5 个，每个都显式给了 contextWindow / maxTokens

字段名就是 contextWindow 与 maxTokens，位于 providers.<id>.models[] 的每个元素内，与 id/name/input 同级。

2. TargetPressureConfigError 的完整消息

我没有 DSH 的运行时日志留存，所以拿不到逐字消息；能确认的是报错文案本身指向了同一个缺失字段——config.ts 里抛出的那句会点名 targetKey：

compaction-basic: no context capacity for intern-ai/deepseek-v4-pro-0813; configure contextWindow on that adapter model

⚠️ 我要说明来源：这句话是异常消息模板，是我在 asar 里读到的字符串，不是从日志里抓的。我在原始报告里也标注过这一点。

3. 版本核实

我这台跑的是 0.2.0-rc.2（DeepSeek Harness.exe 的 FileVersion 实测确认）。

关于 0.2.1-alpha.1：你在 HEAD（dsh-v0.2.1-alpha.1）核到 :304 / :160 / :166 均仍在——与我读 0.2.0-rc.2 的 asar 得到的结论一致（我在 dsh-compaction-basic/lib/index.js 里定位到的是 :936 的 resolveModelInfo 与 :939 的 info.context === void 0 抛错，行号因打包偏移不同，逻辑形状一致）。所以这不是 rc.2 的回归，两个版本都存在。

npm 上 @deepseek-ai/dsh-web-app 现有 0.2.1-alpha.1 / 0.2.1-alpha.2，我还没升到 alpha 验证。

---

关于你的第 2 点（互引 #8245）

同意互引。补一条我这边的独立观测，可能对定位有用：

网关的 /v1/models 返回 OpenRouter 风格嵌套 schema，顶层没有 context_length：

"input_modalities": [{"type":"text",
  "supported_inputs":{"max_context_length":{"value":1048576,"unit":"token"}}}],
"output_modalities": [{"type":"text","max_length":{"value":1048576,"unit":"token"}}]

DSH 的模型发现走 GET {baseURL}/models 并期待扁平字段，读不到 ⇒ 必须手填 contextWindow。而手填的值又没进入 resolveModelInfo ⇒ 正好构成死结："必须手填"与"手填无效"同时成立。

我实测该网关在 40 万 token 时仍返回 HTTP 200（不拦），105 万才返回 400 estimated input tokens exceed the model's context limit——即网关侧也不拦到最后一刻，压缩是唯一的防线。

关于你的第 3 点（诉求）

第 3 条我同意是成本最低、收益最大。不过补充一个实测数据，可能会影响优先级判断：

我把网关 400 的响应体喂给 @deepseek-ai/dsh-llm 的 isQuotaExceededError（5 条正则），结果是 全部不命中；而上下文超限正则命中 3 条。

也就是说：UI 显示"额度已用尽"这一层，不是网关错误文案被误匹配造成的——更可能是压缩抛 TargetPressureConfigError 之后，外层的错误呈现把这类异常兜底成了 message.failure.quota。

如果成立，那么修 UI 文案得同时处理"压缩抛错"这一支，单独改呈现层可能覆盖不全。这是我实测能提供的边界，供你判断。

---

手动 /compact 不受影响（dsh-command-compact 不经 resolveModelInfo），但对高熵内容会话会失败——我这边的实测是报 Compaction could not produce a useful summary（config.ts 的 "summary" 码），因为摘要比原文还大。供参考。