后台资源与操作顺序

本页从运维者视角说明后台对象怎样配合。重点不是字段定义，而是先建什么、后建什么、怎样避免把未验证配置直接暴露给用户。

资源依赖顺序

系统设置 / 价格
       ↓
Proxy（可选） → Account
                    ↓
Channel（可选映射）
                    ↓
                  Group
                    ↓
User / Subscription / Balance
                    ↓
               Sub2API Key

推荐创建顺序：

1. 确认系统域名、价格、注册和支付开关。
2. 如需固定出口，先创建并测试 Proxy。
3. 创建 Account，完成连接测试和模型同步。
4. 创建同平台测试 Group，把账号加入测试池。
5. 创建测试用户和 Sub2API Key。
6. 验证请求、用量和费用。
7. 再创建或接入生产 Group。

Group 是运维边界

Group 不只是账号标签。它同时承担：

• 用户可见的服务产品或权益边界。
• API Key 绑定的路由边界。
• 平台协议边界。
• 账号池与模型可用范围。
• 倍率、订阅、RPM 和部分兼容策略。

建议按“协议 + 供应商/质量 + 计费”拆分：

anthropic-official-prod
anthropic-relay-standard
openai-responses-premium
openai-compatible-economy
openai-oauth-codex
gemini-aistudio-prod

不要把 OpenAI API Key、Codex OAuth、第三方 relay 和不同价格来源全部放进一个无法解释的大池。

测试环境不一定要单独部署

如果暂时只有一套 Sub2API，可以用资源隔离实现最小测试环境：

• 测试 Group 只授权管理员测试用户。
• 测试 Key 设置较低 quota。
• 新 Account 只加入测试 Group。
• 名称明确带 test、canary 或供应商标识。
• 验证后再把账号加入生产 Group。

这不能代替数据库迁移的独立预发布环境，但足以降低日常账号和模型配置变更风险。

用户与 Sub2API Key

运维人员要区分三种凭证：

凭证	谁使用	用途
管理后台 JWT	管理员浏览器	管理控制面
上游 API Key/OAuth	Sub2API 服务端	调用上游，不应发给用户
Sub2API Key	客户端/最终用户	调用 Sub2API 网关

用户入场流程：

1. 创建或审核用户。
2. 设置余额、订阅或平台配额。
3. 授权可使用的 Group。
4. 创建 Sub2API Key 并绑定正确 Group。
5. 设置 Key 的 quota、有效期和必要的 IP 限制。
6. 用该 Key 实际请求 /v1/models 和目标模型。

用户请求失败时，不要只检查余额。还要检查 Key 状态、Key 绑定分组、用户对分组的授权、订阅有效性以及平台配额。

Account 上线门槛

一个账号进入生产池前至少满足：

• 凭证来源和负责人已记录。
• Base URL/Proxy 已验证。
• 账号连接测试通过。
• 可用模型或模型映射已确认。
• 非流式和流式请求通过。
• usage 能被解析，计费模型存在价格。
• 并发、优先级、倍率和到期时间已填写。
• 故障时如何下线、如何轮换凭证已有方案。

账号的凭证选择见上游账号池运维。

Channel 什么时候需要

Channel 适合表达可复用的模型路由和计费映射，不要为了“看起来完整”而无条件增加一层。

需要 Channel 的常见情况：

• 对外模型名与上游模型名不同。
• 多个账号共享一套模型映射。
• billing model 不能直接等于请求模型或上游模型。
• 需要明确限制某类模型只走特定来源。

只做单一平台、单一账号的验证时，可以先使用 Group + Account，确认基本链路后再引入复杂映射。

删除与停用的区别

操作	适用场景	注意事项
schedulable=false	临时摘流、维护、灰度下线	保留配置和历史，优先使用
状态设为 inactive/disabled	明确停止使用	先确认没有生产依赖
从 Group 移除	只停止某个产品池使用	账号可能仍被其他 Group 使用
删除	凭证已撤销且无需继续操作	历史用量通常仍保留关联信息

生产下线顺序应是“停止调度 → 等待活跃请求 → 从生产 Group 移除 → 撤销上游凭证 → 删除或归档”。

配置完成后的验收

不要以“后台保存成功”为验收标准。至少执行：

GET /v1/models
一次非流式请求
一次流式请求
一次目标工具/图片/特殊能力请求（如业务需要）
检查 Usage Log
检查用户扣费与账号成本

同时记录 Request ID，确保运维看板能从客户端请求定位到 user、API Key、Group、Account、上游 endpoint 和模型映射。