Buu 如何给 AxonHub 的上游 providers / groups 排序
Decision（决策）
Buu 给 AxonHub 里的上游 providers / groups 排序时，采用的是综合权衡，不按成功率单一排序。
Context（背景）
Buu 同时会使用很多文本、图片、视频模型渠道。
这些渠道的现实差异并不只体现在“能不能成功”，还包括：
- 价格高低
- 是否有免费额度或补贴空间
- 稳定性波动
- 是否适合当前任务类型
因此，fallback 链路的顺序本身就是一种成本—稳定性折中，而不是单纯的可用率排名。
Criteria（判断标准）
当前排序至少会综合考虑：
- 真实成本，而不是表面标价
- 免费额度、赠送额度、活动补贴等实际可利用空间
- 稳定性与失败概率
- 对当前任务的适配度
- 是否值得放在前面承担主流量
- 是否更适合放在后面承担兜底流量
Facts（事实）
- Buu 明确说明，自己不是按“谁成功更多就排前面”的思路排序。
- Buu 会把更便宜、或有免费额度的 providers / groups 放得更靠前。
- Buu 会把更稳但更贵的 providers / groups 放得更靠后，作为 fallback。
- 这种判断不是只针对文本模型，而是会横跨文本、图像、视频模型。
- AxonHub 的多上游逻辑模型名 + fallback 机制，正好允许这种现实排序落地。
Interpretation（解释）
这意味着 fallback 链路顺序不能被简单理解成“质量梯队”或“成功率梯队”。
它更接近一种现实运营顺序：
- 前面承接更便宜、更有额度优势、但可能不够稳的流量
- 后面承接更稳、更贵、但成本更高的兜底流量
所以，当某个后置 provider 最近更成功，并不自动意味着它应该被移到最前面。
Current Rule（当前规则）
- 排序时先看综合成本与额度条件，再结合稳定性做平衡。
- 成功率只是一个维度，不是唯一维度。
- 便宜 / 免费额度更好的 providers / groups 可以故意放前面。
- 更稳但更贵的 providers / groups 可以故意放后面做 fallback。
- 分析当前链路时，不应擅自把“后置 provider 最近成功”解释成“排序错了”。
Exceptions（例外）
- 如果某个 provider / group 已经差到几乎无法承接任何有效请求，即使它便宜，也不应继续放在前面。
- 如果某条业务对稳定性要求远高于成本，排序可以临时向“更稳优先”倾斜。
- 如果某个免费额度已经耗尽，相关排序判断需要立刻重算。
Review Trigger（复查触发条件）
出现以下情况时，应重新审视排序：
- 价格、倍率、充值汇率、免费额度发生变化
- 某个 group 的稳定性显著恶化或显著改善
- 某类任务的优先目标发生变化，例如从省钱转向稳产出
- 当前排序导致整体成功率或实际成本明显偏离预期