# Route Lab Validation

> 该文档现在只保留“同 group 多 channel + alias 下沉”失败实验的历史记录。  
> 针对插件前置路由架构的当前正确方向，请改看 [docs/SHADOW_PROVIDER_VALIDATION.md](/home/long/project/sub2api-cn-relay-manager/docs/SHADOW_PROVIDER_VALIDATION.md)。

本文件记录 `asxs + codex2api` 同组双线路实验的最小验证路径。

## 目标

验证以下结论是否成立：

1. 同一个 `group` 下可以挂两条不同 `base_url` 的 GPT 线路
2. 两条线路可以通过不同 `channel` 和不同公开 alias 同时对外暴露
3. 用户进入同一个 group 后，可以稳定看到并调用两条线路

## 实验 pack

- pack 目录：`packs/openai-cn-pack-route-lab`
- provider A：`gpt-asxs-route-lab`
- provider B：`gpt-codex2api-route-lab`

## 实验建模

```text
Group: GPT Shared 路由实验
  Channel: GPT Shared - asxs
    Models:
      - gpt-5.4-asxs -> gpt-5.4
      - gpt-5.4-mini-asxs -> gpt-5.4-mini

  Channel: GPT Shared - codex2api
    Models:
      - gpt-5.4-codex2api -> gpt-5.4
      - gpt-5.4-mini-codex2api -> gpt-5.4-mini
```

## 关键约束

- 两条 provider 的 `group_template.name` 必须完全一致
- 两条 provider 的 `channel_template.name` 必须不同
- 第一轮实验不要把两条线路都暴露成同一个公开模型名
- `codex2api` 当前先按 `https://www.codex2api.com/v1` 作为假设 API 根地址；若 preview 失败，需要先校正

## 建议验证顺序

1. 静态检查 pack
2. 导入 `gpt-asxs-route-lab`
3. 记录 `group_id / channel_id / account_ids`
4. 导入 `gpt-codex2api-route-lab`
5. 再记录 `group_id / channel_id / account_ids`
6. 核对：
   - 两次导入后的 `group_id` 应相同
   - `channel_id` 应不同
   - 两组 account 的 `base_url` 应分别落到 `asxs` 与 `codex2api`
7. 用同一个 group 下的用户 key 验证：
   - `GET /v1/models`
   - `POST /v1/chat/completions`

## 成功标准

- 同一个 group 下同时存在两条独立 channel
- `gpt-5.4-asxs` 命中 `asxs`
- `gpt-5.4-codex2api` 命中 `codex2api`
- 关闭其中一条上游后，另一条 alias 仍能独立工作

## 2026-05-28 remote43 实际结果

- `gpt-asxs-route-lab` 已在 remote43 完成真实导入：
  - artifact：`artifacts/real-host-acceptance/20260528_142205_remote43_gpt-asxs-route-lab_key_import/21-summary.json`
  - 导入资源：`group_id=8`、`channel_id=7`、`plan_id=7`、`account_id=9`
  - upstream `asxs` 的 `/models` 与 `/chat/completions` 为 `200`
- `gpt-codex2api-route-lab` 在尝试复用同一 group 时被宿主拒绝：
  - artifact：`artifacts/real-host-acceptance/20260528_142320_remote43_gpt-codex2api-route-lab_key_import/03-import.body.json`
  - 宿主返回 `409 GROUP_ALREADY_IN_CHANNEL`
  - 错误消息：`one or more groups already belong to another channel`
- 因此这轮实验已经证明：
  - 当前宿主允许一个 provider 创建 `group + channel`
  - 但**不允许第二个 channel 复用同一个 group**
  - 所以“group = 模型族，channel = 官方/中转线路”的方案 B，在当前 sub2api 宿主约束下不能直接落地

## 第二轮暂不做

第二轮是把两条线路都暴露成同一个公开模型名，例如都叫 `gpt-5.4`。

这一步当前不建议直接做，因为：

- 现有服务端有同模型冲突校验
- 即使绕过校验，也还缺显式的 route policy，无法保证官方 / 中转的命中优先级和 fallback 语义