模型发现对已安装 catalog 提供方忽略了显式 baseURL（OpenAI 兼容网关场景）

[Wzh0718]

问题概述

Web GUI「设置 → 模型 → 获取可用模型」中，当提供方路由既点名了 pi-ai 已安装 catalog 提供方（如 openai）、又配置了显式自定义 baseURL（如某个 OpenAI 兼容网关/代理）时，模型发现会直接短路返回内置静态模型目录，从不调用 {baseURL}/models。选择框因此展示的是注册表的模型，而不是该端点真实的模型列表。

复现

将某个 catalog 提供方路由指向网关：

llm-pi-ai:
  providers:
    openai:
      baseURL: https://my-gateway.example/v1
      apiKeyEnv: OPENAI_API_KEY

打开「设置 → 模型 → 编辑 openai 提供方 → 获取可用模型」。

期望： Host 发起 GET https://my-gateway.example/v1/models，并提供端点公布的模型。

实际： 直接返回 openai 的 pi-ai 内置目录，完全没有网络请求（dsh-llm-pi-ai 的 discoverModels 在 baseURL 检查之前就返回了 catalogModels(provider)）。

为什么重要

把 catalog 提供方 id 复用于兼容网关是文档明确的配置模式（"a route naming an installed pi-ai provider inherits its endpoint… as defaults"），而 baseURL 正是对该默认值的逐字段覆盖。网关实际服务的模型集往往与注册表不同（镜像部署、企业代理、CLIProxyAPI 类聚合器）。当前的优先级会让模型页推荐端点无法服务的模型，并隐藏端点实际可用的模型。

建议修复

让草稿中显式的 baseURL 优先于已安装目录：

• 携带 baseURL 的草稿在 {baseURL}/models（或协议自身的列表路径）被询问，无论提供方是否在已安装目录中。
• 只有完全没有点名端点的草稿才由已安装目录回答（保留离线路径及其容量元数据）。
• wire 语义、已存凭据/header 解析、解析器与失败码均不变；仅调整分支顺序。

[argszero]

先确认：你的报告在 master d347e70 上属实，而且这处短路是有意的、带测试钉死的设计，不是疏漏——这决定了修复应落在"覆盖判别"，而不是简单调换分支顺序。

源级事实

• llm/llm-pi-ai/src/discovery.ts:273-285：discoverModels 进门先看 request.provider——只要点名已安装 catalog 提供方（catalogModels(provider).size > 0），就无条件返回目录模型并 map 成 {id,name,contextWindow,maxTokens}，全程不读 baseURL。注释原文即设计意图："A catalog route already has its answer, and a better one: the installed entries carry context windows and output caps no listing endpoint reports."
• llm/llm-pi-ai/tests/discovery.spec.ts:77-89 把该行为钉死：{ provider: 'deepseek', baseURL: server.url } 断言返回内置目录、且 server.paths 为空（零网络调用），注释 "pi-ai's own registry is the authority for its own providers"。
• 客户端是如实传参的：ui-settings-models ProviderEditor.tsx:225-242 的 probe = draft.baseURL ?? fallback.baseURL（fallback 是存量路由配置节，stock 路由没有 baseURL 键——输入框占位符走 baseUrlDefault 文案，:415-418），ModelListEditor.tsx:233-238 把非空 baseURL 放进请求。所以 stock 路由的发现请求里根本没有 baseURL 字段，目录短路在那种情形下是对的；只有路由显式声明了端点（你 yaml 里的网关）请求才会带 baseURL——然后被目录短路无视。你踩的正是这个组合。

为什么"出现 baseURL 就必走 live"的朴素规则不够

目录答案不是"没网的兜底"，它比 listing 更肥：contextWindow/maxTokens 是绝大多数端点不披露的（discovery.spec.ts:110-136 显示只有带 context_length/max_output_tokens 等可选字段的端点才会被解析，多数 /models 只有 id）。无条件改 live 会：

1. 让显式写了官方端点的人（如 baseURL: https://api.openai.com/v1 写进配置）每次打开模型页都打网络，还丢掉容量元数据；
2. 端点 401/断网时从"显示目录"变成报错——对纯 stock 场景是体验倒退。

判别维度应是**"请求携带的 baseURL 是否构成对目录默认的显式覆盖"**，而不是"有没有 baseURL"。好消息是上面已证：UI 流程里 stock 路由不带 baseURL，所以"请求带 baseURL"≈"路由显式声明端点"，判别可以安全落在服务端这一条上。

建议方向（你的三条基本成立，补一个保容量的合并步）

• provider 已安装 + 请求无 baseURL → 目录（现状不变：离线 + 容量）。
• provider 已安装 + 请求带 baseURL → 视为端点覆盖：询问 {baseURL}/models 得到 set，再对与目录相交的 id 用目录回填 contextWindow/maxTokens（listing 报 set、catalog 报 metadata，二者不冲突；也保住注释里 "a better one" 的容量初衷）。
• provider 未安装 + 带 baseURL → live（现状不变）。
• 失败语义：网关拒绝应抛现有 DISCOVERY_FAILED，不要静默回落目录——静默回落正是今天误导的来源。
• 安全网已存在：UI 采纳候选时 "Everything already configured starts unchecked"（ModelListEditor.tsx:249-251）保证不会静默覆盖用户修正过的容量，回填合并可以放心做。

家族关联：这条与 #5837（custom provider 静默 text-only）同处一轴——"catalog 默认 vs 路由显式声明，谁优先"。两处都是目录在遮蔽 per-route 显式配置（#5837 是声明式 input 走 catalog.ts 的 declaredInput ?? base?.input ?? defaultInput 链）。#5837 方向已定（显式声明优先、目录作基底），此修复应复用同一语义，避免两处分叉。

插件面：该分支位于 llm-pi-ai 核心 discovery 与 ui-settings-models 探针构造，registerModelDiscovery 按 settingsNs 单槽，插件无法重排此短路；属 upstream-fix 候选（第三方只能像 modlens 那样自建 provider 列表，绕不过这条路）。