把模型选择收进一份配置，而不是写死在业务代码里

把模型选择从业务代码里抽出来

模型名不该出现在业务逻辑里。哪一层调用哪个模型、失败了走不走备选，属于会随时间变化的运维决策；写死在代码里，意味着每次调整都要改业务、过评审、重新发版。

ModelRelay Hub 的做法是把这些决策收进一份服务端配置：业务代码只引用任务名（如 summarize、code_review），主模型、备选和是否允许降级由配置决定；模型名、分组和 Base URL 集中维护，具体可用模型以当前 Key 请求 /v1/models 的返回为准，而不是散落在各处的常量。

回退必须显式

统一配置示例

下面是一份 yaml 形式的路由配置示例：业务代码引用任务名，主模型、备选和是否允许降级都集中在这里维护。模型 ID 请替换为 /v1/models 实际返回的值。

# ModelRelay Hub 路由配置示例（模型 ID 以 /v1/models 实际返回为准）
base_url: https://modelrelayhub.top/v1
auth: Bearer ${MODELRELAY_API_KEY}

routes:
  summarize:              # 短摘要，可重跑
    primary:  <轻量通用模型>
    fallback: <同档备用模型>
    allow_degrade: true

  classify:               # 分类打标，结果可校验
    primary:  <结构化输出模型>
    fallback: <备用结构化模型>
    allow_degrade: true

  code_review:            # 代码审查，需人工复核
    primary:  <代码能力模型>
    fallback: <次选代码模型>
    allow_degrade: false

  billing_reply:          # 对外交付 / 计费相关，禁止静默降级
    primary:  <指定主模型>
    fallback: null
    allow_degrade: false  # 失败时显式报错并记录 request id

额度与计费

符合最新活动资格的用户，累计前 ¥50 实付享 1:1 API 额度赠送，最多赠送 $50；超过部分及达到上限后的充值不再赠送。资格与口径以本站公告和后台核验为准。