同名 provider 冲突会让模型路由漂移

更新于 2026-08-10

**自定义 provider 与内置 provider 用了同一个 id 时，一个「只带了模型名、没带 provider」的会话在解析归属时会命中内置的那个，于是模型名被规范化成 `provider/model` 并路由到内置后端——请求发去了别处，而配置看起来完全没变。**

触发链

  1. 导入外部会话（原生 Codex → 平台）时只导入了消息，provider_id 留空，模型字段还是原生的裸名。
  2. 从该会话派生新对话时，平台要把裸名解析回具体供应商。
  3. 此时若自定义供应商和内置供应商同名（都叫 chatgpt），解析会命中内置的那个。
  4. 模型名被规范化成带前缀的完整 ID，请求发给内置后端而不是用户自己的中转 → 报错。

判据：用报错措辞判断请求实际落在谁那里

这是本条最有价值的可迁移动作 —— 同一类 404，措辞能区分后端：

措辞说明请求发到了
not supported by any configured account in this group官方后端（措辞里带「account / group」这类官方账号体系词汇）
Invalid model name passed in model=...中转/兼容网关（措辞只谈模型名）

所以不要只看状态码。404/400 本身不告诉你落在哪一层，错误文案才告诉你。

规避

  • 自定义 provider 起一个不与内置重名的 id（如用自己中转的名字），这是成本最低的根治。
  • 导入/迁移来的会话要显式重绑 provider，不要依赖自动解析。
  • 派生新对话（引用卡片 → 新建）时，确认新会话继承的 provider 是不是你期望的那个。

相关