支持 OpenCode Go 的最新模型列表

[askdkc]

OpenCode Go 中可用的模型始终会更新在以下列表中：

https://opencode.ai/zen/go/v1/models

DSH 已经预先提供了与 OpenCode Go 集成的配置，这一点非常棒。

但是，目前 DSH 中显示的模型列表已经过时，基本无法使用。

希望能够修改这一部分，使模型列表始终参考上述接口，并自动显示最新的可用模型。

请支持让 OpenCode Go 的模型列表始终与以下地址保持同步：

https://opencode.ai/zen/go/v1/models

[yinsang0910-star]

我把「为什么模型列表不会跟着 https://opencode.ai/zen/go/v1/models 走」定位到了——不是 UI 没刷新，是 discoverModels() 压根没发这次请求；顺带给出可用的本地补丁与实测数据。

根因（packages/llm/llm-pi-ai/src/discovery.ts）

discoverModels() 开头对「pi-ai 内置目录认识的路由」直接返回目录，完全不发网络请求：

if (request.provider !== void 0) {
  const installed = catalogModels(request.provider);
  if (installed.size > 0) return [...installed.values()].map(…)   // ← 直接返回内置目录
}

（发行包对应 lib/index.js 2288–2296 行；discovery.d.ts 的注释写明这是有意设计：pi-ai 的注册表对其自家 provider 视为权威列表。）

于是 Settings → 模型 → 对 opencode-go 点 Fetch available models，返回的永远是 pi-ai 0.85.1 冻结的那 27 个模型；OpenCode 之后新增的模型永不出现。

实测（本机直连网关，Bearer + 浏览器 UA）

• GET https://opencode.ai/zen/go/v1/models → 200，37 个 id
• pi-ai 0.85.1 内置目录 → 27 个
• 差的 10 个：deepseek-flash、deepseek-v4.1-flash、glm-5、grok-4.5、hy3-preview、kimi-k2.5、mimo-v2-omni、mimo-v2-pro、minimax-m2.5、qwen3.5-plus

我们的本地补丁（仅供参考实现，未改上游）

只对 OpenCode 路由跳过该短路，其余 provider 行为一行不变：

1. 改由 {baseURL}/models 真实请求（列目录按 openai-completions 发）；
2. 端点要取目录里 api === "openai-completions" 那条的 baseUrl——取第一条可能命中 anthropic 协议模型，其 base 少一个 /v1，会 404（我们第一版就踩了这个）；
3. 目录里已有的模型用内置元数据回填 contextWindow / maxTokens（列表接口不披露这两项）；
4. 网关不可达时回落到内置目录列表，而不是返回空列表。

实测合并结果：37 条、含 deepseek-v4.1-flash、deepseek-v4-flash 保留 1000000 / 384000、非 OpenCode 路由路径与行为不变。

另一件必须一起解决的事：发现出来 ≠ 能用

即使列表改成实时的，用户仍然用不了目录外的新模型。src/catalog.ts 的 resolveRouteModels()：

const api = request.api ?? base?.api ?? routeApi;   // routeApi = 目录共享协议；多协议时为 undefined
if (api === void 0) invalid(provider, `model "…" needs an api; …`)

路由级 api 的优先级高于每个模型自己的协议。所以为了声明 deepseek-v4.1-flash 而给 opencode-go 设 api，会把同路由里 anthropic-messages（minimax-m3、qwen3.8-flash）和 openai-responses（gpt-5.6-luna、grok-4.6…）的模型协议一起改掉。目前唯一可行做法是另开一条非目录路由放这些新模型（api + baseURL + 显式 models 列表）。

如果希望「接口里有的模型，发现后就能直接采纳使用」，建议 profile 支持 per-model api（或允许在目录路由上追加模型条目）。这也许比单纯同步列表更值得做，否则每次 pi-ai 发版前新增的模型都得走「发现 → 手工建路由」两步。

[askdkc]

我认为这里仍然没有抓住根本问题。

你现在解决的只是：

为什么新模型没有出现在模型列表里。

但真正的问题不是“模型发现失败”，而是 DeepSeek Harness 把静态 catalog 同时当成了模型元数据、协议定义和路由真相源。

这才是根本原因。

现在的设计大致是：

provider / route
↓
static catalog
↓
api protocol
↓
model

所以当一个 provider 下同时存在：

OpenAI Completions
OpenAI Responses
Anthropic Messages

等不同协议的模型时，route-level api 这个抽象本身就已经不成立了。

这不是简单跳过一次 early return，或者给 /models 增加一次 HTTP 请求就能解决的问题。

即使你成功从：

GET /v1/models

发现了 37 个模型，系统仍然不知道：

deepseek-v4.1-flash 应该使用什么协议？
grok-4.5 应该使用什么协议？
minimax-m3 应该使用什么协议？
qwen3.8-flash 应该使用什么协议？

如果最终还需要人工创建额外 route、手动指定 api、等待 pi-ai 更新 catalog，那么所谓“动态模型发现”实际上没有真正完成。

真正应该解决的是：

model discovery
↓
per-model protocol resolution
↓
per-model capability resolution
↓
runtime route generation
↓
static catalog fallback

而不是：

static catalog
↓
发现 catalog 过期
↓
补一个 /models 请求
↓
发现新模型不能直接运行
↓
再手工配置另一个 route

这只是把问题从“看不到模型”变成了“看得到但不能可靠使用”。

我认为至少应该做三件事：

1. 把 api 从 route-level 下移到 model-level

应该允许类似：

{
provider: "opencode-go",
model: "deepseek-v4.1-flash",
api: "openai-completions",
baseURL: "...",
}

而不是一个 route 强制所有模型共享同一种协议。

2. 静态 catalog 不应该再是唯一真相源

静态 catalog 应该退化为：

metadata cache
compatibility fallback
offline fallback

而不是决定一个远程模型是否“存在”以及是否“可用”。

远程 provider 才应该是模型可用性的主要来源。

3. 模型发现必须和运行时路由生成连在一起

如果发现了一个模型，却不能自动生成正确的执行路径，那就不能叫完整的 discovery。

真正的目标应该是：

provider 发布新模型
↓
Harness 自动发现
↓
自动确定协议 / 能力
↓
立即可用

而不是：

provider 发布新模型
↓
Harness 能看到模型
↓
但 catalog 里没有
↓
用户手动补配置
↓
或者等待下一个版本

所以目前这个 patch 可以作为临时 workaround，但不能称为根本修复。

根本问题是：

当前架构把“provider route”和“model transport protocol”错误地绑定在了一起，并且过度依赖静态 catalog。

如果不改变这个数据模型，那么以后每次 OpenCode、OpenRouter 或其他聚合 provider 增加异构协议的新模型时，同样的问题还会再次发生。

应该修的是这个抽象，而不是继续给 catalog 同步逻辑打补丁。