niuniu/sub2api-cn-relay-manager

Fork 0

Files

phamnazage-jpg bcfc08568c docs: sync deepseek official remote43 validation truth

2026-05-27 07:55:49 +08:00

17 KiB

Raw Blame History

Provider Validation Matrix

日期：2026-05-26

目的

这份文档用于回答 4 个问题：

当前仓库已经内置了哪些官方 provider 模板
哪些 provider 已经具备本机可用的官方 key
哪些 provider 已经完成了真实 fresh-host live 验收
哪些 provider 仍然卡在缺 key、缺模板或上游 quota / rate-limit

它不是 gate 文档，也不替代 REAL_HOST_ACCEPTANCE_RUNBOOK.md。

分工如下：

docs/SOURCE_OF_TRUTH.md
- 回答当前项目整体 gate
本文
- 回答 provider 维度的模板覆盖度、凭据覆盖度、live 验收覆盖度
docs/PROVIDER_ONBOARDING_PLAYBOOK.md
- 回答后续如何继续补模板和验收

阅读结论

先说结论：

首批 10 个官方 provider 模板已经落库，且 pack 已继续补入高频中转模板
- 当前 openai-cn-pack 已内置 Qwen、DeepSeek、GLM、Kimi、MiniMax、Step 的 10 个官方模板
- 同时已补入 openai-zhongzhuan 与 minimax-53hk 两条高频中转模板
还不能宣称“国内 10 大模型都已逐个真实验证通过”
- 当前最大的阻断不是控制面代码，而是 官方 key 不齐
- 其次是部分官方 key 即便存在，也会在真实 completion 阶段命中 429 quota/rate-limit
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 仍有偏差
Qwen / GLM / Step / Kimi 官方路线当前仍没有本机可用官方 key 证据
- 所以它们目前只能算“模板已就绪，未完成 live 验收”
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

只能说明什么

它们只能说明：

本机至少存在 MiniMax / Kimi 中转 / DeepSeek 中转路线
当前 DeepSeek 官方 live artifact 也说明：至少存在一把可跑到 upstream /chat/completions=200 的官方 DeepSeek key
但这不等于 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

关键结论：

host /v1/models 已通过，且命中预期模型
upstream /models 也能返回预期官方模型集合
host /v1/chat/completions 返回 429
upstream /chat/completions 同样返回 429

所以根因不是控制面导入失败，而是：

当前官方 MiniMax key 命中 upstream 真实限流/额度问题

证据：

补充说明：

同一批次中还暴露了 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

关键结论：

host /v1/models 已通过，且命中 deepseek-chat
host /v1/chat/completions 已通过，completion_status=200
upstream /chat/completions 已通过，upstream_chat_status=200
但 upstream /models 返回的是 deepseek-v4-flash / deepseek-v4-pro，不是 manifest 里的 deepseek-chat
batch detail 里 account probe 仍记录 API returned 404:，导致该批次最终落成 partially_succeeded / degraded

所以当前真实状态不是 BLOCKED_BY_KEY，而是：

数据面已经通
provider 口径仍需继续校准 upstream model alias / account probe 语义
当前状态：PARTIAL

证据：

D1. 已完成的中转 live 验收

OpenAI 中转

provider：openai-zhongzhuan
artifact：
- artifacts/real-host-acceptance/20260526_155548_remote43_openai_zhongzhuan_multi_model_rootprep

关键结论：

batch_status=succeeded
provider_status=active
gateway /v1/models 返回 gpt-5.4 / gpt-5.4-mini
gateway /v1/chat/completions 返回 200
upstream /models 命中预期模型集合
upstream /chat/completions 当前为 502，但不影响 host 主链路已经 ready

MiniMax 53hk 中转

provider：minimax-53hk
artifact：
- artifacts/real-host-acceptance/20260526_155705_remote43_minimax53hk_multi_model_rootprep

关键结论：

batch_status=succeeded
provider_status=active
gateway /v1/models 返回 MiniMax-M2.5-highspeed / MiniMax-M2.7-highspeed
gateway /v1/chat/completions 返回 200
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 + 小米等”逐个真实收口，建议按下面顺序继续：

先补官方 key
- DASHSCOPE_API_KEY
- MOONSHOT_API_KEY
- ZHIPU_API_KEY 或 BIGMODEL_API_KEY
- STEP_API_KEY
- VOLCENGINE_API_KEY
- XIAOMI_API_KEY
先跑已经有模板的 10 个 provider
- 先补齐模板内的 official 路线
- 再扩厂商模板
优先顺序建议
- Qwen 官方
- Kimi 官方
- GLM 官方
- Step 官方
- DeepSeek 官方别名 / auth profile 收口后复验
- MiniMax 官方复验（换一把非限流 key）
第二梯队扩模板
- 腾讯混元
- 豆包 / 火山方舟
- 百川
- Yi
- 小米 MiMo

H. 当前最短闭环

如果你要最快把这份矩阵往前推进一格，最有效的不是继续改代码，而是：

给我 DASHSCOPE_API_KEY
- 我先把 qwen-official 跑成第一条 Qwen 官方 live artifact
给我 MOONSHOT_API_KEY 与 ZHIPU_API_KEY
- 我可以继续把 Kimi / GLM 官方路线逐个跑出来
对 MiniMax 官方
- 当前不需要改模板
- 只需要换一把有真实 completion 配额的 key 再复验
对 DeepSeek 官方
- 不需要再证明 gateway completion 可用
- 优先修正 upstream model alias / account probe 语义，并补本机 OpenClaw provider/auth profile 后再做最后一跳验收

I. 一句话结论

当前仓库已经进入：

“官方 provider 模板成批就绪 + 两条高频中转线路已完成 remote43 latest 验收” 阶段

但还没有进入：

“国内主流官方模型已逐个 live 验收通过，且本机 OpenClaw 全部可直接消费” 阶段

剩余主阻断是：

官方 key 不齐
个别官方 key 有真实 quota / rate-limit 限制
DeepSeek 官方 alias/probe 语义仍需用 fresh remote43 artifact 再落一次真证据
官方 key 与个别官方 quota / rate-limit 仍会阻断其他 provider

17 KiB Raw Blame History Unescape Escape

Provider Validation Matrix

目的

阅读结论

统计口径

状态定义

A. 已内置的 10 个官方 provider 模板

B. 官方模板外的优先扩展厂商

B1. 已落地的中转 / 非官方高频模板

C. 当前已确认的本机凭据盘点

已确认存在的厂商环境变量

只能说明什么

当前缺失的官方 key 信号

D. 已完成的 official live 验收

MiniMax 官方

DeepSeek Chat 官方

D1. 已完成的中转 live 验收

OpenAI 中转

MiniMax 53hk 中转

E. 为什么 Qwen 还没法“直接宣称已验证通过”

F. OpenClaw 本地验收映射说明

G. 推荐执行顺序

H. 当前最短闭环

I. 一句话结论

17 KiB

Raw Blame History