Files
sub2api-cn-relay-manager/docs/PROVIDER_VALIDATION_MATRIX.md
2026-05-27 07:55:49 +08:00

356 lines
17 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Provider Validation Matrix
日期2026-05-26
## 目的
这份文档用于回答 4 个问题:
1. 当前仓库已经内置了哪些官方 provider 模板
2. 哪些 provider 已经具备本机可用的官方 key
3. 哪些 provider 已经完成了真实 fresh-host live 验收
4. 哪些 provider 仍然卡在缺 key、缺模板或上游 quota / rate-limit
它不是 gate 文档,也不替代 `REAL_HOST_ACCEPTANCE_RUNBOOK.md`
分工如下:
- `docs/SOURCE_OF_TRUTH.md`
- 回答当前项目整体 gate
- 本文
- 回答 provider 维度的模板覆盖度、凭据覆盖度、live 验收覆盖度
- `docs/PROVIDER_ONBOARDING_PLAYBOOK.md`
- 回答后续如何继续补模板和验收
## 阅读结论
先说结论:
1. **首批 10 个官方 provider 模板已经落库,且 pack 已继续补入高频中转模板**
- 当前 `openai-cn-pack` 已内置 Qwen、DeepSeek、GLM、Kimi、MiniMax、Step 的 10 个官方模板
- 同时已补入 `openai-zhongzhuan``minimax-53hk` 两条高频中转模板
2. **还不能宣称“国内 10 大模型都已逐个真实验证通过”**
- 当前最大的阻断不是控制面代码,而是 **官方 key 不齐**
- 其次是部分官方 key 即便存在,也会在真实 completion 阶段命中 `429 quota/rate-limit`
3. **official live 验收不再只有 MiniMax 一条**
- `minimax-m2-7-official`live 已完成,但当前验证 key 命中 upstream `429`
- `deepseek-chat-official`remote43 latest run 已完成 host/import/access/completion 验收,但 provider 仍是 `partially_succeeded/degraded`
- DeepSeek 当前真实缺口不是 gateway completion 不通,而是 upstream catalog / account probe 与 manifest 仍有偏差
4. **Qwen / GLM / Step / Kimi 官方路线当前仍没有本机可用官方 key 证据**
- 所以它们目前只能算“模板已就绪,未完成 live 验收”
5. **remote43 最新新增两条中转路线已闭环到 ready**
- `openai-zhongzhuan``batch_status=succeeded``provider_status=active`、gateway completion `200`
- `minimax-53hk``batch_status=succeeded``provider_status=active`、gateway completion `200`
- 但它们在 OpenClaw 里暴露的是公网 provider 别名(`tksea-gpt` / `tksea-minimax`),不是直接用 pack 内的 `provider_id`
## 统计口径
### 状态定义
- `模板已就绪`
- `packs/openai-cn-pack/providers/*.json` 已存在
- `checksums.txt` 已更新
- `internal/pack` 回归已通过
- `官方 key 已就绪`
- 本机可确认存在该厂商官方环境变量或等价安全存储引用
- 不等于 key 一定有足够额度
- `live 验收已完成`
- 已在真实 fresh-host 上跑过 provider 级 artifact
- `PASS`
- host `/v1/models``/v1/chat/completions` 均通过
- upstream `/chat/completions` 也通过
- `PARTIAL`
- import / host `/v1/models` / host `/v1/chat/completions` 已通过
- 但 provider 仍存在 account probe、upstream model catalog 或 manifest 映射层偏差
- 当前不能写成 fully active
- `BLOCKED_BY_KEY`
- 没有官方 key无法开始 live 验收
- `BLOCKED_BY_QUOTA`
- 有 key但 upstream 或 host completion 命中 `429/403` 等额度问题
## A. 已内置的 10 个官方 provider 模板
| 分类 | provider_id | 官方 base_url | smoke_test_model | 模板状态 | 本机官方 key | live 验收状态 | 当前结论 |
| ----------------- | ---------------------------- | --------------------------------------------------- | ------------------------ | -------- | ----------------------------------------------------------- | ------------------ | ------------------ |
| 通义千问 | `qwen-official` | `https://dashscope.aliyuncs.com/compatible-mode/v1` | `qwen-plus` | 已就绪 | 未发现 `DASHSCOPE_API_KEY` | 未开始 | `BLOCKED_BY_KEY` |
| 通义千问 Coder | `qwen-coder-official` | `https://dashscope.aliyuncs.com/compatible-mode/v1` | `qwen3-coder-plus` | 已就绪 | 未发现 `DASHSCOPE_API_KEY` | 未开始 | `BLOCKED_BY_KEY` |
| DeepSeek Chat | `deepseek-chat-official` | `https://api.deepseek.com/v1` | `deepseek-chat` | 已就绪 | 已发现可跑 live 的 DeepSeek 官方 key | 已完成(部分成功) | `PARTIAL` |
| DeepSeek Reasoner | `deepseek-reasoner-official` | `https://api.deepseek.com/v1` | `deepseek-reasoner` | 已就绪 | 未发现可验证的官方 key | 未开始 | `BLOCKED_BY_KEY` |
| 智谱 GLM 5.1 | `glm-5-1-official` | `https://open.bigmodel.cn/api/paas/v4` | `glm-5.1` | 已就绪 | 未发现 `ZHIPU_API_KEY`/`BIGMODEL_API_KEY` | 未开始 | `BLOCKED_BY_KEY` |
| 智谱 GLM 4.7 | `glm-4-7-official` | `https://open.bigmodel.cn/api/paas/v4` | `glm-4.7` | 已就绪 | 未发现 `ZHIPU_API_KEY`/`BIGMODEL_API_KEY` | 未开始 | `BLOCKED_BY_KEY` |
| Kimi K2.5 | `kimi-k2-5-official` | `https://api.moonshot.cn/v1` | `kimi-k2.5` | 已就绪 | 未发现 `MOONSHOT_API_KEY`;仅有中转 `XUANSUAN_KIMI_API_KEY` | 未开始 | `BLOCKED_BY_KEY` |
| Kimi K2 Thinking | `kimi-k2-thinking-official` | `https://api.moonshot.cn/v1` | `kimi-k2-thinking` | 已就绪 | 未发现 `MOONSHOT_API_KEY`;仅有中转 `XUANSUAN_KIMI_API_KEY` | 未开始 | `BLOCKED_BY_KEY` |
| MiniMax M2.7 | `minimax-m2-7-official` | `https://api.minimaxi.com/v1` | `MiniMax-M2.7-highspeed` | 已就绪 | 已发现 `MINIMAX_CN_API_KEY` | 已完成 | `BLOCKED_BY_QUOTA` |
| Step 3.5 Flash | `step-3-5-flash-official` | `https://api.stepfun.com/v1` | `step-3.5-flash` | 已就绪 | 未发现 `STEP_API_KEY` | 未开始 | `BLOCKED_BY_KEY` |
## B. 官方模板外的优先扩展厂商
这些更接近你说的“六小龙 + BAT + 小米等”的完整矩阵,但当前仓库里还没有正式 provider 模板,或者没有本机 key
| 厂商/路线 | 当前模板状态 | 当前 key 状态 | 建议动作 |
| ------------------- | ------------ | ----------------------- | ------------------------------------------- |
| 腾讯混元官方 | 未落模板 | 未发现官方 key | 先补模板,再补 `HUNYUAN` / 腾讯云对应 key |
| 豆包 / 火山方舟官方 | 未落模板 | 未发现官方 key | 先补模板,再补 `ARK` / `VOLCENGINE_API_KEY` |
| 百川官方 | 未落模板 | 未发现官方 key | 先补模板,再补官方 key |
| 零一万物 Yi 官方 | 未落模板 | 未发现官方 key | 先补模板,再补官方 key |
| 小米 MiMo 官方 | 未落模板 | 未发现 `XIAOMI_API_KEY` | 先补模板,再补官方 key |
说明:
- 当前这批未落模板厂商,不代表项目不支持
- 只代表这轮仓库里还没有为它们建立正式 provider manifest
- 一旦补模板,后续导入路径仍然可以复用当前 pack 驱动模式
## B1. 已落地的中转 / 非官方高频模板
| 路线 | provider_id | base_url | smoke_test_model | remote43 latest 状态 | OpenClaw 口径 | 当前结论 |
| ----------------- | ------------------- | ------------------------- | ------------------------ | ----------------------------------------- | ----------------------------------------------------------------- | -------- |
| OpenAI 中转 | `openai-zhongzhuan` | `https://api.asxs.top/v1` | `gpt-5.4` | `succeeded / active / subscription_ready` | 通过 `tksea-gpt` 暴露 | `PASS` |
| MiniMax 53hk 中转 | `minimax-53hk` | `https://api.53hk.cn/v1` | `MiniMax-M2.7-highspeed` | `succeeded / active / subscription_ready` | 通过 `tksea-minimax` 暴露;本机也保留 `minimax53hk` 直连 provider | `PASS` |
说明:
- 这两条路线都不是“官方 provider 模板”统计口径的一部分。
- 但它们已经有 2026-05-26 的 remote43 latest artifact可作为当前最强的中转线路验收证据。
## C. 当前已确认的本机凭据盘点
### 已确认存在的厂商环境变量
从当前本机配置里能确认到这些变量名:
- `MINIMAX_CN_API_KEY`
- `MINIMAX_API_KEY`
- `MINIMAX_ZHONGZHUAN_API_KEY`
- `MINIMAX_53HK_API_KEY`
- `XUANSUAN_KIMI_API_KEY`
- `DEEPSEEK_API_KEY`
- `DEEPSEEK_2166_API_KEY`
### 只能说明什么
它们只能说明:
1. 本机至少存在 MiniMax / Kimi 中转 / DeepSeek 中转路线
2. 当前 DeepSeek 官方 live artifact 也说明:至少存在一把可跑到 upstream `/chat/completions=200` 的官方 DeepSeek key
3. 但这不等于 OpenClaw 本地已配置对应的 `deepseek-official` auth profile
### 当前缺失的官方 key 信号
当前没有在本机配置中确认到这些官方变量名:
- `DASHSCOPE_API_KEY`
- `MOONSHOT_API_KEY`
- `ZHIPU_API_KEY`
- `BIGMODEL_API_KEY`
- `STEP_API_KEY`
- `XIAOMI_API_KEY`
- `VOLCENGINE_API_KEY`
这也是为什么这轮不能把“Qwen/GLM/Step/Kimi 官方路线”都逐个跑完。
## D. 已完成的 official live 验收
### MiniMax 官方
本轮已实际执行:
- provider`minimax-m2-7-official`
- artifact
- `artifacts/real-host-acceptance/20260521_222212_remote43_minimax-m2-7-official_key_import`
关键结论:
1. host `/v1/models` 已通过,且命中预期模型
2. upstream `/models` 也能返回预期官方模型集合
3. host `/v1/chat/completions` 返回 `429`
4. upstream `/chat/completions` 同样返回 `429`
所以根因不是控制面导入失败,而是:
- 当前官方 MiniMax key 命中 upstream 真实限流/额度问题
证据:
- [21-summary.json](/home/long/project/sub2api-cn-relay-manager/artifacts/real-host-acceptance/20260521_222212_remote43_minimax-m2-7-official_key_import/21-summary.json:1)
- [11-chat.headers.txt](/home/long/project/sub2api-cn-relay-manager/artifacts/real-host-acceptance/20260521_222212_remote43_minimax-m2-7-official_key_import/11-chat.headers.txt:1)
- [19-upstream-chat.headers.txt](/home/long/project/sub2api-cn-relay-manager/artifacts/real-host-acceptance/20260521_222212_remote43_minimax-m2-7-official_key_import/19-upstream-chat.headers.txt:1)
补充说明:
- 同一批次中还暴露了 fresh-host 环境补前置时的历史噪音:
- `api_keys.group_id_fkey` 触发失效 group 外键
- 但最终 summary 已经足够说明真正的 provider-level 主阻断是 `429`
- 因此这轮应归类为:
- 模板就绪
- official key 存在
- live 验收已开始并已拿到真实结论
- 当前状态:`BLOCKED_BY_QUOTA`
### DeepSeek Chat 官方
本轮已实际执行:
- provider`deepseek-chat-official`
- artifact
- `artifacts/real-host-acceptance/20260526_155810_remote43_deepseek_chat_official_multi_model_rootprep`
关键结论:
1. host `/v1/models` 已通过,且命中 `deepseek-chat`
2. host `/v1/chat/completions` 已通过,`completion_status=200`
3. upstream `/chat/completions` 已通过,`upstream_chat_status=200`
4. 但 upstream `/models` 返回的是 `deepseek-v4-flash` / `deepseek-v4-pro`,不是 manifest 里的 `deepseek-chat`
5. batch detail 里 account probe 仍记录 `API returned 404:`,导致该批次最终落成 `partially_succeeded` / `degraded`
所以当前真实状态不是 `BLOCKED_BY_KEY`,而是:
- 数据面已经通
- provider 口径仍需继续校准 upstream model alias / account probe 语义
- 当前状态:`PARTIAL`
证据:
- [21-summary.json](/home/long/project/sub2api-cn-relay-manager/artifacts/real-host-acceptance/20260526_155810_remote43_deepseek_chat_official_multi_model_rootprep/21-summary.json:1)
- [03-import.body.json](/home/long/project/sub2api-cn-relay-manager/artifacts/real-host-acceptance/20260526_155810_remote43_deepseek_chat_official_multi_model_rootprep/03-import.body.json:1)
- [16-batch-detail-final.json](/home/long/project/sub2api-cn-relay-manager/artifacts/real-host-acceptance/20260526_155810_remote43_deepseek_chat_official_multi_model_rootprep/16-batch-detail-final.json:1)
- [18-upstream-models.body.json](/home/long/project/sub2api-cn-relay-manager/artifacts/real-host-acceptance/20260526_155810_remote43_deepseek_chat_official_multi_model_rootprep/18-upstream-models.body.json:1)
## D1. 已完成的中转 live 验收
### OpenAI 中转
- provider`openai-zhongzhuan`
- artifact
- `artifacts/real-host-acceptance/20260526_155548_remote43_openai_zhongzhuan_multi_model_rootprep`
关键结论:
1. `batch_status=succeeded`
2. `provider_status=active`
3. gateway `/v1/models` 返回 `gpt-5.4` / `gpt-5.4-mini`
4. gateway `/v1/chat/completions` 返回 `200`
5. upstream `/models` 命中预期模型集合
6. upstream `/chat/completions` 当前为 `502`,但不影响 host 主链路已经 ready
### MiniMax 53hk 中转
- provider`minimax-53hk`
- artifact
- `artifacts/real-host-acceptance/20260526_155705_remote43_minimax53hk_multi_model_rootprep`
关键结论:
1. `batch_status=succeeded`
2. `provider_status=active`
3. gateway `/v1/models` 返回 `MiniMax-M2.5-highspeed` / `MiniMax-M2.7-highspeed`
4. gateway `/v1/chat/completions` 返回 `200`
5. upstream `/models``/chat/completions` 也都是 `200`
## E. 为什么 Qwen 还没法“直接宣称已验证通过”
`qwen-official` 模板已经存在,后续导入命令也已经标准化;但当前仍缺一条关键前提:
- 本机没有确认到可用的 `DASHSCOPE_API_KEY`
因此 Qwen 当前状态只能写成:
- 模板:已就绪
- 一键导入入口:已就绪
- 官方 live 验收:未开始
- 阻断:`BLOCKED_BY_KEY`
这和“控制面不支持 Qwen”不是一回事。
## F. OpenClaw 本地验收映射说明
remote43 import 通过后OpenClaw 本地不是直接使用 pack 里的 `provider_id`,而是使用公网根域名下已经配置好的最终 provider 别名:
- `openai-zhongzhuan``tksea-gpt`
- `minimax-53hk``tksea-minimax`
- `deepseek-chat-official``deepseek-official`
截至本轮直接实测:
- `openclaw infer model run --local --model "tksea-gpt/gpt-5.4" ...` ✅ PASS
- `openclaw infer model run --local --model "tksea-minimax/MiniMax-M2.7-highspeed" ...` ✅ PASS
- `openclaw infer model run --model "deepseek-official/deepseek-chat" --prompt 'Reply with exactly OK' --json` ✅ PASS已补齐 `deepseek-official:manual` auth profile
因此 `deepseek-chat-official` 的**本机 OpenClaw 最后一跳**已经打通;剩余待重新落 artifact 的,只是 remote43 real-host import 状态从旧的 `PARTIAL` 证据刷新为新一轮 `GREEN` 证据。
## G. 推荐执行顺序
如果目标是把“六小龙 + BAT + 小米等”逐个真实收口,建议按下面顺序继续:
1. 先补官方 key
- `DASHSCOPE_API_KEY`
- `MOONSHOT_API_KEY`
- `ZHIPU_API_KEY``BIGMODEL_API_KEY`
- `STEP_API_KEY`
- `VOLCENGINE_API_KEY`
- `XIAOMI_API_KEY`
2. 先跑已经有模板的 10 个 provider
- 先补齐模板内的 official 路线
- 再扩厂商模板
3. 优先顺序建议
- Qwen 官方
- Kimi 官方
- GLM 官方
- Step 官方
- DeepSeek 官方别名 / auth profile 收口后复验
- MiniMax 官方复验(换一把非限流 key
4. 第二梯队扩模板
- 腾讯混元
- 豆包 / 火山方舟
- 百川
- Yi
- 小米 MiMo
## H. 当前最短闭环
如果你要最快把这份矩阵往前推进一格,最有效的不是继续改代码,而是:
1. 给我 `DASHSCOPE_API_KEY`
- 我先把 `qwen-official` 跑成第一条 Qwen 官方 live artifact
2. 给我 `MOONSHOT_API_KEY``ZHIPU_API_KEY`
- 我可以继续把 Kimi / GLM 官方路线逐个跑出来
3. 对 MiniMax 官方
- 当前不需要改模板
- 只需要换一把有真实 completion 配额的 key 再复验
4. 对 DeepSeek 官方
- 不需要再证明 gateway completion 可用
- 优先修正 upstream model alias / account probe 语义,并补本机 OpenClaw provider/auth profile 后再做最后一跳验收
## I. 一句话结论
当前仓库已经进入:
- **“官方 provider 模板成批就绪 + 两条高频中转线路已完成 remote43 latest 验收”** 阶段
但还没有进入:
- **“国内主流官方模型已逐个 live 验收通过,且本机 OpenClaw 全部可直接消费”** 阶段
剩余主阻断是:
1. 官方 key 不齐
2. 个别官方 key 有真实 quota / rate-limit 限制
3. DeepSeek 官方 alias/probe 语义仍需用 fresh remote43 artifact 再落一次真证据
4. 官方 key 与个别官方 quota / rate-limit 仍会阻断其他 provider