Buu 当前如何选择个人 AI Gateway
Decision（决策）
当前优先把 AxonHub 作为个人长期 AI Gateway 的主尝试方向。
但实际策略不是“一次性彻底切换”，而是：
先围绕云雾图片 / 视频这条真实需求验证 AxonHub，确认能承接后，再逐步替换 CCH。
Context（背景）
Buu 现在高频使用 Hermes，也已经长期在 VPS 上使用 CCH。
问题不在于“有没有网关”，而在于：
- 需要一个更长期、统一的个人 AI Gateway
- 需要兼顾文本、图片、视频等不同类型接口
- 需要处理国内中转站常见的分组、倍率、按次收费、稳定性波动
- 需要在同一个逻辑模型名下，把多个上游 provider 做成 fallback 链路
当前最着急的现实需求，是尽快通过云雾生成图片，而不是无限延长选型讨论。
Criteria（判断标准）
当前这轮网关选择，至少要满足：
- 能支持统一逻辑模型名，对客户端保持稳定请求方式
- 能把多个上游 provider 放在同一个逻辑模型后面做 fallback
- 能表达同一模型在不同 provider / group 下的差异
- 能承接云雾这类 Gemini 原生图片接口与视频接口
- 能适配国内中转站常见的分组与计费现实
- 不把 Buu 拖进长期空转的“选型地狱”
Facts（事实）
- Buu 当前的目标不是把 New API 当最终网关，而是把很多基于 New API 的上游站点接入自己的统一网关。
- Buu 的实际使用方式是：客户端始终请求同一个逻辑模型名，网关内部再决定真实上游模型名与提供商。
- CCH 当前已有可视化的决策链 / 决策列能力，能展示候选、优先级、健康过滤、fallback 过程。
- 云雾当前是重要现实场景，因为它在 Nano Banana 2 上有极强的真实成本优势，但稳定性和速率限制存在不确定性。
- AxonHub 已具备：图片、视频、Gemini API、OpenAI 风格视频接口、按次收费（flat_fee）等关键能力。
- LiteLLM 很强，但更偏通用代理；在“国内中转站分组 / 按次收费 / 现实计费表达”这件事上，不一定比 AxonHub 更贴合。
Interpretation（解释）
Buu 真正需要的不是“世界上最通用的网关”，而是“最贴自己现实用法的个人总网关”。
这里最关键的，不是抽象功能表，而是：
- 是否支持逻辑模型别名
- 是否支持多上游 fallback
- 是否能把便宜但不稳的上游放在前面，把更稳更贵的上游放在后面
- 是否能把国内 provider 常见的 group 差异表达清楚
从这个角度看，AxonHub 当前更接近 Buu 的真实需要。
Current Rule（当前规则）
- 客户端层优先使用稳定的逻辑模型名，而不是直接暴露上游真实模型名。
- 网关内部允许多个 provider 承接同一个逻辑模型，并通过优先级、健康状态、连接情况和 fallback 选择实际上游。
- 对同一个 provider 的同一个模型，优先按 group 区分，而不是把内部命名拆得过于复杂。
- 当前主尝试方向定为 AxonHub。
- 当前迁移方式定为“逐步迁移”，而不是一次性替换所有现有链路。
- 当前最优先验证的不是全文本能力，而是云雾图片 / 视频这条真实链路能否在 AxonHub 里跑通。
Exceptions（例外）
- 如果某个特殊上游接口在 AxonHub 中明显接不顺，而 LiteLLM 可以零摩擦接通，则可局部保留 LiteLLM 作为补充方案。
- 如果后续发现 AxonHub 在 fallback、group 表达或实际维护体验上明显不达标，这个决定需要重新评估。
- 如果未来要真正开放给多人使用，网关选择标准可能会从“个人适配性”转向“多用户管理能力”。
Review Trigger（复查触发条件）
出现以下情况时，应重新审视这条决策：
- 云雾图片 / 视频在 AxonHub 中实际无法稳定接通
- fallback 逻辑无法达到 Buu 预期
- group 维度的定价与路由表达明显别扭
- LiteLLM 或其他候选在真实场景验证中明显更顺
- Buu 的使用重点从个人统一网关，转向小规模多用户服务