使用中转站时，model not found 是最常见也最容易误判的错误。很多人以为是本地工具坏了，实际上是中转站没有识别这个模型名。
模型名有三层含义
第一层是工具发出来的模型名，比如某个 CLI 或插件请求的 Model ID。第二层是中转站后台显示的模型别名。第三层是上游真正调用的模型。
这三层如果没有对应关系，就会出现 model not found。
为什么普通聊天能用，代码工具不能用
普通聊天通常只请求一个主模型。但 AI 编程工具可能请求代码模型、审批模型、嵌入模型、工具调用模型，甚至在不同阶段使用不同模型名。中转站只配了主模型时，就会出现某些功能正常、某些功能失败。
站长应该怎么配置
- 保留原始请求模型名，方便查日志；
- 为常用工具建立模型别名；
- 把别名映射到稳定上游模型；
- 对不支持的模型返回清晰错误，不要只给 500；
- 为 Codex、Claude Code、Cline、Roo Code 分别测试真实任务。
用户怎么排查
用户侧最有效的方法是看报错出现在哪个阶段。如果普通问答可以，执行工具或授权时失败，就要怀疑特殊模型名。把错误时间点发给中转站管理员，让对方查日志里的 model 字段。
如果你只是想稳定使用 Claude Code、Codex CLI、Gemini CLI、Cline、Roo Code 这类 AI 编程工具，不想自己维护模型映射、网络转发和错误排查，可以了解 YYLX.IO 鱼鱼连线。对普通用户来说，最省时间的方案往往不是自己搭一整套网关，而是直接使用已经整理好接入方式的 AI 中转站。
总结
模型映射是中转站稳定性的核心。真正好用的中转站，不只是能转发请求，还要知道各种 AI 工具会请求哪些模型名。
发表回复