模型列表里有，为什么还是不能用：ID、别名与能力分开查
把令牌可见模型、客户端显示名、实际请求 ID 和能力声明分开核对。用同一把 Key 查询列表，再按聊天、工具和多轮任务逐项验收。
下拉框能选到模型，发送消息却报 model not found；文字能回，图片或工具又失败。遇到这些情况，要把四件事分开：令牌能看见的 ID、客户端显示的名称、实际发出的 ID，以及这条调用路径支持的能力。
本文于 2026 年 11 月 10 日核对本站模型接口、Open WebUI 当前模型工作区文档，以及最新稳定版 v0.13.3 发布记录。当前网页文档可能比正式版更早介绍新功能，具体按钮以安装版本为准。本文不提供跨供应商的静态能力大全。
旧名称还可能在服务端自动路由到新型号。以 Gemini 的 2026 年 12 月迁移为例，模型字符串、请求参数和工具往返需要分别验证，不能只等列表刷新。
先用同一把 Key，向同一个地址拿列表
控制台、桌面客户端和服务端环境变量里可能放着不同凭据。用管理账号看到模型，不能证明某个受限令牌也能调用。先从连接基础确认当前工具实际使用的域名和凭据来源，在自己可信的终端中查询：
curl --fail-with-body --silent --show-error \
https://api.nbility.ai/v1/models \
-H "Authorization: Bearer $NBILITY_API_KEY" \
--output models.json
jq -r '.data[].id' models.json | sort
不要开 curl -v 后把整段输出发到群里。使用专用令牌，文件也只保存在需要的地方。本文核对了命令和本站接口说明，没有使用读者的账户运行查询。
模型列表 API返回当前凭据可见的模型。目录与客户端缓存可能更新不同步；查到 ID 后原样使用，不自行补供应商前缀、删日期后缀或换大小写。列表缺失时先查令牌范围与服务配置，不要靠连续尝试相似名字绕过去。
显示名可以是包装，不能当成上游身份凭证
Open WebUI 模型工作区允许在基础模型之上配置提示词、知识库、工具与参数。因此名为“代码审查助手”的项目，可能是一个基础模型加一组预设。它的显示名、工作区 ID 与实际发给远端的模型标识，需要沿配置对应起来。
排查时记录三列就够：
| 位置 | 应核对的值 | 它不能证明什么 |
|---|---|---|
| 界面 | 当前选择的显示名或预设 | 远端实际收到的 ID |
| 客户端配置 | 基础模型、连接、覆盖参数 | 上游接受了所有参数 |
| 请求记录 | 目标路径和发送的模型 ID | 供应商内部所有路由细节 |
模型自己回答“我是什么型号”也不可靠，它可能受系统提示、角色卡或训练内容影响。若怀疑结果变化，应该记录任务与配置，按效果变化排查继续检查，而不是让模型给自己作证。
能力开关是一项声明，还要跑对应任务
在客户端勾上 Vision 或 Tools，通常只是告诉应用可以准备这类请求。它没有给远端模型添加新能力，也不会自动完成协议转换。反过来，模型具备某项能力，客户端关闭入口或没有正确发送字段，也可能用不上。
按自己的用途验证，不必把所有功能都开启：
- 文本：新会话发一个短请求，检查完整可见回答。
- 图片理解：只用公开测试图片，检查能否回答图中特有的信息，避免问题本身泄露答案。
- 工具：使用无副作用的工具，检查参数、返回结果和结果后的继续回答。
- 多轮任务：保留必要历史，再发一个依赖前一步结果的问题。
只读工具测试没有通过，就不要在这条路径上直接启用文件删除、发送消息或数据库写入。JSON 输出、实时语音等功能也有各自的接口要求，不能从“聊天成功”外推。
只有某个客户端失败时，保留最小差异
使用同一凭据、同一模型 ID 和同一协议做最小请求对照。终端短请求正常而应用失败时，检查最终 URL、预设、附加参数、历史消息和解析方式。本站模型说明负责解释能力分类，不替代实际接口验证。
一个近期边界例子是 Open WebUI #33956：作者在 0.13.3 dev 报告某类历史项没有按预期续传，后续参与者提供源码分析与自行测试。查阅时仍 Open。这是特定开发版、协议和多轮场景的报告，本文没有复现，不能把它归纳成“模型不能调用工具”，也不能把评论里的修复说成正式版已发布。
修好后至少重跑原本失败的那一项：工具问题要完成一次工具往返，图片问题要完成图片理解，多轮问题要完成后续一轮。最后在用量日志对齐时间和模型请求；独立工具的执行结果仍要看工具系统自己的记录。
