配置示例

以下示例展示如何按业务目标选择配置模式。示例中的模型名称仅用于说明，应替换为你已检测到的模型资源。

固定模型：测试与结果一致性

适合模型评测、提示词测试或必须固定版本的任务。

配置名称：support-test
模式：固定模型
模型资源：Qwen / qwen-plus
对外模型名称：support-test
RPM：20

特点：请求始终进入同一模型；上游失败时直接返回错误，便于发现问题。

适合客服、Agent 或不能因单一厂商故障而中断的服务。

配置名称：support-prod
模式：故障转移
候选顺序：
  1. Qwen / qwen-plus
  2. DeepSeek / deepseek-chat
  3. OpenAI / gpt-4o-mini
对外模型名称：support-prod

顺序代表优先级，不代表每次轮询。上线前应分别验证每个候选的请求格式、工具能力和输出质量。

适合请求差异较大、希望由路由模型在候选模型中选择执行模型的应用。

配置名称：assistant-router
模式：AI 智能调度
路由模型：默认通用模型
候选模型：
  1. 低延迟模型
  2. 默认通用模型
  3. 推理或高能力模型
对外模型名称：assistant-router

AI 智能调度会先让指定路由模型判断请求，再从候选模型中选择执行模型。它不是质量保证，重要业务应先用真实请求集测试。

自动调度已弃用并停用，不再建议或允许用于新配置。

建议创建两套配置和 Access Key：

环境	配置	Access Key	建议
测试	`assistant-test`	独立 Key	固定模型、较低 RPM
生产	`assistant-prod`	独立 Key	故障转移、已验证候选

不要只通过项目名称区分环境，也不要让测试客户端持有生产 Key。

修改候选模型、顺序或输出后，现有 Access Key 会继续生效。先在低风险时段修改，并立即发送最小请求验证。修改对外模型名称会影响所有客户端的 model 字段，应提前迁移。