# 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